Look at these releases: Nabucco and Nabucco: Extraits. The first contains the full performance, the second contains parts, so it is natural to merge the recordings which show up on both releases (these merges are in the review queue). However, the track marks are not completely consistent. It happens that a single track (2.17) of the first release is split into two tracks of the second release (16 and 17) and several times that a single track of the second release (for example 3) is split into two tracks on the first release (1.5 and 1.6).
What is the right way to deal with this situation? From the official style guide, I got the idea that the split parts should be “edits” of the bigger recording. This is what I did. However, now I found that there is also the relation type compilation (which not covered in the linked style guide!), which might be another possibility. As this situation is not too uncommon and easy to define, I think there should be a clear instruction in the documentation what to do (maybe I just missed it).
The way to indicate the relation by the type “edit” does not feel optimal to me. While without doubt, the reduction to a part technically is an edit, it is a very special and basic one. Knowing that one recording is part of another one, it is clear that a lot of info can be transferred from one recording to the other (in particular from the smaller to the bigger one). From the musicbrainz standard to provide the best possible structured data and given the fact that this situation is not too uncommon, I wonder if it would make sense to have a dedicated recording-recording relation type “part of”.
What to do if two recordings overlap, but none is a part of the other one? I don’t have an example for this, but I’m sure that these cases will occur.
This sounds a bit like “compilation” is not considered a pure recording-recording relationship, but it depends on the existence of other recordings (to disambiguate is from an “extract”). I’m not sure if I like that idea. It could well happen that something which is an “extract” today will be a perfect “compilation” tomorrow if someone adds the missing part.
Why do we need such a concept of “compilation”? What about just renaming the “compilation” relation to “part of”, to more clearly capture its function?
I think the idea is “you can get the equivalent to this recording by getting these other ones instead”, rather than “this is just some part of this bigger recording”.
But is “compilation” directional? If the component tracks were released first and later released as a single track, that’s a compilation, but if the single track was later released as multiple tracks, is that still a compilation? The relationship between them is functionally the same, 2:1 or 1:2.
I still don’t get the idea of “compilation” as a recording-recording relationship. In my opinion, the correct database model would be a playlist on sub-track level.
Anyway, can’t we just (additionally) have a “part of” recording-recording relationship? This one would be very clear.
I don’t think it’s too clear. What is it supposed to be? “this is any arbitrary part of this track”? That is the idea for edit, as far as I can tell.
In current use, yes. In any case, I wouldn’t want to lose the current distinction of “getting all these recordings, you get the equivalent of the bigger one” vs. “this is just some fragment of the bigger one”. I don’t mind renaming the relationship to something else than compilation that keeps this distinction though.
To my understanding, an “edit” is putting the sound file into a sound editor like audacity and apply various kinds of modifications. Like distortion, doubling the speed, reversing etc.
I would like to have a dedicated relation describing the most fundamental kind of an edit, namely reducing the recording to a part (“fragment”), but leaving the material unchanged otherwise.
Let me add another thought: If a recording is “part of” (or “a fraction of” or whatever) another recording, this can be verified by acoustid fingerprints: The picture of the first recording can be found within the picture of the second recording. For a general “edit”, this is not always the case.
Maybe this might convince you that the “part of” relation is important enough for an own AR-type?
I found another release containing material from the same Nabucco performance, which increased the complexity of the relations between different recordings. I was a bit surprised, so maybe it’s interesting not only to me:
Let us denote the involved releases by release A, release B and release C.
Track A.10 is split into two parts on release B, namely tracks B.2.17 and B.2.18. track B.2.18 is the same as track C.18, but track B.2.17 is split further on release C, namely into tracks C.16 and track C.17.
Thus, I’ve added the following AR to the recordings (of type “edit of”, as there is nothing more specific):
This is the idea compilation of was supposed to fill, as I’ve mentioned earlier. Whether we change the name or not, it should still be used rather than edit of for this case as far as I can tell.
In any case, I wouldn’t add any links between C16/C17 and A10 directly - the relationship with the other recording is enough, same as we wouldn’t link a work to both its parent work and that parent’s parent wiht “part of”.
It would be helpful for Style/Recording to mention the compilation relationship, and to clearly answer the questions @spitzwegerich raises here. If the Compilation relationship is sometimes the right choice, then Style/Recording needs to explain when to use the Compilation relationship.
I recently ran into similar questions with Release A, a compilation, which has tracks that I think originate from the same recording session as Release B, a complete opera, but the track lengths differ greatly. I suspect that Release A’s team and Release B’s team made different decisions about how to divide the studio masters in to tracks. Style/Recording didn’t help me understand whether to link Release A’s tracks to Release B’s MB Recording entries, or make new Recording entries. It didn’t help me understand how to relate the MB Recordings of Release A to the MB Recordings of Release B.
I’m not feeling comfortable with the AR-type “compilation” at the moment.
First, I’m not sure about the exact meaning. Is there an official documentation?
“A is a compilation of B” could mean
“A is part of B”;
Indicated by your above answers: "A is part of B, and the remaining material of B can be partitioned into other musicbrainz-recordings.
I would prefer the first option. But then, the name “compilation” is a bit unfortunate and should be changed IMO.
If it really is the second option, I don’t like it as it would be a recording-recording relationship which depends on information “external” to the two involved recordings (which additionally might change over the time). In this case, I prefer “edit of” where the meaning is clear (albeit a bit vague).
Agreed, I will remove those two AR.
Remark: Mathematically speaking, we assume the relation “edit of” being transitive: If x is an edit of y and y is an edit of z, then for sure x is an edit of z, too. In this case, we don’t have to add the latter AR explicitely, as it follows from the other two.
All we have right now is here. All that says is “one long recording that contains multiple songs, one after the other, in which the audio material of the original recordings has not been altered”, which would apply to this, but indeed the “compilation” name is a bit meh in this case. A relatively common current use of this is to add separate recordings for hidden tracks and the like, as shown in the example. For that, “part” would seem to work fine too. On the other hand, for an actual case of compilation (where someone actually put a bunch of tracks together one after another in one long track) “part of” sounds a bit weird, semantically, so there might still be a point in having two similar-but-not-quite relationships…
I think the realization of a compilation as a recording-recording-AR is logically flawed. The first sentence of the documentation (thanks for the pointer!) reads “This indicates that a recording is a compilation of several other recordings.”
For a sound database model, I suggest the following:
Introduce a “part of”-AR and mark the parts as “part of” the bigger recording.
Compilation is then an (ordered) series of “part of”-relations (where the right recording must be always the same).