I never said sample rate here, but bits per sample. Universal Music Group separates releases by bits per sample.
Apple Digital Master is something that the label gives to Apple in 24bit, and Apple gives to the consumer in 16bit lossy AAC downloads or whatever they do for streaming. The label intent is that it’s 24bit.
There is nothing confusing about “24bit / Apple Digital Master” if you have even a cursory understanding of what an Apple Digital Master is and the knowledge that I’ve repeated over and over that Universal Music releases are intentionally separated by barcode in this way.
Disambiguation is supposed to show how a release is different. If this information can’t be used to make it a separate release why include it in the disambiguation. Apple Digital Masters is on most Apple releases now and many are also on Spotify, Deezer, etc with the same barcode and are not considered a separate release and they don’t even have hi-res. So, you going to put on a disambiguation “Apple Digital Masters / TIDAL masters / 24-bit / 16-bit / Deezer / Spotify” because what’s the difference? Why Apple over TIDAL? They many times also share. When does it end. This information is better in the annotation. Not in the disambiguation.
I’m saying there are releases where all these things are true. It’s ridiculous to put them in the disambiguation. If something isn’t a reason to make it a different release, why have it in the disambiguation.
I used sample rate as an example, but bits per sample (aka bit depth) works just as well for what I’m saying. (Since in many cases other hi-res providers like Qobuz and Tidal will also have access to the 24-bit source, as far as I can see the only thing “special” about Apple Digital Masters is the lossy compression algorithm they use – users streaming losslessly should get literally the same data, so it is no surprise that barcodes are often shared.)
What is this hypothetical MB Release disambiguating itself against?
This is essentially my point! I can’t think of anything that even one of the items in that list would reliably disambiguate from, so none of them need to be there*. If two releases differ only by platform, audio format or service-specific mastering, then they’re supposed to be merged anyway, and otherwise they have to differ by something else, so you could disambiguate them by that instead.
*at least, none of them need to be there for the purpose of disambiguating. They might be interesting background information, but “Disambiguation comment fields should not be used to store general background information: that should go in the annotation”. (Disambiguation Comment - MusicBrainz)
Sure, but that’s not the case in my real examples - the barcodes differ. I have no idea what the hypothetical non-existent MB Release example is supposed to prove.
You read Disambiguation Comment - MusicBrainz so I assume you are aware that using the barcode as a disambiguation comment is actually disallowed?
We got twisted up a bit I think: what I have been trying to say from the beginning is that when the barcodes differ, no further disambiguation comment is strictly necessary to distinguish the releases. It may be that an additional disambiguation comment is helpful anyway in some situations, but in my opinion using something from the list of properties that don’t require separate releases is more likely to be unhelpful, for various reasons, many of which have been discussed here.
I had forgotten until I looked up the page again just now that barcodes are in the list of examples of things not to put in disambiguation, but indeed they are, and that makes sense to me. I do indeed think that both (a) a barcode would be a more suitable disambiguation comment than (e.g.) bit depth, because it is a difference between the releases that also justifies why they are separated on MB, but also (b) barcodes never actually need to be in disambiguation comments because they are already visible enough anyway, so in fact it is fine / better to leave the comment blank in the cases we have been discussing.
(I did not make that point very well above: the idea was meant to be that you could use the barcode as the comment in the examples, except style tells you not to, but it tells you that because the barcode is already easy to see. So the conclusion is supposed to be that you could just leave the comment blank.)
There should not be any 100% rule “This should always be on the release disambiguation” vs “This should never be on the release disambiguation”. I think it doesn’t make sense for every release to list their mastering info in the disambiguation, but at the same time, if that is in some cases specifically the difference between two barcodes that otherwise look the same, then it seems obvious that in that specific case that info should be in the disambiguation. Repeating the barcode in any case is useless and doesn’t really help disambiguate - the barcode is already available, it just contains zero useful info.
But if we only show mastering information to distinguish between barcodes, then we never show mastering information. Because we don’t separate releases with the same barcode when the only difference is mastering.
Yeah, this is what I’m confused about here. I can absolutely see that you might want something to make extra clear that the releases are different even if they have different barcodes, especially if they’re just a couple of digits off. (I assume that’s what you mean by “otherwise look the same”? Literally speaking, they’re either the same or they’re not, at least if you ignore the issue of leading 0s.) E.g. on vinyl releases, using the vinyl colour as an additional comment seems useful to me even if there is technically enough info to distinguish without it.
But using a property that wouldn’t distinguish the releases if everything else was the same seems worse to me than just leaving the comment blank: I would estimate that more than half of the time these comments don’t actually apply to all instances of the release (although comments which mention specific platforms, rather than bit depth / sample rate, push that rate up dramatically). Even if one did, this would be hard to justify – e.g. for bit depth on a digital release I’d have to try to check all streaming services, of which there are surely many I don’t know, and often it’s not clear what the bit depth is on them anyway – and could change at essentially any time. I’m also not suggesting that this should be an absolute 100% rule, because this site teaches you quickly that there are always edge cases, but it’s hard for me to think of a situation where this kind of comment would add enough clarity to justify the risk of being incorrect. Would be happy to see one if there’s a suggestion.
Yes, the whole point is that in some cases labels will issue different barcodes to different mastering versions and that is the case where this makes sense.
Which is again why this only makes sense for cases where the releases are explicitly separated by barcode (or catalog number). In that case, you should just add disambiguations to the ones where you know the data, based on their barcode or catalog number.
Sorry, I hope I’m not being annoying – maybe I am being a bit stupid but I still don’t understand.
I do not know how to find out why some digital platforms use one barcode and some use another. Experience tells me that even reasonable guesses, like it depending on the bit-depth, very often have at least one platform which is an exception (maybe because they offer hi-res and normal resolution on the same page, but only had one barcode field? Or maybe they just put the wrong one?) If any exception exists, a disambiguation comment based on the property would be wrong: I don’t see why it’s worth the risk when the releases are already disambiguated by a different field.
seems good. Barcodes distinguish, but so do the colours, so the comment is helpful. In particular, if I find a copy with red vinyl, it isn’t Release 1, even if its barcode is also …123, because the different colour would mean a different release.
and I find a 16 bit relase with barcode …456, then it could still actually be Release 2 (if all the other info matches), and the disambiguation comment was wrong. If this hardly ever happened in practice then it wouldn’t matter, but my experience is that it is quite common.
It’s common. May not be with UMG, but with others it is. Very common to just have one barcode represent all formats. But even when there’s more than one it’s not uncommon to find a release with one barcode only on Apple separate than another on Deezer/Spotify in 16-bit which is the same as the barcode on HDtracks, Qobuz & Mora with 24-bit. If you want redundant disambiguations on your releases, I won’t remove them. But I still maintain there is zero reason to put bit-rate or Apple Digital Masters on releases as neither of those warrant separate releases if the same barcode is used. You never did say why you have mora.jp releases with Apple Digital Masters on them. They obviously can’t use that even if the release was sent to them using that.
Yeah, that doesn’t explain why you put that on a release that also isn’t Apple Digital Masters, like mora.jp. If it was 100% Apple exclusive, maybe. But it’s not. This is the point that is going over your head. When I and other editors see a disambiguation such as bit rate, we assume that would be on every linked site. It’s usually not. I still do not understand why you are so insistent on having this in the disambiguation and just not the annotation where it can be explained better.
Hard to quickly justify “common”, but at least looking through my edit history I found an example almost immediately. I had removed a reference to 24/44.1 from the disambiguation: it was sourced from Qobuz where that is the quality, but the release is also available on Spotify which the internet suggests is capped at 16 bit (because of the lossy formats they use). The barcodes are the same (you can extract from Qobuz here), and I cannot find any other differences that would lead to separate releases on MB. It is also marked as Mastered for iTunes on Apple Music, but again has the same barcode and all other identifiers match as far as I can see.
(Now watch as somebody finds a difference I missed! But it is not the barcode.)
While this may never happen for Universal, in general it does. Maybe the point was that all providers in my example were sent the same 24/44.1 files, but then some of them converted them down before making them available to end users. (I do not know how to verify this, if it is even possible without being employed by the label.) In any case, the brief comment I removed looked like it should be about the final format delivered to the user, which is not always 24/44.1.
