ISRC duplicates

[jesus2099]

@outsidecontext

I still think the best way to track ISRC would be to have them linked to both recordings and 0 or more tracks.

Good idea, it could be linked only to tracks.
And then recordings would list their track ISRC, without holding them itself in duplicate.
Just like how the recording length works.

[yindesu]

ISRC and Relationship Type / Phonographic copyright - MusicBrainz are indeed properties of tracks, not MB Recordings.

[thwaller]

Wow, thanks to all for the feedback and comments.

@kepstin

I put in a warning on duplicate ISRCs on https://magicisrc.kepstin.ca/ to help prevent submissions like that.

I have been doing my ISRC submissions manually. I have hard time trusting the automated tools for such things. I am interested in seeing them, and possibly trying them though.

@goch

And yet I’m a fan of ISRC as an identifier. Especially as they help preventing merges of different edits/versions just because they share the same track time.

This is basically how I feel. It is not perfect, but I believe it is only improving and is a great identifier, as you stated.

[thwaller]

@goch

Example where more than one ISRC for one recordings seems correct (year 2015):

Thanks, I will look at this in detail. I must admit though, I have no experience in considering Deezer or Spotify as a release. That is my personal take though, so I am interested to see how it all works and is structured. To me they are like a radio station, there is no physical or otherwise tangible product. It is something I need to open my mind and learn more on how that data is used.

[thwaller]

@goch

Example where more than one ISRC for one recordings seems correct (year 2015):

I looked into:

1. Alleyway - with ISRCs:
   DE-S31-14-00235, GB-KPL-15-12843, GB-KPL-15-12855, US-LGZ-15-00022

Unfortunately, I cannot find any data on the firs three, and the fourth has no information registered aside from the title and artist.

I see this problem for sure. I tend to blame the individual/company that did this as they did not put in the effort to do things properly, but seems just the bare minimum to get by.

I find the following ISRCs:

1. GBARL1001217
2. USLGZ1500022

This brings some questions…

1. Why do people register an ISRC and fail to submit it?
2. When they do submit it, why do they not complete all the date? It would seem to be in their best interest.
3. I suspect based on the presentation of this example, this might be due to the streaming sources like Deezer and Spotify? Do Deezer and Spotify claim some sort of rights to these recordings? Or, are they claiming some sort of joint rights, justifying a different ISRC?

[kepstin]

@thwaller

I have been doing my ISRC submissions manually. I have hard time trusting the automated tools for such things. I am interested in seeing them, and possibly trying them though.

My “MagicISRC” tool isn’t an automated tool - it’s just a web form that makes it easier to submit ISRCs for multiple tracks on a release all at once. Please give it a try! I took advantage of the opportunity to add some additional sanity checks that are missing from the MusicBrainz site. (MagicISRC is also designed to be used as a form for semi-automated submission - in that case it gives you a way to review changes before they are submitted.)

@thwaller

Unfortunately, I cannot find any data on the firs three, and the fourth has no information registered aside from the title and artist.

I’m not sure what you mean by “registered”. It varies by country, but in many countries there is no requirement to submit any data regarding ISRCs to any centralized agency for any sort of tracking. In the RIAA’s documentation for folks in the US, for example:

You do not need to submit your assigned ISRCs to RIAA at this time. However, you must keep an accurate record to ensure you never assign the same ISRC twice. In practice you need to maintain a database of the ISRC codes assigned and the other metadata associated with the track (title, artist etc). You should provide all this information to business partners such as online retailers. They should be encouraged to use the ISRCs in reporting back to you.

That said, some countries do have a centralized database of ISRCs, and possibly other linked metadata. (Japan’s is linked with their work info database! You can go back and forth between ISWCs and ISRCs!) Requirements there only apply to people using codes administered by that country’s agency tho, so e.g. TuneCore codes are a different story…

[thwaller]

@kepstin

My “MagicISRC” tool isn’t an automated tool - it’s just a web form that makes it easier to submit ISRCs for multiple tracks on a release all at once. Please give it a try! I took advantage of the opportunity to add some additional sanity checks that are missing from the MusicBrainz site. (MagicISRC is also designed to be used as a form for semi-automated submission - in that case it gives you a way to review changes before they are submitted.)

Interesting, I will look at this. I have not heard of it before, so please do not take my initial hesitation personally. I always hesitate with most things that automate, as even the smallest problem can cause massive issues. It sounds like you have this well error checked though.

@kepstin

I’m not sure what you mean by “registered”.

What I mean by this is the data that has been made available to those looking up the numbers. So I guess I use the term “registered” as the data provided to the central database.

[thwaller]

While not the best example, I just completed this soundtrack release, comp. There are no duplicate or multiple ISRCs on it. I am sharing only because my prior example was a normal album release.

The Hating Game (Original Motion Picture Soundtrack)

[foxgrrl]

@jesus2099

When ISRC are added from official CD, even if wrong, they should be kept.

Just a note, there is (almost) no error correction on the ISRC data read from CDs. So, even a little bit of dust or small scratches will silently flip bits in the read ISRCs. (Theoretically, a good drive could maybe possibly correct a bit flip by working backwards from the CRC on that frame, but don’t count on it.)

Usually, what I’ve seen are:

1. ISRC codes for each track are sequential… except one track’s ISRC in the sequence is different by one character. (Not always the last one.)
2. The ISRC is complete malformed gibberish.

But also, sometimes CDs are mastered with the tracks and ISRCs out of order. (Like I guess they changed the tracklist while mastering, after assigning the ISRCs) But you’ll usually have a bunch of unique, shuffled but continuous, sequential range of ISRCs. (If it’s not a compilation.) Sometimes, there’s one missing, maybe they dropped a track off the album at the last minute before pressing…

Anyway, a human can just look at this stuff and usually errors are easy to spot.

If you look the album up on ISRC Search you should also see the same ISRCs listed. I have checked ISRCs against a CD I was currently reading to verify an error… and confirmed that my CD Drive has misread an ISRC from a track.

It happens a lot. (Though I have a lot of used CDs I bought from the $0.50 clearance aisle.)

[jesus2099]

@foxgrrl

It happens a lot.

It happens mostly on thin CD drives and with executables that scan ISRC too quickly, without proof-checking.
If you are on Windows, ISRCSUBMIT.EXE will have troubles with thin CD drives, not MEDIATOOLS.EXE (scans CD-TEXT and proof-checks sub-channels).
I have several ISRC tools on Windows and 1 on Linux.
Sometimes I have to use one or the other.
ISRC can be stored in CD-TEXT, also, not only in sub-channels.

[yindesu]

Some drives are really bad at reading the subchannel data, and end up repeating the same ISRC, or skipping tracks and ISRCs. For example, using the same disc, one drive after another, using EAC, I’ve found a Pioneer and TSSTcorp drive to be unreliable (duplicate ISRCs or holes in the tracklist), but a MATSHITA drive in an old laptop seems pretty rock solid.

All that said, I’ve never seen EAC spit out garbage data as an ISRC, with any drive. The only issue I’ve seen with unreliable drives are incorrectly repeated ISRCs, incorrectly skipped tracks, and incorrectly skipped ISRCs.

[jesus2099]

Garbage ISRC did happen to me on some CD with some drives and some programs.
Changing drive or program allowed me to find the correct ISRC.

The most common bug with programs that don’t scan each track more than once is the bug that I used to call ISRC slide down bug that makes the same ISRC appear on consecutive tracks (in that topic, we see the two cases, garbage and repeated ISRC).

[thwaller]

In the recent replies, there is mention of tools for Windows for this. What tools do you use for Linux, and what are your experiences with them?

@jesus2099

When ISRC are added from official CD, even if wrong, they should be kept.

I disagree with this. My logic is that in another thread, it was pointed out that MB does fix errors, to a certain degree. I would not link a recording was was incorrectly stated on the cover art as it would cause other issues, like an incorrectly assigned AcoustID. I see this the same, not fixing the error would knowingly cause an incorrectly assigned ISRC. As also stated in that thread, I think this is something that should go in the annotations, no the “official” track listing / recording data.

[ernstlx]

Well, since the ISRCs read from the subchannel can be erroneous, it’s probably better not to consider them at all, right?
Recently I added a code different from ISRC search to Recording “Electric” by Robyn - MusicBrainz

The funny thing is that this code didn’t fit in the sequential order. (codes from SEBMC9943010 to SEBMC9943130 for track 13)
But track 4 had SEBMC9901010 instead of the expected SEBMC9943040. I searched and it returned SEBMC9901011, different but not sequential either.

I should probably remove the subchannel ISRC

@thwaller

What tools do you use for Linux, and what are your experiences with them?

cdrdao, but without much experience.

[thwaller]

@ernstlx

The funny thing is that this code didn’t fit in the sequential order.

I see this a lot, enough that it is a valid point, but not enough to be the norm.

@ernstlx

cdrdao, but without much experience.

Yes, that is a great set of tools We Linux users get a double edge sword. On one hand, we have limited softwares (GUI) compared to Windows. On the other hand, the tools we do have are usually better and more accurate, but harder to use and less user friendly.

I asked my question on Linux tools as I Am still working on compiling a list of Linux audio tools, what they are for and how to use them, in brief. This is not just for MB, but audio in general and includes sample/base config files to get started.

I personally find that EAC is not the ideal software as many see it as. Granted, using Linux removes this as an option (I won’t use Wine for it for many reasons), but using cdparanoia (directly or indirectly) historically provides better results, not in my opinion, but the consensus of the internet community.

When I left Windows, it was a difficult adjustment when it comes to audio. I lost tools like EAC, MP3Tag, CD Architect, CUETools, Sound Forge, Audition and many others for general and basic use. I was sort of forced to learn and use the core technologies vs relying on others to provide me a software that does it, trusting it is done without error. I now use tools like Whipper and abcde, which are not close to known as EAC is.

EDIT: I have mentioned Whipper before. For those who do not know, Whipper is a fork of Morituri and actively maintained.

[jesus2099]

@ernstlx

The funny thing is that this code didn’t fit in the sequential order. (codes from SEBMC9943010 to SEBMC9943130 for track 13)
But track 4 had SEBMC9901010 instead of the expected SEBMC9943040. I searched and it returned SEBMC9901011, different but not sequential either.

This situation is not unusual, no problem.
Obvious mistakes is when consecutive tracks get the same ISRC.
But sometimes it’s still not a mistake either.

@thwaller

What tools do you use for Linux, and what are your experiences with them?

I use the same MusicBrainz-isrcsubmit by @JonnyJD.
In Linux, the backend is cdrdao.

If don’t know if cdrdao has the same ISRC slide down bug as isrcsubmit.exe because my Linux
(Debian 10) machine has a very reliable great fat CD drive (internal IDE NEC DVD burner) that never had any ISRC bugs, neither on Windows nor on Linux.

I only mentioned Windows tools because it’s on Windows (company laptops) that my CD drives are not so reliable, slim CD drives, those are usually the not reliable drives, in my experience.

But I have already seen a fat drive (external USB Samsung DVD burner) that was not reliable, also.
Maybe because of external type?

[thwaller]

@jesus2099

I use the same MusicBrainz-isrcsubmit by @JonnyJD.

I did not know of this prior, thanks

I meant to disrespect on the mentioning of Windows only, that is the norm. I have an old Yamaha CDRW SCSI drive that seems bullet proof, but technology leaves it behind. Today I use a Lite-On branded eBAU108 5 L (4L01), USB2.0 external drive. I am quite happy with its results.

[outsidecontext]

@jesus2099

I use the same MusicBrainz-isrcsubmit by @JonnyJD.
In Linux, the backend is cdrdao.

If don’t know if cdrdao has the same ISRC slide down bug

JonnyJD’s tool also has some logic to detect this issue and retry the read. That makes it more reliable. Also you can choose between different backends, so if one is not working well another one might do better. cdrdao is quite good in my experience, though, and does a good job reading the ISRCs. But it is also heavily drive dependent, as you already mentioned above.

[thwaller]

Does anyone know if fre:ac can extract ISRCs? I will need to install it and see, as I have not used it in a while now.

[jesus2099]

Maybe they do because I see a discussion post saying it is (of course) slower when you scan ISRC.