I have to admit, about 6 months ago I was ignorant to the world of ISRC’s but after finding Musicbrainz and helping out and learning about all these new identifiers (ISRC, ISWC, IPI etc.) I thought cool I’ll add them where-ever possible to try and reduce the large amounts of “duplicate” recording entries we have.
However it would seem the dear record companies do not want to make this easy. First of all, you’re lucky if you have them encoded onto the CD at all. I understand that pre-2000 it’s pretty much a low chance this will happen, but even after its not always guaranteed. Independent labels, magazine cover mounts or promotional stuff almost never has them encoded, so I stick to checking post-2000 big label releases.
But it seems that even the big boys (Sony, Universal, EMI, Virgin etc.) cannot grasp it.
Some fun scenarios I have found so far:
Made up ISRC’s with strange numbers that do not appear in any database
The same ISRC applied to multiple tracks on a release, however it only relates to one of the tracks (Sony was the culprit)
All but one or two recordings have an ISRC
ISRCs for live or studio recordings being the wrong way round (so a studio recording has a live ISRC, vice-versa)
ISRC’s having a different duration (not by seconds, but by minutes) in the ISRC databases to that on the CD
ISRC’s for radio mixes being applied to album versions
Just a mini-rant, I know this was going to happen when I did my inital read up that record labels (who surely use the ISRC identifier?) are pretty terrible with them but I felt like letting some steam off.
I just completely ignore ISRCs and similar identifiers. They are just tools for record companies and lawyers to make money, and since I’m neither I couldn’t care less about them.
Thank you. Interesting notes. I like Reality Rants like this. I had been debating whether to look into my CDs and ISRCs as it requires awkward manual scripts. You may have just saved me a wasted effort. Especially as so many of my CDs are 1990s vintage.
So on the flip side of this - when are they reliable? Do the smaller CD manufacturers even bother?
This is often not the fault of the ones assigning the ISRCs, though. The ISRC data is stored in the so called sub channel data. Turns out reading subchannel data reliable is tricky business, and the results depend a lot on the OS and the hardware used. If you encounter the same ISRC on multiple tracks chances are great that it was the software reading them not correctly. Trying to read the ISRCs multiple times can allow you to level out this issue, as you might get different/better results on separate reads.
While you are here @outsidecontext - why does Picard not have a plugin for this? Isn’t this the kind of data that Picard could pull along with a DiscID? Having to go all command line for this is a reason I haven’t bothered.
Short answer: It just hasn’t been implemented. But I’d like to, @zas and I recently had a short chat about that.
Longer answer: There was pretty active development around libdiscid regarding ISRC support at around 2013. That’s also when all the ISRC helper command line tools popped up. There was talk about adding ISRC reading to Picard at the time. But there were also some concerns about reliability of the read ISRCs (see my comment about subchannel data above), and the idea to address those issues before adding such a feature to Picard. Since then the ISRC support in Picard kind of got forgotten, or at least nobody prioritized it really.
It has always been on my pretty long personal wishlist for Picard
Thanks. That makes sense. As some OS\Hardware combos are just bad at “sub channel data” thing means some uploaders will just end up with “blacklisted” readers. That makes sense as to why it would keep staying lower on the priorities list. Too much potential hassle from the users.
Yes, getting trustworthy ISRC reads from audio CDs on a PC is astonishingly difficult. Usually ripping problems manifest as the same ISRC being applied to multiple tracks, which are at least detectable, but I have observed other ripping errors that are not as easy to detect (such as exchanged digits).
Because of this, I would not recommend submitting ISRCs ripped from a CD without some form of external verification (for example, in many cases you can search a ripped ISRC on soundexchange, and then check the title). For Japanese major label releases (including domestic reissues of foreign releases) you can also often get ISRC information from MINC. Of course these databases are not perfect either. For new releases featuring all new recordings the ISRCs are often (but not always) assigned in an obvious pattern which, if applicable, is a reasonable sanity check for a rip too.
I have a lot of drives but only one that I trust for ripping ISRCs. I have some drives that for some discs seem to simply never produce a correct rip of all ISRCs. Usually the error is different each time. With a bad drive and enough rips it may be possible to determine what is actually on the CD with reasonable confidence but this is always a fairly manual process. I’d only do this if I had no other option.
Are you using isrcsubmit.exe, maybe?
There are discussions about this tool having ISRC slide down bug, especially with slim CD drives.
Using mediatools.exe and/or isrcsubmit.py, you should not get errors, or at least not often.
I could submit ISRC for around 1000 of my CD (including many with a slim CD drive), excepting CD with no ISRC, without issues, since I am not using isrcsubmit.exe.
Not sure who you’re responding to (or maybe you’re talking to all of us!) - I’m using freac to read them. Since finding that some ISRC’s are a bit “odd” I now cross check them with the PPI repository (as 90% of my releases are sold in the UK).
Interesting to hear that its a bit funny about reading the sub-channel data. I’m using a standard DVD-rom drive that came with a Dell, I think its a HGST branded one (I used to have a nicer Pioneer one until I left the tray open and walked into it, RIP).
Ultimately, on my edits I always put a note as to where I have “obtained” my ISRC from
I extract ISRCs from all my CDs. I have since I starting ripping. I used EAC and two plextor drives. I don’t any problem extracting them.
I can’t tell you about the quality of the data overall -
duplicates on the same CD
duplicates for different songs
some CDs are missing them completely
The ones I have spot checked are good.
I see no reason to not use them wherever I can. I set picard to ignore MB’s version however, because there are often multiple ISRCs per song, which I believe is a flaw in the data model.
It’s not a flaw in the data model, it’s a reflection of the flaw of how ISRCs are used in reality. As OP hinted at, record companies are known to issue new ISRCs for recordings that already have one or assign an existing ISRC to a new recording. It would be a flaw in our data model to not reflect this.
The one improvement that could be done is having the ISRCs not only linked to recordings, but also to the respective release tracks they came from. There is a ticket at https://tickets.metabrainz.org/browse/MBS-9754
That would allow tracking where a specific ISRC came from and even make it possible to help in release lookup by ISRCs. The same ISRC could be linked to multiple tracks on different releases of course, and the recording would still have multiple ISRCs if it got multiple ISRCs from different releases.
There is some convincing logic to this view. It reflects the messy reality of ISRCs indeed better. In theory (according to how ISRCs are defined) they would be unique for recordings, but this is difficult to achieve in practical use, I can understand why labels often go the easier route. And reality doesn’t care about definitions and database schemas
