@marlonob FYI
That’s only for Apple Music. It still works fine from his website for me, which uses the iTunes API.
1 Like
I did, it’s been added.
Thanks and how did you get it?
With a-tisket I only have Barcode (UPC): [undefined].
I obtained a copy of the iTunes Collection Match file:
As of today, the iTunes URLs generated through the seeder no longer redirect. Lookup still works for the time being, but that could change in the near future. It would be a good idea to update the seeder to add support for Apple Music links.
2 Likes
May I ask a question?
Is it accepted conduct to create a new release with a tool like this, and then merge old releases into the new release? Even if the only difference between releases is the ‘release event’ data? To me that seems unnecessary and dangerously deleting data that is often perfectly valid.
Idk, I was always told keep the oldest MBID whenever possible.
1 Like
The guidelines actually state:
Once all the duplicated releases are there, select one of the releases to merge all discs into; you should choose the release with the most correct information. If there is no real difference, the usual choice is the older entry.
emphasis mine.
So if the only difference is superior release data, then your suggested workflow is perfectly acceptable. It goes without saying that you should make damn well sure that there are no other conflicting fields, or fix them if necessary.
ETA: fixed quote
2 Likes
Yes, but from what I see, you don’t just create a duplicate because you feel like it, or for a minor edit to one field. Something should be very wrong with the existing release (IE not just country in release events):
If a release has so much incorrect information that it would take a ridiculous amount of time to fix it for a merge, you can consider removing it, but this is a last option and shouldn’t be done too often, for the reasons pointed in Merge Rather Than Delete.
1 Like
True, but one could argue that the correction of release countries is not a “minor edit”, since it often involves dozens of release events.
I understand your doubts about the merging procedure since it is potentially dangerous and should be handled with care. But the only alternative at the moment is to correct release data manually, which is not really feasible for widely distributed digital releases.
Were you considering using the procedure yourself or are you concerned about destructive merges?
2 Likes
For sure, it’s not a small edit, it is however minor in terms of quality or importance, at least for digital releases. I’ve seen some debate between editors whether “availability” == “released in”. Since digital rights constantly shifts, I see no point adding hundreds of countries that will inevitably be removed from a steaming platform. Let alone some editors destroying old releases to do so (which is my real issue). Let the existing releases be, and use the seeder for new ones 
3 Likes
Well, if they would have been created correctly in the first place than we wouldn’t need to merge them. Nothing is being destroyed by these mergers. I see no problem with it. I have no idea why some still complain about adding all the countries, especially since the list are now collapsible. Shouldn’t we want the most precise information. Also, availability in and released in are the same thing when it comes to digital platforms. Also, doesn’t matter if a store deletes a country in the future, because it was released at that time in that country. We don’t delete all the out of print physical medium just because they are no longer released.
5 Likes
I’m not sure I follow. If an existing digital media release has correct release information (example, listing the country metadata was added from, such as France, United kingdom, or United States), how is that incorrectly created? It’s 100% accurate, and I don’t understand how that could be regarded as incorrect.
Ah I see now, good points.
1 Like
2 Likes
It wasn’t incorrect and I guess I didn’t mean it that way. It’s just not complete. Adding countries the way I do really is just to save time on my end. I try to merge to oldest when possible. I’d always merge to oldest if we were allowed to add time duration in milliseconds after creation. We can do it with importers, but for some reason not manually.
4 Likes
Is it possible to have the added counties always show 2020-04-21 by their country on releases that are iTunes only and before this date? Because technically that’s when it was released in that country, not before. I’m sure this may be difficult, but then again I tried for years to figure out how to add a script to add the iTunes countries, but marlonob must be a wiz. I’ve noticed that Deezer also actually has more countries than they list as being available on their FAQ.
It seems no one is stopping this ‘duplicate then merge existing perfect release with single release event’ behaviour, I see another user doing it:
https://musicbrainz.org/edit/69121148
https://musicbrainz.org/edit/69109700
https://musicbrainz.org/edit/69107368
Am I crazy here? I tried to vote no on some of them but that hasn’t stopped anyone. Is there some internal memo saying this is acceptable (even though it seems against the guidelines)? I can think of no real reason other than maybe padding edit count.
1 Like
@marlonob noticed a bug:
If an aritst has ‘Jr’ in their name, it seems musicbrainz splits it as 2 artists:
Eg: Eric Greene , Jr. (there is also an extra space in comma)
https://etc.marlonob.info/atisket/?cached=192562908198-d_71956342-s_5vPMkeZ1BVUUrFU3Gio6c0-i_1434738686
1 Like
I’d agree that the edit notes are a bit sober on the edits you linked to. My guess is that the editor is trying to conveniently import information from external sources into those releases. Have you left requests for clarification on your votes? Most editors are quite willing to explain their motivation.
1 Like