[mb-style] RFC-327: Featured Artists

SwissChris swisschris at gmail.com
Mon Jul 18 18:45:37 UTC 2011


On Mon, Jul 18, 2011 at 7:02 PM, Alex Mauer <hawke at hawkesnest.net> wrote:

> On 07/18/2011 05:30 AM, Andii Hughes wrote:
> > 1. If the cover says 'X (feat. Y)' by Z, then artist credit is Z,
> > title is 'X (feat. Y)'
> > 2. If the cover says 'X' by Z feat. Y then artist credit is Z +
> > join-phrase ' feat. ' + Y and title is 'X'
> > 3. If the cover says 'X (with new singing sensation Y)' by Z, then
> > artist credit is Z, title is 'X (with new singing sensation Y)'
> > 4. If the cover says 'X' by Z with his best friend Y, then artist
> > credit is Z + join-phrase ' with his best friend ' + Y and title is
> > 'X'.
> > and so on...
> >
> > i.e. whatever is on the cover...
>
> +1 to all of this.
>

Sorry again, guys, but that's Taliban Speech. We're here in a database, and
a database does build structures to store information from various sources
in a comprehensive, usable form: artist information in artist field, track
information in track fields, Extra Title Information in appropriate Comment
or Annotation fields (wherever these may be found on the original source).
If "feat." should remain in the track title, "as on the cover" then why not
keep everything else there as well just because it happens to follow
directly after a track title?

Why should we keep what in fact is Extra *Artist *Information in the track
title, when stuff that actually is Extra *Title* Information  (like: "from
West Side Story") should be moved to some other field?

I have a disc in hand ("Ute Lemper sings Kurt Weill") where a random track
title reads  "7. NANNA'S LIED - BRECHT/WEILL - Piano: Kai Rautenberg -
BROOKHOUSE MUSIC INC." And this should all go in track title, because it's
"as on the cover"?

We have agreed (e.g. for capitalization guidelines) that you can't deduce
"artist intent" from covers, since what's on a cover is mostly "graphist's
intent". Just because for obvious redundancy and aesthetic reasons a main
artist is not generally repeated on every track, it's no longer "as on the
cover", when we add him?

As said before all collaborations (be it "feat.", "with", "en duo avec")
semantically, logically link two artists, never a track title to an artist.
So "track" (feat. artist)" on a cover is just a shortcut for "track ([by
artist] feat. artist)".

The NGS developers have done a great job on behalf of those that wanted "as
on cover" presentation of the data (ok. They still haven't solved the
problem of font size & color, but I'm sure they're working on this flaw ;-)

The NGS artist credit allows you to credit a featuring artist – in the
Artist Credits – with the exact wording you find on the cover, with the one
tiny exception that the Main Artist ("flowing down from the release level to
the track level", as Andii puts it) has to be included. And now, just
because of this, you simply reject it?

If this is the way it should be, I'd vote with Frederic to just forget about
the two level system completely, which right now makes editing much more
time-consuming and complicated.

Chris/chabreyflint


>
> Those of us (myself, for one) who want more normalized titles can have
> their tagger look at the recordings or the works instead of the tracklists.
>
> The one downside I can see to this is that the feat. artist will not
> have that release appear in their releases because they don’t have an
> artist credit on it (it will only appear in relationships).  I don’t
> know if that’s enough of a problem for it to mean we need an exception
> guideline to the “as on the cover” concept.
>


> —Alex Mauer “hawke”
>
>
> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-style/attachments/20110718/e57b75ce/attachment.htm 


More information about the MusicBrainz-style mailing list