Digital release disambiguation

Wanted to check opinions a particular kind of edit that I’ve been making for a while without no votes (as far as I remember!) until getting a couple of independent ones in two days – would be good to know if there’s a consensus.

You often see disambiguation comments for digital releases which refer to the bit depth and sample rate (e.g. 24bit/96KHz), to a particular digital store, or to service-specific mastering. None of these are now valid reasons for entering a separate release on MusicBrainz (Style / Release - MusicBrainz), although I think some of them may have been in the past.

I’ve been removing or replacing these comments, mainly because otherwise I think it can look like you are supposed to add new releases for these reasons. (But also because it is often hard to be sure that the comment is accurate for all online stores that could be correctly linked to the release.) A drawback which I acknowledge is that this might make it harder to spot that two similar-looking releases are in fact different, e.g. because of their track count or barcode.

So, do people want these comments or not? They could also be replaced by something else, that more directly explains the reason for distinguishing. I have been doing this if the difference is cover artwork, but not if it’s track count, barcode or label because those are already in the table of releases on the group page. (There is an older thread about this here.) Personally, I would still rather repeat one of those things than have something which doesn’t on its own distinguish the release.

Specific examples are here (comment has sample rate, releases distinguished by barcode) and here (comment has online store, releases distinguished by number of tracks).

5 Likes

I usually delete these disambiguation comments when I see them for the same reasons that you listed. I tend to only add comments to digital media releases to call out differences that justify separate releases but are otherwise hard to spot when looking at the release group, like cover art changes or subtle tracklist differences (e.g. same number of tracks but one song has been replaced by a different one).

I thought that there was a ticket open requesting the ability to annotate URLs (rather than releases) with file format information, but I can’t find it now, so maybe I’m misremembering.

4 Likes
3 Likes

I don’t understand the word “boxes” in the context of downloadable releases.

Moving it to the annotation is probably better than losing the information/reason for the separate barcode/cover/etc? Something like “This barcode assigned to the 24bit/96KHz release”.

But I also think it’s a grey area if it should be removed from the disambiguation at all, in these situations. Technically I guess it should stay, if it is the core disambiguation, but I also agree it is very confusing re. misleading editors into thinking it’s a reason to split releases… I don’t know the answer!

Just because they aren’t a reason to separate releases does not mean that they aren’t valid disambiguation comments.

3 Likes

There is nothing else that can be used as a disambiguation comment, which is intentionally concise and to the point, in these examples:

The fact is, the release label intentionally segregates release identifiers based on this criteria, and separating MB Releases by barcode is MusicBrainz 101. Removing the valid disambiguation comment does a disservice to everyone trying to consume the data.

1 Like

Apple Digital Master and bit-rate doesn’t need to be in the disambiguation. Because when you do that, it makes it look like that release is only available in that format, which isn’t true.

What? The release with that barcode is in fact only available in that format.

No. It’s not. Mora.ja doesn’t have Apple Digital Masters. It was decided years ago to remove these types of disambiguation. I run across plenty of releases that have hi-res that are in fact available in 96, 192, and standard 16-bit that are in fact all the same barcode and aren’t separate.

Show me where you can find 00602475856641 outside of 24bit and Apple Digital Master.

Show me where you can find 00602475856634 outside of 16bit.

I’m not talking about those specific release, I’m talking in general. But why have Apple Digital Master as a disambiguation on a release that is also on mora.jp? You can add this information in the annotation, which has been what was decided on when it was decided to no longer separate releases that have the same barcodes.

Why do you think it’s better for digital media releases to have no disambiguations? Why do you think it’s harmful for a digital media release’s disambiguation comment to accurately describe how the record label sees it as being different?

Why are you trying to change something years after it was decided not to do this?

3 Likes

Where was this decided? Who decided it?

It was discussed on the community boards in many different topics. It’s confusing to have disambiguations that are specific to only 1 linked store and not all of them. I suppose if every linked site had the same bit-rate you could possibly make an argument, but I don’t see how adding them to releases does anything but confuse more than it helps.

2 Likes

See above:

See above:

Just seeing now that this jumped back into life.

While I originally focussed on misleading new users about what the style guidelines are, in fact I now think the main issue is more that it will often be inaccurate for some of the attached links. Because as has been pointed out, while barcodes can be correlated with things like the sample rate and bit depth, this correlation is often not perfect (and it would never be possible to really check every possible streaming/download service that could be added as a valid link).

In those examples, the barcode itself could be used as the disambiguation comment, if you really wanted – my point was supposed to be that if two releases are correctly separated as per style then there must be a reason for this (usually one appearing in the list here) and I think it would be clearer and more useful for the comment to refer directly to that reason than to some other property that might not on its own lead to a new release. E.g. if I’m looking at a digital release and trying to decide if it’s the same as something already in the database, knowing that they have different sample rates doesn’t answer that question, but knowing that they have different barcodes does.

This leads to the secondary issue of whether it is appropriate to use the disambiguation comment to repeat information like the barcode which is already visible on the release group page. It looked like most people thought no (see linked discussion from the first post), hence my decision to just blank the comment: but if it was decided that disambiguation was absolutely necessary, I think repeating the barcode (or the track count, or…) would be better than giving the audio format from one of the valid links.

2 Likes

No, the entire point is that the average person doesn’t know how to find the barcode of a digital media release, so repeating the barcode from the barcode field to the disambiguation field does absolutely nothing.

2 Likes

In such a case, then indeed it does nothing, except maybe encourage the user to find out how to find such barcodes (although sometimes this will be impossible since not all services provide them). Unfortunately, quite often the barcode is literally the only thing that distinguishes two releases on MB.

What are you imagining this user trying to do? I am not managing to think of a situation in which (for example) the sample rate would help, but the barcode wouldn’t help more, but maybe you have one in mind.

If you’re trying to decide whether to add a new release, knowing one of the valid sample rates of an existing entry doesn’t help, because yours might have a different sample rate but still count as the same release on MB. If you’re trying to identify a release you have, then it might be helpful if you’re lucky, or it might be actively misleading because the sample rate chosen for the disambiguation doesn’t match yours.

On the other hand, I see no problem with putting a list of all known available sample rates / bit depths in the annotation, where there is no incentive to save space.

2 Likes