Musicbrainz recordings come with a field to list the International Standard Recording Code (ISRC). These codes are issued by IFPI as a means to identify sound and music video recordings, mainly for the purpose of rights management. In theory, ISRCs are unique to a single recording, making them potentially useful for our tribe of industrious MB editors. According to the ISRC Handbook:
ISRC is a unique identifier for sound and music video recordings where one, and only one, identifying code is allocated to each version of the recording.
Anyone spending some time editing the MB database will probably be chuckling to themselves now, making remarks on the lines of “yeah right, in your dreams”. In practice, recordings can have multiple ISRCs, ISRCs can be shared by multiple recordings or ISRCs can be plain wrong for a number of other reasons, which I will not go into here. This topic has been visited several times on this forum like here, here and here.
So we all agree that ISRCs are far from perfect. This is not the reason I started this topic. Usually, whenever I encounter an ISRC that does not match the associated recording, I remove it. My rationale here is that it conveys incorrect information, thereby polluting the database and potentially encouraging bad merges. However when I got into a (polite) discussion with @tigerman325, I learned that some editors have a different approach. He argued that if an ISRC is genuinely associated with a CD or digital track, even if it is misapplied, than it is proper to retain that association in the database. I am paraphrasing here; His full argument can be found in the edit note.
That’s enough background for now. I am interested in hearing the community opinion on this. Please share your view.
The problem with removing incorrect ISRCs from recordings is that you can’t remove them from the source, whether that’s a CD, a download or an external database. So there’s the risk that they’ll end up being added again by editors who don’t know any better, even if you add an annotation about why it’s wrong. That’s why I’d like it if we could disable ISRCs rather than remove them outright, similar to AcoustIDs. I also think it would be better if ISRCs were applied to releases rather than recordings.
Have not commented recently, but this got my attention. Not perfect at all, but generally good. Errors that are obvious, I see both sides. Curious to see where this goes.
My opinion, I would keep known wrong ones, even though it is problematic. It would be nice to have a way to flag them and say … Known wrong but still assigned to … But that is wishful thinking. I tend to agree with @tigerman325.
I agree with @tigerman325 - if the ISRC is associated with the recording by a CD or Digital Media, then it is associated. Even if that is contrary to the official database.
Would be good to have a flag like @thwaller suggests - but at least some notes going into the annotation as to guidance would be good.
People in this thread know my distrust of ISRCs already. I see too many examples that it is certainly not a 1 to 1 mapping. Compilations can make up new ISRCs, or multiple errors creep in where singles and album ISRCs get swapped around.
It seems sensible to me that if someone holds an ISRC in hand and wants to look up what it is ACTUALLY linked to then MB should be able to do that. MB has a chance here to expand the reality that is how ISRC is actually used and not just the theoretical database that ISRC hold.
As @IvanDobsky stated, I recall the distrust of ISRC. On the other side, I use them a lot in my personal cataloging. Compilations are a big issue from what I see as well, and also when there is a different label involved in a release, like a legacy reissue for example. Personally, I store them as different recordings, while MB sees them as the same most times.
No system is perfect, especially when people are involved, errors and mistakes will happen. When was more active editing I did a lot of ISRC edits, I found many issues of different versions of a recording, like radio edit, remixes, album version, etc. the databases are not always good at pinpointing the exact version of the recording, making verifying the ISRC data even more difficult.
If there is a wrong ISRC linked to a recording, and MB documents it as such, we are at least documenting the true reality of it. Yes, we know it is wrong, in that case, but there is a benefit there as it was done /released /associated that way. As suggested, good notes are a plus.
Yep, adding ISRCs at the track level will allow us to distinguish between bad merges and misapplied ISRCs. And sure enough here is a ticket for this.
My thoughts exactly. I suppose it depends on whether we think it is worthwhile to document the exact associations between ISRCs and recordings or whether we merely wish to use ISRCs as a handy tool to collect all instances of the same recording. This is the decision that should be taken by the community (or the style leaders; Where art thou?)
As a general remark, I am surprised that so many commenters argue in favour of keeping the misapplied links. I appreciate documenting the actual associations has its merit, but I find the thought of deliberately keeping all that faulty information grating .
I get your thought that it is “faulty”, but “faulty” in what terms? There is an ISRC database that says one thing. And real world examples that contradict that. Surely MB should document facts and not a broken database. You can always refer to the ISRC database if you want the original plan.
What would be ideal is a flag that says “This is what ISRC should be pointing at”. Whilst allowing MB to document the RealWorld™ examples.
Here we have the digital shops and CD pressing companies to blame for linking the “wrong” data. But their errors become “real” data that people will attempt to look up.
Ruminating a bit over this, I suppose adding ISRCs at the track level accomplishes just that. After all, the linked recording indicates what the ISRC should be pointing at. That just leaves being able to flag the proper ISRC at the recording level, although that may already be evident by way of it being the oldest and/or majority.
I find the way “faulty” is used there highly problematic. If an ISRC was added by an edit wrongly, sure that should be removed.
But we are mostly talking about ISRCs that actually have been associated with the recording on actual releases (CD or digital media), e.g. because on a compilation the label just issued fresh ISRCs for all the tracks.
In theory this shouldn’t have happened, but in practice it has. Just pretending it didn’t happen seems wrong.
ISRCs serve only a single purpose: identifying recordings. If those ISRCs are being removed from the database despite having been issued is harmful for this, as searching for the removed ISRCs will give no results.
I can see a point where e.g. a label just accidentally switched the ISRCs of two tracks around. In such a case correcting the mistake and ensuring the proper ISRC is assigned to the proper recording is helpful.
I actually ran into a case where an artist had accidentally put the same ISRC on two different tracks on a digital download album (on Bandcamp). I contacted her directly to point that out and asked what the correct ISRC should be, and she responded (greatful that I pointed out the problem) and provided the correct ISRC, which I then updated in MusicBrainz. That actually started a friendship. Artists are human too.
That comment was meant to be tongue-in-cheek, but since several people were triggered by it I should probably elaborate.
If a label issues new ISRCs for tracks that already were identified by an existing ISRC, then those ISRCs are “faulty” in the sense that they should not have existed. Since these extra ISRC do not cause undue problems except a little extra bookkeeping I have no issue with them. Therefore I have never and will not ever remove such superfluous ISRCs and I do not endorse that practice.
However, what I meant when I said an ISRC was misapplied is that said ISRC is associated with a different recording from the one it was issued for.This includes swapped ISRCs on compilations, extended versions, explicit vs. clean versions andsoforth. I consider these ISRCs misleading because they lead an editor to believe they are dealing with a different recording from the one at hand. Such misapplied ISRCs are a threat to the integrity of the database because they incur the risk of bad merges. Therefore I have in the past removed all ISRCs whose metadata (duration, version, etc) did not match the actual characteristics of the associated recording.
I am open to the argument that MB should document those misapplications instead, but this should go together with some proposed practice that clearly flags such associations as mistakes. Currently, the only option is really clear annotations on the recording explaining the situation like for example: “ISRC AA-1CU-24-00042 is wrongly associated with Everything Is Awesome (radio edit) on The Very Best of Yodeling Joe but actually belongs to Everything Is Awesome (speedcore death mix)” or something to that effect. My experience is that even such clear annotations are occasionally ignored so anything extra that helps flag such misapplied ISRCs would be welcome.
There is other data that is written into annotations that need to be taken note of if a merge is happening. Seeing someone merging “because the ISRC is the same” often worries me. We need to get people better trained to always check the annotation in case of notes about variations in the recording. This is just the same as AcoustIDs that get wrongly associated. You can’t just merged based only on a number.
In the annotation I will often see a list of ISRCs that detail the remastered recordings. It is better to list items like this than assume all other numbers are wrong. Put all the facts on the page and let people choose and understand.
What would be really useful is a comment field that can be attached to an ISRC. Annotations for ISRCs would let you flag oddities in a clearer way. (But then I also would like that for DiscIDs… )
Thanks a lot for clarifying. I actually agree with all of that. Such mistakes should be corrected. In such cases the ISRC is also associated with a separate recording (or can be moved there), so nothing is lost. I was only worried about actually multiple ISRCs for the same recording (even if issuing the additional ISRC was a mistake, but it happened anyway).
I also agree that it would be great if MB would allow documenting the source release for a ISRC. Its just important that the ISRC then nevertheless is a property of the recording itself also.
One thing to note about ISRCs is that the practises for submitting codes to a central repertoire database vary quite a bit regionally. In the international handbook there’s no requirement for record labels to do anything with codes they’ve assigned aside from track the assignments internally - although regional agencies might have additional requirements.
Of course, ISRCs in the modern day are only really useful if they’re in a repertoire database like SoundExchange (which is used by the IFPI ISRC search tool), but I suspect that a lot of the older/more obscure recordings in there might have incomplete or - rarely - incorrect information caused by mistakes when record labels backfilled things from old internal records
FWIW, the ISRC Handbook section A.13.3 describes the recommendations for recovering from the error of assigning a single ISRC to more than one recording:
Where an error has led to the same ISRC being assigned to more than one recording, generally an attempt should be made, if possible, to resolve this in favour of correctly assigned ISRCs. It is noted that it is often not always practical to withdraw physical or digital stock. A new ISRC shall be assigned to one or both recordings – and used for future releases. Erroneous ISRCs shall be noted in the Registrant’s internal records. Business partners shall be informed of the error and the steps taken to mitigate the potential for further error. The local ISRC Registration Agency or International ISRC Registration Authority should be contacted for further advice.
Regarding multiple ISRCs - that’s just something that happens; either due to record labels having poor records, or a transfer of rights to a new label that doesn’t have information about the old assignment. The handbook’s recommendation here is that none of the ISRCs are erroneous - but instead, that the “Registrant shall select one and use it as the preferred ISRC.” They specifically recommend that databases should store all of the assigned ISRCs but link them to the preferred ISRC. Unfortunately, from the outside, there’s no good way to know which ISRC is intended to be the preferred ISRC. (The handbook recommends that the first registrant to do an assignment choose the earliest assigned ISRC.)
I’d be in favour of a system on MusicBrainz to mark a specific ISRC on a recording as “erroneous” so that it’s still in the DB attached to the recording, but people will know not to use it. Part of the reason for this would be to block it from being resubmitted, which deletion doesn’t cover. (Many ISRC submission tools will not show context like annotations - that’s something I should look into adding to MagicISRC.)
I agree with this approach. Not only does it address the problem of erroneous ISRCs being re-added, it records a fact which can be useful for the database (i.e., that a particular ISRC is associated with a recording, even though it’s erroneous).
.
)