Mini-rant - ISRC's and Record Companies Ineptitude/Laziness

Tags: #<Tag:0x00007f510ff649f8>

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.

:sweat_smile:

4 Likes

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.

2 Likes

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.

5 Likes

In my experience they are rather reliable for newer album releases of bigger labels. Compilations or best of releases are often messy, though.

2 Likes

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.

2 Likes

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 :smiley:

5 Likes

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.

1 Like

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.

4 Likes

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.

4 Likes

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

2 Likes

Oh also as another point to my rant, this one really perplexing.

CDr with ISRC’s embedded but for completely different recordings, not even close to the audio content on the CD?!

Well this kind of things is irrelevant to MB, like homemade compilations.

1 Like

To the OP. :wink:
I should look into freac, I don’t know this one.
It probably used the same ultra fast optimistic ISRC read method as isrcsubmit.exe.

1 Like