Different ISRC or masters (not) sharing the same recordings


#61

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. :slight_smile:


#62

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?


#63

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).


#64

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.


#65

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?


#66

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.


#67

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.


#68

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”.


#69

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.


#70

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.


#71

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?


#72

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.


#73

But how do you know which of them is right? Maybe the first recording you found was the wrong one.


#74

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?


#75

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 :grinning:. 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.


#76

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.


#77

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.


#78

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.


#79

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.


#80

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”.