Looking through the edits I have been doing, I noticed numerous ISRC problems. Things like:
explicit and clean having mixed and crossed ISRCs
DJ mixes using the original mix’s ISRC
Different mixes, such as w/ spoken outro vs w/o spoken outro, having the same ISRC
Extended mix having same ISRC as normal, etc
I believe I know at least one reason this is happening, and I am not sure there is anything that can be done to prevent this. However, is there anything being done to attempt to repair and remedy the problem?
I know this is a partial subject of debate in prior threads, so without rehashing that, one method I see is that any recording with more than one ISRC is a red flag. Yes, this is possible, but in my experience, most modern recordings will not have the issue that existed years ago. Another flag is an ISRC used on more than one recording. Maybe this is a warning that could be integrated to the UI… where is someone enters an ISRC that exists elsewhere, something of a confirmation checkbox could be prompted.
Any thoughts on how such things could be automated?
i don’t work with very popular music, so maybe it’s very different when there are that many people involved in the creation and distribution process. but for me i’m very surprised when it truly does end up being “1 recording = 1 ISRC”. it’s a little annoying, but it is what it is.
an artist i edit a lot does this intentionally. he wants the streams to carry over from one recording to the next, and to do this, he will reuse the ISRC. this leads to this ISRC having two associated recordings that are audibly very different. i don’t totally know how that works but it’s happened enough for me to be very used to it.
on the other end of the spectrum, with many distributors, they require a premium subscription to set a custom ISRC. if you want to rerelease a recording and don’t want to pay this, you will just have to have two ISRCs. beyond this, some artists/distributors just don’t care enough to mess with ISRCs at all.
i do think a confirmation checkbox could be nice… as long as it doesn’t break my ‘submit from spotify’ scripts jkjk
I would agree except there ARE different ISRCs for these recordings. Here is an edit I just did, removing the wrong ISRC while the proper one remains, and the removed one is also on its proper recording.
There is a big difference between two recordings that actually have the same ISRC and two recordings that have different ISRCs but MB lists them incorrectly. I think too often MB uses its assumptions far too lax, causing errors.
Yes, I do agree in some cases, this is the case. I stated that I was suggesting a flag, not a denial, as a flag is an indicator of a potential problem, not a problem.
Even the little I know about them I know ISRCs can’t map one to one to a MB Recording.
I see multiple ISRCs commonly appearing from Compilations. Or reissues. So much so that I ignore them and pay little interest in them.
ISRCs are about payments aren’t they? So having intros or not seem to not matter for that use case. In MB that is a separate recording, to the person who wants paying for use it is the music they focus on…
I would suggest ISRCs need the ability to have notes added to confirm if they are “original” or “compilations”, etc. I often see details like this added at the top of a Recording page explaining the sources of multiple ISRCs. Whereas clicking on an ISRC is a bit of a dull empty page.
They do. There is a “version” section to the ISRC. This is one of the easiest ways to distinguish them. It is not always used, but often is and is very useful. I feel this is an example of MB assumptions leading to misunderstandings… as this request already exists.
I use ISRCs greatly in identifying recordings. This does not apply as mush to older released music though, during those times far more issues existed. You can do in MB, for many modern artists and see no duplicates listed.
I do not see this, unless the compilation uses different versions or edits of the recordings. I believe this also depends on when said releases were released, as in the past, I can also confirm this issue. A reissue is the same recording, and should not justify a new MB recording, since the mastering is not justification for such.
I do agree, as stated, that this is never going to be 100%, nothing ever will. However, if we can change something that is 70% accurate to something that is 90% accurate, is that not a positive thing? I appears that the argument to ISRCs is that it is not 100% perfect, but nothing ever is and the current state can be improved simply by using them with a proper understanding. I have done numerous edits recently just combining recordings with matching ISRCs, then also seeing that the AcoustIDs also match. Just on that fact alone shows that the ISRC identifies matching AcoustIDs, which is used to identify a recording in MB.
From what I see and in my experience (which is obviously not 100% all inclusive so others might have an opposite experience), this has not been much of an issue in the last 10 years. The ISRC for me is more useful than than MBIDs as in my collection it has identified literally thousands more duplicates.
Please no one take this topic as argumentative. I completely understand the historical and in some cases still current issues with ISRC. I am not disputing that at all. What I am stating is that when it comes to identifying a specific recording, the ISRC is just as useful, if not more useful, than the AcoustID. I say this because I can use the combination of the two, along with other more standard logic, to identify a recording, where said recording has one ISRC and multiple AcoustIDs.
The AcoustID is a whole different topic, so I am avoiding that portion… why a single recording can have multiple AcoustIDs… and in some cases, 10, 20 even 30+ of them.
In some cases like with Susan Raye, there is not even a single ISRC assigned to any recording.
Don’t call it “MB assumptions”. This is me who knows nothing about them as it is only threads like this I learn. They are less use to me as I don’t trust them. If there was more data to read when you clicked on them it would be more use. For example - why don’t they link these pages to the ISRC databases?
Comments visible on the pages would be useful. They need to be made more accessible.
I’ll watch out for examples for you and paste them here. It is common from the bigger labels to do this. Especially on older reissues of popular stuff. They just put a new set of numbers on that compilation CD.
When merging recordings I often see the duplicates. I do a lot of AcoustID matching - and they are not unique. This is something that probably follows a 70% rule. Nothing is perfect, but you work with what you have. But because nothing is perfect a merge should not only happen based on an ISRC match. An ISRC match can start a merge, but other checks need to be done to be certain.
ISRC is only one of many bits of data that gives us knowledge. But like a lot of data, it is not perfect.
I agree that this would be very useful indeed. I also agree that currently clicking one in MB is useless, as nothing is provided aside from its MB assignment(s).
Again I need to agree 100% here. Nothing is perfect. I guess I am suggesting MB look closer at them as a resource. I am happy to do merges with those I find. I use the ISRC as a start, then use the AcoustID, the releases it is used on, the duration, etc.
This is a great point. If someone does not understand the message, I agree it will be ignored. Me, I would see it as a check… did I copy the wrong ISRC, or look at the wrong version? This assumes I know what I know, which cannot be assumed for all. There are some that know more and less than I do, so knowledge is useful for everyone. No submission, regardless of the data in question, will be good if the editor does not understand how that data is used in MB.
In the mean time, I can and will do my part, as I can. Historically, people have approved merges with matching durations and AcoustIDs as justification. For me, the ISRC is a better first layer and also improves on the existing issues, as there are times that a match in ISRC does not equal a match in AcoustID. I find however this to be a result of bad data… but not in all cases. I also believe that if the ISRC is not clear, meaning I see a potential issue in MB, but the ISRC DB does not differentiate (like clean vs explicit), it cannot be used without additional support, like a release (having both clean and explicit) and comparing the ISRC from the metadata to distinguish. I am not sure this can be asked of users though. I do it because I want to, I find ISRC extremely useful to me as a user of music in a collection.
Right, as you have surmised I don’t really add ISRC’s. So my use ISRC-breaking use case would be more often merging two releases/recordings that have different ISRC’s.
I add ISRC’s when I import from Spotify, because atisket makes it easy. When there is doubt around ISRC’s (often with VA releases) I skip that step - but of course the release is still linked to the recording, and it’s trivial for someone else to add the possible incorrect ISRC any time.
However I would not make a new recording just because of the ISRC, for reasons outlined for others above, unless there was a big time difference or something
Debate is good. Points of view are good. (I also know I write rubbish at times so hope I make sense and don’t sound aggressive)
Make ISRCs interesting and useful and more people will take note. Make them easier to use. For me they are awkward to extract from a CD, I need a script, and lots of manual work to upload. So I don’t have an interest. I have never submitted an ISRC even though I have added hundreds of CDs.
If I had ISRC checkboxes to tick I would look for a script to disable them. I can’t check what I don’t understand.
To me ISRCs are about money and payments. Not a side of music I am interested in.
AcoustIDs I can generate in Picard from my audio. There are mistakes in the database, which I agree is a mess that needs clearing up. But as I can easily add them, quickly find them in my own files, they are useful. I can add a music files to Picard and generate an AcoustID and see them on the database. They help me make a decision, but will not be the only data I use.
Both sets of numbers aid in a merge, but they are only part of the data for that merge.
One thing that always amazes me about MB is the many and different ways people use this data, and add to this data. I have never see such a multi-purpose database as this place.
I understand this statement, and I believe it to be true. But the purpose of a barcode is the same, an identifier for billing that also doubles as a way to identify a product, although sometimes more than one CD “version” has the same and some have two (differing only in printed material. To me, I do not care about what it is or was intended for, but I do care about what it can or could be used for.
Yes, I agree. AcoutIDs are easy to work with, as you stated you can just use Picard to generate and submit them, not even needing to have your files tagged. How do you “find them quickly in my own files”? Are you meaning that you can find them in your metadata?
Regarding “and see them in the database”, the same is true for ISRC. With a script for the browser, you can have the ISRC and AcoustIDs display under the recordings in releases, but otherwise, there is not much in MB to work with in regard to the ISRC. To this I also agree. I believe this is because MB has not really used the ISRC as much other than an attribute to a recording, which I also understand.
What I am trying to do is
Unless I am just missing it, I would like to use the barcode as a search item for example. If I am trying to locate a release, it would be great to use the barcode as a search term, same goes for the catalog number and other aspects. I was recently informed that in some cases there are advanced search options, but I must admit I have not looked at them too closely. So, if I assume these options are there (I am not sure), they are still not easy to use.
I would also like to kindly ask that those in the discussion have a look at my recent edits, more coming in the next few hours in kind. I want to show that I am not just talking, but I am putting in the time and efforts on this topic. Also note that I have done 3 KWS (popular enough to be mid road popularity) releases so far and in my adding if ISRC, after those three releases I have yet to encounter any recordings that have more than one ISRC. However, I am doing original releases, not compilations. The same ISRC has also appeared for some of the recordings across multiple labels, which in the past has also been a problem, where once a different label did a release the ISRC would change.
I also want to add that I am only providing example(s) to the discussion; I am sure that as stated above others will provide examples to the contrary. I believe that real examples of the cases discussed carry the most strength, substance vs words. I think it will help the discussion to see the real effect in the MB database. Please also provide examples, I know we all work on different types of releases, so seeing what we all work on and the issues related to them is important.
I work with CDs and not purchased digital files. So am all over the little tiny visual differences on the rear of a CD box, or the different locations of manufacturing. (I’m a manufacturing geek ) A barcode helps me identify a whole album. If I had access to ISRCs in Picard I would pay more attention to them during that process.
I find AcoustIDs either because I have tagged them into the files with Picard, or more usually I just fire up Picard and throw the tracks back in and re-generate that AcoustID. This is something I often do when merging two recordings as I want to check which AcoustID I have if I see a heap of AcoustID attached.
I have that turned on. One of those vital scripts that brings the details of this place alive. I have also used that to correct obvious errors when I spot duplicated ISRCs on a page. But often it is a guess as I have no way to check.
Easy to miss. It is on the expanded Search menu at the top of the page. The Search in the middle has many more options to choose. Not the quick search on the right. But you have to select the exact item type to search (It can be a little fussy at times with spaces and punctuation in cat nos)
Personally I use Discogs search as I can throw anything at it - barcodes, cat nos, matrixes or a mixture. I then have a script attached to Discogs that links back to MB. I use that search so often I have it added to my copy of Vivaldi Browser to just search on a right click.
Last night I tried to have a quick fish around for examples in my collection, but hit a wall. Easy to find those tracks in compilations with three ISRCs on the Recording in the MB database, but no way to then trace back from that to which albums they were added from in my collection. Also as I cannot just put those CD back into any software on my PC to read them, I can’t check my originals like Picard. So it will be a while before I can show examples.
Once there is a simple GUI for reading my CD and uploading the ISRCs then maybe I’ll look a them. While buried in a complex command line tool I ignore them as it takes too much time.
If you want bits of feedback on the CDs you added, it is tricky as I don’t know the artist. Looks good. I like people who add lots of the extra data like copyrights.
Especially enjoy seeing an Engineer pop-up on a Recording\Release as I can often see them link between studios of music I like. Though I tend to add these kinds of things at a Recording level on an album like that, unless it is made clear it was done at multiple locations I make the assumption it is the same guy doing all the work.
Personally I am a big one for adding Works. Even if I don’t know who wrote it, though usually there is something in a booklet. OR I research off via Discogs\Wikipedia\Homepages\Fan Sites.
The simple click of following links is what makes MB so deep. ISRCs could do with more of that linkage as all I get now is a big empty page showing me the recording(s) linked to that number, which leads me to a huge page of tracks. Maybe on the ISRC page there could be a “next in order” link that could give you more chance to work out the album it was submitted from.
jkjk
Points of view are good. (I also know I write rubbish at times so hope I make sense and don’t sound aggressive)
) A barcode helps me identify a whole album. If I had access to ISRCs in Picard I would pay more attention to them during that process.