MusicBrainz ID support

[OxygenCobalt]

This feature is about adding MusicBrainz ID support to Auxio.

Normally, Auxio tries to generate a unique "hash" for a music item by compositing hashes for the title, album name, artist name, track, etc. into a single ID that should be unique. These are then used when saving the playback state, grouping up albums and artists, and eventually when creating playlists. However, there are still edge-cases that would result in different artists being treated as one, or a hash collision occurring and causing unexpected behavior. Making the hashing process be derived from the MusicBrainz ID would be much better, as they are guaranteed to be unique.

The current plan is this:

1. Wait for Direct metadata parsing #128 to graduate from an experimental setting to Auxio's default and unchangeable behavior. I cannot implement this beforehand, as hashes must stay relatively stable across toggles of the current setting.
2. If a MusicBrainz ID is present, only use it's hash for saving and grouping. Otherwise, default to the typical hashing behavior.

Nothing like scrobbling will be implemented from ID support. I don't like scrobbling.

[OxygenCobalt]

Quick question @animaldaydream. Is it possible for well-done libraries to have a mix of files with ID tags and without ID tags?

I'm going to migrate existing music hashes to MD5, which is stronger than a polynomial hash and allows me to represent my hashes as the same UUID datatype as a MusicBrainz ID. However, I'm somewhat worried that I could create issues if the hashed ID of one song collides with the tagged ID of another. This would only happen if not every file in a library has the proper ID tags.

I'd imagine this isn't the case, but I can never be sure. I may still mitigate it anyway as the cost is likely minimal.

[KraXen72]

Quick question @animaldaydream. Is it possible for well-done libraries to have a mix of files with ID tags and without ID tags?

I'm going to migrate existing music hashes to MD5, which is stronger than a polynomial hash and allows me to represent my hashes as the same UUID datatype as a MusicBrainz ID. However, I'm somewhat worried that I could create issues if the hashed ID of one song collides with the tagged ID of another. This would only happen if not every file in a library has the proper ID tags.

I'd imagine this isn't the case, but I can never be sure. I may still mitigate it anyway as the cost is likely minimal.

for my library, this could be a problem. i have 2 music folders, one primary where 99.9% of stuff is tagged and has an album cover, and then another where theres just a bunch of low quality, incorrectly tagged stuff i used to listen to in 2012-2016 ripped from youtube, but i still keep it because occasionally with friends you wanna play some 2014 bangers or so.

so this problem of ID's colliding could occur. i guess you could add some salt to the hashes to prevent this, (not sure if this would solve the problem as i don't understand where the salt is added in a hash 100%, just have a general idea)

[OxygenCobalt]

Okay, I was justified at least. MusicBrainz ID's aren't hashed though, they are just used as-is, so salting isn't exactly reasonable. I think instead I'll just have a "tag" in my internal representation that signifies if these IDs are Auxio or MusicBrainz. Something like:

• axo:uuid is an Auxio ID
• mbz:uuid is a MusicBrainz ID

[OxygenCobalt]

Done. Should arrive in 3.0.0.

[alanorth]

I tag all my music with MusicBrainz Picard and or beets so 99% of my music has these tags. Will be interesting to see how this works. Current dev branch has a build error so can't try it yet.

[OxygenCobalt]

@alanorth

MusicBrainz IDs will only really extend to grouping (If you have two artists with the same name but different MBIDs, they will be different artists) and persistence (i.e the saved playback state).

Current dev branch has a build error so can't try it yet.

Have you tried running prebuild.py again? I have to bundle a patched ExoPlayer component ATM so I can support ID3v2.4 multi-value.

[alanorth]

@OxygenCobalt yeah it's actually a lint error at the end of gradle aR, not a build error. I still get an APK in ./app/release/app-release.apk.

[animaldaydream]

I tag all my music with MusicBrainz Picard and or beets so 99% of my music has these tags.

Interesting indeed. Picard will make multiple values for the MBID fields but beets will discard all but the first one. It will do the same for every single tag, too.

If you want I can share a Picard script that'll tag your files with standard artist names and multi-valued tags, as Picard only does the latter without standard names.

But you'll have to stop beets from touching the tags. I'm sorry about that but there's not enough resources to fix that issue it seems, and I'm not a dev…