A release is not forward-compatible

MusicBrainz
1

Consider the following scenario:

User-1 wants to tag an album. He looks up the disc ID and discovers that user-2 has already entered a release. He checks the provided information and tags his songs (which now have a MUSICBRAINZ_ALBUMID field).

Some time later, user-2 adds additional information (e.g. scans of the booklet). As it turns out, there are multiple versions of the release, let’s say one with a red booklet and the other one with a blue booklet. User-1 happens to have the blue version and user-2 has uploaded scans of the red version.

Now, even though user-1 carefully checked the available information at the time of tagging, the MUSICBRAINZ_ALBUMID does not point to the correct release anymore, simply because user-2 has added additional information.

According to Alternate CD matrix/runout inscriptions: enough for a new release?, even minute details like the mould SID code could potentially be entered as separate releases. In other words, the number of “release splits” depends on the amount of research done. There is always the possibility that some (otherwise identical) limited run from a remote pressing plant is discovered that gets its own release. So, if a user wants his metadata to be correct, he has to periodically check whether the release still matches his version.

An alternative approach, that I would like to hear your opinion on, would be to assign UIDs not to releases but to “features” of release groups (e.g. bar code, catalog number, number of pages in the booklet, matrix runout etc.) and to write that information into tags. That way, once the user has verified a feature, it will never go stale.

Another advantage of this approach would be that the user can be notified about new features of a release group when he does a metadata update: “Hey, since your last update, we discovered that there is a huge mark-up for releases with mastering SID codes that end with a ‘2’. We have thus decided to add a feature ‘Mastering SID code’. You might want to check this.” The user can then decide to either check this or ignore it. In both cases, the existing tags are still valid.

And if researchers want to give a name (aka release) to a specific set of feature values (barcode A, 6-page booklet etc.), they could still do this, although it would be clear from the start that such a classification is subject to change at any time. The important distinction, however, would be that releases would be inferred from features and not the other way around.

Please let me know what you think!

1 Like
2

You run that risk with any open-ended database without write restrictions. Even though I discard Album MBID and only retain the Release Group MBID and Recording MBID, I still get burnt by editors incorrectly merging recordings. (Then, depending on the grievousness of the merge, I may feel it warranted to move every release out of the recording to nuke the bad Recording MBID since you can’t unmerge anything in MusicBrainz…)

1 Like
3

Cool thought, but a very radical shift, and does this scenario/problem actually happen that often?

I wonder if some sort of plugin that checks for new releases in the release group since the files were last tagged and then prompts you would be helpful for you.

4

@yindesu: Yeah, recordings are another thing that I feel could be improved. Similar to
these proposals (Proposal: Release editions, Audio checksums), I’d start with the actual audio content and checksums.

@aerozol: I only recently joined MusicBrainz so I cannot really tell whether that’s a common occurence. I will report back in a few months :slight_smile: Such a plugin would be useful, but I guess for the moment I’ll go with yindesu’s proposal and discard the Album MBID or develop a certain calmness about the correctness of my metadata :wink:

5

This has been rejected, and I doubt it will change. MusicBrainz wants a Recording to represent multiple versions of audio content and multiple checksums.

6

There is still an open ticket, so not all hope is lost yet :slight_smile: Kidding aside, there is value in knowing that two “audio contents” are “basically the same”, especially when you take into account releases on vinyl or cassette. But I have a feeling that this could easily be built on top of a content-addressable system. Then again, the developers probably know what they are doing :wink:

7

We already have this with AcoustId :slight_smile:

1 Like
8

I’m unclear how this would work. Would it require defining an exhaustive list of all the “features” that can distinguish one release from another? What happens if the key distinguishing feature (booklet color, in your example) hasn’t been filled in for an existing release? Can I still tag my (possibly different color) release with it?

2 Likes
9

@outsidecontext:
Yeah, exactly :slight_smile: What I meant to say was that since there is no easy way to use AcoustID on vinyl or cassette (you first need to digitize and then there will probably be a lot of variation due to recording equipment etc.), it is still valuable to know that track X on a vinyl release corresponds to a certain recording. With digital media, that is easier, of course.

@highstrung:
Good questions. It would not require an exhaustive list of features. Features would be added on an as-needed basis. So if a collector found out that during manufacturing the plant switched to a different plastic for the CD tray and he wants to retain that information, he could add a new feature. When updating, other users would then be notified that this information is missing in their tags and could then decide what to do.

The features would belong to what is now the release group. So if the key distinguishing feature hasn’t been added to the release group, you could still tag your files with the information that would have been added so far.

For every feature, the user would be prompted to choose between the possible values (or add a new one if nothing matches). If a feature has only one possible value in the beginning (say, only scans of the red booklet have been uploaded), the user would be prompted to check that his physical album matches the value. If it doesn’t, he could either add a second possible value (scans of the blue booklet) or decide to skip this feature for now.

10

Yes, indeed. But this is also already available with the recording feature of MusicBrainz. If the original Vinyl and later CD or digital releases are basically the same (format specific audio differences aside) they will ideally share the same recording. In the end this is something that human editors must help maintain, but technology can assist in this. And AcoustID is one such tool. Strict audio checksums don’t help much, as the Vinyl rip will almost be guaranteed to produce a different checksum then the CD rip. And if you encode in any lossy format you again will produce many different checksums for the same recording.

1 Like
11

I think the main issue is that each person may slice the tracks at different points.
This prevents AcoustID matching more than quality differences, I think.

3 Likes
12

@outsidecontext:
Oh, I believe we are talking past each other here. When I said “there is value in…” or “it is still valuable to know…”, I was acknowledging the usefulness of those (existing) features :slight_smile: . I still believe that checksums would be a useful addition, though (obviously only for digital media).

@jesus2099:
Yes, absolutely, no clearly defined start and end times would be another source of variance.

13

Oh yes, on this I agree.