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?
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.
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ā¦
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.
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.
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:
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.
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.
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?
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:
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
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.
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!
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ā¦
