Just submit your ISRC from CD once you know that the recordings are not new mixes, instrumental versions, lives, mono versus stereo or that sort of things. 
So you are fine with such a mix of ISRCs, and just add another set in without knowing what all the other versions reference? Also, how does not make sure it is not a new mix? It is not a instrumental, live, mono or anything like that.
So of all the data we have to identify, the ISRC is of no use as it might be correct or not correct, and the acoustID cannot help here, so we are ok with matching a title and duration and calling it a match?
Title and duration is not enough to identify a recording. But dates and performers generally are. If they all match then having different ISRCs is not itself enough to justify a new recording (see comments passim).
1 Like
Usually they would advertise new versions as theyâre trying to sell CD to us who already have other edition.
But in doubt, donât merge / create new recordings.
When you say that all the ISRCs on that release are âwrongâ, can you elaborate on how? Iâm still new to the ISRC concept.
On âPushermanâ, for instance, i see two ISRCs:
GBAWA9862573 - the soundexchange lookup shows no results for this
USRH10282652 - soundexchange says this is assigned to âFreddieâs Deadâ rather than âPushermanâ.
So if thatâs accurate, then the second one is clearly wrong and should be reassigned, but the first one may or may not be right.
Am I interpreting these correctly?
I used âwrongâ here simply as a meaning for does not match the release being questioned. There looks to be a multitude of exact reasons, you pointed out one above, so it was easiest to just stick with no match, sort of a 1 â 2 thing.
It is my opinion that if I add the ISRCs for this release to these recordings, I am just making a mess a bigger mess. But it appears that the response here is to do it. I think everyone is taking it too literally that the only thing in question is a different ISRC. The point is more that if I have an ISRC, acoustID, etc ⌠all data to properly identify a recording or a set of recordings, does it make sense to use this data and create a proper recording(s) that is more completely and correctly specified vs adding even more variation to a very loosely recording(s).
I will certainly see what others have to say on this release (@highstrung please do share your thoughts), but I my efforts on fixing such issues are for naught. I think that is what some have been trying to tell me⌠but I guess I just cannot help trying to fix something I can see to be not proper. All I am trying to do is add data and knowledge that I have, and after I make edits, leave MB is a better condition than when I started.
I think itâs hard to answer âis everyone ok with these being wrong?â without knowing specifically how theyâre wrong. For the GBxxx codes, it seems like they should be left alone in the absence of anything showing conclusively that they actually are wrong.
For the ISRCs attached to the wrong titles - edit history shows those were applied in edit 19277708 by wonder_al, whoâs still an active editor. I would suggest you start with asking them if they know what might have happened.
Yeah, let me rephrase⌠what I mean is that since I can, with this release, ensure all the recordings are proper, is everyone ok with just leaving it as-is vs me fixing this release. There are so many releases involved in all those current recordings, going into each one of those to try and clean it up is not really realistic.
It is more a question of deciding to start clean and make it a new but correct set of recordings, or just leave it as-is. It seems most are ok with leaving it as-is and continuing to lump all in. I am just making sure that is really what all want, because although things like verifying dates and performers, etc are all great and ideal, it is just not a possibility given the conditions. The current recordings re defined by the numerous releases they are on, which in this case, it is mostly âsame name, same durationâ.
So it sounds like your proposed fix would be to create a new batch of recordings, attach only the verified ISRCs associated with this release to them, and then use those recordings on only this specific release?
That seems to me like it would be creating duplicate recordings that differ only by ISRC (as far as we know). I think thereâs a consensus to not do that.
2 Likes
No. It would be creating new recordings with all verified information. If one were to add a second ISRC to the recording, it would be verified to actually be a match. ISRC would be one factor of identification only, but would actually be used. So for example, if one would merge a recording into it, you would need to verify that the ISRC of the recording is the same as you have. If not, then a comparison between the existing ISRC and your ISRC would be needed to make sure it is the same. If so, then merge away. There are recordings with duplicated ISRCs, I have never denied this, so I am unsure why this keeps coming back to a proposed required 1 to 1 relationship, that is not at all the case. I would think that a recording could have one to many ISRCs, and an ISRC could have one and only one recording.
My question is (after having only skimmed the thread), why is there thinking that an ISRC is âwrongâ? Why is soundexchange considered any more canonical than the ISRC encoded on a physical CD? How do you confidently decide that a particular recording should not have a given ISRC?
As far as I know there is no official database of ISRCs; While it would be nice to have something like wikidataâs âreferencesâ system (so we could say âthis is the ISRC according to soundexchange; this is the ISRC according to release X; this is the ISRC according to release Y, etc.â), thatâs currently not possible. The most Iâve seen is a best guess based on âthe tracks on this album follow the pattern USXXX1234567 and go in order from track 1 to track 17â, and things like that. So how do we ever know if itâs wrong?
1 Like
To start with, when it is assigned to a recording with a different name. That was just one example. I used wrong in quotes as well, and as I explained, this was to combine all reasons leaving my intent being just that it is not a match. Nothing more. No one can ever be sure of the integrity of data, nothing is ever perfect. MB just in this thread has proven to mix up recordings of different titles under the same name. Error is always expected, it is excess error that should be a concern. Like the freedb database and last.fm database. It is the deviation out of the expected margin of error.
An ISRC is wrong for whatever criteria you use as correct. The name of the recording, the year it was recorded, the version of the recording, duration, etc. Even a direct 1-to-1 mismatch can mean wrong, although I think we all agree that a different ISRC for reasons of only barcode of release or similar does not qualify as criteria to make it wrong, but to make it an additional.
soundexchange could be wrong, I use mostly the embedded data in files to gain this data anyway. soundexchange is nice though, especially to use it as a sharing platform since I cannot show you metadata or the contents of a CD.
But how do you know which of them is right? Maybe the first recording you found was the wrong one.
Which ISRC is right? I would not without looking through all of the releases used with all the recordings. Thus the idea of starting with new, fresh and verified recordings. Maybe I am misunderstanding?
Very good point, unless you hold the the CD with the ISRCâs on them you do not know what belongs where. Then there are all the earlier CDâs with no ISRCâs at all. A number of years ago I went down this rat hole looking for a ISRC authority, much of what the RIAA had was in filing cabinets, makes you wonder where MCPS is on this issue, Europe has always led where data was concerned.
Do not take this wrong, but this has been a great topic to monitor, thwaller has the bug and is going to be a great member. For a moment there I thought he was going to back off, but he keeps going 
. He is correct on the issue of data lose but looking at magnitude of unattached recordings I think the present merge policy is correct.
I am at nearly 6000 edits in the last 7 weeks and have created, edited, or verified nearly 3000 of my releases in the DB, there are a lot more issues than ISRCâs. Wait till he starts looking at discids, but that is another topic.
3 Likes
I think what is meant here is if the soundexchange database lists it as assigned to one recording but in MB itâs attached to a different title. Thereâs an example above, where MB has an ISRC attached to âPushermanâ that according to soundexchange is assigned to âFreddieâs Deadâ. Unless the soundexchange data is unreliable, that seems clearly worng.
I wanted to share an example:
I just finished going through the releases for this artist. I added ISRCs for all the recordings as pulled from my files. Please note that the exchange site to get ISRCs was not used for any of those, just the meta data from the release files (how convenient). There are no duplicates, recording or ISRC. This type of thing may not be the case for older artists and/or older releases, but this is my experience as a whole. It will show better once more releases using her recordings are added.
Most digital retailers require such data to sell in their stores, so that is also a difference. Additionally, CDs are becoming obsolete. This is proven by retailers stopping CD sales. Best Buy, a larger retailer in the Milwaukee area and maybe elsewhere, just stopped selling CDs (or started the process). This is a big thing as they used to carry multiple isles of CDs in their stores, this is no more. My point is that the way digital releases are sold, structured, formatted, etc is not only where things are going, but we are getting there today.
I understand no one here puts much in ISRCs, and that I can respect. But I hope all will see that changes in releases cannot be ignored for much longer. Attributes of such releases will become more and more important, and ISRC is just one of those factors, and is even embedded in the file metadata. So I guess I will consider this topic done as looking at ISRC as an important factor (only a slight factor) has been mostly unanimously rejected. I hope at some point we can start looking ahead instead of present to past only.
I disagree, ISRCâs are important, they are data attached to the recording, how important they are I cannot quantify or measure, I do not have enough data or facts to support a informed opinion. Reading through this topic I am not sure anyone has expressed a qualified âresearchedâ opinion on the subject, they appear to be opinions. Are we going to dismiss this topic without a âresearchedâ explanation into their importance.
I think I understand the reason for the merging but I do not agree with it. Nowhere in this topic have I seen a âexplainedâ technical reason relating to the DATABASE and the DATA as to why this merging is going on. Without that explanation I have to assume a âdouble standardâ of attribution exists for the Database, we have to research Artist, Recordings, etc and supply attribution on that research (and we should), but for the ISRC merging where is that attribution of reason for the merge explained.
I am not asking for a change, I am asking WHY it is being done? What is the REASON behind the merging? What is the NEED for this merging? Lastly why are the ISRCâs not important to others.
I apologize if this seems confrontational, but there really needs to be a better technical explanation. This topic frustrates me, I come from a world of âbig dataâ & âbigger dataâ, throwing away the context (origins) of where the data came from is not right. It may be ânecessaryâ, but it renders this data almost useless except to say "here are the ISRCâs that MAY BELONG to the recording, not âhere are the ISRCâs that BELONG to this recordingâ.
The points about CDâs and retailers is not accurate and not well thought out, but that should be a different topic, IMHO does not belong in this topic, it side tracks the topic.
The latter is exactly what we claim. These ISRCs all belong to this specific MB recording (which doesnât match the ISRC definition of recording 1:1 - itâs worth keeping in mind neither match the âpopularâ definition of the term ârecordingâ either). If what you want is to associate ISRCs to tracks (âthis track in this specific version of an album has the associated ISRC Xâ) Iâd actually think thatâs a good idea, although it would require changes in the schema.
5 Likes
Thank you. I know this can be a difficult subject for some. I just wanted clarification. And thankâs for the recording vs track statement it provides clarification I had not though about, I am just getting started with âworksâ.