Are you sure you aren’t streaming Shadow - Single by Triplo Max | Spotify in place of Shadow - Single by Triplo Max | Spotify ?
4 Likes
I can stream both fine but only Shadow - Single by Triplo Max | Spotify is visible to me on artist page. Which unsurprisingly is licensed to Germany.
1 Like
Well, https://open.spotify.com/album/5hBbYosL96xrrmAVSxr5v6 is the “available to zero markets” version of https://open.spotify.com/album/415m7ofwksKlV6Ke8WPJdc . The track in this album shares the same ISRC TCADY1802862 which is presumably how Spotify determines if you can stream a track from an album that isn’t actually available to you.
As you probably noticed, the sound copyright information differs from https://open.spotify.com/album/13HMpsY3PVzkyi6LMDhArI even though it’s the same recording.
Anyway, my point is that I haven’t experienced the Spotify API returning incorrect available markets, and Spotify does some fancy redirection for end users, so the answer to your question is that the API isn’t faulty and it’s not a stale data problem.
6 Likes
I can attest to yindesu as I’ve had two similar Spotify releases where the licensed countries are different but actually contain the same track(s) with the same ISRC. The tracks can be played on either album page but only one is visible from the artist’s page.
1 Like
I think the community needs to get out of its own
for a perfect example of what i think should be done this keeps the data its easily editable its all there but does not break the interface
bless you @chaban I do not see any drawbacks to this method and since we as yet have no really set a standard without going in circles this should be it
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.
5 Likes
I don’t see flags, neither on my PC nor on my Android.
I was addressing my little relationship remark to @chaban. 
1 Like
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
Output:
- US: 2019-12-03
- GB: 2019-12-03
- RU: 2019-12-03
- CN: 2019-12-04
- JP: 2019-12-04
For different labels:
Input:
- XW-CN Parlophone Spain
- CN Warner/PLG
Output:
- 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.
10 Likes
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)
5 Likes
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:
13 Likes
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
5 Likes
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:
- Use [Multinational] / [Multiple territories]
- Use the Area value of the release label.
- 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.
6 Likes