Please make sure whatever changes you make that other programs than just Picard can obtain the data.
Well, if Picard can others can as well. Picard has no special access to data.
3 Likes
Another lengthy discussion:
https://musicbrainz.org/edit/90325400
See also preceding one:
https://musicbrainz.org/edit/90272519
Among other it revolves around uninhabited islands.
1 Like
idk if this has been mentioned, but as a distributor for a label, generally we set worldwide or ā+WWā (with the option to remove it from any specific countries) as the country its available in rather any actual list of countries, so 99.9% non-region exclusive digital releases are meant to be available worldwide. the actual wordwide-ness might be lost in translation depending on the system of the distributing company & the platforms it get posted to.
and in my opinion having every digital release be a list of 190-210 countries because in not available in x amount of territories where internet may not even exist only really removes/hides information. a āworldwide minus these countriesā would be useful for region-exclusive releases such as (essentially) worldwide except north america, or except oceania, or except germany/austria, which are quite common for some labels. and thats also how it works when distributing digital releases
12 Likes
i actually think having insight as to the intentions of an average label is very helpful, thank you.
in addition i have to say i really like aerozols mockup for a web distribution option, altho i vastly prefer the may 13 revision to the may 14 revision
3 Likes
Did someone write a script to replace a long list of release events by just one worldwide?
I came to this case:
But it is released at the same date, with same barcode, by same label on Flood | Stella Donnelly
And since we usually consider Bandcamp releases worldwide this long list of 204 countries/dates can be replaced by one.
But how to do it? Did I miss a useful script?
5 Likes
Not a userscript, but I have a bookmarklet to do that:
javascript:$('.remove-release-event:not(:first)').click();void $('#country-0').val(240).trigger('change');
Never published that one in my GitHub repo as I only needed it once or twice so far 
Edit: Added to my repo as Mark Release As Worldwide.
8 Likes
Thanks @tigerman325 
Is there a new trend to add 100+ countries to physical releases?
1 Like
Well, it explicitly says that they will ship to any countries except a long list of countries
So, I took that to mean that it was released in the countries not on that list. Should I just have said US and left it at that? Itās not worldwide. But it apparently isnāt just US either.
As I understand it, for Physical Media Shipping Destination is not release. Otherwise anything sold through Amazon is always Worldwide.
Iād have just put US. This is where they āreleasedā it. And then someone in the Texas office had a job of sticking it into envelopes and shipping it worldwide.
Digital Media distorts the meaning of āreleaseā to mean ādistributionā. Different topic.
4 Likes
I can see that. But Amazon I donāt think will ship anywhere will they? Can I go to Amazon.uk.co and order stuff and have it delivered here in Texas? I know they will sell imports, but they usually say āimportā on the page. I have no issue with just marking it as U.S. though. I just get annoyed how so many editors will mark CDs as Worldwide on anything they see sold on the internet.
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 
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?
34 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