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

I have ordered from Amazon.de to deliver to UK. And ordered from Amazon.com (in US). So yes, they would ship to anywhere you pay for. It is just shipping costs and will also add import taxes etc.

The simplified way I see it is object is released in a country. Stacked on a shelf in that country. And Shipping is the next stage to get it to the customer. In the Digital Media world these two steps are combined which is why we end up with these weird long lists of countries on Digital Media that don’t occur on physical media.

In this example, the fact they don’t ship to a random list of countries is something for annotation.

As an added PS here - if they sent a crate load from Texas to the UK or France and then sent the European orders out from that crate, now we have a “European” release as they did a separate distribution step.

2 Likes
1 Like

We need an option to choose between point-of-time release and same-day release.
Example: UK (origin) 2022-10-15 00:00 to GB|HK|US
Same UTC time:

  • GB 2022-10-15
  • HK 2022-10-15 (08:00 CST)
  • US 2022-10-14 (17:00 PDT)

Same day (existing model):

  • GB 2022-10-15 00:00 (UTC)
  • HK 2022-10-14 16:00 (UTC)
  • US (west) 2022-10-15 07:00 (UTC)

It’s okay to store territory list for the same release “event” separately and simply shows Worldwide or Multi-territory to the end user.
Just make sure it’s allowed to add another date for a specific release-territory combination manually. (e.g. when the previous licensee’s rights expire and the new distributor is allowed to add that territory code to one of its existing digital release at a date different to other territories)

Re. specific dates for regional changes: Do we often have that level of detail available?

I personally think setting one date is fine, and putting details, if known, in the annotation. But that’s because I would rarely know that kind of info, not from atisket/the digital source anyway.

Did you see the ‘click twice if this region was later added or removed’ function suggestion? I can tell that you want something much more granular, but I’m not sure it would be use much. But we can always optional date fields to each area as well. Would you use it in tagging or anything like that?

Re. Timezones… I don’t know how to deal with that at all to be honest. I don’t know if MB has ever dealt with that in any way. If you can give suggestions re. how we could do it (UI + display + schema/end use) I’ll try absorb your train of thought :smiley:

p.s. another reminder to all that no dev has picked this up, or is planning to afaik, but I still think it’s useful to map out possibilities

2 Likes

I believe they’re talking about a release coming out at the same time worldwide (therefore on different days depending on time zone), vs. coming out at the same time of day, like say, 6:00 pm on October 15th local time.

sometimes we do have this level of detail. for example, I know COVER corp. releases come out using the local time scheme, and I’m pretty sure any YouTube release will follow the worldwide time scheme

I’m not going to pretend that we’ll always have this data, but I think it is worth considering including.

1 Like

We’re actually seeing real issues on the site due to the long country lists:

  • The page for releases in Fiji (or any other small country) taking forever to load because of it having to load all the release events for every release there (plus the usability fact that it makes it almost impossible to see what most people would think of “Fiji releases” - that is, releases from Fiji released only / primarily in Fiji).
  • Editing some releases actually times out because of the struggle with the huge amount of release events.

I completely understand that “[Worldwide]” feels like a bad fit for something that we know wasn’t specifically released in Russia or North Korea or whatnot. That said, we also know that the lists atisket and other similar scripts bring up are essentially flawed - they don’t represent the countries the releases was available in at the date indicated, but the date it was released, paired with the countries where it is available now.

The country an actual release was released is a lot more significant for physical music (although possibly even for that is now less significant than before) but I get the feeling that the significance is almost nil for digital music.

As such, I’m really, really, really tempted to add a “[digitally]” release “country” that can be used together with the digital release date for digital releases that are not significantly region-locked (so, the ones that are not just “Japan-only release” or the like). That would allow us to have a sensible release event, and still allow people who care about per-country availability at any specific time to check and add the appropriate list to the annotation.

While I mostly stream my music, I can’t think of any case where I’ve cared about which countries it was allowed in on release - at most, I might care about whether I can access it from my country right now which is a different issue entirely.

Is there a reason why this is a terrible idea that should never be adopted, even taking into consideration the drawbacks of the current long lists?

33 Likes

I’m personally in favor of adding this. As long as specifying individual countries - e.g. for Korean digital releases, where all domestic streaming platforms are region-locked - is still possible, I’m fine with it.
Never was a fan of the long country lists anyway, since they only slowed down page loads while editing, and my music library manager always took the first country for tagging which means I supposedly have a lot of releases from Afghanistan…

8 Likes

It’s a good opportunity to put more eyes on making the artist country available in the release.

3 Likes

I’ve always taken “[Worldwide]” to mean “Internet” myself, which would also include many livestreamed concerts and the like. I don’t really see the point of adding a new release country when we’ve already got (IMHO) a perfectly acceptable one already.

that said, if we added a way to exclude countries from [Worldwide], that could be a possible way to fix some of the issues brought up in this thread.

9 Likes

I think the point of this proposal is specifically that it’s quick to implement and bypasses the controversies of “Worldwide not actually meaning every single point on Earth”.

I am strongly in favor of this, even if all it accomplishes is finally ending this debate through the application of authority.

4 Likes

I’m not necessarily against it, I think it would be significantly easier to just say “Worldwide not actually meaning every single point on Earth” and leave it at that. we also wouldn’t have to edit all the existing releases which are already marked as [Worldwide] too.

that said, I think there is a case for adding more distribution regions as areas, that way we can more easily mark a release as Worldwide except Oceania without overloading a release with 180+ release events. then we can do the same with less than 10 release events. I mean, we’ve already got [Europe]…

possibly related is @aerozol’s proposal from above

edit: I forget who posted a screenshot of a digital distribution websites region selector (probably not searching in the right places), but those would probably be good regions to include.

7 Likes

Woo!! +11

Not being able to find real Fiji releases is a very valuable issue for this mess that basically just shows where some shops are selling media on the day a release was added to the database.

Distribution patterns should be added to Spotify\iTunes\Deezer pages. History should be recorded on those pages as to when countries like India started add to streaming, and when Russia\Belarus was excluded.

There are some complexities like how Pink Floyd splits distribution around the planet, but that data is better shown on a single label page, not every single release. (@tigerman325 has plenty of experience here)

2 Likes

I don’t think it matters if we use [worldwide] or [digital], these are the important steps either way:

  • Have a-tisket default to [worldwide]/[digital] (!)
  • Have some guidelines that specify when to use what

I think don’t think the problem is that we don’t have enough areas…
Both of those could have been done ages ago without this faffing about.

My main concern with adding a new area:
I’m worried this will be another membranophone situation, a small change which has wider reaching consequences than we may expect.
Thousands of editor hours spent going through the DB swapping all digital releases from [worldwide]? Yet another historical MB mess to clean up/that will never be done… ugh.

If we’re doing a bandaid fix (don’t get me wrong, I know dev time is limited, it’s better than nothing) can we try not to add complexity for a change.

It will be the hard calls that have to be made by @reosarevok/the style lead that are the main factor anyway. When is a digital release not [digital], if ever. When is anything non-digital [worldwide], if ever. etc

8 Likes

This could potentially be solved by a bot, one that goes through all current [XW] releases and checks if they have Spotify/Deezer/Apple (etc.) sources. If we want to be fancy it could do check the APIs of the services to see if they exclude too many countries to recognize things like Japan-only releases.

A bot came to mind too, but all to stop people using long country lists? Let’s just try a guideline that guides everyone not to.

The nuance of which will be the same issue no matter what we call the area - [worldwide/digital]?

1 Like

Still see no problem with country lists personally. Rather that. Those are released there according to the distribution. It’s good to spot patterns. Now I’d prefer more options to shorten them, like other continents besides Europe. Usually that’s how the labels are distributing them. Like have North America, Africa, Asia, etc as options. Also, wish we could have Worldwide, except China or Worldwide, except United States for those instances when only a handful of countries are exempted.

I think it’s the most sensible solution other than removing it completely for digital release (might be tricky to code), a dummy country for digital release might be better.

While we’re on the subject, what do we do with theses ?

1 Like

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