[mb-style] Recording/track distinctions

Andii Hughes gnu_andrew at member.fsf.org
Thu Jul 21 22:45:23 UTC 2011


On 21 July 2011 17:56, Kuno Woudt <kuno at frob.nl> wrote:
> Hello,
>
> I think I've given my view on this topic in earlier threads,
> but just in case anyone is interested I'll try to articulate it again :)
>

Likewise :-)

> In general I do not object to all the normalizing we tend to do, so
> would support proposals which re-introduce our existing guidelines
> for track and release titles.
>
>
> However, our guidelines are very focused on the english language market
> in my opinion, and I would like to see the guidelines be made a bit more
> general -- or just make it clear they don't apply to releases which
> are not intended for english speaking markets.
>
> I do not think it is enough to add exceptions for other markets later
> on, that would mean a new editor working on releases intended for a
> market no-one else is working on yet is burdened by english focused
> guidelines which are not appropriate for the stuff they're working on.
>

Well, yes that's something to work on but I don't see exactly how it relates
to track/recording title separation.  You also don't mention the big downside
of track/recording separation which is that it's pretty much doubled the work
of everybody in terms of correcting releases which don't meet the guidelines.

>
> The second issue with regard to the guidelines is that we really do have
> a lot of them, it is not easy for a new editor to just start editing.
>
> I have tried to make this a bit more accessible by collecting all of
> them as subpages of http://wiki.musicbrainz.org/Style and listing them
> on that page --- so atleast it should be clear that those are ALL the
> official guidelines, if you're familiar with those you know everything
> you need to know when editing.  But it's still a daunting amount of
> material.
>

In my experience, new editors aren't so much overwhelmed by guidelines
as they don't see them at all and just fill the database with rubbish that
someone else then has to correct.  Perhaps the guidelines should be
more prominently linked in the editing dialogs?

There are a lot of guidelines, but most can be selectively ignored if they
don't apply e.g. if your release has no feat. artist, you can ignore that
guideline for that release.  People tend to learn them on an as-needed basis
and on correction from editors.  At least, that's what I did and I
think the voting
system works well at doing this.  They are, after all, *guidelines*
not strict rules,
and exceptional cases are best dealt with through the voting system.

Do you have some concrete evidence that new editors really suffer from
over-abundance of guidelines?

I do think the new structuring helps, so thanks for that.

>
> As-on-cover track and release fields to some extent solves both issues,
> it makes it much easier for editors to get started.
>

Depends what you mean by this.  My experience so far is that newbie editors
have tended to ignore the guidelines and enter whatever is on the
cover, both before
and after NGS.  So I'm not sure how that has changed.

The featured artist example is a good one, because both before and after NGS
we get artists added called "X feat. Y".  I don't think, even
following the cover, we
want such an artist but the feat. moved to the title (pre-NGS) or the
feat. entered into
an artist credit (post-NGS).  So neither practice that we would want
in the DB is
the 'obvious' case and I don't think doing the obvious is best for
making a consistent
database.

The same goes for mis-spellings and capitalisation.  This now has to
be handled at
two-levels and it's even more difficult if the track listing differs,
because then the
recording has to be altered separately.  For a 20-track release, that
means loading up
and editing 20 recordings separately.  As such, I've tended to keep
with our old guidelines on capitalisation so that tracks need only be
entered once.

Also, 'on the cover' becomes difficult when the cover is unavailable
and the source is some online website; this is true in many cases, and
especially with digital media which has no cover.  Does 'on the cover'
then mean 'whatever rubbish Amazon have in their listing'?  Because
that's what gets entered initially.

>
> If we start applying the old guidelines on tracks and releases again
> I do think we have to also work on solving these issues.  Reducing and
> simplifying our current guidelines to make them more accessible to new
> users is probably the biggest challenge here.

I don't recall there being a consensus on ignoring them to start with;
if there was,
perhaps you can point me to it?  For me, I'd assumed the existing ones
would still
apply and I imagine many others did too.

>
>
> -- kuno / warp.
>
> _______________________________________________
> 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
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-July/012796.html
lists.musicbrainz.org
crawl=CC-MAIN-2014-52
8332
application/http; msgtype=response
sha1:36N4OYVTSMV6VL3XUAMKSPVFYBY2VGTG
<urn:uuid:7718a108-61ad-4f46-8e88-f1152c519930>
2014-12-22T17:43:09Z
72.29.166.156
sha1:IIKQMWSFLO5SO2JJQO2S4FR4MJQ3WPDT
<urn:uuid:54c9f6b7-8df4-4514-9cb7-0cf57184a8fd>
http://lists.musicbrainz.org/pipermail/musicbrainz-style/2011-July/012796.html
response
<urn:uuid:6177051f-eae0-40c5-93be-a85b2c7ca3f7>
robots: classic
hostname: ip-10-231-17-201.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2014-52
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for December 2014
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf