A bug I’ve noticed: This Spotify release doesn’t list the track ISRCs. I think it’s because the ISRCs for this album actually have dashes in them on Spotify, which most other tracks do not.
You’re right. Totally failed to notice that.
In the past iTunes web preview did show if there is a booklet. They no longer do which is really annoying.
Well, booklets shouldn’t be added as tracks anyway. Data tracks are meant for CDs.
Digital booklets should rather be uploaded to the CAA. If you don’t have it an annotation would be good.
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?
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.
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.
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.
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.
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.