Which ISRC takes precedence when IFPI and printed CD differ?

Tags: #<Tag:0x00007f7cf8e08388> #<Tag:0x00007f7cf8e0fcf0>

If https://isrcsearch.ifpi.org/ has a different sequence in ISRC’s as found on the actual CD, which one has precedence?

Ref: edit #62592632

1 Like

Barring a misprint on the CD track list, I’d be tempted to add both/all ISRCs to relevant recordings, since those ISRCs are obviously being used to refer to those recordings in different contexts.

If you have to choose, I guess I’d lean towards IFPI’s data. Maybe.

1 Like

If we lean to putting the typos from a CD in for a track name, then the CD’s actual ISRC should be just as important.

My attitude is always to add too much data. Adding the oddities with notes seems more important than when it is normal and correct.

Especially as I have also seen recording merges plainly ignoring the ISRCs leading to multiple ISRCs against many tracks anyway.

1 Like

I would for sure agree to keep misprinted ISRC, if we would assign them to the track entity instead of the recording, as the track is bound the originating release.

My thinking is line with you Freso. No perfect solution.

1 Like

I would add both and explain what I know is special there in the recording annotation.


Having dealt with SoundExchange on many occasions over the last couple of years, I would say that the CD version is more accurate. SoundExchange’s staff is extremely careless and inconsistent with data sent in by artists and record labels. As an example, I sent them a spreadsheet of almost 200 ISRCs/recordings on releases to be added and almost every single one of them had errors. Anything from spelling mistakes in the song titles or artist names, mixed up ISRCs entered with the wrong album, wrong (or more often “no”) dates added to releases. It was a nightmare.

I actually had to spend a month dealing back and forth with a supervisor over the phone and spelling out each and every mistake, then him referencing it to the spreadsheet that I sent it, and then sending it back again to the same entry department for corrections. Then wait a week for the system to update and go through it all over again to spot what was either not fixed or what new mistakes were made during the supposed fixing process. There are things that never even get fixed, like having dates added or corrected in their system. The supervisor kept giving me excuses for the data team (such as “it’s a demanding job”, “everyone is entitled to human mistakes”, etc) finally I just gave up. SoundExchange’s data entry department is a joke. They clearly don’t take data entry seriously.

I can confirm that some ISRCs listed for my music on their database/on IFPI is incorrect, and I would personally be really displeased if someone added those to my MusicBrainz entries.

But it’s worth noting that SoundExchange only deals with DIGITAL releases, not physical ones. So their database would have the ISRCs for the DIGITAL version of a release, not the PHYSICAL version, and some record labels have different ISRCs for each different format (one for digital, another for CD, another for vinyl, another for tape, another for the radio mix sent for promos).


Interesting story @hds, thanks for sharing that. I often see a new set of ISRCs for recordings which clearly had existing ISRC codes before. Not only for different format, also for compilation CD’s. But in this case the sequence within the same set was mixed up (something with ordering in the spreadsheet :wink: ). But I can imagine this poor data entry jobs can be done every where, also where CD’s are printed. Please correct me if I am wrong, maybe there are organizations who do deliver accurate information to IFPI.

Off-topic: If you reach the point sending Excel sheets back and forward, on with straight forward data you register on a daily basis, it maybe expose a friendly web interface to your customers. Having a look to the great interface of MusicBrainz should give some inspiration how things can be done differently.