I just came across this edit (Edit #83082559). I happen to have a copy of the album where this recording originated (Herb Alpert’s Rise), and I have embedded the ISRCs for the tracks, as I found them on SoundExchange.
There are several edits for the other recordings on this album. The ISRCs as shown on SoundExchange don’t match the ones in the merge targets, so I got curious.
Taking one track (‘1980’) as an example, the ISRC in the merge target (QM4221500408) doesn’t appear in a search on SoundExchange. Looking through the edit history, this ISRC was added from Spotify. Per the MB documentation, the first two letters are a country code, but (QM) does not exist in ISO 3166-1.
Tracking that down, I learned that a new standard was created for ISRCs. The first two characters no longer specify a country.
But the IFPI’s “ISRC handbook,” if I read it correctly, says that a new ISRC should not be assigned to a recording that already has one, and any recording should have exactly one ISRC.
So the questions that arise from all this are:
Is the recording used by Spotify the same as the one on my release?
If they are the same, shouldn’t the earlier ISRC be used?
If they aren’t the same, should the recordings be merged?
In addition to the above, I think the MB documentation may need to be updated to account for the new IFPI definition of ISRC.
Yes, but in practice, it happens quite often the same recording gets multiple ISRCs, the main reason is the lazyness of labels, it takes often more time to research for previously existing ISRC than creating a new one.
There is not a one-to-one mapping between a Recording MBID and an ISRC. If you are interested in storing the “exact” ISRC from the release, then you will want to discard ISRC data downloaded from MusicBrainz.
On a similar note, I regularly ignore MusicBrainz producer data because I don’t want executive producers stored in my tags - I just want the sound producer.
Maybe. ISRC handbook is wrong in reality. There are many instances where the same ISRC is used on more than one recording, unfortunately. On many compilations the labels add existing ISRCs to recordings that have different ISRCs. Both are correct if the label put them there, but don’t be surprised if the extended mix has the same ISRC as a shorter mix. Happens all the time. Also, there are plenty of times ISRC search will show a time for a recording that is totally different than the recording actually is. I will stress though that if Spotify is showing a different ISRC and the COUNTRY CODE & YEAR are the same, but the extra code is different, please pay closer attention. Sometimes it could be the difference in a mono/stereo, or explicit/clean difference. These should be separated out if you can spot the difference. There are very sloppy editors who just pick the first recording MB suggest to them and then they add the ISRCs from Spotify that might be wrong because they didn’t select the correct recording.
No, both ISRCs should be used, IF, they both are for the same recording. ISRCs are separate even if different mastering is only difference in recording, not just different mixes. This is why you see so many recordings on MB with more than 1 ISRC. A 2010 remaster & a 2020 remaster of the same original recording are the same recording, but will have a different year code on the ISRC.
Yes, if you see 2 recordings with the same EXACT ISRC and very close times (within 7 seconds) than they should be merged. However, pay attention if other ISRCs exist on one of the recordings you want to merge. It might have an improper mix, i.e. stereo/mono or explicit/clean. If you see this, look at the history and see when the recording was first used and use that, than separate out the improperly chosen ISRCs, recordings, etc. If you see a conflicting recording with 2 ISRCs of the same code & year, maybe not merge and just use one of them for the base recording if you have to untangle bad merges, etc.
The guidelines are for MB, not ISRC. IFPI is not 100% accurate and I’ve found 100s of mistakes there over the years. Their guidelines are what SHOULD be, but not in reality what IS. The labels make mistakes in assigning them. Often. Especially on VA compilations and the like.
