-
-
Notifications
You must be signed in to change notification settings - Fork 150
Why Are These Features Missing?
One of the reasons I built Auxio was out of frustration with other FOSS android music players, which had too many features, frustrating UI/UX flaws, or both. Thus, I (OxygenCobalt) am incredibly apprehensive towards certain functionality that I consider to be far too detrimental to the app experience to be implemented.
As a result, I only tend to work on features that:
- Benefit everyone's use, including myself.
- Are in line with Auxio's purpose as a music player.
- Will not be an unstable technical nightmare if implemented.
The following is a list of some of the most commonly requested features that will not be implemented. A full list can be found here.
Lyrics, while a popular feature, will never be implemented for the following reasons:
- LRC files cannot be read due to "Scoped Storage" security restrictions put in place after Android 10. Thus, I would be forced to implement alternative lyrics sources, such as:
- Deriving it from the file metadata itself, such as through the
SYLTID3v2 frame and some made up Vorbis Comment specification. This is extremely clunky and will not work for most libraries. - Fetching it from an external source. This violates the "No Internet Connectivity" promise I have made regarding this app.
- Deriving it from the file metadata itself, such as through the
- Modeling lyrics is extremely difficult, as lyrics would have to be loaded on-the-fly and kept in-sync with the internal player. This would likely cause a variety of hard-to-fix issues.
- Implementing lyrics in the user interface is extremely difficult. Not only does it have to be crammed into an (already quite full) "Now Playing" user interface, it also must be easily accessible and not overload the app's performance to the point of unusability.
- Most of my music is instrumental, so lyrics don't really apply. If I am curious about lyrics, I tend to research them and then memorize them through enough listens.
Programs should do one thing and do it well. A Tag Editor is an adjacent, yet much different program than a music player. Trying to graft on a Tag Editor to Auxio would simply take away time to focus on music playback and not even result in a good tag editor. In line with this, I've thought about making a kind of companion tag editor app to Auxio, but I haven't found much motivation for such given that desktop tag editors work just fine, not to mention the dismal state of editing the filesystem on modern android.
I would personally recommend Beets, Picard, kid3, or Ex Falso for editing tags. There's also Automatag if you have to edit tags on your phone.
Not only do I not get any use from scrobbling, last.fm is a non-free network service that I do not want this app to connect to in the first place. In general, I don't want to implement any connectivity features unless Auxio becomes a music streaming client, which is unlikely as it stands.
Similarly to the Tag Editor, this is not implemented due to the needs of a folder-based music player and tag-based music player largely being opposed to each other. Auxio has always been built as a tag-based music player with a very strict metadata support in order to create a good user experience. Meanwhile, folder-based music players are far more liberal with how music is organized, with an increased amount of edge cases to handle and a much different user interface. If I were to support both of these models, it would simply result in an inadequate experience for both.
Ever since Android 10 trying to do something as basic as delete a file has grown so exponentially complicated and bug-filled that it's more or less impossible to implement in a sane manner. I'd recommend using a file manager like Material Files.
This isn't added because it's a potential slippery slope. Adding a toggle between two styles results in someone asking for a third, and then a fourth, and then a fifth, and so on. Eventually I would end up with my attention split across 10 radically different UI styles that all don't work well. Instead, I keep my attention focused on making one playback layout as good as possible, resulting in a much better UX overall. This does not rule out customizing parts of the playback view, but even those are kept limited for the reasons outlined prior.
This is for the same reason as alternative playback layouts. As a single developer, it's better to hone in on a single widget layout & theme than split my attention across 10 widgets or countless subtle widget options. Given the convergence of widget styles on Android 12+ in particular, I further restrict the theming to make sure the widget adequately blends in with the rest of the system UI.
Algorithmic recommendations can be neat, but I am also not a tech company with a whole team of AI researchers. Most "For You" pages implemented in FOSS music players simply fake the recommendations through a random number generator. This is absolutely absurd and nothing but a useless screen you skip past to get to the music library you actually want.
Again, the needs of an Equalizer and the needs of Auxio are too different to combine into a single app without both becoming in-adequate. Auxio does have support for external equalizer support, such as through the (highly recommended) Wavelet.
I don't really like listening to music when I go to sleep, as it's usually too active to allow me to relax. I find the nature sounds provided by apps like Noice to be much nicer.
Auxio is not really equipped to play audiobooks and podcasts, and I don't want to add features that accommodate such, given that it would distract from the app's purpose as a music player.
Crossfading actually is impossible with ExoPlayer as it currently stands, as it completely breaks the timeline model (Where does one song end and another start?).
I usually know what I've just added to a library, and what songs I've been playing the most. You can sort by date added, however.