Digital releases: Merging? / Long country list? / Just [Worldwide]?

Are we supposed to see country flags in the annotation?

Also, the following:

© & ℗ «2016 GREY WATERS LTD.»

Belongs to release-label copyright ©2016 relationship and to recording-label phonographic copyright ℗2016 relationships instead of leaving it in the annotation.

1 Like

in that case @chaban and @marlonob need praise I am perfectly satisfied with this approach until the interface catchs up to streaming
@jesus2099 do flags matter in this case if data is preserved ?

Yes, It’s a way to display the information in a more meaningful way, as this will only be read by humans.

This is meant to register information that it’s rarely added. The editor may omit that part and make the relationship instead, if they can and want to. If not, however, the information remains there so anyone could then add it as a relationship and edit the annotation.


I don’t see flags, neither on my PC nor on my Android.

I was addressing my little relationship remark to @chaban. :wink:

1 Like

Added the relevant ticket :


Hello everyone,

Rest assured with [Worldwide] when you don’t see China in available markets, if a release is available everywhere else. Because:

  • Most releases will make their way to the mainland China (as long as the artists aren’t banned).
  • Almost all Deezer releases with more than 10 licensed territories are licensed to CN. Deezer lists territories on the track level, rather than the release level, so this info isn’t seen (yet) with a-tisket.

Although it’s a lot more code-work to do, I still want to share the concept of territory calculator with you, which could resolve the following mentioned problems in the long term:

  • Stores get licensed in new territories, while many releases in MB entered with exhaustive long lists need updates;
  • Worldwide premiere at the same time (two dates in different timezones), while store APIs return the same date for all territories;
  • Store-exclusive premiere, available everywhere some days later;
  • Editor knows a more accurate date than the API (written date);

It works like this:
+ [multiterritories:Spotify] except IN
+ [multiterritories:iTunes]
(almost) [Worldwide] except MM
(super-long territory list except Myanmar, but includes China & India)

  • No need for editors to enter/check a long list of same dates.
  • Store territories don’t have to go into the DB. They can be stored separately and maintained by MB admins.
  • The webpage/API calculates the super-long list when requested.

Most suitable for releases with/without a Japan bonus track:

  • Japan version: JP
  • non-Japan version: [Worldwide] except JP

For same-day releases:
Input: 2019-12-03
Output: Everywhere 2019-12-03
If Spotify gets permit to run in North Korea on 2019-13-57:

  • Everywhere 2019-12-03
  • KP 2019-13-57

For same-time releases:
Input: 2019-12-03 18:00 GMT+0

  • US: 2019-12-03
  • GB: 2019-12-03
  • RU: 2019-12-03
  • CN: 2019-12-04
  • JP: 2019-12-04

For different labels:

  • XW-CN Parlophone Spain
  • CN Warner/PLG


  • US Parlophone Spain
  • GB Parlophone Spain
  • CN Warner/PLG

Complex example: Different release dates/imprints (displayed as separate release events, not co-imprints):

  • [XW:iTunes] 2010-02-01 Warner Music Malaysia
  • [XW:Deezer] 2019-02-01 KKFarm
  • XW 2019-02-15 KKFarm

This approach requires a few more computation power, but compared with the effort that all editors above have put into these issues, I’m sure it worth a consideration.

At least one new table (Digital release events) is needed for this approach, with these columns:

  • Storefront set
  • Excluded territories
  • Date and time
  • Same-day or same-time
  • Labels

The last column is not necessary for most editors, but if you have looked into the industry, you know it worth a column.


Thank you very much.

Multiple editors started adding duplicates (and merging them afterwards) for sake of more easily entering the licensed territories as release events (and track sub-seconds).

(Before I’ve only witnessed editors intentionally adding duplicates to enter milliseconds for non-CD releases)


12 posts were split to a new topic: Handling of multiple listed release countries

This seems really wrong to me (the 196 countries).
The country field is supposed to be used to store “the country the release was issued in” not where it’s available. @rdswift pointed this out much earlier in the thread:


I have to say that I’m for using [Worldwide] if anything is released on a homepage that’s not geoblocked or a multinational platform. Availability can change, but that’s not important. For me a release can cease to be available anywhere, it’s still been released.
We certainly wouldn’t ignore a release that has been destroyed completely or forbidden after being released


How do you know if it’s geoblocked or not? If it’s on a multinational platform, that is NOT worldwide. Only use worldwide if you can prove that it truly is by data.

1 Like

In those cases, the releases usually will have a different barcode, which indicates that they are two unique releases warranting their own entry; hence MusicBrainz only permitting one barcode per entry. In contrast, I have come across digital “duplicate” releases. These are releases with more than one entry across the mainstream digital retailers that contain the same track list, with the same barcode. In those cases, I have assigned all external links to the release and included an annotation explaining the situation in order to mitigate confusion or duplicate releases simply because the external link to a retailer may differ than the one assigned. This personal policy is adhered to in my own editing when I can identify them as having duplicate barcodes, and do so under the assumption there is an error on the back end of retailers own inventory, or because there are just regional licensing differences which can be indicated within a single MusicBrainz entry anyway.

My final 2¢, I usually will assign [Worldwide] unless there is a clear single market region a release is relegated to. For instance, a select few releases may be exclusive to North America. That said, more often than not those releases will have a unique barcode. If they do not have a unique barcode, I will assign both the [Worldwide] country if there’s a long country list, and then also just the select few for the release market. In instances where there may be an early release on Bandcamp/Beatport/release label official website, with the worldwide market release coming a few weeks later; I will assign no country at all to the early release, with the [Worldwide] country assigned to the more “public” release following it, even though both events may be available to the global marketplace.

1 Like

My final 2¢, I usually will assign [Worldwide] unless there is a clear single market region a release is relegated to. For instance, a select few releases may be exclusive to North America.

At the risk of drawing you back into a conversation that you were trying to exit, I think this is the kind of thing that we should avoid doing: using idiosyncratic systems that dilute the meaning of “Worldwide” while providing inaccurate data. I’ve done things like this, too, and I feel your pain. It’s probably been suggested before, but I think that for times when an editor is not prepared to add a detailed list of release events, we should have a meta-country like [Multinational] or [Multiple territories].

  • It’s informative without being misinformative.
  • It provides a queryable value for anyone who wants to look for releases that are missing a detailed list.
  • It’s a value that could be useful to Picard users (see below).
  • It makes us much less tempted to overload [Worldwide] (which should only mean one thing: that a release has no territorial restriction).

As for the Picard problem, I’m not sure that only one solution would satisfy everyone, so maybe it should be handled by a setting in the preferences. The specific use-case is when there are two or more release events with different countries but with the same release date (which is also the earliest release event). Options:

  1. Use [Multinational] / [Multiple territories]
  2. Use the Area value of the release label.
  3. Prefer a default/home country specified by the user.

I do think that we should continue to document release events, but having this extra option makes contributing much easier for new editors, and it helps MusicBrainz to ensure that [Worldwide] has an unambiguous definition.


People are still unhappy to see long country lists.


See also: A multi‐source seeder for digital releases

I believe that a‐tisket has been updated recently, because I tried to re-import a release, which was already imported into MB with 222 release events, and this time a‐tisket said that all of the Spotify/Deezer countries were accounted for, so it set the release to [Worldwide]. (Which I believe is the correct thing to do by the way.)

I actually sat down and compared the list of countries that Spotify/Deezer were presenting against ISO 3166-1:2013… because I thought it was strange that there were release events for Antarctica…

Short summary, Spotify and Deezer don’t list places like Puerto Rico, Vatican City, or the Isle of Man as countries where streaming is available… but I don’t think that means that streaming is actually excluded from any of these places…

I’m going to guess that if a release is available in the United States, then that probably includes Puerto Rico.

And if it’s available in Denmark, then it’s probably also available in the Faroe Islands and Greenland…

If it’s available in the UK, then that probably includes the Bailiwick of Jersey, Gibraltar, etc. etc.

France… Saint Martin, French Guiana, etc. etc.

I’m wondering who handles music licensing for Antarctica…

Oh yeah, by the way, these Spotify/Deezer releases are… apparently… licensed tor sale/performance in North Korea

(I mean, is that what a North Korea release event means? Spotify and Deezer don’t exclude North Korea… they explicitly claim that this release is available in North Korea, and Antarctica.)


I still don’t know why the release list (assuming it’s 200+ countries) has to be represented either in the release country list or in the release annotation. Isn’t the best place where this territory list should be the Spotify/Deezer URL itself? I know there is currently no such option to add but perhaps there should be something like URL annotation? Or maybe even territory availability list for all streaming/download URLs?


I thought about this too. But, Not all iTunes or Spotify releases are available iTunes or Spotify wide. Many labels have restrictions on where they released. Unless you created something like Spotify Worldwide or iTunes Worldwide, etc. Most releases have at least 2 digital versions and many have more than that.


Adding hundreds of release countries doesn’t add any benefit over using [Worldwide]. When you list almost every locale, it’s the omissions that are interesting. This somewhat reminds me of the time an editor added over 100 Wikipedia links (back when we still did that, with English + native language being the consensus at the time) to Mozart. But he forgot the German one.

And blindly trusting data from sources like iTunes, Spotify etc. means we end up with tons of dubious information. For the record, there are just above 6500 releases added for Heard Island and McDonald Islands, an uninhabited island group situated about 4000 km away from any permanent settlements. And some of them are using obvious placeholder dates, often January 1. This release entry claims to have been digitally released on New Year 1973.

Also see, which led me down this rabbit hole.


these country lists with 200 - x countries are crazy. That’s my opinion. Worldwide would be better even if it is not 100% correct.