I recently had a discussion with another editor regarding the use of disambiguation comments for digital releases. I would love to get some clarification from the community to ensure I’m following best practices. In a specific case Edit #152527637 - MusicBrainz / Release group “Extinction” by Across Oceans - MusicBrainz , there are multiple digital releases of the same release group. The duration and tracklist are identical, and there are no differences in audio quality or bitrate (no iTunes mastering, etc.). However, they have different barcodes, and they are tied to different streaming platforms, which is reflected in the attached external links.
The user made a valid point that a disambiguation comment (“Apple Music”, “Bandcamp” or “Spotify”) is necessary so users can distinguish them in release lists, since a barcode is just a string of numbers. I don’t think the user is wrong, and they also follow the guidelines Disambiguation Comment - MusicBrainz . I definitely don’t want to single anyone out.
I interpreted the guidelines to mean that because the barcodes are different and the specific streaming links are attached, the releases are already uniquely identifiable. My concern was that adding platform names to the disambiguation might be redundant and not add any necessary new information. In my understanding, this additional data is only needed if the entries cannot be distinguished by their barcodes/links, or if they differ in other specific characteristics (such as audio quality, mono/stereo/remaster/color of the album etc.). Otherwise, we would have to include these details for digital releases by all other artists as well.
Furthermore, in some cases, I have encountered barcodes that ended up being associated with multiple streaming platforms that were not covered by the disambiguation, meaning the disambiguation text was inaccurate and had to be removed anyway.
How should this be handled in general? Is a disambiguation comment recommended here, or should we avoid it because the database already distinguishes them via barcodes and URL relationships? Is there a specific rule covering this scenario that I might have missed?
I’m open to changing my routine and just want to make sure I’m handling this consistently. Thanks in advance for your help!
I usually try and add such disambiguations to make it clear at a glance that the two releases are different, like for seperate Bandcamp and SoundCloud releases without barcodes (but with some other difference that’s not clear on the release group page, like album art or a relationship)
either way, I see no issue using the disambiguation field like this, since external programs might not show URLs but do show disambiguations, Picard for example
While I argued against these comments in the past, if I remember correctly the consensus was that they can be useful as a failsafe if somebody doesn’t notice the barcode. That is also reasonable, so I leave them, except if they are not accurate (e.g. “Apple Music” on a release also available on Spotify, “24/96” on a release also available at 16/44 or in lossy formats…) or particularly uninformative (e.g. “streaming”, if every digital release in a group is available for streaming, or “digital media”, which is duplicating the already easily visible format field).
(My objection at the time was that these comments describe things that wouldn’t result in separate releases if the barcodes were the same, which I find slightly awkward. If there is some other disambiguating difference that can be used instead, like the cover art, then I would probably edit to use that… but normally there isn’t, in my experience.)
Thank you for your reply, I understand your perspective and share your experience. I agree that it makes a lot of sense, especially for Bandcamp releases, as it really speeds up the process of finding the right release when tagging with Picard.
However, in this case, we are dealing with standard music streaming services, all of which have barcodes (no Bandcamp/Soundcloud/YouTube links are added). I find it a bit difficult to imagine adding every single streaming service to the disambiguation. Since links/withdrawn statuses can change quickly, it feels like it might become a bit inflexible and perhaps even contradict the purpose of the relationship data. One of my most frequent edits is changing dead links to the “ended” status. A link that works today might be dead tomorrow just because a release gets replaced by a deluxe edition (looking at you, Apple Music). That was my main reason for originally thinking the disambiguation might be unnecessary here.
That said, I also understand the practical need for those disambiguations.
Extra webservice calls from your client to the server is not a reason to remove disambiguation comments, as normal clients won’t send those extra webservice calls to fetch the non-standard information.
add disambiguations when they add something not already displayed in the general interface or in search results
My reason to remove it is because it’s not 100% accurate. Store shops shouldn’t be in disambiguation unless they are exclusives, like Target exclusive, Walmart exclusive, Apple Music exclusive, Spotify exclusive. But if it’s on more than one service, what’s the point? It’s clutter. We can see they have different barcodes already. That alone is enough to show that it deserves to be a different release. Mastering information, i.e. bit rate, Apple Digital Masters, etc. also shouldn’t be on releases. We can’t create separate releases any longer when all data is the same except for bit rate, so why is it even a necessary disambiguation? It’s not.
Yeah, that’s exactly the point I’m struggling with. Before I started using userscripts, whenever I saw “Digital Media”, I would manually check the links to see if the specific streaming link was present.
Nowadays, Harmony handles the lookup for most of us. However, if the streaming service is linked but the barcode is missing, I still have to manually copy the link into Harmony. Conversely, if the barcode is there but the streaming service isn’t, I have to update the release. Both scenarios often lead to removing the disambiguation because it becomes misleading.
Sometimes, there are no visible differences for an album on the same platform (same track count, etc.) and the only way to distinguish them is by comparing the actual URLs. That’s the major drawback of digital releases compared to CDs, where a disc has a physical appearance and a (mostly known) release event.
Perhaps in the near future, to better handle these digital distribution changes, there could be a way to natively build in these relationship shortcuts. I’m not very familiar with the technical side of MusicBrainz, but maybe it would be possible to fetch those links with the release itself via a single API call directly within the release view.
Hopefully you know, but Harmony still needs to be double-checked because barcodes are not unique identifiers on their own - A, B, C.
C) it’s well known that Apple’s lookup API is unreliable because it “helpfully” finds releases that don’t match the barcode you asked for.
B) barcodes get reused between withdrawn and reissued releases
A) barcodes get reused by different record companies at the same time. In these cases, any small difference in the copyright statements between Spotify, Deezer, and Tidal may indicate releases from different labels.
Tangential, but in the event you just mean being able to visually discern relationships on the RG page, the Display shortcut for relationships userscript puts these details inline with icons for each provider, and supports representing ended relationships by greying them out.
Thanks, I’m personally already using it.
However, the counterargument is that the extension isn’t available to everyone right from the start (regarding the online release view and Picard), making disambiguation necessary. To “counter” the flexible streaming services, a built-in link view would be quite interesting.
That is precisely the problem I encountered: that disambiguations are misleading because barcodes are reused, and so on. The only reliable source of information is the link itself.
So, we’re actually talking about the same thing, just from different perspectives
