Open OxygenCobalt opened 1 year ago
More stuff about this:
intersting. the only thing is, upon rewriting big things like this or custom metadata parser (you already did), i would consider doing a small amount of extra work and releasing these systems as a library. it's very cool that you got to a point where the metadata parser can fully replace mediastore for metadata and is wayy more sensible & reliable, but unless you publish it as a library, other devs making something that tries to read music metadata on android will have to either use MediaStore, extract the system from this app and modify it make sure it somehow works + they lose all automatic bug fixes by doing this, or re-implement it themselves.
for example, musicolet has a pretty good metadata parser+editor implementation but it's not open source and it's not published as a library, so no one else can use it.
intersting. the only thing is, upon rewriting big things like this or custom metadata parser (you already did), i would consider doing a small amount of extra work and releasing these systems as a library.
I am thinking about trying to split off the module, but it's really tied up with the rest of this app and would require a lot of internal reworks.
Another thing this may enable: LRC file support that plays along with scoped storage. Other reasons why I don't want lyrics still apply though.
Bad news: According to https://github.com/google/ExoPlayer/issues/10706, duration parsing is actually not supported by ExoPlayer and is unlikely to be "properly" supported even if implemented. I would likely have to give up and bundle a tagging library (like TagLib because it seems pretty quick) if I were to do this. FFMpeg may also be considered, but that would require obscene amounts of work on my end vendoring the extension, patching in multi-value tags, and figuring out how to plug it into the extractor framework. Not really sure where to go from here.
Okay, maybe it's not entirely impossible. Again, just requires more patches, and there will remain edge cases where I am forced to fall back to android's metadata (example: VBR MP3 with no Xing header).
More information I've learned about this:
I'm not sure if this is relevant, but i've found an old opensource app called Camera Roll which has an option in its settings to bypass MediaStore by using something they call MediaRetriever… The app is old (2019) but maybe it can be somewhat salvaged to achieve our goal ?
After some more research, i've come across this repository for something called MediaRetriver, from around the same time, and which seems to achieve kind of the same goal: https://github.com/jiajunhui/MediaRetriever
Welp, would you look at this: SAF Media Scanner witha few edits here and there it should be pretty usable.
I'm not sure if this is relevant, but i've found an old opensource app called Camera Roll which has an option in its settings to bypass MediaStore by using something they call MediaRetriever… The app is old (2019) but maybe it can be somewhat salvaged to achieve our goal ?
After some more research, i've come across this repository for something called MediaRetriver, from around the same time, and which seems to achieve kind of the same goal: https://github.com/jiajunhui/MediaRetriever
Not even remotely similar, actually. Your camera app is referring to MediaMetadataRetriever
, which is android's metadata extractor and is largely terrible. I would be using it for this, but only as a fallback. This library is just a standard component library, and a super old one at that.
Welp, would you look at this: SAF Media Scanner witha few edits here and there it should be pretty usable.
I don't use third-party libraries. That project in particular uses a completely different database schema, music interpretation, and tagging system. Loading with SAF is actually dead simple, I got ChatGPT to write half of it a few months back and I could write the rest in an afternoon. The issue is the down-stream impacts that I have to mitigate, and the fact that this is super low priority since MediaStore works okay for now. I need to reach playlist feature parity and gapless playback before I focus on this in any capacity.
Yeah, as i thought, most of it ended up being irrelevant 😄 thanks for taking the time to answer anyway. Since i saw this issue with a good bunch of comments from you, and knowing this was something that some other audio players would have wanted, i got curious and figured i could do some research on my own. Well ! should have researched harder.
That's fine. This isn't really a "How do I do it" problem as much as it is "How do I integrate it" problem, so researching it won't yield too much.
Planning to do this alongside the now-prioritized #327 in a 3.5.0 or 4.0.0 release.
Bypass
MediaStore
entirely and just iterate through a Document TreeUri
provided by the user.Related links: 1 2 3 4
More or less, the new user flow would be something like:
MediaStore
. Still uses ExoPlayer first, followed by the system metadata extractor. Cache system remains.More or less, this addition would really just make Auxio create it's own, more sensible variant of
MediaStore
that should have maximum device compatibility.Benefits:
MediaStore
database.MediaStore
, even in stupid scoped storage edge cases like SD Cards.Drawbacks:
MediaStore
with the user directories.I actually think this is what the big proprietary music players like Musicolet and Poweramp do. Seems vaguely possible if I continue thinking about it. Definitely non-priority right now since
MediaStore
currently works ok. Will probably group with the big service rework in perhaps another major version.