I don’t know if it’s been mentioned yet in this thread, but if I’m trying to seed a particularly long release (e.g. around 60 tracks or longer) the seeder will time out and not load the release. Is there a way around this, e.g. by increasing the allotted wait time if a release is X tracks long?
2 Likes
Hi! I just started using this piece of code, and it’s great! Thanks a lot!
One idea I’m having: As the audio files are accessible on both deezer and spotify (I don’t know about Itunes), could it be possible to use it to compute and submit the acoustid of the recordings? It’s a very useful tool to find duplicates and could even be used when creating a new release (to spot which recordings are already in MB).
Not sure if that’s possible, but you can use the ISRCs given by both Spotify & Deezer to see if they match recordings already on MB. That’s what I do to make sure against clean vs. explicit situations, etc. AcoustID isn’t really good for that situation.
3 Likes
Checking ISRCs works if recordings in MB have ISRCs, but in my experience, only few have. Maybe it’s different for different types of music. My feeling is that much more recordings have acoustids than ISRCs, but that could be a bias because ISRCs are not displayed.
1 Like
Back on the topic of sites that can potentially be scraped to seed releases:
2 Likes
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