If you edit something out of a recording, it’s a new recording on MB, as it should be. What you are saying is that clean & explicit recordings are the same. They are not. Only trim that is considered not to be a new recording is fade in/fade out trims. A recording is NOT just the master tape, but also the MIX of that. The original examples of this whole thread prove this.
8 Likes
This is not “my way”. This is a way designed by MB over many years. Not something thrown together with little thought like you are doing. I am just refusing to waste my energy playing the “pick an argument apart line by line” game.
No one is forcing you to use MusicBrainz. You can tag your files in any way you want to.
2 Likes
It used to be a bit different pre-NGS and a much more complex model was considered. I’ll just dump these links here for now:
6 Likes
They have a relation to each other. The radio edit or clean edit can be marked as an edit of the original. Also, everyone, not just MB, thinks different mixes are different recordings. Different ISRCs are issued to them because they are different recordings. Sometimes radio edits of a recording even have different engineers. Are you seriously trying to tell me that the mono mix and the stereo mix of all the Beatles recordings are the same because they recorded them once in the studio? This is what we are saying. A recording isn’t just the recording to the master tape, there are processes where they are mixed before mastering. We treat the different mixes as different recordings. ISRC treats even mastering as a different recording so don’t act like MB is alone in listing recordings from the same recording date as different. I just don’t really understand the issue with recognizing different mixes.
9 Likes
Ok, so indeed you want to restructure the database schema. That was not clear in your first posts, where it more seemed you wanted to merge existing recordings without changing the structure.
So if I get you correctly you would have a single entity for the recording, but therer would be different mixes or variations of this recording. Things like mixing relationships, ISRCs and AcoustID would be linked to variations, as would be the tracks of a release. So it basically boils down to what I already wrote above, that your suggestions leads to another layer.
What I don’t get is how this helps with the original concerns of this discussion? The schema would get more complicated, editors would still need to identify either the exact mix or they would add a new mix. They also would need to identify exactly on what recording this mix is based on. If they couldn’t say for sure, they probably would need to add a new recording and a new mix.
So from the view if an editor, how exactly is this additional complexity making it simpler for me to edit?
7 Likes
Yes indeed, this is the general definition of a recording.
But MB recordings are not recordings.*
I think we could (should?) have called them tracks, mixes, or something like that…
Update
I think naturally we think of the definition number 2.
But definition number 3 is not that far from MB recording entity.
* It’s why I often include MB before each MB entity names: MB releases, MB recordings, MB labels, etc.
5 Likes
Wow, I love this kind of passion I gotta say haha. Even if I’m not on board with the thinking…
I’m not sure if I’m understanding your train of thought, but doesn’t MB already cover all this as a ‘work’? Everything is listed together there:
It seems to me everything you want merged would already be merged at that level? So what’s the point of not allowing the granularity at the recording level?
Or maybe there’s some improvements re. linking recordings to works or using the work date that could be done, but I’m not sure what your exact use case/issue actually is.
6 Likes
I find sarcasm and dismissive attitude really unhelpful in discussions like this.
I did not design the MB schema. There are things about it I don’t like, and things I would have done differently. But I believe that intelligent people devoted (and continue to devote) time and energy to getting it right, and that they had valid reasons for making the choices they did. I think that’s a better starting point for discussing shortcomings and potential improvements.
18 Likes
So if I get you correctly you would have a single entity for the recording, but therer would be different mixes or variations of this recording. Things like mixing relationships, ISRCs and AcoustID would be linked to variations, as would be the tracks of a release. So it basically boils down to what I already wrote above, that your suggestions leads to another layer.
Yes, but it’s not “another layer,” because the information is already present in the database.
The problem is primarily one of display on the front-end and JOINing on the back-end.
For the eighteenth time, the relationship between Release Groups and Releases is handled in an excellent manner, but Recordings taken in a completely opposite direction.
Release Group → Release
“Recording Group” → Recording
KISS.
The only reason you don’t see the unnecessary bloat and complication now is because you’re used to it.
If you venture to most any music collection circle online and there is a thread or topic about MusicBrainz, you will assuredly discover a lot of people cannot wrap their brains around things like the fact songs are considered distinct and separate simply because of something like two “Yeah” ad libs in-between choruses.
Here’s (what should be) a “Recording Group”. On the back-end, all the variations of this song are already joined together. Visually, headers can used to group the track variation that appears on a various compilation and the one that appears on the original album, from this random “radio edit” released 2016, but currently shares no - zero - none - nada - relationship with the original recording in any tagging program and is hella confusing for many non-MetaBrainz insider club members on the website.
The vast majority of people tagging from the database through Picard, MP3TAG, beets and whatever simply want there to be an actual relationship between “Say My Name” from 2006’s “Live in Atlanta” release and “Say My Name (Timbaland remix)”, by way of the original song.
For starters, not every track in the database is linked to a work.
EDIT: 1st a., but since all “recordings” in the database must have a “recording” entry, this would ensure persistent relationships among each “recording” entered into the database.
Next, adding work relationships after entries and is likely beyond the patience and time commitment of most editors.
Third, tagging programs using the database are not able to link individual track information based on the WORK ID.
Fourth, see above with the “Say My Name” example. The already-present-in-the-database information is what needs to be used to leverage the relationships among what @jesus2099 (correctly recognizes as confusing to casual taggers and) labels “MB recordings.” Not adding more fields and more lines to the schema.
Fifth, the granularity won’t go anywhere. It would just be consolidated using a less cliquey, insider-catered to format.
I shouldn’t get into this because of the general attitude, but I’m just too confused not to ask:
I must be missing something, but… Having a “recording group” above “recording” is literally adding an extra layer. In fact, “release group” is a separate layer above releases, that was added a lot later than releases were - before that, we had just one layer for those.
It seems you think a second layer is not needed because we would separate the different mixes “visually” inside the recording page, but how would that work exactly, without a layer in between recording and track to store which mixes go together?
8 Likes
This song has like 42394394 unrelated, unlinked “recording groups,” due to the current “Recording” definition.
My proposal consolidates them all into just one
So no, no “extra layer” is “added.”
Do you want a user script that renames Work to Recording group, for you? 
I think it’s just what you say with Billie Jean.
3 Likes
We are going in circles, but again: if we don’t add an extra layer and just merge everything you consider the same recording into one entry then we loose distinction between those different variations / mixes / versions of a recording.
There needs to be some entity in the database where things like mixer relationship and AcoustIDs are attached to. If you don’t add this layer these variations / mixes / versions of a recording become indistinguishable.
If you do add this layer things become more complex, not less complex. People already struggle with deciding if different recordings in MB are actually to be considered the same mix. I doubt it will be easier then to decide if two different mixes are actually based in the same originally recorded material.
4 Likes
A recording is not any real object - it is just a word we use to describe a particular concept. This may be initially confusing to newbies, but if so, it’s quickly cleared up by looking at the first sentence on the Recording doc page: " A recording is an entity in MusicBrainz which can be linked to tracks on releases."
Remastering is the process of preparing mixed audio for release. If a re-release is remastered, but not remixed, then that uses the same recording - see, for example, Michelle by The Beatles, which is the same for the 1965 stereo vinyl and the 2009 CD remastered release.
Remixing is any process which changes the mixed audio, including changing the relative volumes of tracks, adding new tracks, re-arranging the positions of audio. That does warrant a new “recording”.
If your remaster sounds different, apart from being louder, quieter or with more or less dynamic range, then it’s probably actually a remix, and so does get a new recording.
The current definition of recording in MB was decided after a two month long discussion between quite a few people until we got consensus:
https://www.mail-archive.com/musicbrainz-style@lists.musicbrainz.org/msg16558.html
It seems like that consensus broadly still exists, but obviously not every single person using MB will agree. If that applies to you, I guess your options are to open a style ticket on JIRA and try to achieve a new consensus to convince the right people to change the guidelines, or start your own online music database.
10 Likes
Yeah, but your suggestion still requires editors to select existing and/or merge recordings, a step that, as you’ve ascertained, beginner users wont be interested in doing.
So they can either:
Do the work and merge all of X recordings
Do the work and link all of X recordings to its work
It’s currently not perfect, but given the above I still don’t understand the point of merging everything. Maybe you have a specific use-case that I’m still not sure about where the work relationships could be leveraged better for you? Or is it a UI/display issue?
3 Likes
When a beginner editor or casual tagger comes across tens to hundreds of different “Recordings,” are they more likely to:
- Take an hour out of their day to research (for one song!) which “recordings” already in the database have the same two “Yeahs” after the bridge
- Scroll through the list of tens to hundreds of recordings for a moment, think, “Screw it,” and add… yet another new recording
- Give up entirely after one to a few rounds of going through this process
I’m gonna go with 2 → 3 -----------------------------------------------------> 1
On the other hand, with my proposal, if this beginner wants to add another edit of “Billie Jean”, they don’t have to take the time to hunt down which of the 953451023 current “Recording Groups” it should belong to (which they’re not going to do, by the way), but the addition would still be included with the rest of the “Billie Jean” entries and someone with more dedication and interest can come behind and then further tie it to whichever grouping it belongs.
For naught, because - again - the only thing Picard does with WORK IDs is insert them into a file’s metadata. There still is no relationship among “recordings” in tagging programs that utilize the database, even when tracks share the same WORK ID.
I most certainly did NOT call anyone unintelligent. I believe you have entirely missed the intent of my comment.
3 Likes
So is the idea that when I add any track named “Billie Jean” it is automatically added to the same recording group with all other recordings by that title? How would that apply in the case of, say, “Love Song”?
4 Likes
Which can only be done with an extra layer 
We actually considered this extra layer too, for what it’s worth, but ended up deciding that the current situation is still less confusing than having a double layer here (same reason as we don’t have a layer for arrangement under work). Both of those layers I’d love to have, as a schema designer, but they would make things even more messy because you can’t expect volunteer users to figure it all out.
For what it’s worth, you can already link an edit of a recording to the original recording - Picard or any other software could be made to follow those links to get an original date if desired (same for a remix, although I’d expect in that case people would want the date of the remix). Other situations (like live versions) wouldn’t be shared in your idea either, so neither option would help with those.
9 Likes
My point was, in your proposal, how do they link it to the recording/make it the same recording as the others? They still have to “hunt it down”/do a search right? (which they wont do, same as now)
So I have to assume the same as @highstrung, your are proposing to automate grouping everything based on title and maybe artist? Would be interesting seeing this attempted, and what trouble it throws up (this site is open-source after all, copy the code and go for it!)
5 Likes