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

I personally believe that music released digitally on the Internet should be marked as [worldwide] because typically the intent (by the artist) is to achieve the widest distibution. Further, I think that much of the “problem” with the long countries lists on the release are because people are trying to capture “availability” location rather than “release” location (whereas “release” location is more appropriate to a physical medium).

Perhaps a long-term solution would be to add a new (sort of) relationship to capture “availability” locations (countries) with start and end dates for digital releases. This would also allow capturing the availability history (e.g. originally available in country ‘x’ but later blocked or originally blocked but later unblocked), without having to constantly try to update the countries list (either in release countries list or annotation).

7 Likes

While that might be true on self-released Bandcamp or Soundcloud releases, major streaming releases on iTunes, etc. usually have labels and typically more than one. There are many digital releases that are only available in certain areas due to label restrictions. So, Worldwide is not accurate at all unless it really is Worldwide. It’s annoying that just because it’s on iTunes people automatically put Worldwide and it turns out it was a US only release. Very common. Also, very common for it to be Worldwide, except US and the US release have a completely different label. So, it makes sense to see a release not include the US and then have one that is US only. This is accurate. Worldwide on a release that has different labels in different areas is just wrong. Also, I find it informative for when releases aren’t available in a bunch of countries because they are explicit releases. They aren’t Worldwide. So, having a digital option for date and listing the countries in the annotation is a better solution, than just saying everything is Worldwide if it’s on the internet.

4 Likes

Or perhaps “[internet]” rather than “[digitally]” just to more closely match the location rather than type/medium of the release? That should also help satisfy those that are opposed to using “[worldwide]”.

9 Likes

Can’t we just agree to ignore Russia, Belarus and certain small islands? This would make most releases [Worldwide] already and we can just put in the annotation that these are excluded like some of us already do. I do, however, believe that the extended country lists should still be used for releases that get distributed in different continents by different labels.

3 Likes

Yes, having lived in the US and the UK, my experience is that itunes is country specific

  • so is Netflix.
  • and Pandora
  • and amazon
  • and …

They enforce the rules based on where you are trying to watch/listen to the content vs where you purchased it. This is where it was released The reason why is that they enforce the licensing restrictions for the content. The licensing restrictions for older content and more mainsteam / high volume is usually country specific. Bandcamp and Soundcloud might be ‘worldwide’, but this not the same as every country in the world due to export restrictions. I think there is no such thing as ‘worldwide’. There is a list of countries that was the valid list at the time of release and that’s the list we should use. Countries come and go, but the list valid at that time is the same list. The UI should just hide it, ideally nicely.

1 Like

I’m in line with @rdswift proposals considering the current system. It was designed to represent Physical releases and Digital world creates new/transforms/exacerbates the problematics to handle (see NB). As of now we are trying to fit “Digital releases” as we can into MBz, even by altering the initial logical/behavior behind the fields which is far from accurate to preserve those data.

For instance:

  • Country differences among stores. As said upper Bandcamp being WW whereas there will be restrictions on Spotify (ex: “Paradise Bangkok: The Album, Vol. 2”)
  • Similarly some releases won’t be available on all plaforms and/or not added on same date (ex: “Les Forêts natales” being in Spotify/Deezer but not iTunes)
  • Removed releases/Excluded countries: This was added only recently to MBz and not by deleting the release event (see Announcement: New release statuses "Cancelled" and "Withdrawn" and ex: Body Count album due to Cop Killer song)
  • Those limitations can also happen on track level
  • a-tisket don’t cover all platforms (ex: Qobuz, Beatport, HdTracks, Tidal, Bandcamp, Junodownload, Amazon,…)
  • It’s almost impossible to get access to all of those informations, especially in the past (ex: Hard to list all the release removals & reissues from HDTracks)

So having release Events to show WW (or Internet) and first date available is indeed not perfect but at least not wrong: In most cases files are the same among the different countries and even there are restrictions those can be easily bypassed. We could assume that today’s releases were made having this in mind (for instance release day was changed due to those issues Global Release Day - Wikipedia) and the availability dates can be set directly on the linkimage then (for now) dedicated/excluded countries/labels go in annotation.

Oh and as we are speaking about release events, could we set a minimum date to Digital Media (at least 1990)? With platforms showing the intial release dates we see more and more WEB releases from 70’s, 60’s,…

NB: I remember those topics are being discussed for many years Digital releases - #75 by thwaller) but no clear answer or update to guidelines ex: What should be considered a different release for Digital: tracklisting, barcode, format (24bit, mp3,…), platform, download/streaming, label…? (seems the consencus is around tracklisting and Barcode to avoid multiplying the entities but there are cases where the platform and/or format have made splitted ones); Which data do we want to store: Only related to music or also ones coming from platforms/stores (ex: Track credits vary depending of stores and can change in time, “Fake” releases which look more playlists, Do we consider Streaming as radio or as release,…)); …
Those are not trivial as they can have an important impact on system. ex: it seems we want to reflect the evolution in time but this concept exists only on the relationship level as of now (begin/end dates). Other fields and functions are designed to reflect a “picture” at the initial release time (which is normal with the constraint of physical :slight_smile: ).

4 Likes

I’ve added the digital Thai release of the album - I don’t see how it would be more useful with both releases having the same country/[XW]?

Where the only differences are defined by regional publishing agreements that makes a regional overview even more important (not saying I think long country lists are the answer ofc)

the example shows a different barcode for each country

1 Like

Yeah, but the only reason they have a different barcode (otherwise one release would do the trick) is because of regional publishing, ya know.

Nicer to have a human understandable touchstone rather than “hey check out five oh five six oh three two three zero eight four oh four, that’s distributed by…”

Thanks, it gave me the idea to push some tests since I got a Thai IP

Results:

Connecting to the stores
I have access to all the pages then:

  • Deezer: Only preview for both versions as Deezer Free is not available in Thailand

  • iTunes:

  1. Buy: Work on both versions
  2. Streaming: Preview for both when not connected. If connected Thai version shows Play button (but don’t have a membership so still preview)
  • Spotify: Access to all songs

  • Bandcamp: Access to all songs

  • Qobuz:

  1. Buy: I can add to my cart no matter connected to my account or not, WW release?
  2. Streaming: Qobuz not available in Thailand

https://atisket.pulsewidth.org.uk/

  • Deezer:
    Thai version returns Thailand & UK as Available but Ticking “Ignore vendors” Returns Thailand only
    WW version Returns Thailand as excluded

  • Spotify:
    Returns Thailand as excluded
    but Ticking “Ignore vendors” Returns Thailand & Russia as excluded

  • iTunes:
    Thai version returns Thailand as available in both cases
    WW version returns Thailand as excluded but Ticking “Ignore vendors” and “Search iTunes globally” Returns Thailand & China as excluded

https://etc.marlonob.info/atisket/

  • Deezer:
    Thai version returns Thailand & Mexico as Available but Ticking “Ignore vendors” Returns Thailand only
    WW version Returns Thailand as excluded

  • Spotify:
    Returns Thailand as excluded in both cases compare to other server (but Russia don’t appear in list of available countries)

  • iTunes:
    Not working

To summarize:

  • Cannot get accurate data: Different results depending of server used and/or options ticked
  • Countries resistrictions seem to vary among the stores: Hard to confirm out of Bandcamp as for Spotify/iTunes/Deezer it could be linked to issues with a-tisket and for Qobuz there is no API to confirm it is set as WW. Also (maybe already known) but rights differs between apple music and iTunes store
  • Those restrictions seem not effective: I can listen to all songs on Spotify despite Thailand being excluded.

Remain to test the thai version (5056032308404) by an user out of UK, Mexico, Thailand to see if it plays previews or full songs.

Funny points:

  • Apple discreminates seniors:
    image

  • Qobuz flags me as using a VPN despite I was not

  • Deezer have a Thai only release when the service is not even available in Thailand:
    image

8 Likes

re: “Apple discriminates seniors” - there is no one left alive who was born in 1900. They would be 122. So I think Apple would be allowed to ban them, unless they are now allowing Zombies. :zombie:

Nice research… next what you need is a Time Machine so you can see what the results were last year when companies where happy to sell to Russia…

Also you mention “no Digital Media before 1990”. It is more likely 2001 and later with only a few exceptions maybe for Napster? Each shop on A-Tisket has a known start date (see Wikipedia). But at least these entries stand out a mile. It is when stuff appears dated 2004 it is harder to know if this was the real launch date on Digital Media. Those shops like vague data to make us think they always existed… :slightly_smiling_face:

2 Likes

There were definitely tons of Digital Media before 2001, even distributed over the internet. The reference implementation for MP3 was published in 1994, but even before that there were tracker formats or MIDI files that allowed efficient transmission even over the slow lines of the time.

Showing a warning if the claimed release date is earlier than the creation of the platforms is probably a good idea anyway though, just not a hard cutoff.

5 Likes

I was thinking more about these scripts that are connected to a limited set of shops. If shop data is their source, then they should not be selecting a time before the shop existed.

As a percentage the “tons of Digital Media before 2001” is likely pretty small and never coming via a script

With physical media, if we have a doubt of a date we leave it blank. If a script sees a dubious date, it should leave it blank. That would allow the user to fill something in if they have another source they can show for the date.

1 Like

Hello, I’m a new MusicBrainz user (joined last week) and just wanted to share my experience as a newbie and my confusion as to how to add digital releases, which is the vast majority of the releases I add.

TL;DR: adding digital releases is confusing for a newbie with no consensus on how to handle release events and lack of official, up-to-date docs about this

I’ll admit when I first started adding releases I didn’t read through the documentation or style guide and just jumped straight in, using [Worldwide] for the release country because I naïvely assumed ‘of course it’s worldwide, it’s on Spotify/YouTube/Bandcamp’.

I then started noticing the a-tisket-generated annotations and long country lists on many releases, and spent some time finding this tool. Now, I use a-tisket to add releases and update existing releases (even wasted an hour writing a little script to help me with this before I discovered texke’s userscript) with annotations and release events, assuming that this was the preferred way to handle digital releases given how commonplace this is.

Then, I stumbled across this thread and took the time to read through the entire thing. I’m now more confused as there doesn’t appear to be a consensus on what to do.

I’m sure you’re all aware of this, but a user trying to figure out how to handle digital release events will probably consult the style guide and read this:

If you are entering a digital release, the country will depend on where it is available from. Pages like Bandcamp, SoundCloud and other similar sites have no region restrictions. In this case, it is safe to set the release to [Worldwide]. For releases from shops like Amazon or iTunes, that have region restrictions, it is safest to choose the country of the shop (if you’ve bought it in the French iTunes store, use France). Remember that you can always leave the field blank if you are not sure!

As such, it’s understandable that they would use a-tisket and those long country lists in order to reflect where the release ‘is available from’. It’s a little concerning to me that this issue has been debated about for years yet the docs haven’t been updated and users conforming to the style guide are having their edits rejected.

FWIW, here are my thoughts on this issue:

  • The accuracy of the MB DB shouldn’t be compromised by aesthetic desires to shorten release event lists or some finding the UI of the web interface ugly — I believe MB’s priority should be its value as a machine-readable source of reliable information
  • However, as many have pointed out, available_markets etc. returned from vendors’ APIs do not accurately reflect the release country and change over time, creating issues for releases added to MB years after the initial release date
  • The web UI should have an option to display many release events with the same date as e.g. ‘[Worldwide] excluding Russia and Belarus’
  • If we decide availability of digital releases is something we want to store in the MB DB, maybe there could be a property on releases that stores what countries the release is available to on a particular date, kind of like "availability": [{"date": "2020-01-01", "countries": [/* all countries */]}, {"date": "2022-03-01", "countries": [/* all countries excluding Russia and Belarus */]}]. This could be a way of accurately modelling the information we have about the availability of releases at a given time, especially when the countries that the release was available to at the time of release is unknown
    • However, I’m not sure this level of information would be useful to anyone and it seems excessive
    • Alternatively, maybe a property as_of on release events to represent when the availability information was retrieved, with that property ideally being as close to the release date as possible
  • Then again, is it MB’s job to record such fine-grained information about the various geo-blocking and political events resulting in North Korean, Russian, Belarusian residents etc. not being able to access some digital releases? I agree that for releases only available in a handful of countries (e.g. Japan-only releases) there should be a release event for every country, as it seems like the artist/label’s decision to have exclusive releases for particular countries. But for the Russia/North Korea issue, is the artist wanting/intending to release to all countries except Russia, or is it because they are simply unable to given the current political climate?
    • Maybe it’s worth distinguishing releases only available in a few countries from releases available in all but a few countries. I like the idea of an [Internet] pseudo-country for the latter

Sorry if none of that made sense I didn’t mean for this to be so long.

15 Likes

I’m on the same boat here, though I’m not a new user, my new account is, but my old one dates back to 2017, so I’ve been doing this for quite a while and there have been tons of releases I’ve added and edited using a-tisket. Now I honestly don’t know what to do, I even added the new Noel Gallagher’s single as [Worldwide] but it feels wrong because it doesn’t include Japan as Japan have their own distributor and barcode. This make it seem like the Worldwide releases include Japan but you would only know it doesn’t if you read the annotation, which many editors ignore.

The lack of consensus is also bringing some editors to vote down certain edits while other editors immediately approve others. Like, why was this voted down and this was approved? The latter was recently changed to [Worldwide] but the other releases of the Post Malone single remain with the long country list. Call it OCD, which I do have lol, but this lack of consistency is making me wary of making new edits.

I know it’s not easy to make a decision, but we need something to be done about this and have it included in the guidelines, so we won’t have votes based on personal preference on a topic that it’s still on-going. Nothing against @chaban or any other editor, it’s not personal, I’m just pointing out that this is also creating an issue on how editors should be making edits and adding new releases moving forward because I honestly don’t know what to follow anymore…

8 Likes

Wow, nice testing!!

To be honest I don’t think the specifics are all that important. The country field is not a hard rule like “you can never get this release in x country”. For physical releases as well. It’s really just another way to disambiguate a release.

We keep saying ‘Thai version’ for a reason right! It’s useful and it reflects artist/label/distro intent.

The long country lists are partially to blame for this problem… Because they look complex they give the expectation that country information is/needs to be perfect. Another reason why the atisket (and mb) long list method isn’t great (but I think removing all country data from digital is an over-adjustment)

2 Likes

The first commercial digital single was 1992. And no iTunes until 2004. I honestly think that there are very few releases from before 2004 that still exists today. I always check mora.jp now for release dates. They are the most accurate in my experience.

4 Likes

I agree mostly, but just because it wasn’t on that particular shop doesn’t mean that it didn’t exist before that. I mean, releases were on iTunes before Spotify or Deezer even existed. So, it’s totally possible that a release on Spotify with a 2004 date could be the same release that iTunes might have had. So, any release that was on iTunes in 2004 could have been available on any service or directly from the artists websites themself, etc. Remember, the services are just the store front in reality. That’s why it can be so hard to nail down an actual release date from this time. I try to check out archive.org and see when a site first gets archived as well. Also, yes. I’ve seen plenty or digital releases that were just added manually that have dates well before 2001. It’s just inexperienced editors and they typically get fixed rather quick unless it’s from an artist that doesn’t get a lot of traffic.

2 Likes

I agree, to my point it just means that this option should be let to users who know what they are doing (= defaulting a-tisket to WW).

The other interesting information we can get from those is (as spotted by @tigerman325) that the data are stores dependant so, with the current guidelines, make them belong more to relationships than release events.

But this option do not exist today and making quick devs, moreover mostly driven from a “technical” point of view is neither a good idea. System was not designed to handle all the problematics that raise Digital so, in my opinion, it just put back on table the need of workshops around this: What do we want to archive, Does it makes sense, Is it feasible, What are the hypothetical worst cases scenarii, Review release definition, How it would look,… then required changes could be designed properly and guidelines updated to let editors know how to handle those releases until changes can be delivered since we’ll know the target.

Happy to help with more tests & researchs to feed the discussions from those meetings :slight_smile:

2 Likes

Let’s assume that some music is licensed to be sold / streamed without restrictions on location by its owner. There’s a suggestion that this is marked in MB as ‘world wide’.

I do not understand how ‘world wide’ makes any sense. I interpret it to be a short hand to
mean “all the countries in the world”. This is imprecise and not accurate enough:

  • the names and number of all countries in the world has changed has changed over time (and will change in the future). So “world wide” is not meaningful without a date and then a reference list of the countries valid on that date. Instead, it is more practical to just list the countries and forget about ‘world wide’

  • Available to listen to and/or buy ‘world wide’ is unfortunately unlikely because it requires there to be no restrictions to ‘export’ and ‘import’
    a) no government sanctions in place restricting sales to any countries like Russia, Iran etc
    b) even if the streaming network offers the content to a country, there are no restrictions in that country to buy the content. There are restrictions like this in China, North Korea and others.

Unless both are true, a list of countries is needed and ‘world wide’ is not useful. If we are lucky enough to live in a truely open world, then a list of countries will also support this scenario.

Conclusion: stop using ‘world wide’ and instead use a list of countries.

1 Like