If I had two tapes in my hand - one with the Boney M Single and one with the Boney M Album are they not different recordings? And why should MusicBrainz not say these are different when they clearly are?
This is not about a tidy database, this is about documenting variations.
The broken thing at the moment is the trouble with linking dates. IMHO we need an extra field to handle that for hand entering dates. A way of linking those various versions back to the original recording. I don’t want to see the database mushed and details just to get some dates into some tags.
If I use Audacity to record myself saying, “Yeah,” into a microphone five times, upload it to YouTube and later go back, remove the last “Yeah” and re-upload to YouTube… what on Earth makes the second a “different recording?” As stated, MusicBrainz’s definition of “Recording” is mind-bendingly unconventional. One ends up looking like a pretzel after twisting and molding themselves to believe an original seven minute “extended mix” cut to three minutes and faded for radio is a “different recording”, entirely separate from the original.
The variations are already documented at the release-level… as stated already. A tidy database makes for less confusion, better interpretation and efficient use of the data. A haphazard splooge of disorientation, emphasizing convoluted answers to non-issues, necessitates employing more tangled solutions in the future (like adding another date-linking relationship on top of the plenty that already exist) rather than adhering to the time-tested philosophy of KISS.
The “Recording” section links dates. That’s not broken.
“Extra” here also meaning extra convolution and extra confusion.
More is not always better.
Especially when the functionality currently exists and is simply limited by a torturous definition.
They are not. The fact that a recording appears on a single does not in any way state that it is different than the album version. It can be different, it can be the same.
Yes, but the mixing is an important step in it. Most studio recordings are not even done by everyone playing together when someone is recording it. Instead the individual instruments and voices are often recorded separately (in time and place), and the final result is created by the mix.
Your simplistic view if seeing everything as the same recording only works if you don’t care about what version you are listening to. But many do, I definitely do. And I want software like Picard to be able to identify the proper version, something your suggestion if merging everything together would break. You can’t just apply different AcoustID of completely different versions to the same recording and treat them like they are identical.
There are many cases where I strongly believe the difference matters. The above example of Bony M’s single with different singing parts is one of them.
Also many singles have multiple mixes of the same song, it would be strange if we say they are all the same.
Or the release https://musicbrainz.org/release/51d5a087-0842-44a3-b657-1ac502ac723f is a new mix of the original recorded material, one that is significantly different to the original. It matters a lot to me which one I listen to, and I definitely want a software like Picard to distinguish them.
Remastering already is no reason for a separate recording, so this concern is a non-issue.
That is not what the Boney M example is. I agree that your example is the same recording and would be merged under MB guidelines. Your example comes under the “early fade” type rule. Play them both back at the same time in Audacity and you will not hear any different.
Whereas the Boney M example has two different sets of vocals on the Single and Album. Play them at the same time in Audacity and there is a clear difference.
Audacity is an ideal tool for spotting the differences in two recordings.
Like @outsidecontext , I want to have a choice as to which version of the Boney M recording I listen to.
They are. By definition, two different releases are inherently distinguished as different.
Applying your point of view to Release Groups means each distinguishable release should receive its own Release Group.
Releases can be same… they can also be different! MusicBrainz considers “different” releases as part of a whole, but “different” mixes of the same recording need to pollute the database because of adherence to an unconventional, confusing interpretation of a common term.
Best Artist Ever - My Great Love Song (2001 album mix)
Best Artist Ever - My Great Love Song (extended mix)
Best Artist Ever - My Great Love Song (ad-libs removed from between two verses mix)
Best Artist Ever - My Great Love Song (extended mix with fade out)
Best Artist Ever - My Great Love Song (2000 radio mix)
Best Artist Ever - My Great Love Song (mix with extra compression to the chorus applied)
Best Artist Ever - My Great Love Song (Estonia radio mix with ad-libs remove from after two verses mix)
Best Artist Ever - My Great Love Song (single mix with fade out)
Best Artist Ever - My Great Love Song (2002 Bhutan radio mix with fade in)
Best Artist Ever - My Great Love Song (two "Yeahs" cut mix)
Best Artist Ever - My Great Love Song (2013 remaster)
Best Artist Ever - My Great Love Song (2012 remaster single mix)
Best Artist Ever - My Great Love Song (remaster extended mix with fade in)
Best Artist Ever - My Great Love Song (remaster box set radio mix with three additional "Yeahs" mix)
Ordinarily, ninety-nine percent of the English speaking population is going to understand these are all variations of the same “recording”. But the one percent would rather stick with the current re-invented and confusingly implemented wheel and think each of these a distinct (somehow) “recording.” But, even they don’t apply this same rationale to Release Groups.
As someone who has recorded and mixed a number of artists on classic analog and digital consoles in professional recording studios, I am aware. I remember one artist later had one of her tracks re-mixed by another engineer for comparison and she wouldn’t have considered his mix versus mine as separate “recordings,” that if entered into a database would be entirely split from the other. You implicitly acknowledge this difference with your use of “mix” to distinguish from “recording.”
And your convoluted view now has to create mishmashed, contrived labyrinthine methods in order to link different variations of the same recording. As opposed to my KISS method, which would properly link all the different variations and use the already-existing disambiguation field to inform sticklers that “this single mix (which exists as a separate release already) removed two ‘Yeahs’ after the bridge.” Easy peasy - and without waiting half a decade on a ticket to clear or additional hits to server to go along with the numerous other square peg → circular hole queries that have built up over the years.
Luckily, the disambiguation field is already being used to annotate the differences and variations between mixes!
When I add “I Am Nothing” to Picard, there’s no way to trace the history and evolution of the song back to its original release. In the database, I have to click through a bunch of dopey-worded fields to get to the historical beginning. EDIT: Even more amusing is that your example amplifies my earlier argument regarding Release Groups. It is nonsensical MB acknowledges the relationship between the 2001 original “Believe in Nothing” release and the disambiguated 2018 re-mixed and remastered release, then throws away this logic with regards to Recordings.
The current and your way of thinking says, “The origin of this re-mixed recording is 2018. It has no relevance beyond that year. It has zero relation to any release that came before it.” My way of thinking easily accommodates the ability to trace the “2018 remix” back to its origins in 2001.
I’m glad someone bit on this - since remasters can be just as “different” as re-mixes and this furthers my point that the current definition of “Recording” is chaotic and arbitrary.
The difference being so significant it necessitates the incorporation of yet another date field to the database, which the server must then account for… rather than simply utilizing the existing Disambiguation field which, amazingly enough, is already being used for the exact purpose of your concern? Not only that, your choice can already be recorded in Picard using the %_recording_comment% (or whatever it is) tag! KISS
Fixed that for you. That’s why there is a Remix relationship. They are now linked.
Not much point in replying to other parts of your post as you are just trolling now whilst ignoring the actual way MB handles recordings. Your bizarre list of My Great Love Song recordings would only be less than half the length as fade outs, remasters, compression, etc are not treated as separate recordings.
AKA You just want things done your way and can’t provide a logical response when the absurdity of your method is revealed.
Nothing has changed.
The track is still treated as completely distinct and separated from its original version in Picard.
And people conventionally think of a “remix” as a song that DJ Tiesto or whomever gets a hold of and turns into a dance version.
Confusion. Convolution. Chaos.
Your solution is to then add an untold number of fields ( which would take years to implement) to rectify what you’ve acknowledged as problem, just to accomplish something already well within the capacity of both the MusicBrainz database and its tagging program with the simple adjustment of a silly definition.
That’s obviously not at all what I said. This discussion is not about releases but recordings. And of course the album and single can contain exactly the same recording of a song, or it can be different. You implied that the fact that a recording appears on a single is enough to say that it is different from the album release, and that’s not true.
But they would both have different credits, one mixed by you and the other mixed by the other engineer. Where would you pu that?
The disambiguation is not enough to technically distinguish the two mixes properly. I am not even sure which existing disambiguation you would use for this, because the one of the recording would not be useful if all different mixes get merged into a single recording.
But let’s assume we have a field for that on e.g. track level: Neither would there a place to put separate credits, nor a place to put separate AcoustID. Also the information that two releases contain the same mix would be lost. The separate mixes become technically indistinguishable. You can no longer answer the question which releases contain the same mix, nor can you use AcoustID to identify your mix cleanly.
What you are proposing is treating the recording and mix separately. But if you follow this approach through and want to implement it without loosing information and thus functionality you would need to add the “mix” as an actual entity that sits between an recording and the release.Then the AcoustIDs could be assigned to mixes, as could the mixer credits.
Instead of simplifying the schema that would even make it more complicated, and we would have the same discussion about “Allmost all Mixes are for merging”.
Your analogy is wrong. MB acknowledges that the 2001 and 2018 release are versions of the same album, but it also makes it clear they are different. Likewise it acknowledges that the individual recordings are recordings of the same works, but it also acknowledges that they are different. The remix is even linked to the original. If we would follow your logic of merging two recordings that have an audible difference because they share a history and apply the same logic to releases, we should merge the 2018 and 2001 release.
If that hasn’t been clear already: That “simple adjustment of a silly definition” would maybe fix your original date issue, but it would seriously break audio identification in Picard.
I think your core issue is that you want to get the original recording date independent of the mix. If that’s the use case we should find a solution for this, instead of breaking things by removing any distinctions between variations of a recording.
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.
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.
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.
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?
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.
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.
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.
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?
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.”
