[Feature Request] Smart Crossfade for LOCAL library: BPM/Key-aware transitions (offline metadata, zero real-time DSP)

[YisusPineapple]

👋 Hi! I'm another user who'd love to see this feature. (Echoing the request in #1708 — great idea!)

I've researched how it could integrate with PixelPlayer's current architecture (with AI assistance, as I don't code in Kotlin), and wanted to share some implementation notes that might help:

🗺️ Where it could fit (based on codebase analysis)

• data/model/Song.kt: Add optional bpm: Float?, keyCamelot: String? fields (nullable, like existing genre, bitrate)
• data/preferences/UserPreferencesRepository.kt: Add SMART_MIX_MODE preference using the same DataStore pattern as CROSSFADE_DURATION
• data/service/player/TransitionController.kt: Hook into transition logic to check BPM delta + Camelot compatibility (e.g., 8A → 8A/7A/9A/8B) before falling back to user-set duration
• tools/ (optional): Lightweight analyze_library.py script for offline metadata generation (like existing migration scripts)

⚡ Low-risk design

✅ Reuses existing DualPlayerEngine — no new audio pipeline
✅ Metadata pre-calculated offline → zero CPU during playback
✅ Graceful fallback: auto-reverts to standard crossfade if metadata missing or device constrained
✅ Fully optional toggle — preserves simplicity for users who prefer manual control

🙋 About me

I'm a daily user on low-end hardware (TECNO Spark 20, Android 13). I don't write Kotlin (in fact, I don't even know how to program), but I'm happy to:

• Test early builds on my device
• Provide the Python analysis script or JSON schema if needed

Thanks for considering this — and for building such a polished player! 🙌

[theovilardo]

Hi! I also like this idea but it will be quite hard to run, the app is already pretty bloated with features and BPM analysis on the fly would be very hard to optimize, maybe it can run on powerful devices but mid-range to low will be a problem

[YisusPineapple]

Hi! I also like this idea but it will be quite hard to run, the app is already pretty bloated with features and BPM analysis on the fly would be very hard to optimize, maybe it can run on powerful devices but mid-range to low will be a problem

Thanks for the feedback! 🙌 I completely agree—real-time DSP would be a nightmare for battery and performance on many devices.

That’s why the core of this proposal is to keep it 100% offline-based:

1. Metadata-Driven: The app would only read two small values (BPM/Key) from the local database, just like reading a Title or Genre tag. Zero CPU impact during playback.
2. Flexible Implementation: The analysis could be done via an external tool or a one-time background task (only when charging/WiFi). If the data isn't there, PixelPlayer just uses the standard crossfade.

🎯 A "Low-Impact" Proof of Concept?

To keep it simple, we could start by just defining how the BPM data is stored. I’m currently drafting a minimal JSON schema and a lightweight Python reference script to see how fast and accurate the offline detection is on older hardware (testing on a Dual Core system).

Would you be open to checking out the JSON structure once it's ready? This way we can ensure it fits PixelPlayer’s philosophy before even touching the Android source code.

[theovilardo]

Hi! I also like this idea but it will be quite hard to run, the app is already pretty bloated with features and BPM analysis on the fly would be very hard to optimize, maybe it can run on powerful devices but mid-range to low will be a problem

Thanks for the feedback! 🙌 I completely agree—real-time DSP would be a nightmare for battery and performance on many devices.

That’s why the core of this proposal is to keep it 100% offline-based:

1. Metadata-Driven: The app would only read two small values (BPM/Key) from the local database, just like reading a Title or Genre tag. Zero CPU impact during playback.
2. Flexible Implementation: The analysis could be done via an external tool or a one-time background task (only when charging/WiFi). If the data isn't there, PixelPlayer just uses the standard crossfade.

🎯 A "Low-Impact" Proof of Concept?

To keep it simple, we could start by just defining how the BPM data is stored. I’m currently drafting a minimal JSON schema and a lightweight Python reference script to see how fast and accurate the offline detection is on older hardware (testing on a Dual Core system).

Would you be open to checking out the JSON structure once it's ready? This way we can ensure it fits PixelPlayer’s philosophy before even touching the Android source code.

I get it but what you're talking about here is not a feature but a complete new environment that would need to connect between devices to run. Not to metion latency, If every change in playback needs a network check that will cause other issues as well

[YisusPineapple]

Hi! I also like this idea but it will be quite hard to run, the app is already pretty bloated with features and BPM analysis on the fly would be very hard to optimize, maybe it can run on powerful devices but mid-range to low will be a problem

Thanks for the feedback! 🙌 I completely agree—real-time DSP would be a nightmare for battery and performance on many devices.
That’s why the core of this proposal is to keep it 100% offline-based:

1. Metadata-Driven: The app would only read two small values (BPM/Key) from the local database, just like reading a Title or Genre tag. Zero CPU impact during playback.
2. Flexible Implementation: The analysis could be done via an external tool or a one-time background task (only when charging/WiFi). If the data isn't there, PixelPlayer just uses the standard crossfade.

🎯 A "Low-Impact" Proof of Concept?

To keep it simple, we could start by just defining how the BPM data is stored. I’m currently drafting a minimal JSON schema and a lightweight Python reference script to see how fast and accurate the offline detection is on older hardware (testing on a Dual Core system).
Would you be open to checking out the JSON structure once it's ready? This way we can ensure it fits PixelPlayer’s philosophy before even touching the Android source code.

I get it but what you're talking about here is not a feature but a complete new environment that would need to connect between devices to run. Not to metion latency, If every change in playback needs a network check that will cause other issues as well

Sorry for the confusion, my proposal is actually much simpler and 100% offline:

1. No Network: There is no connection between devices and no cloud sync.
2. Local Metadata: The app just reads a "BPM" value from its local SQLite database (pre-calculated).
3. Zero Latency: Since the data is local, there's no network check during playback.

Think of it as adding a "BPM" tag to the database, just like "Genre" or "Year", and using that number to adjust the crossfade duration.

I've already tested the analysis on a 2011 Dual-Core PC, and it's extremely fast. This would be a "power user" feature with zero impact on performance or connectivity.