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.
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:
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.
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?
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.
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”?
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.
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!)
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.