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

Well, the problems are mentioned on my post: they actually are making the site work significantly worse, and there aren’t any great ways to avoid that either that we have seen in the team :slight_smile:

7 Likes

But if a distributor says it was released in Fiji than it was. I agree about the dates. That’s why I suggested several times to use a date only once on a blank country or new “digital release” would work for this and then just list the rest of the countries without dates. However, we could shorten the lists by having continents available or Worldwide less certain countries, etc. But if we have to because of time outs, I understand. I agree that maybe “digital release” is better than a long lists when there is only 1 label that has it worldwide though. However, there are some bands (i.e. Pink Floyd) that have 2 major distributors and I believe that information of country distribution is important. If there was an “except option”, then lists of 52 countries (Europe) & 180 countries (outside of Europe) could be 1) Europe & 2) Worldwide, except Europe.

3 Likes

TL;DR: Let’s use the “worldwide minus X,Y,Z” format. Actually, let’s make streaming a separate thing completely. Default behavior is what matters. Some editors are aiming too high.


So I finally took the time to read through this entire thread, and scroll through a few others. And I would like to give my opinion, even though I am only a beginner here on MB. Absolute wall of text coming.

I arrived here wondering about these giant lists of countries, which to me felt like noise generated by a script. Turns out, it is indeed a script, and my opinion is shared by a significant fraction of editors. I wanted to find arguments in favor of keeping these before deleting anything, and found some here, so thank you all for the discussion so far!
But I still believe these lists are too much. Again, I only joined recently, so it’s not about the interface being broken/ugly anymore. I genuinely believe the current way of saving this data hurts the database more than it feeds it, for several reasons.

We have established that the list of dates and countries a-tisket provides only mirrors the date of query, and does not represent the actual release events. It only tells you where you can listen to it now; not to mention the modified, retroactive dates.
In a perfect world, this data would be corrected, checked before submission, and corrected again by peers, making it accurate and worth keeping. But we are not in a perfect world. I don’t expect anybody to manually correct all 200+ events when adding a release. And I expect such releases will be checked and corrected once submitted even less.

a-tisket is a great tool, and I want to thank @marlonob for releasing it. But as with any tool, we are left trusting the person using it. Thanks to this tool, the energy barrier for submitting releases to MB is significantly lowered. But this in turn invites editors less concerned with data quality, and a bulk of releases hardly checked.
Yes, nobody should take a-tisket’s output as gospel, and we should always double check everything. But while I admire the high standards some people in this thread set to themselves, I will not trust any user to do the same.

Which is why, whatever the final consensus is, I strongly recommend an update of a-tisket’s default behavior. Lazy editors will remain lazy; perfectionists will remain perfectionists. It’s the middle ground, and bulk of our userbase, we have to accommodate for.
Making submissions easier to invite additions, while maintaining high standards for the final result, is a very delicate balance, but one we must strive for. I am confident “quick and dirty” submissions were not @marlonob’s goal when they developed the tool for themselves; but if it can be used for that, then we have to assume it will be. Which is why I believe the script’s default behaviour is the most important.

Now, back to the countries lists.

I hear the arguments in favor of, and against, using “worldwide” or a different flavor of it for digital releases. But the point that the database needs to be user-friendly is valid. We need to invite collaboration if we want our submissions to be checked and the data to be improved. For this, things need to look concise. I don’t believe anybody wants to scroll through 200+ countries for every version of every album, when submitting to or browsing MB.

As many already suggested, I believe this issue could be addressed by subtracting countries, instead of adding them. We could mark any digital release by default as “web”/“streaming”/something, and add countries that are excluded. This could, of course, be reversed for small-scale online releases, such as e.g. the DACH regions mentioned previously. But a special location, that is known to be a “dirty worldwide”, would keep things visually simple, make it known that some detail may have been lost, and allow other editors to see and therefore verify it more easily.

Whatever system we decide on, there will always be exceptions and imperfections. Which is why I insist on keeping the default behaviour adapted to the most common situation. In the case of online music, the common occurrence is “almost worldwide”, which is why the “negative” version (assuming worldwide and adding non-releases) is the only one I can get behind right now.

But you know what?
I don’t even like streaming, on MB or anywhere. And it might be relevant to this whole can of worms.

Thinking about this whole issue, I was first seeing things as a consumer trying to access the music. Where can I buy a CD? Where can I listen to Spotify? This was challenged by people comparing streaming to a delivery rather than a release, or a mix of the two. But the differences are larger.

”Digital release" has been used pretty vaguely AFAICT. I believe we should split it, and make the difference between music streamed and music available through download. In the latter case, I can own a copy of the music, just like when I buy a CD at the store. My hard drive may break just like the CD may get scratched, but until then, I am free to listen to the music any way I want, wherever I am. In the case of streaming, my enjoyment of the music will always be conditional to the platform, their geo restrictions, and their contracts with the labels. Nobody will come to my house to take my CDs, but my favourite album might be deplatformed from Spotify tomorrow.

Now, I agree that music not being available to stream anymore does not warrant its removal from MB. I am going further, and claiming it wasn’t even released by the streaming platform to begin with. Streamings can and should be registered into MB, but in a way different than releases. Was a 90s tube “released” when I could hear it on the radio, or when I could buy the cassette tape?

Maybe we can’t reach a decision about date & place of “release” because it’s the wrong way to think about streaming.
I’m happy to start a new thread if people want to discuss this point somewhere else.

Finally, and stepping back a little bit, I would like to quickly express a concern. Some people here seem to wish for a level of detail that I personally find excruciating. Listing every country and island on Earth and implementing hour of release per country seems ridiculous to me, when in contrast some albums don’t even have a known artist.
Of course, my beliefs are not reason enough to discard data; neither is the fact that this data is lost/never existed for older releases. But it is not worth raising our expectations for new releases and editors, either. I would rather see longer descriptions including such footnote-level details, than force everyone to deal with forms cluttered with such fields, fields which in most cases will at best remain empty and at worst contain wrong information. Again, we have to keep in mind the average submission from the average user. I don’t believe this data will be known most of the time.

Which is why I humbly suggest that we lower our standards on such issues, and focus our energy on other pursuits requiring editors’ attention. Not to mention such a level of detail might scare off newcomers.
Please, do not bite more than you can chew. There is such a thing as too much information.

Anyway, just my few cents in way too many words.
Thanks again to everyone contributing to this conversation, and to MusicBrainz in general.

12 Likes

I think debating the legitimacy of streaming releases goes way beyond the scope of this topic, and you run the risk of creating a neat definition that may suit your personal needs but alienates a large fraction of the potential userbase (because like it or not, streaming is how most people get their music today).

4 Likes

Sorry if my previous reply came off as aggressive towards streaming haha. I completely agree that it is the main way to listen to music nowadays, and kicking it out of MB would make zero sense. I’m only suggesting a different format than “Digital media” for steaming services, for which different rules regarding release date and location could apply, instead of the giant lists of countries originating from a-tisket. But yes, this does deserve a new topic if the idea seems reasonable at all

1 Like

You might be interested in this thread: Is Digital Media good name?

1 Like

I actually hate…yes, HATE how their are a huge list of countries. It looks messy, these releases update my music with a country that isn’t the US when I update my music through Jaikoz. IMHO this topic has become so blown out of proportion. Is this music available mostly worldwide…then worldwide is what should be shown. If you are looking at “release events”, I believe this is the wrong place to be putting that information–you should create a separate field(s) for that data. People that are that interested and want to be that specific can spend their time populating that new area of data.

5 Likes

After having a few days to think about this, “digitally” released would be a great compromise. I have no issue with this, and it seems most people responding like it. I hate having all the countries in the annotation, but that’s only because it’s duplication from the release events. Now it’d be necessary if we want to preserve distribution data. We can add/re-add them from a-tisket and add them to the annotation.

I know I’m probably the only one, but I’ve added release events from countries that were from the distribution lists on Jaxsta and not just a-tisket. If this release event is added, it’d be cool if there was someway to autogenerate the annotation from the existing release event lists. Adding those countries took a long time. Yes, despite what some have said in this thread, there are some of us who took the time to add 100s of countries manually. To me anyone who engaged in calling releases without countries Worldwide after a long list was already on this engaged in destructive edits. So, this compromise would benefit everyone.

6 Likes

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