4.1.3 No re-use
[…]
A new ISRC should be assigned whenever a recording has been re-issued in a revised or fully remastered form. Also see Sections 4.9.1 Re-mixes/ Edits / Session Takes and 4.9.10 Re-mastering
4.1.4 Format Independence
A single ISRC is used for each unchanged recording regardless of the format in which it is released.
4.9.10 Re-mastering
When a track is re-mastered for the purpose of reproduction on a new carrier without restoration of
sound quality (also see Section 4.9.1 Re-mixes/ Edits / Takes), then no new ISRC is required.
It is nevertheless the Registrant’s responsibility to decide where to draw the line between sound
restoration (full re-mastering) and simple re-mastering.
7. Our company uses in-house code for identifying our sound and music video recordings. We then use this in the designation code of the ISRC. Sometimes an in-house code may apply to two versions of the same recording because we have remastered some of our backstock for re-issue. Can we use the same ISRC for the new remastered version?
No. Re-use of an ISRC that has already been allocated to another recording or to
another version of a recording is not permitted. This is in order to guarantee the unique
and unambiguous identification provided by an ISRC.
A new ISRC should be assigned whenever a recording has been re-issued in a revised or re-mastered form, even if both items have the same in-house code.
GRid (Release identification, BTW has anyone seen these in the wild?)
What a bummer:
The primary function of the GRid is to support machine-to-machine communication
through system-to-system messaging. It is therefore intended to be largely invisible
in use. However, there may be circumstances in which GRid is displayed to a human
user, in which case some rules for presentation are in place.
That’s all nice and fine, but the specs say how it should be. Doesn’t change the fact that the exact same recording often gets assigned new ISRCs in reality. I have seen plenty of examples for this. And I bet there are enough cases where the same ISRC was used for different recordings. I don’t know any myself, but one of you can probably provide an example.
In the end MB needs to deal with the often messy reality.
@Zas - give me a bit to put this together. This was brought up in the past, so I want to collect all the data on this before just posting info. The concept remained with the three tiers (work, recording, release) but changed where and what data is stored in which object, and the creation of a new object off of the recording with a one-to-many relationship to the recording.
@outsidecontext and @chaban-
Thanks for posting that, it is helpful for all to see the specification. Although there are times that a new ISRC is assigned to the same recording, I would like to see some data supporting the frequency of this. I believe (meaning that it is my educated guess) that this is more an issue in the past. That said, I could be wrong on that, I can only speak from my own personal experience.
I believe the issue will be a wash with the barcode issue in the same. A barcode is sometimes used on two different releases, a new ISRC is sometimes assigned to the same recording. The barcode is a bit more destructive since having a duplicate recording does not really provide bad/conflicting data, whereas a barcode on two different releases can cause some brain malfunction while you try and figure it out.
Although I am 100% on the side of a reform here, I will also be first to admit that nothing will ever be perfect. Even if MB could design a system that itself is perfect, junk in = junk out. So any errors from the music industry themself, or any other source for that matter, are simply out on the control of MB. Although I hate saying it from a data standpoint, it is just something we need to accept and should focus on the side of matching the metadata, not trying to change it to what we think it should be. There is a different place for stuff like that, as it is also important data.
Speaking using an example of iTunes music files via download … there is a difference of data importance compared to MB. This is also the case, but a bit different, with other stores like Amazon, but I have a large base of samples to use for iTunes so I speak to that with facts to support it in hand. One great identifier is the “vendor” atom. Currently this is formatted as :isrc:. The ISRC is the ISRC, simple. The vendor is the label (and sometimes not a label) that is tied to the ISRC. There is also a “copyright” atom which supplies the c and/or p holders, depending. That is one big conflict I See trying to locate the proper label to see in the label MB field as it is not really disclosed to us in the same as physical media where you match logo/picture to name and you have it.
As I mentioned before, I believe our job should be to first to properly identify music as it is and can be identified, not what we think should be there. Second is to make some sense of the crap and make it usable.
Release is an aggregate and stands beside the other two. On the atomic level MB goes like this: work → recording → track (which not coincidentally mirrors FRBR’s/LRM’s work → expression → manifestation, a model that NGS was to a certain extent based on). But ok, I’m arguing semantics here.
Now that’s something I can’t agree with at all! While all those years I’ve been using MB for my personal collection, still from some idealistic point of view I genuinely believe in MB’s strive for being the perfect/ultimate music database (and eventually a cultural one, indexing other art forms too). Which means it shouldn’t repeat industry’s cataloguing mistakes.
However I do agree with you that, ideally, it should fully map industry’s standards.
Multiple ISRC’s jumbled into one MB recording is simply lost data. So, if our own definition of recording doesn’t match the industry’s one (for whatever reasons - remasters, erroneous code assignment by different registrants etc.), then we need to go down to a more granular level (recording → track) to reflect all the exceptions.
Now I don’t think I’m in a position to discuss the technical side since that’s not my cup of tea. I can only present the idea for a specific case:
ISRCs remain attached to MB recordings
Two separate masters of a recording are represented as different MB tracks
each ISRC can be optionally mapped to different sets of tracks
An exactly the same recording, Godmother by Holly Herndon and Jlin has been first released as a single in 2018 and assigned a code GBAFL1800302.
It was reissued as a part of the 2019 album spanning multiple digital, cd and vinyl issues with a new ISRC, GBAFL1800329.
I don’t think there’s any need to question or ponder on this decision, only to reflect it properly. That is, the [MB recording 1] contains two ISRC codes, where [ISRC 1] maps to [MB track 1] and [ISRC 2] maps to [MB track 2], [MB track 3] and [MB track 4].
This is an interesting approach. Not wanting to argue over semantics as you have also stated, the object that represents the recording could hold multiple ISRC codes that would then be a key in the relationship to the album or release object. My thought was to make the recording object unique, but this may very well be a better approach.
I wanted to clarify this. What I am meaning is that the problems created within the music industry is not something anyone can fix but them. I think it is still important to capture that data as-is. However, MB can add some intelligence to that and help fix the gap so to say.
Thanks for the example. I am sure they do exist, and your idea seems to be a solid way to address it. For me, using ISRC is ideal as I can query metadata for a code and get what I am looking for. nothing else allows me to accomplish the same. I can then create releases in a more virtual sense, so if the same ISRC is used on 4 releases, those releases can all use the same recording, generally speaking.
For me, MB is not really usable. I tried and contributed and learned while doing so. What I am sad to say is that I have replaced a=literally all of the files that I used MB to tag as I wanted the original metadata back. I believe that there should be a different methodology to Picard, but that is a different topic. Please do not misunderstand me, I do appreciate MB and what it is trying to do or I would not take the time to type this. MB is king when it comes to physical releases, the best I have used. Thinking of myself as just a guy who listens to music, the fact that my music is mostly all digital now, MB does nothing to help me. I believe that MB has built a solid brand and positioned that brand as a leader. Even if my thoughts are all disregarded, I want to see MB transition to the digital era.
In practice, industry is actually attributing ISRCs to tracks rather than recordings, and this is why we end with multiple ISRCs for one recording.
Also definititions of remaster/edit (=whether to create a new ISRC or not) vary a lot in the industry, they will never match MB definition perfectly anyway.
@yvanzo@Bitmap : What’s your (technical) opinion on this idea ? Is it feasible ? Any drawback ?
Drawbacks are mostly on the UI side: we would need to figure out a way to do this assigning. The schema is always easy, how to make it clear and understandable is almost always hard
I don’t think it’s impossible, though. There’s also been talk of just assigning ISRCs to tracks only, which is also a possibility I guess. Either of them would require fairly big changes to the UI but might still be doable in a sensible way.
@Zas - I find it hard to directly answer your question on making definition changes right off the start here. There seems to be conversation on where attributes should be placed, and it seems like it is in a positive direction. The definitions, I would think, will depend on which objects hold which attributes.
Looking at past discussions, I found 2 elements to add.
A digital release could be all-inclusive in the sense that references could carry attributes of their own, its own object that is tied to the release. In this, you an store the store IDs, store barcodes, etc. This would greatly reduce the digital duplicates which seems to be a major issue with many, and would also allow for the details offered by each store to be captured, like a sub release if you will of the main one. Not sure if that is technically possible given the current database, but it is a thought.
The performers could also be an object of their own tied to the recording. The reason for is is lets say you have a recording and a remastered recording, for whatever reason assigned a new recording due to distinct enough differences. Instead of having to add all the performers again to the new recordings, and thusly the new entire release, you could simply attach the performers object to it. Same could apply to recordings that have a normal set of performers, and sometimes a guest musician, like in remixes and such. In these cases, you could simply add the normal performer object, and add the individual extra performers as needed.
I do think that Skeebadoo’s suggestion for ISRC handling is good, and even say as it is probably better than the ideas previously discussed. Someone had told me a while back that such additional levels of data is just not doable given the database structure, but since such things are being discussed now, maybe that has changed. Regardless, it seems like a good idea.
Thinking about this idea, is it really best to have the ISRC at the release level vs the recording level as an attribute with a one-to-many with tracks on a release? I mean this as to not duplicate ISRC entry on all the releases an ISRC might be used.
For example, maybe as you enter the tracks to a release, it can provide a pulldown to select an existing ISRC or enter a new one. Alternatively, we would need to provide/allow for the user to say unknown and not default to anything.
I just meant that ISRC edits, like most edits are more trustworthy, IMO, when done per release because usually it means you know what you are talking about in context with more proof.
Sadly a note with source of ISRCs is made only by a handful editors.
A mapping of tracks-recordings would be really nice.
Recently I had a case of an artist who changed his digital distributor and got new ISRCs by mistake. He also got new UPCs. Nothing else changed, he said.
That’s right. I do add edit notes but it’s really inconvenient because I have to come back to my edit history to add edit note after the edit is made.
It would be more convenient to write edit note at the time of edit and that the ISRC submit tool would fill in its technical details there:
I posted this on the wrong thread, so I am reposting here, as appropriate:
Yes, as a collective, changes have been discussed in numerous places. Hence the issue I had with a direct question … redefine this. I believe what @Zas was proposing is that I offer a suggestion of sorts. I have many ideas, but I would like what I contribute to be community effort. If I were to put together some form of data flow diagram and structure, is there a format that works for all here?
I am not a dev or maintainer of the database here … but I believe the next step is a proposed structure that shows a different Inheritance and attribute placement. IMO, I believe it best to start with the current chart. Is this available? Either way, I can start, but as a community, we can put together a UML class diagram, DFD, etc on a new way for a release to be built.
