Differing/non differing digital releases with and without Barcodes... an ongoing discussion between editors

After reading through this thread, I’m in strong agreement with Augmente: If Bandcamp doesn’t provide a UPC on a digital release, the only real info that provides is that the UPC was not entered when the release was published.

Much of this debate seems to boil down to open-world vs closed-world assumptions, and I’d argue that Musicbrainz always needs to assume open-world, especially here.

Within digital distribution, it’s a de facto requirement that all releases have UPCs and ISRCs. This is uniformly enforced to the point where you can treat (UPC, ISRC) as a natural key for a track on a release, and UPC as a natural key for a release. Just because distro happens to work this way doesn’t mean the rest of the world does.

Compare recordings- mb doesn’t treat ISRCs as defining recording identity: ISRCs are overissued, not actively curated, never merged, not public, not resolvable via a centralized registry, have blunders, etc. It shouldn’t be surprising that Musicbrainz’s definition of what constitutes a recording differs from IFPIs.

Regardless, an ISRC is a useful handle for finding and referring to a recording. But it doesn’t define it, and it would be nuts to, say, block recording merges or require splits based on mismatching ISRCs, let alone missing ISRCs.

Getting back to UPCs - I don’t think Bandcamp exposes it, but they do optionally collect works registration information and ISRCs for tracks on releases. Let’s say the info was available -

  • Would it be a good assumption that a recording missing ISRC data has never been issued one?
  • Would it be a good assumption that a track without works details doesn’t contain any registered works?

Why make the same assumption about UPCs on releases, especially when Bandcamp is basically the only platform where you’ll see releases without UPCs anyways.

Doesn’t that only apply to the major platforms? As you pointed out later in the same post, Bandcamp doesn’t require them. I don’t think archive.org does either, and of course artists or labels who release music on their own websites can do whatever they want.

I think there’s some misunderstanding here. Bandcamp supports barcodes. They do not require it, but it’s an optional value that is readily available and it can be said with 100% certainty if a Bandcamp release has an UPC or not. Recordings are equivalent to release groups, not releases. Any comparison with ISRC/ISWCs falls flat, because they’re values that are meant to be reused, but UPCs are codes that are not meant to be reused. Labels sometimes intentionally release things with a different UPC for every streaming service, that has the same ISRC code for the tracks, because one is meant to know when to combine recordings and the other one is meant when to differentiate releases.

This is absolutely not true. I add a lot of digital releases that do not have UPCs because they were made available outside of the digital distribution ecosystem, sold on their own websites, offered for free download on mixtape sites like DatPiff (RIP), free netlabels, user uploads on SoundCloud (not auto-uploads part of the digital distribution ecosystem, which have UPCs). It’s technically possible for these to have UPCs, but they’re pretty much never present. A lot of the ones I added that I know for certain does not have a barcode in that issue are from Bandcamp, but that’s because it’s a very popular platform for artists outside of that ecosystem. Some of these have been reissued as part of the ecosystem at a later date with an UPC value that did not exist until the reissue.

If [none] is a barcode value on a release and not incorrectly set, I know that the release does not exist inside that distribution ecosystem. You can know for sure that a release that lacks a barcode (and wasn’t incorrectly entered) doesn’t exist on platforms that use this type of distribution. That is useful information to me.

3 Likes

My personal reason (copied from my edit note):

When my label releases stuff on Bandcamp I don’t claim ownership of the same release on the artist’s [Bandcamp] page (which is usually/often the case that we do a dual release, and because I’m mainly setting up a page to sell physical media). And I think the money split (buying from one goes to the artist, one to the label (and then maybe back to the artist but only maybe)) is significant when it’s self-release vs label.

I am not advocating to split releases on Spotify (etc) that are identical to a Bandcamp release except for barcode, this case is about the existence of a label + artist Bandcamp release, one without barcode.

To clarify, when I say “digital distribution” here, I mean distributors using DDEX to get releases to DSPs and other industry consumers. Posting on Soundcloud isn’t what I meant by distribution, though I could have been more clear about distribution vs platforms.

They’re all intended to identify unique entities. A UPC is absolutely meant to be reused, by identical products which are members of that SKU. That’s how ISRCs and ISWCs are intended to be used as well.

Maybe I’m misunderstanding what you mean by “reused”, but UPCs are reused all the time for reissues, yeah?

1 Like

The difference is that an ISRC and ISWC are meant to represent a recording or a song, in every context it appears on (some have more than one, but the intent is that they should be unique). Yes, an UPC is on more than one product, but it represents one particular issue (release in MB), not the concept of an album (release group in MB). Recordings and works are not comparable to releases, since the latter is something that is intended to be added many times to represent all the various issues of an album represented in a release group.

There often are simultaneous physical/digital releases that are pretty much completely identical other than UPCs, because they’re intended for different markets. They’re changed as soon as there is a difference to keep track of, while ISRCs are meant to keep track of the same recording in every context it appears in.

And yeah, UPCs are often reused in scenarios where it’s confusing, but that’s usually on the laziness of labels rather than by design of the value.

I think the point people are making is that the same laziness means they won’t type in a barcode unless it’s mandatory to fill in that field, in many cases :slight_smile:

That said, I guess a sensible way to deal with this sort of thing could be the same we do with stuff like pressing plant info: “if someone has made the effort to split the releases based on this info, don’t merge it, but don’t feel like you have to make the effort every time you add a release”.

4 Likes

One thing I think we’re missing here is that part of this problem comes from how barcodes are modeled in MusicBrainz in the first place.

Right now, a release can only have one barcode. That makes sense for physical releases, but for digital it often doesn’t reflect reality. The same digital release can end up associated with different UPCs on different platforms, or have one shown in some places and not in others.

Because of that limitation, we’re are pushed into creating separate releases just to store a different barcode, even when nothing else about the release has changed. That feels wrong.

Maybe instead of treating the barcode as a single value, it should be possible to store multiple valid barcodes on one release. That would let us document what’s actually out there without implying that every barcode change means a new release.

I think this would also reduce a lot of the “barcode present vs not present” ambiguity, especially for platforms like Bandcamp, where the absence of a barcode doesn’t necessarily mean anything meaningful.

To me, this seems like a more realistic way to model digital releases than splitting them over what is often just incomplete or inconsistent metadata.


Besides this point, I’m still trying to understand how barcode information is useful in a broader sense. One thing that has been mentioned is using MB as a research tool. I am not really sure how digital barcodes are useful for research, but if they are then this is another argument towards giving them more flexibility and treating them more like relationships that have a start and end date, that a digital release can have more than one of those and that allow for a greater flexibility in terms of organising the information and (re)searching it.

I have some background in data modelling, and the current status quo just feels odd to me professionally. It seems that the data model that prompts so much duplication in the database just because the barcodes are different or absent is a model that can be improved.

I understand that some people have responded here in a way that points out my ignorance and lack of understanding how MB works and how it is used, but I never claimed that I know everything and I think said at least a few times that my understanding is limited. We come here to consult as a community, and the spirit of consultation should promote mutual understanding.


In any case, unless something serious comes up that requires my response, I will be present in this conversation read-only. I have received about 80 emails over the last couple of days from this thread and from all the edits people have visited to share their comments and honestly I cannot keep up with it.

As @reosarevok said, if someone decides to split releases based on the missing/present barcode principle, I won’t vote against it. I will remove my ‘No’ votes from Xone’s edits right now. Even though I believe in a longer run not splitting the releases based on the presence/absence of a barcode will benefit the database health, I think right now there’s not enough people that feel that this is necessary, even though some people have shared that they agree with my point of view. If in the future the discourse will shift, those releases can always be merged. But I also kindly ask that if you stumble upon a release that I have imported in the past and want to split it, go ahead; but kindly don’t tell me that I’m wrong and don’t know how to catalogue data. It is abundantly clear how ambigous these waters are.

2 Likes

Releases with different UPCs on different platforms are because they aren’t the same release:

  • they may have different text scripts, intentionally
  • they may have different distributors
  • the label/distributor may be intentionally tracking sales/listen data for different markets separately
  • the record company may consider 24bit sources (including iTunes/Apple Music) to be a different release from a 16bit source (Spotify) - see Universal Music Group

And this is assuming you aren’t talking about the iTunes API “helpfully” returning similar releases with a different barcode than the one you submitted to the lookup API.

It’s only a problem when there isn’t another visible difference between the releases on platforms that don’t expose the barcode (Spotify may soon join Amazon Music there).

(And even in the case where digital releases share barcodes, they may obviously be different releases by having different URLs/IDs on all music platforms. That’s no different from CDs manufactured by different companies in different countries with different back cover credits sharing barcodes.)

4 Likes

To quickly respond to this:

That’s a valid reason for splitting, no one argues it.

Multiple distributors can be entered via relationships, we’re not limited to one per-release.

This is irrelevant in the MB context, we’re not tracking that data.

Doesn’t mean that we should. Discogs considers mp3/WAV/FLAC, etc. all different releases, but MB doesn’t.

That’s why a digital release should have mutliple barcodes. Barcode is an identifier, but there’s no global body that ensures that this ID is universally unique.

If releases have different URLs on different platforms, we don’t separate them. Spotify/Deezer/Tidal releases are always one entity, given that all other variables are the same. Here we were only discussing barcodes.

That’s exactly what I am doing. Your effort to refute everything I said means you’re just straight up ignoring Style / Release - MusicBrainz so why should anyone reply?

1 Like

Like yindesu said, they’re often intentionally different. They are not supposed to be unique for a certain album.

They’re only different if the barcode or other information is different for 24-bit releases, because the label intentionally assigned it another barcode to keep track of these releases. Not as a general rule.

Your idea of a multiple barcode digital release is not a good idea. Should we not split them if copyright and distributor credits are different either? Should we just add all possible URLs, copyright and distributor values to the same release, and then use the annotation to say which is relevant for which barcode? It’s a bad idea and it requires to katamari-ify a lot of information for different things into a weird blob where you would have to mess with the database to be able to tie UPC values to URL and copyright relationships, instead of just using release groups as they’re intended.

Multiple barcodes are potentially useful for physical edge-cases where a release can have multiple ones printed, but absolutely not for digital releases.

3 Likes

I just urge people not to go crazy merging stuff.

I gave an example in the comments of the edit that prompted this current discussion -

To give a more concrete personal example, if these two were added to MB as a single label release, that would be incorrect:
https://limblessmusic.bandcamp.com/album/annihil…
https://unsanitarynapkin.bandcamp.com/album/anni…
The version on the band’s Bandcamp has nothing to do with the label (mine).

In this case they don’t even have different barcodes (both are no barcode, and not by accident), but I can guarantee that it would be wrong to merge them.

The same disclaimer again: I’m not against identical releases being together, where it really seems like someone has just omitted a barcode (though I also don’t see the need to merge if someone has split something).

1 Like

No. If a digital release has a different barcode, it’s always a different release. Should never be considered the same. Just like if a physical release in every instance with a different barcode is a different release.

2 Likes

Personally, I really dislike these fudges, and would much prefer a clear guideline in either direction. (The “you don’t have to get everything perfect first time” part is fine of course, but I think there should be a clear standard to aim for.)

i think the distribution argument makes my case even stronger.

we have a dedicated “distributed by” metadata information field. now if a release is distributed by recordjet there will be a UPC. and if you link the label “recordjet” into “distributed by” (which would be correct to do) all the pages which use no barcode are automatically not distributed by recordjet.

1 Like