I can hear differences in some of those earlier remasters, but does 2011 sound different to 2016? Is there really much change from 1994 to 2011? It is why I generally started seeing the point in MB’s “just mush them all together as it is a gimmick to sell albums”.
I picked a simple one with Meddle. If I had picked Dark Side of the Moon it gets even more complex as you then add in 20th, 30th anniversary editions. I know I have my preferred copy I pull from the shelf, but if I was a true addict then I’d be chasing down specific Japanese pressings from certain factories. This is not a distinction that appears in ISRC numbers. This appears from packaging and matrix details. ISRC does not give enough detail for finding those. “best” recordings will always require a combination of data to locate.
I guess some of this is different for me as I look at whole albums, and not loose tracks.
If you look at the recordings, the ISRCs are all clean, no duplicates and one per. This is a newer artist though, but one of reasonable popularity. I wanted to provide an example of my side of it, to show the opposite of the examples provided to me.
She is fairly simple. Not many albums, limited reissues, and no Greatest Hits compilations. Only been around a few years so not had time to drop into those “back catalogue VA compilations” from the labels.
I understand when it is perfect and neat, a bit like AcoustIDs, but real world data gets messy.
We aim for perfection, but also deal with the messy stuff along the way.
Some individual record labels might do that, but it’s completely up to the discretion of the record label or ISRC issuer. The fields in an ISRC are all pretty simple - 2 character country code, 3 character registrant code, 2 digit year, 5 digit designation code assigned at the discretion of the issuer.
I’ve seen some labels that use the first 4 digits of the designation code to identify a recording, then the last digit is 0 for original, and incremented for edits. But I’ve also seen the full 5 digit number range being assigned sequentially, or out of blocks.
There’s no way to derive any meaning from the designation code numbers without knowing the details of how a particular record label assigns numbers.
This was probably a bug with a CD drive or software. There’s a few cases where the drive/software can get out of sync, and repeat an ISRC when reading the info off the disc (in some of these cases, it results in some or all of the following ISRCs being on the wrong track!). I put in a warning on duplicate ISRCs on https://magicisrc.kepstin.ca/ to help prevent submissions like that.
That’s actually one of the reasons why the ISRC submission was not yet added to Picard (the other reason being that simply no one has yet started doing the work).
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.
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.
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.
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.
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.
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:
GBARL1001217
USLGZ1500022
This brings some questions…
Why do people register an ISRC and fail to submit it?
When they do submit it, why do they not complete all the date? It would seem to be in their best interest.
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?
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.)
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:
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…
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.
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.
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.
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:
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.)
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.)
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.
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.
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?
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.
