Release Date issue - same country


There are 2 release dates, both US. The web UI tells me I cannot add two dates for the same country. What I have done is added one as Worldwide. Here are the two references:


Although I have no clear proof to show in a reference link, it appears this is due to her signing with new label in November, causing a new release licensed to her label. As it is the same release, that is a second release event, which apparently MB does not allow to happen in the same year.

If someone could change this to fit MB guidelines/rules, that would be appreciated. I am unable to enter it to what I believe to be proper.

1 Like

Something can’t be both a new release and the same release. Different labels mean different releases.


This sounds a lot like it should be a separate release if it gets released at a later date by a different label.


Hard to say. There is no “label” for digital releases as MB refers to it. There is no logo printed on the CD or artwork. The label that is included in the metadata is not considered the label by MB. I can tell you that the release (the files) are the same. The difference is only in the metadata, which is slight only.

If you want to call these different releases, someone can make those changes. On a digital release, I would welcome anyone to try and distinguish them from one another among all the digital sources that MB considers the same, just a digital release. Example, which one is the Amazon release? Deezer release? I would also ask how you would want a user to take their digital release and determine which one they have. I do not see how a real distinction can be made on the actual releases when in the hands of the user.

1 Like

This has prevented me to merge identical releases many times…


That’s definitely not true. There usually is a label for digital releases just as there is a label for physical releases. The fact that you cannot see the label for downloaded files does not change that. Many online stores show some information on the label behind the release.

That’s no surprise. Why should the audio change when label changes?

The fact that digital releases are hard to distinguish when you only have the files doesn’t change the fact of different labels and re-release. And in this specific case the difference seems to be known, so nothing preventing you to have this information in MusicBrainz appropriately.

1 Like

I can offer yet another example of where issues with digital releases are problematic.


On this release, I was going to add the Bandcamp reference. I am unsure which barcode it belongs to. I have 2 choices for digital. One is for Deezer, which is a stream only release. The other is iTunes, for which the references are not even valid anymore. My copy, from Bandcamp, I have no idea which barcode it has, it is a digital release, and barcodes, labels, etc are not commonly disclosed.

This might be true for some, but when dealing with iTunes, this is never the case. When you look at a digital release, most often the “label” listed is not the label that MB wants. This is just proven by numerous edits and discussions.
EDIT: Please note I say the label MB wants vs the label used. There is often “a label” listed, but often times, that specific label is not what MB wants there. This is a problem.

This could be fair. So you suggest that the metadata of audio files trumps? This is going to mean that every store, each having a distinction in the metadata, is its own release.

EDIT2: In effort to avoid duplication, I posted a specific issue. Rather than going back into the same old debate, there is an issue that MB cannot resolve, one that @jesus2099 seems to relate to. If you want them separated, by all means. Someone else can put their name on it. Also while doing this, please add the Amazon release to the appropriate one. There is no sense rehashing the digital release attribute debate as my stand has been confirmed many times to me, so I have nothing to prove. MB can do as they wish, it is not my data or company. All I will control is what I put my name on and what I will not. So for this, I placed my name on a series of edits to make a release that I will stand behind. I won’t however put my name on edits that I know to be incorrect in the proper distinguishing of releases.

1 Like

A note for whom ever wants to MB-ize this …
Edit #58371037 - Edit relationship

The earlier release date iTunes ID was apparently removed within the last few hours. The release date is important to retain though, as it was released in June. The later one is another release event of the same release.

1 Like

After seeing the edits done, I have two questions though.

  1. How does a user with the release determine which one they have? It appears that the releases are actually indexing the web site and API contents vs the release contents. Meaning that with release in hand, the distinctions you are making do not make the differences clear.
  2. What is important for information for digital releases, the metadata or the website / API content? Which takes priority over the other?

What I find really interesting is I am one who believes that digital releases in MB need way more information, and at the same time, I see this type of stuff not only senseless but confusing. The data being entered provides little value for a person with a release “in hand”.

I just said a release released by a different label should be added as a separate release. I wouldn’t go as far as generalizing a rule that metadata in audio files trumps everything. For this metadata in files is just too volatile and often badly managed. Stores often add their own data there, metadata might even be different per download (e.g. contain customer specific identifiers). So the metadata might not even contain any label information. My arguing that releases by different labels should be separated stays the same.

It lies in the nature of downloaded files that you cannot distinguish them easily. In your case the labels are part of the metadata. If this would be missing the user could maybe go by purchase date or even knows the exact store page they downloaded from. But this all implies the user really cares about the exact label that stood behind the release in the date they purchased it. If not it does not really matter which one to use, as everything else is identical.

While less common similar issues can also arise with physical media. It is not uncommon e.g. to get only a CD in a jewel case that was both sold separately and as part of a box set. If you only get the jewel case there is no way to tell that it originally was bought as part of the box set.

1 Like

partially true, yes. The label is listed as 1501 Certified Ent in the metadata. This is correct, although apparently you want it as SoSouth, which is actually the distributor. The label for both of these “versions” is listed as 1501, but for the second one, it is most correct to use 300, because that is the actual label. iTunes does not use the actual imprint label in the metadata, so you cannot really rely on that to provide what MB wants. Both are under the label of 1501, but the Dec release is licensed to 500, that is the difference. Nothing more, licensing.

EDIT: Kid Devine made edits to the release, so this topic is basically closed. It has been MB-ized. It is really unfortunate that the data here is saved in a manner that is not so usable. For the CD releases here, and I would assume the same for vinyl, cassette, etc, the data is great and was the main reason I even came here. However, I find the digital release data to be just getting worse in usefulness. The important factors needed to identify releases are not being saved, and with the efforts to add other bits of data to the releases and combining different sources, the data given in return of a query ends up being not 100% accurate to the specific release. At least for now, I will just refrain from making efforts, which is a sad thought to even have.

Your statements make no sense.

  • In the case of digital download releases, I do store identifying information - barcode, label, bit depth - which you actually complain that MusicBrainz should NOT be storing.

  • “with the efforts to add other bits of data to the releases and combining different sources, the data given in return of a query ends up being not 100% accurate to the specific (digital) release” - Why do you think this claim doesn’t apply to CD rips and vinyl recordings? When you rip or record the music into computer files, you don’t get the packaging’s barcode or imprint. That’s no different from files you download from iTunes or Amazon Digital Music. Furthermore, because MusicBrainz Recordings are shared across non-identical audio, you’ll also have false postive ISRCs or worse when you tag your computer files with MusicBrainz, regardless of whether you ripped from a CD, recording from a vinyl, or downloaded from a store.

This is completely false. I encourage you to read a bit more closely. Bit depth, yes, also container, ISRC, etc. The barcode and “imprint” are not commonly found in metadata. Yes on some it is there. But looking at the market share of the common retailers … Amazon, iTunes, Deezer, etc, the norm is that barcode and “imprint” are not in metadata.

This is possible, yes, but not false. Just a possibility of multiple. On the digital releases I have been working on, I have yet to see any issues. Works quite well, no issues for iTunes purchases, promotional material, a few lossless releases here and there, etc. Not a single issue. I do however see an ISRC issue more common on older releases and recordings. But as I have said, MB is great when it comes to old stuff.

EDIT: sorry, I missed your question. What I mean by this. For example, I tag a digital release. From this tag, my release is populated with a barcode. Many times, there is no real way as a regular non API type user to verify that barcode. So, MB is now populating my metadata with assumed information. At least for me, this is not acceptable. When I populate metadata, I expect the data to be verified to the release. Onus is on the user to compare their release to the ones in MB and find the proper one to match. Once that selection is made, I would expect that all the data on the release to be valid. But when things like barcodes are used to distinguish digital releases and most digital releases do not include a barcode, how do I choose when I need to pick between barcodes? On the recording level, yes, there is an issue. There can be more than one ISRC. There is also a potential issue on the source of the ISRC. I can tell you from my experience that when using ISRC’s that are in the metadata, I have yet to see an issue. Again, I do realize that for older releases this is more an issue.

You guys can do as you wish. I am only trying to help and have the same opinion as the others who are looking for MB alternatives. MB is the most common source of data on taggers. There is good reason for this, the CD content is top notch. However, you will find that others are writing plugins for these tagging programmers to get data from elsewhere, especially for digital releases. If you take a step back, look at why people would want another source of data, that implies that MB is not fitting the need as it once did. You can call it opinion, which is somewhat correct. But when a company stops listening to user issues that go beyond a handful of people, that is now market share is lost. I continue to bring up these points as I would personally prefer to not see that happen. For me, if I query my digital releases, I would estimate that no more than 5% have a barcode associated with them in the metadata. My digital collection is made up of iTunes, FLAC, some Amazon purchased material, then some minor random sources. I do not use rips in this because I am referring to actual digital releases, with original metadata. Just like a CD, you refer to the CD, case, stickers, artwork, etc that originally came with the release. In both CD and digital, the user can always modify things, yes, so that is not a real factor as it is there regardless… copies of CDs, mix CDs, metadata that is all scrambled (very common with those that grab mp3s off the internet), etc. Those items should not be cataloged anyway, as they are not the actual release.