A multi‐source seeder for digital releases

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.

https://etc.marlonob.info/atisket/?cached=8714069108127-s_7AQAnFXPNcQljjWAkbqLS5-i_1468896236

2 Likes

It’s a digital booklet. See that release on Amazon: https://www.amazon.com/dp/B08256SM9S

Another example: https://musicbrainz.org/release/92a398ad-06b5-4ad4-8700-fa9fb42d4661
(can’t set medium type as MB doesn’t allow to do so)

2 Likes

You’re right. Totally failed to notice that. :blush:
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.

2 Likes

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

4 posts were split to a new topic: Problem with staying logged on when using importer tools

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

10 posts were split to a new topic: AcoustIDs, ISRCs, and barcodes for digital releases

Back on the topic of sites that can potentially be scraped to seed releases:


2 Likes

@marlonob FYI

https://musicbrainz.org/edit/68618942#note-68618942-5

That’s only for Apple Music. It still works fine from his website for me, which uses the iTunes API.

1 Like

Do you get the barcode with https://itunes.apple.com/ca/album/id1483150748 ?

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