This super-long country list seems kind of crazy to me. For example:
But I concede that I don’t have a solution.
3 Likes
Oh that is a funny variation of it. I thought the “available to buy in this store” link was supposed to be limited to the original country? LOL!! Madness. 
It makes “available to buy in this store” pointless if that is done. In that case, that also means Amazon should get every store on the planet listed for their CDs? And so should my mate’s record store… Yeah. that one ahs got silly.
-=-=-
Back to Detective Work. Thank you @bflaminio for the Paper Lace example of Release Dates…
So - Paper Lace is a June 2012 release? Back to Wiki and the iTunes version of that “territories by date” list: iTunes Store - Wikipedia
Lets select INDIA again. On that list is say “India from 4th December 2012”. So that says is was not available via iTunes in India in June 2012.
Look at the MB list of daft countries for Paper Lace… err… yeah, there is India. Claiming you could buy this in June 2012 via iTunes India.
I could repeat that with many other countries for on the list.
The API is duff - it is returning TODAY’s territories and not the RELEASE DATE territories.
Okay - so that is a Size 9 Boot into the Spotify and iTunes lists. Any more? 
5 Likes
That’s perfectly possible:
Territorial variations in Release desciptions
Metadata in different languages
ApplicableTerritoryCode
ApplicableTerritoryCode vs Deal Territories
Your example release is indeed really crazy. Even looking at the edits in the edit history of this release looks pretty rough to me. I don’t really mind the UI displaying all links, but imho there is no need for different regional links with the same album id to begin with. I wonder if it would be better to just have a one link without localization (https://itunes.apple.com/album/id644152001) and the mb UI letting us pick which localization of the link we want to visit? Or something along the lines of that.
1 Like
That’s a US iTunes link. There’s no such thing as an iTunes region-agnostic link.
As it happens, the US is not one of the iTunes links listed on https://musicbrainz.org/release/128fea20-85f5-4604-9c07-6792bf5a369f, and your US iTunes link doesn’t work.
2 Likes
Given that all of these entries seem to be fault of a bad API they are wrong and although worldwide is also wrong I believe that when a artists chooses to make a digital release the intention as always to reach as large a audience as possible given any restrictions at the time with that in mind even though the terminology is poor worldwide is our best option at this point in time we still need to fight for change in future could we not adapt the term multinational for lengthy lists?
I’ve made a userscript which might interest some of you. It reduces the length of long lists and adds a “show more/less” button. It was originally made a year ago because I got annoyed by the long AC lists on the artist/works page which made it hard to compare works.
I recently modified the script a bit so that it now also hides items on long country lists which recently have become a bigger problem. It currently only hides countries on the artist pages (release, RG and artist/releases) but I might expand it later so that it to also hides countries on pages that displays edits. The number of work ACs and countries shown are both set to 5, but that can be changed in the settings section of the script. I’ve only tested the script on the latest version of Firefox with Greasemonkey and Tampermonkey.
13 Likes
I think adapting multinational as opposed to world wide can we all agree?
2 Likes
From my reading of the thread, there are (at least) three cases here:
-
True worldwide releases (bandcamp, soundcloud, artist website, etc.) The existing ‘worldwide’ works fine for this.
-
Regional/national licenses, as cited by @yindesu upthread. For instance this Tokyo Girl single has DM releases on two different labels, one Japanese and one British. Is using ‘multinational’ (or whatever is settled on as meaning ‘lots of countries’) for both of those the best approach? It seems like we’d be losing potentially useful information.
-
Single-label, widely-distributed releases. I think this is the case that the ‘multinational’ solution is aimed at. It seems like a reasonable approach, but only applicable to a subset of digital releases, so I don’t think we should make assumptions as @jesus2099 suggested upthread based on the format alone.
6 Likes
IMO calling the concept of “released as widely as (practically) possible” [Multinational] instead of [Worldwide] doesn’t make much of a difference. The problem lies with where we draw the line between releases like this and releases that are released in a specific country on a store/platform which also does the former.
BUT multinational is more accurate then our current definition of worldwide
“Multionational” would appear to apply to any release with more than a single release country, which is not the point either.
3 Likes
Not necessarily we set a hard limit on number of countries listed anything that exceeds said limit as in API edits would then use multinational
This is why is important to have this data in the database as soon as possible: if we added the list on the release date, then, after, if the same release becomes available in other country or a new country is founded, merged, splited… then someone could add that country to the list and be registered as such.
Is as they say: Perfect is the enemy of good.
I haven’t seen that in Spotify or Deezer. iTunes, however does it frequently.
This is a perfect example of why this lists are necesary: At first sight, the release may seem to be released as widely as possible, but there’s one key country which is absent. Nobody will examine every country listed so they could add or remove, what?, territories?, continents? That’s what computers are for, and they need data to make this happen, data which is being provided in this lists.
So, yes: This approach breaks some pre-conceptions. But MB is a database, and there’s no such thing as too much data in a database.
Yes, the details gathered from the APIs may not be complete, and some dates may be inacurate, but this is an editable database. Any erroneous data may be corrected if detected.
Thank you! This is really helpful, and may put some minds at ease.
2 Likes
That would be a nice solution for browsing.
Updating every digital release available on one of many streaming services whenever the regional availability of one of these is updated (often for completely inscrutable business reasons) does not seem feasible.
When data through sheer scale appears to imply a level of accuracy which is not actually there, there very much is.
9 Likes
Neither it is to record every piece of music ever written, recorded or released, but here we are.
And what are the rules for this implication? In releases where there is only one country registered, is it implied that it was released only in that country, or that it was released including that country? What if it had three? six? ten? I don’t think a list of release events in MB could ever be considered complete, so why would this accuracy should be demanded just for releases listing dozens?
Puting it in another way: If what you’re saying is that listing that many countries implies that any country not in that list doesn’t have a release event, then that is an erroneous implication which fault lies on the interpreter as MB desn’t have a way to asses such claim about any release.
2 Likes
Are you going to enter + vote on those edits? Because I definitely won’t. Store availability data would need to be centralized (i.e. managed in one place in the database) if this should become the official strategy.
I don’t mind many release events in general, but in the specific case discussed above, the release events the API claims are so obviously untrustworthy that they should be disregarded completely, IMO.
4 Likes
Spotify is not the only digital vendor/distributor. The fact, e.g., that India is in the API tell us that the release is licensed there; if Spotify became available in India only in 2019, that doesn’t mean no other store had it before then.
I must clarify that those edits are the result of gathering as much info as possible, not just random data. I even, when possible, query every iTunes store (arguable, the most widespread vendor in the world). The fact that most vendors don’t have an open API or even show the complete data in their pages doesn’t make it easy, but one have to try al least.
4 Likes