[mb-style] RFC-327: Featured Artists

Andii Hughes gnu_andrew at member.fsf.org
Fri Jul 15 23:55:47 UTC 2011

On 16 July 2011 00:45, SwissChris <swisschris at gmail.com> wrote:
> I wouldn't disagree on the fact that "feat." has a specific meaning
> different from other link phrases. A said before I wouldn't thus oppose
> keeping it as link phrase between artists even on recording level.
> But fact is:
> 1. We agreed on adding (featured) artists on tracks (instead of artists)
> only because of the pre-NGS technical limitations. Now that these
> limitations are finally gone, we should get rid of this (wrong) guideline
> asap.

Yes, which is what this proposal is progress towards.

> 2. Many (if not most) of the so called "feat." artists we now have in MB are
> actually not "featured" artists in reality, since the guideline asked to
> always use "feat." whatever the actual link phrase on a release may be. It's
> wrong or at least inaccurate information that we shouldn't wait any longer
> to correct.

I don't see this; there are plenty of 'vs.' and '&' connected artists
instead of 'feat' and these have mostly been converted to artist

> 3. If I understood correctly ws/1 users will still get the information, it
> will only be displayed in a less elegant, less accurate way. This is IMHO
> not reason enough to double the work of the editors trying to improve the DB
> according to the NGS principles.

They'll get a huge bunch of new artists called 'X feat. Y'.  In some cases, that
will turn a discography under a single artist under to one split into
maybe 10 or 20
different artists (if a lot of their tracks have feat. artists).

I don't see how this 'double[s] the work of the editors'.  You still
have to change
existing track and recording titles separately, and even if we change
the track guidelines,
it sounds like they will be different from the strict recording
structure as people want them
closer to the cover.

> 4. The current guideline is a pre-NGS guideline, which - like so many others
> - has obviously not really been updated. What editors do in such cases is to
> ignore the parts that no longer apply because we now have a better way to
> deal with a specific problem. They have done so in the past and will
> hopefully do so again, until there's an agreement on a new guideline. If
> your proposal passes, it would be a post-NGS guideline much harder to ignore
> ;-)

You shouldn't be ignoring it.  I'll vote down or revert any such edit
I see and others should too.

> Chris/chabreyflint
> On Fri, Jul 15, 2011 at 10:00 PM, Ryan Torchia <anarchyriot at gmail.com>
> wrote:
>> On Fri, Jul 15, 2011 at 11:21 AM, lorenz pressler <lop at gmx.at> wrote:
>>> > "feat." (or whatever synonym is used) stands for a collaboration
>>> > between
>>> > artists, not between a title and an artist. (It's the artist that
>>> > *features*another artist, not the title)
>>> exactly my thoughts, on compilations where the artist is given on
>>> tracklisting, the feat. is often moved to the artist column. also i do
>>> think that even if we want to be as close to the cover as possible on
>>> release/tracklevel the data should be modified to fit into the
>>> title/artist table; otherwise, whats the point in having an artist column
>>> on tracklevel, a one-dimensional array would suffice.
>> Well, there'd still be split releases and real collaborations.
>> "Featuring" seems to me to be more akin to a cameo appearance on a sitcom:
>> yes the name attracts attention, but they didn't write the episode or create
>> the show.  They come on, say their two lines, collect a check and go -- most
>> times they don't contribute any more than a session player whose name is
>> buried in the credits.
>> (Plus there's currently a "this blows" factor with Picard -- if you set
>> one track of Some Band's album to "Some Band feat. Guest", Picard will mark
>> the album as a compilation.  This occurs after plug-ins and tagger scripts,
>> so it can't be fixed during tagging.)
>> --Torc.
>> _______________________________________________
>> MusicBrainz-style mailing list
>> MusicBrainz-style at lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> _______________________________________________
> MusicBrainz-style mailing list
> MusicBrainz-style at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Andii :-)

More information about the MusicBrainz-style mailing list