@IvanDobsky Bless you for all the hard work but this still begs the question how should we handle this? I say keep "world for now while fixing these current list but moving forward lets maybe go by region and then as you said have the Gui some how tell you if its available to you
@MJmusicguy - it is not exactly hard work to look on a dated list on Wikipedia. What was getting me was this total belief in a list that seems to have no connection to reality. I never saw a “when” on that list. Clearly the “when” is actually “Now as the API Runs” and not “Release Date”.
“By Region” would also be incorrect. Region for who? Spotify? Deezer? iTunes? They all work on slightly different regions.
[Worldwide] is closest, but still very wrong. China? They are in the World, but can you buy through the above services in China?
And surely it is important as to which digital service as sometimes tracks are exclusive to one service or the other.
(I have no idea what the end of your post is trying to say as your Speech Detection has gone mad )
Sorry I don’t have an answer. I’m just picking at the details from both sides. Looking for holes.
@IvanDobsky fixed well then i think we can live with world for now because physically in the case of stone cafe it was only ever released physically in Hong Kong and Japan but we can assume the label wanted digital to be every service possible at the time so would should be ok?
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?
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.
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.
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.
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.
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.
What was getting me was this total belief in a list that seems to have no connection to reality. I never saw a “when” on that list. Clearly the “when” is actually “Now as the API Runs” and not “Release Date”.
)
