Why does Picard display multiple ISRC numbers for a song?


#1

I have a CD with ISRC numbers written on the disc - in the data. EAC reads this information and includes it in the CUE file that it creates. In this case of this specific song, Picard displays two ISRC numbers:

GBA077700010; NLF057790025

This appears to be because the MusicBrainz database contains two ISRC numbers for this song:

The first ISRC number, GBA077700010, does not appear to be a valid ISRC number if I search for it at the ISRC: https://isrcsearch.ifpi.org/#!/search. (Edit note: The number is correct per PPL - see below)

It is also not the number that EAC retrieves from the disc. EAC only retrieves the second number NLF057790025. This does exist if I search for it.

It seems to me that what is written on the disc is the definitive ISRC number and that number is the only number that Picard should use. Perhaps I dont understand something? Are both numbers on the disk?
Please can someone explain or refer me to something to read?

Thanks
dpr


#2

It is not uncommon for a recording to have more than one ISRC. While in theory there should probably be only one,in practice a new ISRC sometimes gets applied for a recording. I have seen this especially if it gets included on compilations, where each track on the compilations gets a brand new ISRC (often in order). Probably the labels sometimes consider it easier to assign new ISRCs instead of figuring out the already assigned ones. Or they don’t care. Or it’s just an oversight.


#3

There are plenty of reasons for a MusicBrainz Recording to have more than one ISRC:

  • lack of research from registrants, and lack of unique common international database (one wasn’t always available, and there are still issues with that), it is often faster to register a new ISRC…
  • http://www.ifpi.org/content/library/isrc_handbook.pdf , see section 4.9.3 Special Cases and following
  • remasters, edits: MB doesn’t distinguish remasters from original recordings, and a simple edit like a fade-out may or not be considered as a different recording, definitions are rather fuzzy, so registrants may allocate a different ISRC (4.9.10 “It is nevertheless the Registrant’s responsibility to decide where to draw the line between sound restoration (full remastering) and simple remastering”)
  • ISRC rules evolved over the time
  • errors, some CDs contain ISRCs unrelated to the recordings…
  • incorrect merges of recordings

The goal is clearly to have one recording - one ISRC, but we can see that’s not really the case in practice, especially for recordings released over and over in many countries since years.

Have a look at USSM19917403 and USSM10203146 for example.

Those look very legit, but it seems clear that’s 2 ISRCs for one recording, and it’s hard to know if it is actually an error or not.
US-SM1-99-17403
US-SM1-02-03146
Same 1974 recording, same country, same registrant code, only 3 years apart, why ?
Hard to know, but MusicBrainz is correct and matches the ISRC database on this one.


#4

First, it turns out that GBA077700010 is a valid ISRC number according to PPL who are the GB authority.
https://isrclookup.ppluk.com/faces/pages/search.xhtml shows:

Note that the Artist name and the length are different. Eric Patrick Clapton is Eric Clapton’s full name…

I think there are three separate issues here:

  1. Picard should not change the ISRC numbers that it reads from the CD regardless of what is in the database. Currently, it does and I think this is a bug.

  2. The ISRC indicates that different recordings of the same song with different lengths should have different ISRC numbers. In the case of this example they are different lengths according to the ISRC databases (and my CD) The NLF057790025 version is 3:45. The GBA077700010 version is 4:20 according to the PPL. It turns out that GBA077700010 is on the disc of another recording of Wonderful Tonight - Crossroads, disc 4, track 5. This is 3:43, not 3:45 in length.

  3. MusicBrainz database lists the same ISRC numbers for many versions of a song. See the link below.
    https://musicbrainz.org/recording/0ad55b53-db63-4acf-b285-ca1e98b9d22a

In the top right corner, there are only two numbers listed. Yet the same pages shows multiple versions of the song with different releases and different lengths…Some are live and some are not. The data looks suspicious to me. Can I suggest some defensive checks - a live and a studio version cannot be the same?


#5

Picard does not use the ISRC from disc but applies metadata from MB to your files, so I don’t think this is a bug. Reading and using ISRC from disc if data was loaded via Disc ID lookup could be a feature, though. Currently Picard intentionally does not read ISRCs from the CD when you perform a disc lookup, since reading ISRCs is way slower then just reading the TOC required for the disc ID.

If this is actually a different recording it should be split out. But this is difficult to tell without having access to this release and other releases which contain the recording. From what I can tell from the data we currently have there is no strong indication that it is different. A two second difference usually doesn’t tell much, it’s pretty common that the same recording has e.g. more or less silence at the end depending on the CD mastering. But in case you have access to the Crossroads track you can probably compare it to the track from the other disc you are looking up.

Actually what is listed on this page is from MusicBrainz’ perspective not “many versions of a song” but the very same recording. If there are different versions in this list they should be split out as their own recording (see also above).

In this case I don’t think there is much we can do currently. The recording has multiple ISRCs assigned right now. Whether the track on Crossroad got assigned the wrong ISRC by accident is hard to tell, that’s the labels business.

What I think is missing for MusicBrainz is to track from which release a ISRC originated. Then you could know which ISRC applies to your specific release version. See also the related discussion at:


#6

Another thing: If you just don’t want Picard to overwrite the ISRC field with what was already added by EAC, add isrc to the “Preserve these tags” setting in Options > Tags


#7

Thanks for that information. It doesn’t seem to work for the Slowhand disc. Picard still lists both. I’ve restarted it… Is it because Picard is not reading the ISRC from the disc anyway??

When I write the CUE file file using the ‘Generate Cuesheet’ plug-in, no ISRC number is written and a lot of the other information in the existing file is either changed or missing:

  • GENRE,
  • DATE now becomes Release date…
  • Multiple INDEX entries
  • Per track COMPOSER

Looking at the source code, it looks like most of the above are not supported.


#8

I understand the performance issue, but I’d rather have it correct vs fast. To me, what the label put on the disc as the ISRC is the definitive truth. Changing it is wrong in my opinion. So, we’ll have to disagree! :slight_smile:

I do have access. I had a look at the booklet that came with the Crossroads box set and it clearly says for Wonderful Tonight, “From Slowhand, released November 1977”. So, I think that it is clear that it is the same recording. The length is 3:42. Clearly, the PPL entry has the wrong length. In my view, they should have used the original ISRC from Slowhand and not created a new one.

I looked at other songs on Crossroads. They are all previously released on other CDs/Albums and have ISRC numbers on those. However, all have been allocated new ISRC numbers on Crossroads. Incorrectly in my view.

Then there is a seperate issue that different ISRC databases are inconsistent - why is it listed on the PPLUK site and not on the ifpi.org site…

Yes I understand this now. Thanks for helping me.

I think its clear, that the label should have used existing ISRCs on Crossroads as it is a compilation of selected tracks from previously released albums… but as someone said earlier, the rules have evolved.

Agreed. It would also help to ‘contain’ the problem in the database…

Thanks.