I have an on going discussion with editor augmente since some time. I think it would be good if we can clear this specific issue in the style guide. (Style / Release - MusicBrainz)
Steve Roach releases are often released via label Projekt and by himself on his own bandcamp page. Now while the Projekt releases usually have Barcodes which match with those of the streaming distribution, Steve Roach does not use barcodes on his Bandcamp page and also credits the Copyright to his own label (Soundquest Music) and not to Projekt.
There are at least two arguments:
The Barcode was not entered by the artist
There is no barcode
i strongly support the second argument. if there is no barcode entered at the bandcamp page, there is [none] Barcode. the first argument seems to me arrogant (saying someone forgot something but i as an MB editor know better) and just besides the facts (there is no barcode after all and you can fact check)
now maybe we can discuss this here, because my discussion with augmente always repeats itself over the last years.
Thank you for creating a topic here, as these discussions indeed take a lot of time. It would be good if this is clarified in the style guide indeed.
I think the key issue is being framed the wrong way.
In these cases, we often have a barcode explicitly shown on the Projekt version of the album (and it matches whatâs used for streaming distribution). Then Steve Roach also offers the same album on his own Bandcamp page, but the barcode is not displayed there.
The important point: absence of a barcode on Bandcamp is not evidence that the barcode is different. Itâs entirely plausible itâs the same barcode and simply not entered/shown on that page.
Because of that, we should not treat âbarcode missing on one storefrontâ as a reason to create a separate release. The barcode field on the Bandcamp page is often incomplete metadata, and splitting based on ânot shownâ would create duplicate releases that differ only by what the storefront happens to display.
So my position is:
If we have a reliable barcode from the Projekt release (and/or streaming distribution) and no evidence that Roachâs self-posted version uses a different one, we should not split.
A separate release makes sense only when we have positive evidence of a difference (different barcode/UPC/ISRC set, different tracklist/audio/mastering, different release date/edition, etc.).
What would help most is style guidance that explicitly says: âNot displayedâ is not the same as âdifferent,â and missing barcode data on a storefront shouldnât by itself justify creating another release.
When I read that, I thought maybe the releases should be split based on the label or copyright, but from a quick glance at the two Bandcamp pages, I donât think that anymore. It looks like itâs just a copyright statement, not a label imprint. If they had conflicting copyright statements, I think splitting would make sense. But it looks like the Projekt page doesnât mention the copyright at all, so thatâs the same situation as with the barcode.
All Apple Music releases have barcodes. Just check them with the Toad King script instead of relying on Harmony to see if itâs the same release as the others. Harmony doesnât have the ability to see the barcodes because of the Apple Music API not being public. As far as the Bandcamp release, Iâd say itâs a different release because of copyright, label & barcode all being different. I disagree about the barcode not being enough. I say it is. Almost all releases that have the barcodes are usually the same as the ones seen on the mainstream sites. But Iâm not going to get in an argument about that. However, being self released vs. Projekt is definitely enough to warrant a different release.
Thanks for the response â it actually highlights the same underlying issue, just framed around labels instead of barcodes.
Regarding Apple Music: itâs not disputed that Apple Music releases have barcodes or that tools like Toad King can reveal them. The issue is whether there is evidence of a different barcode for the self-released Bandcamp version. A barcode not being displayed on Bandcamp does not by itself demonstrate that it differs from the Projekt / streaming one. Only a confirmed difference would justify splitting on that basis.
The same pattern appears with labels. According to the guidelines, releases on different labels should be split. However, self-released is not a label â itâs the absence of one. That is not the same situation as âLabel A vs Label Bâ.
So âProjektâ vs âself-releasedâ is fundamentally different from âProjektâ vs another concrete label entity.
This isnât an argument that releases should never be split, or that combining is always correct. The broader downstream use of MusicBrainz data isnât something that I can judge. The point is that current guidelines donât clearly define how to handle cases where metadata is absent rather than different, whether thatâs barcodes or labels.
Iâm not insisting on one way or the other Clarifying this in the style guidelines â in either direction â would help avoid recurring misunderstandings and repeated discussions like this.
Iâd disagree here. Self-released is certainly a different label situation - if a release is self-released, then a label chooses to publish it, those are two releases. The question here is whether that is what happened at all, or whether the release is just put out with the label but the label is not mentioned on the artist page, if no other credit is given / itâs not actively claimed as a self-release.
In this particular case I think the line is very blurry. Steve Roach is coordinating his releases with Sam Rosenthal and often (not gonna say âas a ruleâ since that requires a deeper research) the album is released at the same time at both label page and artist page. The artist page sometimes explicitly mentions that the album is released by Projekt, sometimes he sells Projekt CDs on his personal page, sometimes it doesnât mention it at all. But it is my feeling that the musicians themselves (in this situation) donât see it as two different releases, what they see is two separate distribution channels allowing the album to reach a wider audience by being published in both places. I think his own discography page is a good rule of thumb: Discography | Steve Roach, where certain albums are attributed to Projekt Records, yet they are hosted at both bandcamp pages.
And the other way around? If itâs published on a label (weâre talking about an imprint of course) first and then the artist also puts the album on his own bandcamp page?
If the same rule is applied and in this case we have to create two separate releases, could it be please clarified in the guidelines, that a no-label release and label-based release should always be entered as separate entities?
The issue here is the lack of barcode, not the label. This should be added as two releases if it was released on a label Bandcamp without UPC and other digital services with an UPC. I could buy the reason if the barcode was shared, but no UPC is pretty much always a distinct release according to guidelines.
Differing barcodes. Not all services list releasesâ barcodes, however, so do not automatically assume that no barcode being visible means a new release must be added.
We know explicitly from the value is being unset that there is no barcode for the Bandcamp release, so adding an URL relationship on a release that has an UPC is not what the guidelines intended. Bandcamp does list barcodes (though just in html source without userscript), so the exception here doesnât apply.
It seems kind of absurd to duplicate a release because an artist couldnât be bothered to type the barcode in, to be honest, unless we have a clear reason to think that was because they were intentionally claiming no barcode at all for this release (if a different barcode had been entered, Iâd 100% agree).
That said, either way is probably fine as long as itâs clearly documented why the two are kept separate.
Someone could also just ask the artist if itâs an intentional separation, of course
If an artist gets a distributor assigned barcode, then changes distributor and gets another distributor assigned barcode, itâs also not âintentionalâ to create two releases. We know a release 100% doesnât have a barcode and that it just isnât shown on Bandcamp, the reason why isnât really important, since it means the UPC value is incorrect for that release.
Why? They would likely have no idea about the database definition of releases and thus their input is completely useless. If you were to ask an artist that had two releases that only differ due to different distributor assigned barcodes, they could consider them the same too. We have a clear internal definition of what is considered a different release, and the artist would just be going on a vague definition of what a release is. Another artist might claim that a MP3 and FLAC copy where the latter is priced a bit higher are different releases.
The new digital guidelines are great, and it would be bad if we allowed exceptions to it based on statements from artists.
this is my point. how do you know that the artist didnât bother? i think we will never know and so we have to take the releases as what they are. and they are by fact without barcode!
vice versa you are implying that we should never use [none] on Bandcamp releases.
I personally probably wouldnât use [none], at least if the same release is available anywhere else in digital stores with a barcode and thereâs no clear mark the artist meant for the two to be different. In fact, I mostly only use [none] for physical stuff where itâs obviously clear. But digital is a mess, so if some people add Bandcamp because they think itâs important and relevant to track it separately I guess I wouldnât merge it either
I donât like the wording of the guideline. I think it should probably be more explicit. âIntentâ is vague and not useful for a basic guideline on how to separate digital releases. A distributor assigned barcode changing into another distributor assigned barcode is probably not intentional by the artist/label at all! We do not talk about âintentâ with physical releases, we talk about differences. The way itâs worded makes it sound like the actual interpretation of a different release by the artist/label overrides these, which it shouldnât do.
The bolded parts here should be changed:
Digital media releases (download/streaming releases) should always be entered as a separate release from their physical counterparts. If a digital media release already exists, only add further digital media releases to MusicBrainz when there was clear intent by the artist or label to create multiple releases. This requirement can be satisfied by the following:
To something like this instead:
Digital media releases (download/streaming releases) should always be entered as a separate release from their physical counterparts. If a digital media release already exists, only add further digital media releases to MusicBrainz when someaspects of the release differ from other releases in the database. This requirement is satisfied by any of the following:
Not to be rude, but as an editor I really donât like the implication by reosarevok here.
Adding the amount of releases Iâve added to the database is a lot of work. I do not want to contact an artist every time I see a release missing a barcode on Bandcamp but it has one on digital retailers. Iâve added hundreds of releases like that. I donât want to send a hundred emails and wait for responses. I want to add the thing correctly as quick as possible and be done with it without having to worry about the response. What if the artist is deceased or just doesnât answer the emails? This should not be necessary at all for such a common thing. Again, no offense, but this response is exactly why I think we should remove the word intent from the digital release guidelines, as we do with physical releases. A CD that has a mistake that is fixed in another printing is a separate release. We do not have to ask the artist if itâs an intentional separation, if they consider the fixed printing a separate release from the one with a typo. The guidelines tell us that any differences in artwork IS a separate release. It should be the same here. It saves everyone time, editors and artists/labels who donât have to answer emails about this.
Edit: I donât think I have to point this out, but I will still since I donât want my post to be misunderstood. Iâm not against contacting artists for database related things. There are legitimate cases where contacting the artist might be a good idea, due to inconsistencies in information or similar issues, but absolutely not for something as basic and abstract as what the definition of a separate release to a database they probably have no experience with adding information to should be. They would just be confounded by the question, and rightfully so, because itâs something that should be handled internally, just like physical releases are.
The guidelines are a bit ambiguos. They can be fixed. But for it to be possible we need to take a step back and understand why they are the way they are.
The main question is who benefits from splitting digital releases based on the barcode presence/absence? How is this data used by consumers? And what is the purpose of the barcode on a digital release?
As far as I know the only purpose for a barcode to exist as an entity is that this is an unofficial de-facto standard how various streaming platforms synchronise releases with each other. Thereâs no other contract that has been developed, so this is how it is currently done.
And as a MusicBrainz and Picard user with a gigantic collection of music, I have no use of barcode whatsoever and never had. Yes, it helps to link releases between various platforms when importing, but itâs auxiliary, thereâs no direct benefit for my music collection. And while all other variables are the same (tracklist, cover art, credits, recordings) am I going to keep two copies of the same album on my hard drive just because one of them is downloaded from bandcamp and the other one is purchased and downloaded from qobuz/beatport? No. Itâs a waste of space. I understand that thereâs no difference at the essence level: it is same music, same bytes. Distribution channels vary, it could have been a label or it could have been artistâs personal bandcamp. But this details doesnât mean that this is a different release. Same music, same bytes.
Then for what sake should we separate these releases in the MB Database? It results in a higher friction (due to ambigous guidelines on when to split and when not to), it results in a more time spent by editors on entering another copy, it results in higher data scattering (platforms supply various degrees of credits which donât always overlap, so not entered for both copies). I can name at least 3 more reasons why blindly splitting is not good for the database health. I cannot name even one reason why it is good.
Wild take: for Digital Music Guidlines I think we should remove barcode criteria as a reason for splitting entirely. The benefit is not visible.
I as an editor would argue that I do this. It means that data that was correct at the time of submission wouldnât have to be edited years later because a barcode was added.
This is essentially what we had in the past, where releases were only defined by unique tracklisting and it didnât work out well. A release is not just defined by distinct differences in audio content for physical releases. It shouldnât be for digital either. If just the cover art is different between two digital releases, would you really need to keep two copies or just two cover art files?
I find it much harder to have reasons why to not split releases. It transforms a release from an entry that can more or less be correctly added from one copy to a vaguely defined concept that can be correct one day, and then it gets added to streaming with another barcode and itâs suddenly wrong. The point of the current digital release guidelines is that a snapshot is always correct for release defining information, and credits can be sourced from other releases if applicable and added as a relationship. On most cases, these are on recording level, so duplication is already avoided for those relationships, so itâs just mastering/artwork/copyright etc, which can differ from release to release.
Again, if anyone using the data doesnât care, they can simply select an arbitrary release and just make Picard or whatever method theyâre using for metadata to just discard the barcode value entirely.
The benefit is quite visible for unique barcodes, since you can only store one barcode. It means that we would probably be stuck with the first barcode that was entered, even if it changed distributors. And getting rid of the value entirely makes digital entities harder to cross-reference. For no barcode, it makes editing a lot easier in edge cases (there is one Bandcamp release without barcode that exists, and two or more digital releases with multiple barcodes. Does a single Bandcamp release suddenly become multiple ones?).
And getting rid of digital barcodes entirely makes cross-reference while editing a mess, even if you can store it in an annotation, it makes lookups so much harder. I think multiple releases is an acceptable sacrifice since it simplifies maintaining releases ([none] wonât be outdated, we donât have to pick one barcode out of several arbitrarily and stick with it and add others to the annotation, which to me is worse than adding credits multiple times, since thatâs an one time thing) and it means the data is truly correct for what itâs linked to.
i think in this paragraph you are looking on your own use cases. these might be interesting for yourself but you canât conclude for other editors and also (and maybe more imporantly) you donât know how MB data is handled by an unknown number of attached systems.
what you are writing here is basically, that you only need one release for every issue with the same tracklist and tracklength. this is not how metadata works imo. a bit over the top now: in your logic one cd issue would cover all the digital releases.
if editors only want to enter one issue thats fine, noone is forced to add all the available releases.
yes the database gets bigger, but just check some discogs releases with 400+ issues. thats just how complex reality is. if we close our eyes in front of that complexity MB gets unbelievable and unusable for research.
i am absolutely against this and from a metadata perspective it would be an absolutely catastrophic and wildly taken suggestion!
Clarifying this in the style guidelines â in either direction â would help avoid recurring misunderstandings and repeated discussions like this.
