Purpose of release-level (not release group) matching?

[RollingStar]

Quick refresher:

1. A "release group" is a group of all possible versions of a single "album". example https://musicbrainz.org/release-group/72d15666-99a7-321e-b1f3-a3f8c09dff9f
2. A "release" is one single release of a single album. example https://musicbrainz.org/release/c98efea8-15fa-4919-812c-ec5dbfcedfcf

Beets was designed with the idea of matching every track to a specific release. We're now 17 years out from the original conception of beets. So, is anyone doing anything cool with this core design philosophy?

My take on it:

... take the manual tagging and throw it into the sun. The return on time investment is not there unless you are really particular about knowing whether you have the 1984 or 1992 master of The Wall. We should focus on matching release groups, not releases. The false matches happen more on popular tracks, which is what normal people are matching most of the time. Let's design for a future where we save all possible data about an imported track, and a user can fine-tune the match later. This goes hand in hand with ever-wilder ML [machine learning]. Beets is ripe for someone with <2 years ML experience to come in and blow our minds. As Adrian said above, the database is the source of truth. We can update it at any time. And a user should only do that when they have a use case that requires it.

Pretty much every popular streamer only has one or two releases of an album. They can change name or mastering silently in the backend and the user might not even notice. Clearly a large % of streaming users don't care about the release, only the release group (and arguably, they just care about the track, not even the release group). I'd call myself a music enthusiast and I only actively own, maintain, and care about having multiple masterings of a very small number of albums. These are my all-time favorite albums/artists, or ones with notably different mastering. Things like Thriller, The Beatles, and Floral Shoppe with its 3 releases to cover every track on it. Even if I was a "prosumer" level of music owner with 200 albums, it would come out to like 20=10% of my library. Yet Beets is implicitly designed around serving this 10% use case at the expense of confusion and complexity for the other 90%.

I can think of a few use cases:

• physical music cataloguing, searching, displaying
• disambiguate multiple releases in the same group (I think most people only collect multiple releases for the small % of albums they adore)
• "Do I have the good version?" - sometimes albums are reissued with less tracks, or lyrics changed, or better or worse mastering. If we think about automated sources of music (Bandcamp and spotify) maybe we would think about "hey user, do you want to upgrade your crappy vinyl needledrop with the new master that just dropped?".
• duplicate handling. "You have the vinyl and you just imported a CD, do you want to remove the vinyl?"
• analytics on various music labels (do Universal records have higher dynamic range than Sony?)

[michaelkrieger]

See #5355 .

I am debating generating a plugin that strips the track-and-release specific tags from the tags, as for that exact reason, I don't want to incorrectly assert that this is the ABC-12345 catalogue number release of the album when I have no idea where the source came from.

It still likely needs to choose a release for the purposes of pulling track names/numbers/credits/etc as that's where the data is in MusicBrainz, but then writing this with authority in the tracks is of concern to me.

Likely, this being pedantic is a waste of time, but it's a reality.

A plugin that, after choosing the release, asks "do you know the source of this release and you know it's _____" and if yes continues, and if no, will negate the release specific tags ('asin!' 'isrc!' 'barcode!' 'catalognumber!' 'label!' 'media!' 'releasecountry!' 'releasestatus!' 'mb_albumid!' 'mb_workid!' 'mb_trackid!' 'mb_releasetrackid!' 'mb_releasegroupid!') in the file.