[mb-style] Composition/Performer/Production ARs at Release or Track level? - PROPOSAL

[Brian Schweitzer]

>> well, i totally disagree! if i was to go through my record collection
>> now i would conservatively predict that over half would have
>> non-specific release wide credits. we're just going to ignore these?
>> it's of vast discographical importance, surely?

>Don't put in an AR if you cannot confirm the information does not
>equal "ignore it".  If I don't know something, I put it in the

But Lauri, noone is arguing this.

> "applies to some tracks, but not enough data to identify which particular
tracks"
this is not the same thing as "data I cannot confirm".

"Fuzzy" !=
>'put it on release level if we're not sure'.
"Fuzzy" = 'put it on release level if we're not sure' which particular
tracks the data applies to.  There's a huge difference.

> I don't enter assumptions, without evidence.  Take the Delerium albums

You keep leaving out the last part of the phrase.  Noone except you has even
suggested this is what we're talking about.  I even specified in my last
email what "fuzzy" does mean:

> Thus: ARs at the release level can be "fuzzy" - if you know someone
> played alto sax on some track, but you don't know which track(s), then it
> can be added at the release level for someone later (who has better info)
to
> move to the proper track(s).

I took it as given, based on the discussion so far and in IRC, but perhaps I
ought to have further specified: "know" means you have some solid source - a
band member, a liner, etc - not "know" as in "well, I guess..."

In the example you give of the drum player's data, that would be the type of
data that would then allow you to take  a fuzzy release-level AR and move to
to the correct tracks.  I seriously doubt, however, that many, if any, of
the CD/LP liners provided anything close to such a level of detail.  Most
likely, the liners said "Drums: foo" about the entire release.  That's what
we're talking about - where the data is in the liner, but isn't good enough
to be able to specify which tracks in particular it applies to.  We're very
much not, however, talking about "Well, I'm gonna guess that foo played
drums on this, so I'll toss in a release-level AR for foo playing the
drums".

By the way, I do have some releases which, for instrumental recording (and
vocal recording) list not only who recorded which tracks, but for some, even
where, on which day for each track, and in at least 2 cases, where on what
date for each sample in each track.

Anyone can set up all the straw horses they want to. For almost every AR in
the list, we can identify if it is one that applies only to releases, or one
that applies to tracks as well.  This isn't about that, however.  As I said,
I also followed the "a release-level AR must only be one which applies to
every track".  However, the main problem with continuing with viewpoint #1
and adhering to this definition is that over half the editors don't use it.
So we end up with two mutually exclusive approaches to such ARs.  Someone
adds an AR to the release because it applies to some tracks on the release,
but they cannot say which.  Someone else doesn't have good enough info to
specify which tracks the AR belongs to, but does know it doesn't apply to at
least one track - so the 2nd editor edits to remove the AR.  Sum total?  We
have less data than we could have.  Knowing John Foo sang on a release tells
us something.  Would we rather know which tracks John sang on?  Sure - but
that level of specificity may be more specific than the editor has access
to.  On the flip side, for those following viewpoint #1, given that there's
still half the editor-base using viewpoint #2, the editor has no greater
certainty for using the data.

With half of us using one defintion, and the other half using the other, we
end up in a situation where half the editors are trying to remove ARs from
the other half, and noone quite knows how specifically to interpret any
given release-level AR (Does it mean it applies to all tracks?  Does it mean
it applies to at least one track?  Who knows?)

Would I rather see viewpoint #1 in place?  Sure - at least so long as it
takes to get all the data moved to tracks.  But realistically, there's
already a large number of "fuzzy" release-level ARs.  If we now migrate all
those ARs down to the tracks in an automated fashion, we end up with all
those fuzzy ARs attached to tracks where they are 100% incorrect.  So,
instead I'm suggesting we lock track-level ARs as only non-fuzzy (as there
is nothing smaller than a track, so no fuzzyness is even possible), but make
release-level ARs fuzzy *and* non-inherited.  This at least clarifies what
release level ARs do and do not mean, as well as providing guideance for
100% of editors who are asking "John is on the release doing blah, but he
doesn't do it on all tracks - and I cannot say which tracks specifically.
Do I add the release AR?  Do I vote yes or no to the edit which is adding
the AR?"  Right now, how those questions are being answered depends on who
edits/see the edit - and in no way can we say that even close to 100% of all
release-level ARs apply to all tracks.  We can, however, say that 99.9% of
all release-level ARs apply to either the release or some track on the
release.  So let's at least accept what we can say with certainty and make
it policy, instead of trying to pretend it's not already the case.  Hence
why, though I prefer #1, I'm willing to accept the compromise I proposed.
:)

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20080102/5132059d/attachment-0001.htm