Re: [mb-style] Slow down.

[Aaron Cooper]

On Tue, Mar 9, 2010 at 8:29 PM, Mika Heiska  wrote:
> On 9.3.2010 14:58, Chad Wilson wrote:
>> I'm at the point where I feel like making random objections to things
>> without a proper argument just to slow things down. That's a ridiculous
>> situation...
>>
>> Chad / voiceinsideyou
>>
>
> +1
>
> I've totally just zoned out of all things mb-style right now, it's just
> too much to keep track of.

Same here.  I am probably going to unsubscribe just to avoid the inbox flood :P

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFV: PartNumberStyle (second attempt)

[Aaron Cooper]

The way I see it is "Parts {1} and {3 to 5}".  I see two items being
listed, not three or four.  If I were to speak this title, I wouldn't
say "Parts 1 3 to 5" I would say "Parts 1 and 3-to-5".

-cooperaa

On Mon, Jul 20, 2009 at 2:33 AM, Brian
Schweitzer wrote:
> Re #1, yes, that makes sense.  Regarding #2, that doesn't flow as logically
> for me - you're still dealing with 3+ items, not 2; doing "one & three –
> five" seems to treat "three – five" as a singular item, not as the 2+ plural
> items it is describing.  Try changing it to arabic for readability a moment
> - does "Parts 1 & 3 – 5" really parse, to you, in a manner that is
> consistent?  It's using an ampersand between the first two elements of a 3
> element list, which, to my knowledge, is never grammatically correct, in any
> language.
>
> Brian
>
> On Sat, Jul 18, 2009 at 8:37 PM, Aaron Cooper  wrote:
>>
>> A couple quick questions:
>>
>> 1. Why "TrackTitle, Parts 1, 3 & 5" and "TrackTitle, Parts 1–3, & 5"?
>> To be consistent, shouldn't we do "TrackTitle, Parts 1, 3, & 5" and
>> "TrackTitle, Parts 1–3, & 5"?
>>
>> 2. Why "TrackTitle, Parts One, Three – Five" instead of "TrackTitle,
>> Parts One & Three – Five"?
>>
>> -cooperaa
>>
>>
>> On Fri, Jul 17, 2009 at 6:51 PM, Brian
>> Schweitzer wrote:
>> > http://wiki.musicbrainz.org/Part_Number_Style
>> >
>> > On Fri, Jul 17, 2009 at 3:31 AM, Kuno Woudt  wrote:
>> >>
>> >> On Fri, Jul 17, 2009 at 01:41:45AM -0400, Brian Schweitzer wrote:
>> >> > If you recall, I'd agreed to drop PartNumberStyle back to RFC status
>> >> > due
>> >> > to
>> >> > debate on the RFV, but had delayed any further action while a few of
>> >> > us
>> >> > involved in the discussion were dealing with vacations and other
>> >> > offline
>> >> > issues.  Now that enough time has passed, I think, for us all to be
>> >> > back,
>> >> > I'd like to bring this RFV back to the table.  As the original RFC
>> >> > was
>> >> > kept
>> >> > open, I don't think I need to re-RFC.  To be fair, however, I will
>> >> > give
>> >> > a 7
>> >> > day expiration on the RFV, rather than simply the normal 48 hours.
>> >> >  So,
>> >> > if
>> >> > it should happen that there are no continued objections, this one
>> >> > would
>> >> > pass
>> >> > on Friday, early AM (EST), July 24.
>> >>
>> >> Waah, way too much text for an RFV :)  Please include a link to a wiki
>> >> page with the proposed changes, so I can just agree/disagree based on
>> >> the
>> >> the actual proposal and only look into the previous discussion if I
>> >> disagree.
>> >>
>> >> -- kuno / warp.
>> >>
>> >>
>> >> ___
>> >> Musicbrainz-style mailing list
>> >> Musicbrainz-style@lists.musicbrainz.org
>> >> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>> >
>> >
>> > ___
>> > Musicbrainz-style mailing list
>> > Musicbrainz-style@lists.musicbrainz.org
>> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>> >
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFV: PartNumberStyle (second attempt)

[Aaron Cooper]

A couple quick questions:

1. Why "TrackTitle, Parts 1, 3 & 5" and "TrackTitle, Parts 1–3, & 5"?
To be consistent, shouldn't we do "TrackTitle, Parts 1, 3, & 5" and
"TrackTitle, Parts 1–3, & 5"?

2. Why "TrackTitle, Parts One, Three – Five" instead of "TrackTitle,
Parts One & Three – Five"?

-cooperaa


On Fri, Jul 17, 2009 at 6:51 PM, Brian
Schweitzer wrote:
> http://wiki.musicbrainz.org/Part_Number_Style
>
> On Fri, Jul 17, 2009 at 3:31 AM, Kuno Woudt  wrote:
>>
>> On Fri, Jul 17, 2009 at 01:41:45AM -0400, Brian Schweitzer wrote:
>> > If you recall, I'd agreed to drop PartNumberStyle back to RFC status due
>> > to
>> > debate on the RFV, but had delayed any further action while a few of us
>> > involved in the discussion were dealing with vacations and other offline
>> > issues.  Now that enough time has passed, I think, for us all to be
>> > back,
>> > I'd like to bring this RFV back to the table.  As the original RFC was
>> > kept
>> > open, I don't think I need to re-RFC.  To be fair, however, I will give
>> > a 7
>> > day expiration on the RFV, rather than simply the normal 48 hours.  So,
>> > if
>> > it should happen that there are no continued objections, this one would
>> > pass
>> > on Friday, early AM (EST), July 24.
>>
>> Waah, way too much text for an RFV :)  Please include a link to a wiki
>> page with the proposed changes, so I can just agree/disagree based on the
>> the actual proposal and only look into the previous discussion if I
>> disagree.
>>
>> -- kuno / warp.
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Release Groups style / bootlegs

[Aaron Cooper]

I think it is very useful.  For example, there are some older
Metallica bootlegs that have 15+ different issues on vinyl, CD, etc.
Here are some good examples that I've worked on at RYM:

http://rateyourmusic.com/release/unauth/metallica/san_francisco_march_14th_1985/
http://rateyourmusic.com/release/unauth/metallica/austin__texas__2_03_89/
http://rateyourmusic.com/release/unauth/metallica/live_in_argentina/
http://rateyourmusic.com/release/unauth/metallica/1984_12_20__lyceum_ballroom__london__uk/
http://rateyourmusic.com/release/unauth/metallica/1989_05_13__yoyogi_olympic_pool__tokyo__japan__fade_to_black_/

-cooperaa


On Mon, May 25, 2009 at 9:56 AM, Pavan Chander  wrote:
> That sounds like you're suggesting that all the live bootlegs of a concert
> should be merged together; not just when there is an official release, but
> always. At first I was against that idea, but I'm warming to it, maybe there
> is a case for merging all the various releases of the same concert.
> After all, there are some similarities between a concert and an album from a
> "single logical entity" point of view
> (http://wiki.musicbrainz.org/Release_Group#Definition).
> Pavan Chander // navap
>
>
> On Mon, May 25, 2009 at 9:39 AM, Aaron Cooper  wrote:
>>
>> I like the idea of grouping multiple versions of the same concert.
>> Let's you see what other versions are available - some contain bonus
>> tracks, some are abridged, others have multiple discs, etc.
>>
>> -cooperaa
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Release Groups (and associated style)

[Aaron Cooper]

IMDB gets away with this just fine.  It isn't hard to remember that
"Il buono, il brutto, il cattivo" = "The Good, the Bad, and the Ugly".
 Personally, I think it is more correct to use the original language
and I'm sure most people would agree.

-cooperaa

On Mon, May 25, 2009 at 8:52 AM, Mika Heiska  wrote:
> This is what I hope for, or something close to it. Not just for official
> translations, but for pseudos as well. I'm all for having original
> language as a default, but there is something to be said about usability
> of the site, and quite frankly, browsing the release listings of some
> foreign artists in a language you don't know or understand is just bad.
>
> ~Mika
>
> Brian Schweitzer wrote:
>> Well, for a more 'familiar' case, where multiple official translated
>> releases are frequent, try the soundtrack world.  Morricone, especially,
>> has many official releases where, over the decades, official releases
>> have occurred in English, French, German, Italian, etc.  Or, as another,
>> classical, where you have the same releases with various releases using
>> various languages.  It really seems like there should be an ability for
>> multiple titles (release and track) of a RG to share "official" status,
>> with an attached language and script.  Use then, say, the user's site
>> language selection to determine which to show; the same for data
>> accessed through the webservice.
>>
>> Brian
>>
>> On Sun, May 24, 2009 at 11:00 PM, Aaron Cooper > <mailto:coope...@gmail.com>> wrote:
>>
>>     That sounds correct.  Of course you would expect the Beatles albums to
>>     be filed under an English release group.  I don't know Shakira well
>>     enough to say, but I would assume English since the majority of her
>>     other albums are also English (just a guess).
>>
>>     -Aaron
>>
>>     On Sun, May 24, 2009 at 9:33 PM, Chad Wilson >     <mailto:chad.wil...@gmx.net>> wrote:
>>      > Yeah, it's certainly worth discussing this. You'll note that the
>>     page as
>>      > it currently stands says to merge transliterations/translations,
>>     but not
>>      > alternate-language releases. Maybe this is confusing. I fear
>>     there may
>>      > be many variations I'm not aware of as well.
>>      >
>>      > The main issue I could thinking of if merging "alternate language"
>>      > releases, would be choosing a title for the release group. Which
>>     title
>>      > would be most appropriate?
>>      >
>>      > With a transliteration/translation, it seems more clearcut -
>>     choose the
>>      > official release. If two of the "transliterations" are actually
>>     official
>>      > (i.e. some JP releases also get released in the West with "official"
>>      > transl[iter]ations on the covers, even though the audio is the same),
>>      > choose the more native-language name for the release group.
>>      >
>>      > If you were to merge Shakira's "Servicio de Lavenderia" with "Laundry
>>      > Service", which title would you choose?
>>      >
>>      > I'm actually tending towards merging this particular example too,
>>     now;
>>      > and giving a general direction to "Choose the language and
>>     release title
>>      > for which the artist is most well known/popular."
>>      >
>>      > What do you think?
>>      >
>>      > Aaron Cooper wrote:
>>      >> One quick comment.
>>      >>
>>      >> Guideline says, "If there are two versions of a release in different
>>      >> languages; each language would be its own release group."  What
>>     about
>>      >> for Translations/Transliterations?  It appears these were
>>      >> automatically merged into the same release groups on test (I'm
>>      >> thinking of the Complete Beethoven Edition, Volume 1 and 2).  Why
>>      >> aren't we merging albums just because of the language
>>     difference?  As
>>      >> far as I've seen, RateYourMusic.com groups albums even if the titles
>>      >> are in different languages (some Beatles albums come to mind).
>>      >>
>>      >> -cooperaa
>>      >>
>>      >>
>>      >>
>>      >
>>      > ___
>

Re: [mb-style] Pre-RFC: Release Groups style / bootlegs

[Aaron Cooper]

I like the idea of grouping multiple versions of the same concert.
Let's you see what other versions are available - some contain bonus
tracks, some are abridged, others have multiple discs, etc.

-cooperaa



On Mon, May 25, 2009 at 9:22 AM, Pavan Chander  wrote:
>
> I think the two rules are talking about two separate scenarios, but maybe
> the text should be amended to further clarify that.
> "Different bootleg recordings of a live show, *that don't have an official
> release*, e.g. [...]".
> Would this wording help, what would you suggest?
>
> Pavan Chander // navap
>
>
> On Mon, May 25, 2009 at 9:11 AM, Bogdan Butnaru  wrote:
>>
>> Hi!
>>
>> From the page:
>> “There are a number of cases where it is not appropriate for releases
>> to be part of the same group: [...] Different bootleg recordings of a
>> live show”
>> “Promotional and bootleg versions of albums, singles etc should be in
>> the same release group as the regular official release.”
>>
>> There seems to be a contradiction in the spirit of these two rules.
>> There's also a logical contradiction if, for example, there is an
>> official live recording as well as bootleg recordings of the same
>> show. (The second rule would suggest grouping them, the first keeping
>> them apart.)
>>
>> My instinct would be to keep bootlegs of the same show together, I'm
>> not sure what the rationale was for suggesting they be kept apart.
>>
>> -- Bogdan Butnaru
>>
>>
>>
>> On Sun, May 24, 2009 at 6:26 PM, Chad Wilson  wrote:
>> > Hi all
>> >
>> > As you most know, very soon Release Groups will be live. Style is
>> > obviously a work in progress as we're not sure how it's all going to
>> > work out across the variations in the real world but the basic cases are
>> > reasonably well known. Pronik, prodoc, gioele, navap, ruaok and I have
>> > put together a starting point which I think we need some wider comment
>> > and discussion on now.
>> >
>> > Comments/feedback/argument?
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Re-release with bonus disc and Release groups

[Aaron Cooper]

I think I agree with you.

This whole release grouping is easier for other sites (like
RateYourMusic and Discogs) because they only or primarily only link
one release event with one release.

If multiple discs were displayed on a single release's page, then we
would probably group all releases together.

i.e., ReleaseA = Disc 1, 2, 3;  ReleaseB = Disc 1, 2, 3 + bonus disc;
The release group contains both releases.

-cooperaa


On Mon, May 25, 2009 at 5:32 AM, Gioele  wrote:
> Hello,
>
> what should the release group guideline be for re-releases with bonus discs?
>
> Release "Foo Bar" has been released in 2007. In 2008 it is re-released in 2-
> cd limited edition with another complete album "When I was younger" as
> additional bonus disc.
>
> Pre-release groups we would have
>
> "Foo Bar" = release
> "Foo Bar (bonus disc: When I was younger)" = release
>
> "Foo Bar" -> "Foo Bar" = next disc AR + bonus disc
>
> Now, which of these three scenarios should we have?
>
> Scenario 1: everything in one release group
>
> The same releases are merged into a single release group with the next disc
> AR intact.
>
> Scenario 2: two release group
>
> One release group with "Foo Bar", another release group with a duplicated
> "Foo Bar" and the bonus disc. The AR relates the duplicated "Foo Bar" with
> the bonus disc
>
> Scenario 3: dupes in one release group
>
> One release group with
> * "Foo Bar" (without AR)
> * "Foo Bar" (duplicated + re-release AR + next disc AR with the bonus disc)
> * bonus disc
>
> Which one do you prefer?
>
> I prefer the third scenario, I think it maps NGS more nicely than the other
> two.
>
> --
> Gioele 
>
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Release Groups (and associated style)

[Aaron Cooper]

We're talking about the same music though. It personally doesn't  
matter to me which group name they're filed under but I would expect  
the movies original language (Spanish for "good bad n ugly"?)




On 24-May-09, at 11:55 PM, Brian Schweitzer > wrote:


Well, for a more 'familiar' case, where multiple official translated  
releases are frequent, try the soundtrack world.  Morricone,  
especially, has many official releases where, over the decades,  
official releases have occurred in English, French, German, Italian,  
etc.  Or, as another, classical, where you have the same releases  
with various releases using various languages.  It really seems like  
there should be an ability for multiple titles (release and track)  
of a RG to share "official" status, with an attached language and  
script.  Use then, say, the user's site language selection to  
determine which to show; the same for data accessed through the  
webservice.


Brian

On Sun, May 24, 2009 at 11:00 PM, Aaron Cooper   
wrote:

That sounds correct.  Of course you would expect the Beatles albums to
be filed under an English release group.  I don't know Shakira well
enough to say, but I would assume English since the majority of her
other albums are also English (just a guess).

-Aaron

On Sun, May 24, 2009 at 9:33 PM, Chad Wilson   
wrote:
> Yeah, it's certainly worth discussing this. You'll note that the  
page as
> it currently stands says to merge transliterations/translations,  
but not
> alternate-language releases. Maybe this is confusing. I fear there  
may

> be many variations I'm not aware of as well.
>
> The main issue I could thinking of if merging "alternate language"
> releases, would be choosing a title for the release group. Which  
title

> would be most appropriate?
>
> With a transliteration/translation, it seems more clearcut -  
choose the
> official release. If two of the "transliterations" are actually  
official

> (i.e. some JP releases also get released in the West with "official"
> transl[iter]ations on the covers, even though the audio is the  
same),

> choose the more native-language name for the release group.
>
> If you were to merge Shakira's "Servicio de Lavenderia" with  
"Laundry

> Service", which title would you choose?
>
> I'm actually tending towards merging this particular example too,  
now;
> and giving a general direction to "Choose the language and release  
title

> for which the artist is most well known/popular."
>
> What do you think?
>
> Aaron Cooper wrote:
>> One quick comment.
>>
>> Guideline says, "If there are two versions of a release in  
different
>> languages; each language would be its own release group."  What  
about

>> for Translations/Transliterations?  It appears these were
>> automatically merged into the same release groups on test (I'm
>> thinking of the Complete Beethoven Edition, Volume 1 and 2).  Why
>> aren't we merging albums just because of the language  
difference?  As
>> far as I've seen, RateYourMusic.com groups albums even if the  
titles

>> are in different languages (some Beatles albums come to mind).
>>
>> -cooperaa
>>
>>
>>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Release Groups (and associated style)

[Aaron Cooper]

That sounds correct.  Of course you would expect the Beatles albums to
be filed under an English release group.  I don't know Shakira well
enough to say, but I would assume English since the majority of her
other albums are also English (just a guess).

-Aaron

On Sun, May 24, 2009 at 9:33 PM, Chad Wilson  wrote:
> Yeah, it's certainly worth discussing this. You'll note that the page as
> it currently stands says to merge transliterations/translations, but not
> alternate-language releases. Maybe this is confusing. I fear there may
> be many variations I'm not aware of as well.
>
> The main issue I could thinking of if merging "alternate language"
> releases, would be choosing a title for the release group. Which title
> would be most appropriate?
>
> With a transliteration/translation, it seems more clearcut - choose the
> official release. If two of the "transliterations" are actually official
> (i.e. some JP releases also get released in the West with "official"
> transl[iter]ations on the covers, even though the audio is the same),
> choose the more native-language name for the release group.
>
> If you were to merge Shakira's "Servicio de Lavenderia" with "Laundry
> Service", which title would you choose?
>
> I'm actually tending towards merging this particular example too, now;
> and giving a general direction to "Choose the language and release title
> for which the artist is most well known/popular."
>
> What do you think?
>
> Aaron Cooper wrote:
>> One quick comment.
>>
>> Guideline says, "If there are two versions of a release in different
>> languages; each language would be its own release group."  What about
>> for Translations/Transliterations?  It appears these were
>> automatically merged into the same release groups on test (I'm
>> thinking of the Complete Beethoven Edition, Volume 1 and 2).  Why
>> aren't we merging albums just because of the language difference?  As
>> far as I've seen, RateYourMusic.com groups albums even if the titles
>> are in different languages (some Beatles albums come to mind).
>>
>> -cooperaa
>>
>>
>>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Pre-RFC: Release Groups (and associated style)

[Aaron Cooper]

One quick comment.

Guideline says, "If there are two versions of a release in different
languages; each language would be its own release group."  What about
for Translations/Transliterations?  It appears these were
automatically merged into the same release groups on test (I'm
thinking of the Complete Beethoven Edition, Volume 1 and 2).  Why
aren't we merging albums just because of the language difference?  As
far as I've seen, RateYourMusic.com groups albums even if the titles
are in different languages (some Beatles albums come to mind).

-cooperaa


On Sun, May 24, 2009 at 12:26 PM, Chad Wilson  wrote:
> Hi all
>
> As you most know, very soon Release Groups will be live. Style is
> obviously a work in progress as we're not sure how it's all going to
> work out across the variations in the real world but the basic cases are
> reasonably well known. Pronik, prodoc, gioele, navap, ruaok and I have
> put together a starting point which I think we need some wider comment
> and discussion on now.
>
> I have made an executive decision and merged a couple of pages together
> into a Style/Terminology page at at
> http://wiki.musicbrainz.org/Release_Group
>
> There are some open points on the Discussion page on the wiki; please
> take a look at them. I also think the rules around use of the "type" and
> "title" are possibly a bit weak currently.
>
> We also need documentation for the edit types; I'll try and get to that
> too; but I think the main style and discussion should stem from the
> above page.
>
> Comments/feedback/argument?
>
> Chad / voice
>
> PS: I apologise to any feathers ruffled by my
> merge/re-structure/redirects, but I felt it was important to have a
> single page to talk about and have something roughly similar to the
> structure of other terminology and guideline pages to present a
> reasonably clear and unified face to users from day 1.
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] PartNumberStyle - "Foo, Parts 1-3" vs "Foo, Parts 1 - 3"

[Aaron Cooper]

I also don't think we should keep the example with the spaces.  I have
never seen the guideline applied that way.  Every instance has used
1-3 with no spaces.  If the spaces are left in the example, they will
most definitely be used to change titles to include spaces.  People
will say "See the example?  You need to make it like that - add
spaces."  That's exactly what happens with Classical... "look at the
examples - capitalize like that, punctuate like that, etc."

-cooperaa


On Thu, Apr 23, 2009 at 8:26 PM, Brian Schweitzer
 wrote:
>> as discussed on the wiki, the table of examples were IMO pointless as
>> they just added unnecessary bulk to the page - they didn't show you
>> anything the 3 others already showed you.
>>
>
> I don't really consider 1 comment, and a "+1" to be much of a discussion;
> definitely not a definitive one.  :P
>
> For the record, the applicable "discussion" was this:
>
> I also don't think the new examples table is necessary as examples are given
> in the section above. I don't think anyone really has any trouble with how
> to use this style! --Gecks 23:30, 15 March 2009 (UTC)
>
> +1 for the example table not necessary. Murdos 01:59, 24 March 2009 (UTC)
>
> As for showing or not showing anything the other examples didn't already,
> the examples show:
>
> Flares, Part 3
> 09-15-00, Part One
> Creepin', Parts 1 & 2
> Train to Lamy Suite, Parts 1 - 3
> This Is a Trackname, Parts 1, 4 & 5
>
> The table I added showed, for various numbering schemes ("1", "1a", "A1",
> "A1a", "A", "I", and "One"):
>
> Part 1
> Parts 1 & 2
> Parts 1 - 3
> Parts 1 & 3
> Parts 1 - 3, 4
> Parts 1, 3 - 4
> Parts 1, 3 & 4
>
> Perhaps you consider it redundant, but pray tell, how do the 5 examples,
> especially if you're viewing them as definitive guidelines in of themselves,
> lead directly to "Parts 1 - 3, 4" and "Parts 1, 3 - 4"?  The only part of
> the guideline which, if you read it exactly as written, would actually apply
> is this:
>
> ""Train to Lamy Suite, Parts 1-3" -- More than 2 numbers, which are in
> sequence are separated by a hyphen "-", the part indication in its plural
> form. ", based on the "More than 2 numbers" bit.
>
> Anyhow, if we were talking about 30 or 40 lines, maybe that really could be
> described as "unnecessary bulk" - but we're talking about 1 line of text and
> a 7 line table; that's not a very large increase in page size, especially
> when it was aimed directly at clarifying some of the vagueness of this
> guideline.
>
> Brian
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] PartNumberStyle - "Foo, Parts 1-3" vs "Foo, Parts 1 - 3"

[Aaron Cooper]

I admit, "it looks weird" isn't necessarily a good reason not to use
"SPACE-SPACE".  It does prevent the "1-1-1-3" problem but I suspect
that it may be common for part numbers to be printed on booklets
without the spaces (perhaps this would explain why so many people seem
to dislike the spaces).

If it seems like a majority prints part numbers without the spaces, we
probably should write them without the spaces and when a release has
parts 1-1-1-3 we can enter the part numbers as they are printed.

-cooperaa

On Mon, Apr 20, 2009 at 9:36 PM, Brian Schweitzer
 wrote:
> Well, SeriesNumberStyle indicates we shouldn't be changing the part number;
> I would suggest that that also seems to apply to any subparts, subsubparts,
> etc.  It also feels like we'd be manipulating the data, as a further
> complication, just to find some way to still make "Parts 1-3" work, rather
> than simply using "Parts 1 - 3" and avoiding all the complications/etc...
>
> Brian
>
> On Mon, Apr 20, 2009 at 8:02 PM, StoneyBoh  wrote:
>>
>> My suggestion...
>> - Use the dash (hyphen so we don't have any typography issues) for
>> ranges with no spaces.
>> - For sub-parts, use a period.
>>
>> Parts 1-3  is a range
>> Part 1.1 is a subpart
>> Parts 1.1-1.9 is a range with subparts.
>>
>> simple.
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] PartNumberStyle - "Foo, Parts 1-3" vs "Foo, Parts 1 - 3"

[Aaron Cooper]

I have yet to see any work with parts greater than 12 or so, so I am
not worried about the "twenty-two-twenty-four" problem.  Also, I
rarely ever see part numbers written as words - much more common to
see "1 and 2" or "I and II".

Whoever started using "1-1" to signify subparts should be thrown off
the boat, as far as I'm concerned ;)  Parts "1a" and "1b" make much
more sense, IMO.

-cooperaa


On Fri, Apr 17, 2009 at 1:35 PM, Brian Schweitzer
 wrote:
> On Thu, Apr 16, 2009 at 12:31 PM, Paul C. Bryan  wrote:
>>
>> I've now read the discussion page in the wiki, and understand the GC
>> issue a bit more clearly. I'm still of the opinion that we should follow
>> English convention in expressing ranges rather than deviate in order to
>> ease GC issues.
>>
>> My vote would be on "Parts 1-3" without spaces.
>>
>> On Thu, 2009-04-16 at 09:25 -0700, Paul C. Bryan wrote:
>> > I agree, keeping it "Parts 1-3" is more intuitive to me, in common
>> > English style.
>> >
>> > I don't understand what in particular "breaks" beyond perhaps the new
>> > Guess Case code when dealing with numbers spelled-out rather than
>> > numerically. Brian, could you provide further clarification on the
>> > issue?
>> >
>> > We humans seem to have no problem disambiguating:
>> >
>> >   * parts 1-3
>> >   * parts one-three (highly unusual to spell numbers but still use
>> > hyphen)
>> >   * part twenty-two
>> >
>> > I agree that it's currently not well defined in the guideline and
>> > probably should be. So, Brian's point about RFC seems correct.
>> >
>> > Paul
>> >
>> > P.S. I didn't think we had transclusion from MB to docs yet. Do we? So,
>> > if it got to docs, then someone changed it there too?
>> >
>> > On Thu, 2009-04-16 at 17:05 +0100, Chris B wrote:
>> > > there's a silly revert war going on on the wiki
>> > > (http://wiki.musicbrainz.org/Part_Number_Style) so rather than carry
>> > > on with that i think it's time it was brought to this list.
>> > >
>> > > the conflict is over how we represent ranges: a) "Parts 1-3" or b)
>> > > "Parts 1 - 3"
>> > > it's been stipulated as a) (in the examples) since the guidelines
>> > > conception, as far as i know (my only references to the very first
>> > > discussion are now-defunct links to a defunct online list mirror) with
>> > > no problems for 5 years, but brian's arguments for b) are:
>> > >
>> > > "The style itself doesn't specify that there should be no space around
>> > > -; only the example gave this impression. However, A) the
>> > > no-space-around-hyphen style actively *breaks* on anything *but* 0-9
>> > > ranges, whereas the spaced version does not, and B) the new GC was
>> > > written to insert that space. We could keep switching this back and
>> > > forth, but if the sense is that there explictly should be no space,
>> > > this really should be decided by RFC, with reason given as to why the
>> > > fact that this causes misinterpretations (Part 1-1, 1-3, Twenty-two,
>> > > etc all would appear as ranges, not singular part numbers; spaced
>> > > ranges doesn't introduce that problem.)"
>> > > http://wiki.musicbrainz.org/Talk:Part_Number_Style
>> > >
>> > > my arguments keeping it as a) are:
>> > > - a dash with no spaces is the standard way of showing a number range
>> > > - http://en.wikipedia.org/wiki/Dash
>> > > - is it really worth making it unintuitive and ugly (to me, at least)
>> > > to protect these edge cases (has anyone even got any real-world
>> > > examples of examples that break it?) when 0-9 ranges are in the
>> > > majority
>> > > - if anything, wouldn't it be better to add the space only in those
>> > > edge cases, rather than for all?
>> > >
>> > > i put it to the list :)
>> > >
>> > > as an aside, i don't really like the way the change appeared to
>> > > instantly go 'live' on the wikidocs -
>> > > http://musicbrainz.org/doc/PartNumberStyle - when it's clearly not a
>> > > 'stable' page as stipulated in http://musicbrainz.org/doc/WikiDocs :(
>> > >
>> > > chris/gecks
>> > >
>> > > ___
>> > > Musicbrainz-style mailing list
>> > > Musicbrainz-style@lists.musicbrainz.org
>> > > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>> >
>> >
>> > ___
>> > Musicbrainz-style mailing list
>> > Musicbrainz-style@lists.musicbrainz.org
>> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> I think this has been a bit misrepresented as to what the issue is.  I
> actually made it clear to Chris, in private emails weeks ago, that this
> specifically is *not* an issue within the new GC code.  The new GC code
> actually quite specifically has a small bit of code to handle varying
> spacing, depending upon the type of numbering used.
>
> There are actually two 

Re: [mb-style] PartNumberStyle - "Foo, Parts 1-3" vs "Foo, Parts 1 - 3"

[Aaron Cooper]

My vote is for a)... no extra spaces.

-cooperaa


On Thu, Apr 16, 2009 at 12:31 PM, Paul C. Bryan  wrote:
> I've now read the discussion page in the wiki, and understand the GC
> issue a bit more clearly. I'm still of the opinion that we should follow
> English convention in expressing ranges rather than deviate in order to
> ease GC issues.
>
> My vote would be on "Parts 1-3" without spaces.
>
> On Thu, 2009-04-16 at 09:25 -0700, Paul C. Bryan wrote:
>> I agree, keeping it "Parts 1-3" is more intuitive to me, in common
>> English style.
>>
>> I don't understand what in particular "breaks" beyond perhaps the new
>> Guess Case code when dealing with numbers spelled-out rather than
>> numerically. Brian, could you provide further clarification on the
>> issue?
>>
>> We humans seem to have no problem disambiguating:
>>
>>   * parts 1-3
>>   * parts one-three (highly unusual to spell numbers but still use
>> hyphen)
>>   * part twenty-two
>>
>> I agree that it's currently not well defined in the guideline and
>> probably should be. So, Brian's point about RFC seems correct.
>>
>> Paul
>>
>> P.S. I didn't think we had transclusion from MB to docs yet. Do we? So,
>> if it got to docs, then someone changed it there too?
>>
>> On Thu, 2009-04-16 at 17:05 +0100, Chris B wrote:
>> > there's a silly revert war going on on the wiki
>> > (http://wiki.musicbrainz.org/Part_Number_Style) so rather than carry
>> > on with that i think it's time it was brought to this list.
>> >
>> > the conflict is over how we represent ranges: a) "Parts 1-3" or b) "Parts 
>> > 1 - 3"
>> > it's been stipulated as a) (in the examples) since the guidelines
>> > conception, as far as i know (my only references to the very first
>> > discussion are now-defunct links to a defunct online list mirror) with
>> > no problems for 5 years, but brian's arguments for b) are:
>> >
>> > "The style itself doesn't specify that there should be no space around
>> > -; only the example gave this impression. However, A) the
>> > no-space-around-hyphen style actively *breaks* on anything *but* 0-9
>> > ranges, whereas the spaced version does not, and B) the new GC was
>> > written to insert that space. We could keep switching this back and
>> > forth, but if the sense is that there explictly should be no space,
>> > this really should be decided by RFC, with reason given as to why the
>> > fact that this causes misinterpretations (Part 1-1, 1-3, Twenty-two,
>> > etc all would appear as ranges, not singular part numbers; spaced
>> > ranges doesn't introduce that problem.)"
>> > http://wiki.musicbrainz.org/Talk:Part_Number_Style
>> >
>> > my arguments keeping it as a) are:
>> > - a dash with no spaces is the standard way of showing a number range
>> > - http://en.wikipedia.org/wiki/Dash
>> > - is it really worth making it unintuitive and ugly (to me, at least)
>> > to protect these edge cases (has anyone even got any real-world
>> > examples of examples that break it?) when 0-9 ranges are in the
>> > majority
>> > - if anything, wouldn't it be better to add the space only in those
>> > edge cases, rather than for all?
>> >
>> > i put it to the list :)
>> >
>> > as an aside, i don't really like the way the change appeared to
>> > instantly go 'live' on the wikidocs -
>> > http://musicbrainz.org/doc/PartNumberStyle - when it's clearly not a
>> > 'stable' page as stipulated in http://musicbrainz.org/doc/WikiDocs :(
>> >
>> > chris/gecks
>> >
>> > ___
>> > Musicbrainz-style mailing list
>> > Musicbrainz-style@lists.musicbrainz.org
>> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] (feat. artists) (disc#) vs. (disc#) (feat. artists)

[Aaron Cooper]

I'm hoping it is just a typo.  The DiscNumber is usually the last
thing entered into the ReleaseTitle and the only occasion I can think
of where this might not be true is if there are different performers
on each disc.

-cooperaa


On Sun, Apr 12, 2009 at 8:06 AM, Brant Gibbard  wrote:
> I notice that in http://wiki.musicbrainz.org/Classical_Release_Title_Style
> there are statements which appear to conflict with one another.
>
> In the section marked "Structure" there is a schema for the structure of a
> classical title which finishes with:
>
> DiscNumber [[[Disc Title|DiscTitle [[[Featuring
> Artist|FeaturingArtist]]]
>
> Which is odd, as it is suggesting putting the disc number BEFORE the
> featured artists, which is certainly not the way this has been done in the
> past, and yet every single example in the "Examples" section that has
> multiple discs puts the disc number AFTER the featured artists:
>
> Die Zauberflöte (Berliner Philharmoniker feat. conductor: Karl Bohm) (disc
> 1)
> Piano Concertos Nos. 1-5 (New Philharmonia Orchestra feat. conductor: Otto
> Klemperer, piano: Daniel Barenboim) (disc 1)
> Requiem in D minor / Ave verum corpus / Missa Brevis in D minor (Kölner
> Kammerchor & Collegium Cartusianum feat. conductor: Peter Neumann) (disc 1)
>
> Is this simply a typo in the "Structure" section, or is it really the
> intention to change the order?
>
> A similar structure is given in http://wiki.musicbrainz.org/Release_Title
>
> Brant Gibbard
> Toronto, ON
> http://bgibbard.ca
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "Feat." on non-english releases

[Aaron Cooper]

"disc" is not part of the release title and will (hopefully) one day
be moved to a separate field.  I don't think we need (or should) make
it conform to the release's language.  That would make it harder to
manage the releases - I have no idea what "disc" is in every language
and I doubt most users do.  It'd be a lot easier for every user to use
"disc" than make every user learn the translations for "disc".

The same goes for "feat."

-cooperaa


On Sat, Mar 7, 2009 at 11:56 AM, Z  wrote:
> Yes, I think we also should change "disc" to whatever language the rest of
> the title is (in spanish it would be "disco", but most people go with "CD"
> because it's unversal, then someone comes along and changes it to "disc" and
> we're back with titles in two languages for no reason).
> If someone gives me a good reason why we shouldn't translate these terms
> I'll drop the issue, but if not I think this should be stated in the style
> guidelines.
>
> 2009/3/7 Kuno Woudt 
>>
>> On Sat, Mar 07, 2009 at 03:09:32PM +0100, Aurélien Mino wrote:
>> > I consider "feat." a special keyword that shouldn't be translated, the
>> > same way we don't translate "disc" or "*bonus disc"* from our
>> > DiscNumberStyle guideline.
>>
>> If a dutch disc has 'schijf' instead of 'disc', I would probably use
>> that.  Most use 'cd 1', 'cd 2', etc..  I'm ok with changing that to
>> 'disc'.
>>
>> -- kuno / warp.
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Passed RFV: YouTubeRelationshipType wiki page

[Aaron Cooper]

I'm not sure, but I think you should probably forward this to the
MB-dev mailing list.

-cooperaa


On Fri, Mar 6, 2009 at 7:21 AM, Mike Morrison  wrote:
>
>
> I believe this RFV has now passed. Now we just need a RelationshipEditor
> to implement the AR per the wiki page.
>
> http://wiki.musicbrainz.org/YouTubeRelationshipType
>
> Mike
>
>
> On Tue, 3 Mar 2009, Mike Morrison wrote:
>>
>> It's been two weeks since I opened the RFC [1] on the current revision [2]
>> of this wiki page, and no changes have been suggested on this list in that
>> time, so I am moving it to RFV.
>>
>> I will remove the "work in progress and not official" warning from the
>> page after 48 hours, if there is no veto.
>>
>> Mike
>>
>> [1] 
>> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-February/007618.html
>>
>> [2] http://wiki.musicbrainz.org/YouTubeRelationshipType?action=recall&rev=2
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] 1 CD/digital = 2 X LP = 2 disc?

[Aaron Cooper]

I picture the future with no such thing as "discs" as releases won't
necessarily be split up to fit on any specific media/format.  If media
is obtained online as digital files, there is no limit to what can be
issued in a single release.

I really don't like all the duplication (eg. Death Magnetic CD as a
single release and then Death Magnetic Vinyl as a 5-"disc" set) -
there's just too much duplication of information when the releases as
a whole are identical.  Should we continue to stick to these
traditional divisions in a release?  There's really not any harm in
just having one MB release for an entire physical release.  If you
tagged a double-disc album with disc numbers, it'd still be grouped
together and play all the way through (if shuffling albums).  The same
thing would occur if track 1 of disc 2 was track 17 of a single MB
release.  Sometimes you'll even see this on Amazon when they don't
show disc divisions but list all tracks from all discs together.

I doubt we'll stop, but I'm all for leaving "disc numbers" as a thing
of the past.

-cooperaa



On Tue, Mar 3, 2009 at 2:23 PM, Paul C. Bryan  wrote:
> I guess I prefer it too.
>
> What's really not working here is equating releases to discs. I'm seeing
> the same issues with a bunch of Mosaic multi-disc (5-10 CDs per release)
> releases that were released simultaneously on CD and vinyl. If/when I
> tackle the vinyl equivalents, it's going to clutter MB's database up,
> but given the current model, not much choice IMO.
>
> Paul
>
> On Tue, 2009-03-03 at 20:16 +0100, Kuno Woudt wrote:
>> On Tue, Mar 03, 2009 at 08:57:50AM -0800, Mark Woodson wrote:
>> > When the track listings are identical, the catalog numbers are
>> > identical and it's been broken across multiple discs because of
>> > limitations in the media with vinyl, I'd argue that it doesn't create
>> > any real value in the database. There is never going to be a disc id
>> > to attach to these things. Most often a download is provided with the
>> > purchase, and so PUID's would have to be manually linked to this weird
>> > multi-disc edition. It just seems kind of an unnecessary waste.
>>
>> If I have such a release as a two disc LP, I'll have 'disc 1' and
>> 'disc 2' directories when I rip it.  I prefer the DB to match that
>> situation.
>>
>> -- kuno / warp.
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Revise SortNameStyle for artist names that contain a person's name

[Aaron Cooper]

+1

On Mon, Mar 2, 2009 at 11:52 AM, Paul C. Bryan  wrote:
> I think that there's enough support for my earlier query that I should
> propose this formally as an RFC.
>
> Problem Summary:
> According to SortNameStyle, a band name that contains the name of a
> person should sort as a fictitious name rather than as the person's
> artist sort name. This results in works of the artist and any eponymous
> bands to be spread throughout artist listings rather than being grouped
> together.
>
> Proposal Summary:
> Amend SortNameStyle to indicate that in the case where an artist name
> contains the name of a person, that it sort per the person's name, not
> as a fictitious name. This makes it more consistent with the spirit of
> ArtistSortName, as it allows for better grouping of an artist's work
> when displayed in a list sorted by artist.
>
> Affects:
> * SortNameStyle
>
> Proposal:
> Change the last bullet of #6 in SortNameStyle to read as follows:
> Artist names that contain a person's name (usually eponymous band names)
> sort as the person primarily, with remaining identifiers as
> comma-separated suffixes. Examples: "The Sensational Alex Harvey Band"
> has sort name "Harvey, Alex, Sensational, Band, The". "The Jimi Hendrix
> Experience" has sort name "Hendrix, Jimi, Experience, The".
>
> Rationale:
> Artist sort name is a cue to systems that produce lists on how names
> should be collated. This change allows for better grouping of works of
> an artist, regardless of whether they perform solo or in eponymous band
> names. This makes it easier for people to locate such works in sorted
> lists.
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] ArtistSortName w. trios, quartets, quintets, etc.

[Aaron Cooper]

On Sun, Mar 1, 2009 at 9:59 AM, Leiv Hellebo  wrote:
> SwissChris wrote:
>> Searching (and finding) releases isn't the problem here ;-)  But where
>> should they appear in a sorted list (e.g. subscriptions, or "albums I
>> own"): half of them as Louis and half as Armstrong?
>
> In my opinion, yes :)

That makes *zero* sense.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] ArtistSortName w. trios, quartets, quintets, etc.

[Aaron Cooper]

On Sun, Mar 1, 2009 at 4:07 AM, Leiv Hellebo  wrote:
> Paul C. Bryan wrote:
>> A change to SortNameStyle I'd like you to consider is:
>>
>> 'Artist names that contain a person's name (usually bands) should sort
>> in a manner consistent with the person's name as an artist. Examples:
>> "The Sensational Alex Harvey Band" has the sort name "Harvey, Alex,
>> Sensational, Band, The". "The Jimi Hendrix Experience" has sort name
>> "Hendrix, Jimi, Experience, The".'
>
> I much prefer what we already have, because group names are not
> conventionally chunked up as person names are.
>
> I don't see person sorting as useful here, and libraries etc. that use
> this kind of sorting probably does it to conveniently have Benny Goodman
> and Benny Goodman Quartet recordings placed close to one another.
>
> This concern does not apply to MusicBrainz, because you can click "Benny
> Goodman" -> "View relationships" and easily find "Benny Goodman Quartet".
>
>> If this change is too extreme, would a suitable compromise make sense
>> for trios, quartets, quintents, etc?
>
> No reason to treat classical artists different from other artists, IMO.
>
>
> Leiv

I currently change my jazz trios/quartets/etc sort names manually so
they group with the main artist.  I'm all for changing MB's guidelines
to say artist sort name like "Goodman, Benny, Quartet, The"

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Invitation to connect on LinkedIn

[Aaron Cooper]

LOL.

On Fri, Feb 27, 2009 at 6:43 PM, George De Bruin  wrote:
> LinkedIn
>
> MusicBrainz,
>
> I'd like to add you to my professional network on LinkedIn.
>
> - George
>
> PS: Here is the link:
> https://www.linkedin.com/e/isd/501887102/4QlVh-fK/
>
> 
>
> What is LinkedIn and why should you join?
>
> © 2009, LinkedIn Corporation
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "feat." in classical release titles

[Aaron Cooper]

On Wed, Jan 28, 2009 at 6:01 PM, Aaron Cooper  wrote:
> On Wed, Jan 28, 2009 at 5:38 PM, Leiv Hellebo  wrote:
>> I guess most people don't consider FAS as really applicable for
>> classical - and this makes sense, because we use
>> ClassicalReleaseArtistStyle, not ReleaseArtistStyle to find the artist.
>
> I'd love to see FAS go from classical release titles.  Since we have
> ARs, we shouldn't be putting this performer info in ReleaseTitle field
> anymore - we should be requiring ARs.
>
> -cooperaa
>

PS: Requiring ARs would also prompt more people to subscribe/watch
performers and not just their favourite composers which I think would
be a good thing.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "feat." in classical release titles

[Aaron Cooper]

On Wed, Jan 28, 2009 at 5:38 PM, Leiv Hellebo  wrote:
> I guess most people don't consider FAS as really applicable for
> classical - and this makes sense, because we use
> ClassicalReleaseArtistStyle, not ReleaseArtistStyle to find the artist.

I'd love to see FAS go from classical release titles.  Since we have
ARs, we shouldn't be putting this performer info in ReleaseTitle field
anymore - we should be requiring ARs.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "from the beginning" and "until the end" attributes for "member of" AR

[Aaron Cooper]

On Tue, Jan 27, 2009 at 10:48 AM, Gioele  wrote:
> Could add two attributes: "From the beginning" and "To the end" to the
> "member of" AR? With these attributes we could easy express that a certain
> artist has been a member of a group from its inception to the (eventual)
> end. Also one could say that an artist has been "member of" a group "from
> beginning" to 2008-12-20.
>
> Right now there we cannot differentiate between "Since the beginning" and "I
> don't when since when".


Can't we just give the member the same start date as the band?

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Classical Composers vs Artists

[Aaron Cooper]

Who would the artist be - the orchestra, the conductor, or the
soloist?  There are times when we set the ReleaseArtist to a performer
already - see http://wiki.musicbrainz.org/ClassicalReleaseArtistStyle

In a perfect MB world, all performers would have performance
AdvancedRelationships on the releases/tracks they performed on so that
we could go to their "Appears On" page and see all performances.

-cooperaa


On Mon, Jan 19, 2009 at 8:05 PM, Jason Longland
 wrote:
> Hi Guys,
>
> Just curious with the classical styling guide as to why with the advent
> of ID3v2 tagging you still force it to use the Composer as the Artists
> when the newer ID3 tags all have the composer field available.  After
> all, would it not make more sense to use the Artist who actually
> performed the track as the Artist so that media players can pick
> everything up as being the same CD when you search for say San Francisco
> Symphony Orchestra versus having to go through and look for a dozen
> different composers?
>
> Just curious,
>
> Jason

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

On Mon, Jan 19, 2009 at 5:30 PM, Leiv Hellebo  wrote:
> Aaron Cooper wrote:
>> I think the book title is an important piece of information - much
>> like the work title in classical music.
>
> Sure.
>
>   We always put the work and
>> then the movement in classical track titles even if there is only one
>> work on a release.
>
> As I'm sure you remember I started a discussion about this last year
> here on mb-style[1]. My view: This is redundant, makes for unwieldy
> titles which even are hard to read for short tracks, and I don't think
> it looks good.
>
> For a post later in that thread I did some checking and found that the
> include-workname-even-for-opera-and-similar-practice was not common
> earlier, but became more common during 2007. The reason for it becoming
> more common was discussions om mb-style starting from the assumption
> that we did not have Works.

That's still how we do it in the classical world and how the examples
are in the CSG.  Because we include work names now, I think it would
be appropriate to include book names in audiobook track titles.  If we
decide elsewhere that including the work name is now extraneous then I
could see us making an identical change to audiobooks (dropping the
book name).

>> I think we should apply the similar rule here.
>
> One reason for not doing so: Audiobooks differ from classical recordings
> by rarely having more than one work included.
>
> For those who really want it in, isn't it possible to have Picard add
> the release title to the track title?

Making Picard do this would be a pain in the butt as you'd have to do
it on a case-by-case basis for the rare occasions where the release
title is not the book title or there are multiple books in the release
title.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

I think the book title is an important piece of information - much
like the work title in classical music.  We always put the work and
then the movement in classical track titles even if there is only one
work on a release.  I think we should apply the similar rule here.

-cooperaa

On Mon, Jan 19, 2009 at 4:02 PM, Leiv Hellebo  wrote:
> Aaron Cooper wrote:
>> It looks like we've decided to drop the book name from the track
>> titles though - I think we should keep this info there for reasons
>> that have been previously discussed.
>
> But isn't this only a good idea when the audiobook contains more than
> one book? If so, my opinion is that we should not let the exception
> (more than one book on a single disc/cassette/download audiobook)
> dictate the general rule.
>
> Sorry, if I missed something...
>
> Leiv
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

Why don't we just leave "part 1" out of the track title unless it is
a) part of the chapter name or b) printed on the cover/booklet.

We don't really need to put part numbers in the track titles if they
aren't on the back cover/booklet.  If the CD says "Tracks 1-4: Chapter
1" why don't we just set the title of tracks 1, 2, 3, and 4 to
"Chapter 1"?  The track numbers will differentiate as they do for
releases with multiple untitled tracks.

It looks like we've decided to drop the book name from the track
titles though - I think we should keep this info there for reasons
that have been previously discussed.

So, I'd say track titles should be:

Book Name: Chapter #
Book Name: Chapters #-#
 - use PartNumberStyle if "Part" is part of the title as printed on
the CD booklet

-cooperaa

On Mon, Jan 19, 2009 at 5:28 AM, Fridtjof Busse  wrote:
> Are there any real arguments against using what's already used for
> releases with several discs: [disc x]?
> I.e. "Chaptername [part 1]"
>
> --
> Fridtjof Busse

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

On Sat, Jan 10, 2009 at 4:42 AM, Fridtjof Busse  wrote:
> * "Paul C. Bryan" :
>> If there is only one track for the chapter, then it would be:
>>
>>   * Chapter 01: $name
>>   * Chapter 02: $name
>>   ...
>>
>> This was originally proposed by Keschte in AudioBookStyle, and was
>> intended to keep tracks sorted properly if the trackname was the only
>> cue. I happen to agree this is a worthy objective to maintain.
>
> It's not the job of musicbrainz to keep tracks sorted if the
> TRACKNUMBER got lost.
>
>>   * Chapter 01-01: $name; note the leading zero on the chapter
>> number
>>   * Chapter 01-02; not fond of repeating chapter names
>>   * Chapter 01-03
>>   * Chapter 02-01: $name
>
> I really dislike this. The second part of a chapter has no name, this
> makes no sense IMHO.
>
> Also, I'd prefer not to use the naming scheme in musicbrainz as an aid
> to keep your tracks sorted or work around "broken" audio players.
> What I mean by this is basically what the "(disc x)" header does. The
> program you're using can decide for itself if it wants to put this part
> in the title or simply strip it and use the number for DISCNUMBER (e.g.
> sound-juicer does this). If something similiar was used for
> audiobooks, you (resp. your tagging application) can decide what
> filename to use for the file on your PC. I hope you can understand my
> idea behind this.
> Something like "$chaptername (01/09)" or the like.

I don't like leading zeros either - the tracks will be sorted by TrackNumber.

I also don't like using "Chapter 1-2" to designate a sub-part of a
chapter.  For classical releases, we use "Chapter IIIa" for standard
sub-parts and "Chapter III-ii" for non-standard divisions (I believe
there was some support behind this although it was never made an
"official" part of the CSG).

I think it would be good to do the same for audiobooks.  If a chapter
has standard sub-chapters, then use "Chapter 3a: Subchapter Title" .
If a chapter is just arbitrarily split amongst several tracks, then
use "Chapter 3-iv" or even "Chapter 3, Part 4" from PartNumberStyle.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

Also, including the book/work name is used in the CSG.

On 7-Jan-09, at 9:59 AM, "Frederic Da Vitoria"   
wrote:


Ah, but the book is not the release. There may be more than one  
"book" in one release and a book is of course often spanned on more  
that one release.


2009/1/7 Bram van Dijk 
I agree, why would we do that for audiobooks if we don't do that for
regular music?
Do people play audiobooks with different software that is not able to
read tags?
Just:
Chapter 1: foo
Chapter 2-4: bar
seems fine by me, and it is a lot less cluttered.

People can always use tagger scripts if they want the release name in
the title, I think.

Bram

Fridtjof Busse schreef:
> * "Frederic Da Vitoria" :
>
>> You wouldn't include an ordering sequence?
>> A Journey to the Center of the Earth, 0:Prologue
>> A Journey to the Center of the Earth, 1:Chapter 1a
>> A Journey to the Center of the Earth, 2:Chapter 1b
>>
>
> I honestly have a problem with repeating the release title in the
> track name.
> This generates unnecessary long tags and contains redundant
> information (in ALBUM and TITLE).
> Imagine this:
> ALBUM=The Lord of the Rings: The Fellowship of the Ring
> TITLE=The Lord of the Rings: The Fellowship of the Ring,
> Chapter 1: Concerning Hobbits
>
> Also, I'd like to suggest not to use "(feat. narrator: xyz)" in the
> release title. It's not part of the release title and useless if
> there's more than one narrator. This information should be stored
> somewhere else.
>
>



___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



--
Frederic Da Vitoria

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april. 
org


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Audiobook styleguide

[Aaron Cooper]

My really quick attempt at a AudiobookStyle would be:

Track titles should be:
A Journey to the Center of the Earth, Chapter 1

If there are chapter titles:
A Journey to the Center of the Earth, Chapter 1: Title of Chapter 1

If a chapter is spanned across multiple tracks:
A Journey to the Center of the Earth, Chapter 1a
A Journey to the Center of the Earth, Chapter 1b

If multiple chapters are included on one track:
A Journey to the Center of the Earth, Chapters 1, 2   (comma when only
2 chapters)
A Journey to the Center of the Earth, Chapters 1-3   (hypen when >=3
consecutive chapters)

If there are other non-chapter segments:
A Journey to the Center of the Earth, Prologue

-cooperaa


On Wed, Jan 7, 2009 at 6:46 AM, Fridtjof Busse  wrote:
> Hi,
>
> I'd like to bring up a topic that seems to have been forgotten for some
> time now: The audiobook styleguide.
> There's an inofficial one at [1], but both authors are not working on
> musicbrainz any longer and the last discussion on the ML dates back to
> June 2007.
> I recently added some audiobooks and noticed that there are tons of
> different styles the other audiobooks were named after (e.g. with the
> narrater as part of the release title, "Chapter x" in front of every
> track, etc), so a styleguide would definitly be a good idea.
>
> I can't propose the perfect style guide, though I have some
> ideas. I'm not familiar enough with musicbrainz to do this by myself,
> but I'd definitly be willing to help to get a audiobook styleguide
> finalized. Is anybody interested in picking this up?
>
> At least I'd like to get the discussion started again.
>
> [1] http://musicbrainz.org/doc/AudioBookStyle
>
> --
> Fridtjof Busse
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "Good Style" releases

[Aaron Cooper]

>> 2008/12/31 Michelle . 
>>
>>> Hi all,
>>>
>>> I've recently noticed that most of the classical releases have  
>>> poor style,
>>> and it's very difficult to work out what the correct style is from  
>>> the
>>> entered releases, especially since so much depends on the individual
>>> work/composer. And although there are examples in the Guidelines,  
>>> it's
>>> hard
>>> to know which one to follow unless you have a pretty decent  
>>> knowledge of
>>> the work in question.
>>>
>>> Could there be a growing list, or a way of flagging individual  
>>> releases,
>>> to
>>> denote that the style of a release is "Good" and therefore can be  
>>> followed
>>> as standard for other releases of similar works? Of course,  
>>> additions to
>>> the
>>> list should be done by experienced editors or by vote. Is it even  
>>> worth
>>> the
>>> effort?
>>>
>>> Michelle (dirtyboots)
>>>

What about changing the DataQuality to high once the titles have good  
style and ARs etc are created?

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Add release media type "DVD-Audio" (was: Re: Music DVDs)

[Aaron Cooper]

I like how rateyourmusic.com organizes their stuff.  They have video  
and audio categories and then different release medias for each.  So  
when you say a release is a video release you can only choose from  
VHS, DVD, etc. and then when the release is an audio release you can  
choose cassette, CD, etc.

-cooperaa


On 22-Dec-08, at 11:18 PM, Mustaqil Ali wrote:

> Sorry for the double post here, but after a discussion on IRC about  
> release formats, perhaps it does make more sense for there to be  
> "DVD" and for current release events for these stay as they are.
>
> But rather, DVD-Audio should be added, as should DVD-Video for that  
> matter, so new release events can be added and a level of accuracy  
> recorded over whether this item was released as an album on a DVD  
> with higher sound quality/channels etc, or whether it's the audio  
> track ripped from a live performance or collection of music videos  
> etc. These examples are purely for argument's sake, but should  
> hopefully get my (now changed) point that if we're going to give  
> users an option over the release's physical media's data format, we  
> shouldn't be cherry picking which ones.
>
> In essence, this is getting the ball rolling on the now outdated 
> http://wiki.musicbrainz.org/ReleaseTypeRestructuringProposal 
>  which needs some TLC paid towards it.
>
> From: Mustaqil Ali 
> To: MusicBrainz style discussion  >
> Sent: Tuesday, 23 December, 2008 3:34:21
> Subject: Re: [mb-style] RFC: Add release media type "DVD- 
> Audio" (was: Re: Music DVDs)
>
> Hah, funny that, seeing that the only DVD releases that come to mind  
> for me are DVD-As that I've added or rips I've wanted to tag.
>
> Either way, my point is that the current DVD media type shouldn't'  
> just be left as this is vague and these release events should  
> dictate whether they're DVD-Video rips or actual releases on DVD- 
> Audio discs and the entire point of this mailing thread appears to  
> be requesting the introduction of differentiating the recorded data  
> format on the physical media.
>
> What should happen with the current DVD release events? Something  
> needs to be done with these and if we add one (in this case, DVD- 
> Audio), the other needs adding too.
>
> From: Aaron Cooper 
> To: MusicBrainz style discussion  >
> Sent: Tuesday, 23 December, 2008 3:02:22
> Subject: Re: [mb-style] RFC: Add release media type "DVD- 
> Audio" (was: Re: Music DVDs)
>
> On 22-Dec-08, at 9:54 PM, Mustaqil Ali wrote:
>
> > From a technical aspect, adding "DVD-Audio" to the list of media
> > types isn't all that needs doing.
> >
> > The current DVD media that exists will need renaming; either to DVD-
> > Video or to the proposed DVD-Audio and then the DVD-Video media type
> > added.
> >
> > I favour the latter. The reason being for this is that for releases
> > that currently exist in MB with the "DVD" media type are and have
> > been for the most part DVD-Audio discs, although it is undoubtful
> > that a few DVD-Video releases have slipped into the DB which will
> > need amended as they're encountered. With it done this way, there's
> > no confusion when faced with the options "DVD" and "DVD-Audio" on
> > the media types, and the previously entered DVD releases are handled
> > as gracefully as possible.
> >
> > --
> > Muz
>
>
> The only DVD releases I know of in MB are DVD-Video releases.  I have
> never seen a DVD-Audio disc (even outside of MB)!
>
> -cooperaa
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Add release media type "DVD-Audio" (was: Re: Music DVDs)

[Aaron Cooper]

On 22-Dec-08, at 9:54 PM, Mustaqil Ali wrote:

> From a technical aspect, adding "DVD-Audio" to the list of media  
> types isn't all that needs doing.
>
> The current DVD media that exists will need renaming; either to DVD- 
> Video or to the proposed DVD-Audio and then the DVD-Video media type  
> added.
>
> I favour the latter. The reason being for this is that for releases  
> that currently exist in MB with the "DVD" media type are and have  
> been for the most part DVD-Audio discs, although it is undoubtful  
> that a few DVD-Video releases have slipped into the DB which will  
> need amended as they're encountered. With it done this way, there's  
> no confusion when faced with the options "DVD" and "DVD-Audio" on  
> the media types, and the previously entered DVD releases are handled  
> as gracefully as possible.
>
> --
> Muz


The only DVD releases I know of in MB are DVD-Video releases.  I have  
never seen a DVD-Audio disc (even outside of MB)!

-cooperaa


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Album or compilation?

[Aaron Cooper]

On 29-Oct-08, at 6:10 AM, Kuno Woudt wrote:

> On Wed, Oct 29, 2008 at 10:59:42AM +0100, Gioele wrote:
>> Back in the 60s, a guy released many singles. After few years his  
>> label
>> issues his "first album", an anthology of his best known singles.
>>
>> How should this released be catalogued? Album or compilation?
>>
>> I'd say compilation, but then many contemporary pop album should be
>> considered compilations as well, given the number of singles released
>> before the full record. So I think I'll set it as album.
>
> If it has any new tracks, I'd say album.  Otherwise compilation.
>
> In my mind, a compilation compiles tracks which are or were available
> on earlier releases.  It is therefore rarely interesting for me,
> because I would prefer to have the earlier releases.  If it however
> adds a number of tracks, I probably DO want to have that release,
> and wouldn't usually call it a compilation.
>
> (just IMO, i didn't read up on what our guidelines say about the topic
> before posting this reply ;)

ReleaseType says:

The MusicBrainz project does not generally consider the following to  
be compilations:
 *  a tribute release containing covers of another artists work.
 *  a classical release containing new recordings of a  
classical artists work.
 *  a release containing two albums and/or EPs.

So two reissued albums on one disc is considered an Album.

If they intended this to be his first "album" then I would think Album  
seems appropriate.  Singles always come out before albums these days.

My vote is for Album.

-cooperaa

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Creating a non-code AR to grou p releases into “cultural identifiers” for future im porting.

[Aaron Cooper]

On 9-Oct-08, at 3:11 PM, Jan van Thiel wrote:

> Why is this needed at all? 'Earliest release of' and 'Remaster of' ARs
> can be taken advantage of right now if you write some software. This
> new AR will be attached to exactly the same releases as these two ARs.
>
> Jan (zout)
>
But right now we don't/can't link two versions of the same album that  
were released on the same day.  Not to mention a CD version (1 mb  
release) and a vinyl version (5 MB releases).

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Creating a non-code AR to gro up releases into “cultural identifiers” for future i mporting.

[Aaron Cooper]

On 8-Oct-08, at 3:58 PM, Kerensky97 wrote:

> I just want to mention that "Cultural Identifier" is the BBC's term  
> and I
> don't like it.  Robert prefers the term "release groups" which I  
> think is
> much better.
>
> Release groups, Release family, Similar Releases, whatever.  As you  
> read
> keep in mind that "Cultural Identifier" is just a name for grouping  
> releases
> that are the same except they may have added bonus tracks for an  
> overseas or
> limited edition release.  Or a release that is later remastered and
> re-released with some added "unreleased tracks".
>
> The identifier is an MBID that will mark that these are all one  
> album of the
> artist, that has been re-released in slightly different ways.
>
> We have a similar system existing now in that vinyl, cassette, and  
> CD all
> share the same release on Musicbrainz; but only if the tracklistings  
> match.
> This is the same idea, but not bound as tightly to the tracklisting  
> rule.
> Much the same as wikipedia groups all releases together on one page  
> but
> specifies the bonus and alternate tracks in a separate paragraph.
>
> -Kerensky97

"Release Groups" sounds good.

One question I run into now with the "earliest release of" AR is which  
release would we create the relationship from?  I assume we'll  
probably decide to link to the "earliest" since that is easiest to  
determine in most cases.  What about linking the bonus track/special/ 
limited/enhanced versions to the "regular" version?  Would it be too  
hard to identify the "regular" version?

Another question:  Can someone write a report that will show all  
releases with a remaster/earliest release AR and no release group AR  
so we can save a bit of digging?

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "Unmerging" a box set

[Aaron Cooper]

Oh, and I guess another good idea would be to leave a note on the  
merge edit saying you're recreating it so they know not to do that  
again.

-Aaron


On 18-Sep-08, at 9:37 AM, Bram van Dijk wrote:

> +1
>
> Aaron Cooper schreef:
>> Go for it.  Maybe add the "earliest release of" AR and a note in the
>> release's annotation saying "don't merge this according to BSNS".
>>
>> -Aaron
>>
>>
>> On 18-Sep-08, at 9:33 AM, Andrew Conkling wrote:
>>
>>
>>> Unearthed (disc 4: My Mother's Hymn Book) is available separately,
>>> and was on MusicBrainz until it was merged. Yet again,
>>> BoxSetNameStyle doesn't seem to be what people are following (this
>>> was even merged the opposite direction). Anyone mind if I create a
>>> new release?
>>>
>>> -- 
>>> Andrew Conkling
>>> http://andrewski.net
>>> ___
>>> Musicbrainz-style mailing list
>>> Musicbrainz-style@lists.musicbrainz.org
>>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>>>
>>
>>
>> ___
>> Musicbrainz-style mailing list
>> Musicbrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>>
>>
>>
>
>
>
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] "Unmerging" a box set

[Aaron Cooper]

Go for it.  Maybe add the "earliest release of" AR and a note in the  
release's annotation saying "don't merge this according to BSNS".

-Aaron


On 18-Sep-08, at 9:33 AM, Andrew Conkling wrote:

> Unearthed (disc 4: My Mother's Hymn Book) is available separately,  
> and was on MusicBrainz until it was merged. Yet again,  
> BoxSetNameStyle doesn't seem to be what people are following (this  
> was even merged the opposite direction). Anyone mind if I create a  
> new release?
>
> -- 
> Andrew Conkling
> http://andrewski.net
> ___
> Musicbrainz-style mailing list
> Musicbrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Deluxe/limited/superduper editions

[Aaron Cooper]

On 19-Aug-08, at 12:19 PM, Sami Sundell wrote:

> Hi,
>
> I got into a conversation about the additional information that's used
> to differentiate between versions of a release - deluxe edition,  
> limited
> edition, remastered, or in the case of
> , "not final  
> master".
>
> To cut the long story short: I've the impression that we remove that
> kind of information from release titles, unless there's some other
> reason to leave it there (such as it being the whole name, as in Led
> Zeppelin's Remasters compilation). However, I couldn't find anything  
> in
> the guide lines to actually verify that; the closest thing is part of
> discussion in http://wiki.musicbrainz.org/ExtraTitleInformationStyle  
> and
> even there it's only "leave out information not discussed in official
> style guidelines".
>
> Some people are of the opinion that if it says "deluxe edition" in the
> release then it should say so in MusicBrainz as well. Others think  
> it's
> superfluous information that can very well reside in annotations. I
> think it might be a good idea to actually decide on the policy and say
> it out loud in the guidelines.

I really don't like filling the release titles with stuff that isn't  
part of the release title (performers in classical, mastering info,  
etc.).

Perhaps we could solve this with a "version" AR for linking releases  
(and tracks!).

"X is a(n) { acoustic | abbreviated | instrumental | live | remastered  
| remix | unmastered | etc. } version of Y"

As for things like "deluxe/limited" editions, I'm more than happy to  
see that in the annotation since there is no difference in the audio  
on the release (except for extra tracks).  Things where the music is  
different (acoustic, live, remixed, remastered, etc) I think would be  
best solved using ARs.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] BoxSets

[Aaron Cooper]

On 16-Jul-08, at 3:17 PM, Simon Austin wrote:

> What's the policy with BoxSets of previous releases? Is it still  
> they're
> not a unique release? I ask because someone's added all 16 discs of  
> Pink
> Floyd's "Oh, By the Way"[1] and I think they're pretty much just the
> same releases as before, even down to matching DiscIDs[2]
>
> - Si
>
> [1]
>  >
> [2] 
>

Looks like our documentation says not to add those types of box sets  
[1], but I have the impression that this sentiment has changed over  
the last few months.  I hope I'm not presenting a biased opinion, but  
I think we seemed to be heading towards a "if someone wants to add the  
box set, let them" sort of approach.

[1] 
http://wiki.musicbrainz.org/WhatDefinesAUniqueRelease?highlight=%28unique%29#head-431368a6a71f2e13641867f880b84515edc311c6

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] multi-disc releases / box sets.

[Aaron Cooper]

On Wed, Jul 16, 2008 at 11:11 AM, Kuno Woudt <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 16, 2008 at 09:35:07AM +0200, Jan van Thiel wrote:
>> 2008/6/26 Kuno Woudt <[EMAIL PROTECTED]>:
>> > I would like to have an AR to group multiple discs of a single releases.
>> > This would be intended as a temporary solution until we get proper
>> > release and boxset support with NGS.
>> >
>> > Considering this, not all that much time should be wasted on it.
>> >
>> > In it's simplest form, I would suggest an AR like this:
>> >
>> > album B  "is part of a release with"  album A
>>
>> What is the advantage over adding this as an annotation to each of the
>> discs involved?
>
> Machine readable.   In my current musicbrainz related scripts I'm
> grouping multiple discs of a single release together based on their
> release titles.  I have encountered many releases which don't neatly
> fit the (disc 1, disc 2) or (title, bonus disc) schemes, these
> releases confuse my script -- and instead of coding increasingly
> complicated heuristics it would be cleaner if I had _some_ structured
> way to record this information with musicbrainz and be able to query
> it.
>
> IMO, an AR for this is a simple solution which can be implemented now
> with relative ease, and will be easily converted to NGS whenever that
> materializes.

Some things I thought could use some discussion:

1. How will we link 8-disc sets?  Link discs 2-8 to disc 1?  That
might work... if you visit the first disc, it pulls the other discs
from the AR and if you visit one of the other discs it pulls from disc
1 and all disc 1's related discs.

2. Is it appropriate to link bonus discs with a release even though
not all releases of a release came with the bonus disc?  I guess it
wouldn't hurt and would be interesting if you could see the different
bonus discs that came with a release.

I'd definitely like to see something like this and I think it is a
step in the right direction (grouping multiple-disc releases).

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Classical Example? (And, detecting era with taggerscript)

[Aaron Cooper]

On Tue, Jun 24, 2008 at 11:09 AM, Adam Golding <[EMAIL PROTECTED]> wrote:
> Can anyone point me to a classical release that is already particularly well
> tagged, replete with ARs and such?  I'd like to test my scripts on it.

Complete Beethoven Edition.

eg. http://musicbrainz.org/release/af71fc52-7b14-42f6-b9d9-e8c4951b042e.html

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG: Box set compilations / disc names / title length

[Aaron Cooper]

On Tue, Apr 29, 2008 at 9:05 AM, knakker <[EMAIL PROTECTED]> wrote:
> Thanks for the link.
>
> It's more of a standards question that came up seeing the current lack of
> disc titles for many (classical) releases: are all disc texts other than
> just "disc x" considered a disc title and should therefor be added, or is a
> title something more specific? I suspect this to be a vague area as all of
> my classical box set additions (without disc titles) were accepted, so i
> wonder what are the thought on this.
>
> Cheers, knakker


If there is obvious disc titles I think they should be included but I
also think that there are editors who might be "creating" disc titles
from the material that is included on the disc.  It is likely that
each disc says what is on it and when we're talking about classical
releases I doubt it is typical to write out the track list like this:

Symphony No. 1: I. Allegro
Symphony No. 1: II. Allegro con brio
...

but rather they will just write on the disc:

Symphony No. 1
Symphony No. 2

Are these disc titles?  It's hard to say for sure whether its just a
"track list" or a "disc title."

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG: Box set compilations / disc names / title length

[Aaron Cooper]

On Tue, Apr 29, 2008 at 4:56 AM, knakker <[EMAIL PROTECTED]> wrote:
>  Hi,
>
> I'm wondering what the consensus is on the use of disc titles in classical
> box set compilations (complete symphonies, complete concertos, complete
> works etc.). In most cases no titles are used if the content does not
> represent more than the "index" (disc 1: symphonies 1 & 2, disc 2:
> symphonies 3 & 4 opposed to disc 1: The Early Symphonies, disc 2: The Late
> Symphonies). What is the definition of "title" is in this context? is the
> title whats printed on the individual disc as almost all discs have, or is a
> title used when more descriptive of the content - rather that an index?
>
> From a practical perspective I'd prefer to not add the titles in cases where
> the content is more or less obvious like in the symphonies example, the work
> / box set / volume and performer information in the title already contain
> much information resulting in lengthy titles, adding disc titles in all
> cases (being an index) would result in lengths worthy a discussion.


If you're worried about ginormous album titles in your tags, check out
the Disc Numbers plugin for Picard here:
http://wiki.musicbrainz.org/PicardPlugins

Cheers,
-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] A Classical track with two composers

[Aaron Cooper]

On 26-Apr-08, at 1:04 PM, Andrew Conkling wrote:
> On Sat, Apr 26, 2008 at 12:45 PM, Brant Gibbard  
> <[EMAIL PROTECTED]> wrote:
> I cannot seem
> to find a guideline that indicates what to do for the TRACK artist  
> where a
> classical work is the result of a collaboration. I am just  
> considering how
> to enter a release where one of the tracks is an aria from a zarzuela
> composed by a collaboration of two composers, Tomás Barrera and Rafael
> Calleja. (and they really are both composers, the librettist was a  
> third
> individual)
>
> How should this be handled:
> A) With "Various Artists" as the track artist, and composition ARs  
> for the
> two composers
> B) With a collaboration artist "Tomás Barrera & Rafael Calleja" for  
> track
> artist
>
> I'd say B), referring to the second case of FeaturingArtistStyle.  
> What do you think?

That's what I'd think also.

-Aaron (cooperaa)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: ClassicalStyleGuide FeaturingArtist example

[Aaron Cooper]

On 22-Apr-08, at 7:06 PM, Brian Schweitzer wrote:
> When we had the lengthy debate about keeping this type of info in  
> release titles, the two convincing arguments to those of us who  
> wanted to see it completely removed there as well were:
> 1) ARs don't show in toc-add view, and facing 150 12-track releases  
> identified solely as "Requiem" was far from ideal, and
> 2) We don't yet have a way to search for release title + ARs on the  
> release pairs; keeping the info in the release titles for the time  
> being allows this type of searching, until the system can handle  
> such combinatory searching.
>
> I'm sorry, but I just don't see either as applying to track titles,  
> and I don't think we ought to be even further extending already  
> overlong classical titles by putting data into them that ought to be  
> in the AR fields that exist for that data, just because some  
> software or devices doesn't support tag fields which have existed at  
> least since ID3v2.2 came out in 1998, ten years ago:
>
> 4.2.1 TCM Composer
> 4.2.1 TOA Original artist(s)/performer(s)
> 4.2.1 TOL Original Lyricist(s)/text writer(s)
> 4.2.1 TP1 Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group
> 4.2.1 TP2 Band/Orchestra/Accompaniment
> 4.2.1 TP3 Conductor/Performer refinement
> 4.2.1 TXT Lyricist/text writer

If Track ARs are used, I believe they will be visible when selecting  
releases for TOCs.

Searching is still an issue, but we could have a number of solutions  
to this problem (One possibility is to use performers as release  
artists... another would be to change search to include ARs).

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: ClassicalStyleGuide FeaturingArtist example

[Aaron Cooper]

On 22-Apr-08, at 6:56 PM, Andrew Conkling wrote:
> On Tue, Apr 22, 2008 at 6:31 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
> How about we don't add any of this information to the track titles and
> just use Advanced Relationships?
>
> This seems to be what a lot of editors are suggesting, but that  
> seems to be suggesting to be GettingRidOfFeaturingArtistStyle (yes,  
> there's a page for that), which doesn't seem to be going away. At  
> least, I'm not going to tackle that RFC!
>
> So in the meantime, I thought I'd take a concrete example of where  
> the ClassicalStyleGuide seems to deviate from other guidelines and  
> clarify it to help editors of only/mainly classical remember that  
> there's a bigger world out there. I know I've been reminded of that  
> a time or ten. ;)

Perhaps symphonick's suggestion to bring CSG in line with regular  
guidelines would be best then:

symphonick said:
 >Why not stick to the usual FeaturingArtist guideline? If the tracklist
 >really says "Dies irae (feat. Tina Turner)" then fine, use it. If not
 >-> AR


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: ClassicalStyleGuide FeaturingArtist example

[Aaron Cooper]

On 22-Apr-08, at 6:22 PM, Andrew Conkling wrote:
> Currently, the ClassicalStyleGuide reads (excerpted):
> Track Title"If a track has a soloist then add it using  
> FeaturingArtistStyle: (feat. violin: Tamsin Little). If all tracks  
> on the release feature a performer/group/conductor, this information  
> is added to the release title only, and not repeated on every track.
> Examples:
>
>   •
> The Lark Ascending (feat. violin: Tasmin Little)
>
>   •
> Tasmin Little performed only this track on the release, therefore  
> the performer information has to be added to this specific TrackTitle.
>
>
> It seems to come time and again that this isn't how releases should  
> actually be edited (most recently: 
> http://musicbrainz.org/show/edit/?editid=8614418) 
>  and it's also come up on ClassicalStyleGuideDiscussion 
> (http://tinyurl.com/52xaal 
> ).
>
> The only case for preserving information of this type in the track  
> title seems to be for searchability based on performer in less-than- 
> awesome media players. (There may be other cases in the history of  
> this discussion, but I don't know them.) I used to take this side  
> staunchly, but the more I think of it now, the more I can see why  
> this isn't such a good idea.
>
> I think a lot of editors would love to see this scrapped, but I tend  
> to think that FeaturingArtistStyle is fairly clear, even if it has a  
> complicated history of its own, so I don't think we can scrap this  
> altogether. I do have a more narrow amendation, which is ultimately  
> just a clarification of how this guideline interacts with  
> FeaturingArtistStyle, and also how it seems to be read by most  
> editors:
>
> "If a track has a soloist then add it using FeaturingArtistStyle:  
> (feat. violin: Tamsin Little). This should not be used for ensembles  
> or conductors, only for soloists." (italics only for emphasis on  
> what is added)
>
> A small addition, but I'm sure the ensuing discussion will be  
> juicy. :)

How about we don't add any of this information to the track titles and  
just use Advanced Relationships?

I would like to see us drop the performer info in the release titles,  
too, but one step at a time I suppose...

-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Lyricists on instrumental performances

[Aaron Cooper]

On 14-Apr-08, at 3:25 PM, Brian Schweitzer wrote:
> On Sun, Apr 13, 2008 at 7:05 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
>> On 13-Apr-08, at 6:57 PM, Paul C. Bryan wrote:
>>> On Sun, 2008-04-13 at 16:28 -0400, Aaron Cooper wrote:
>>>> It doesn't make much sense to me to put a Lyrics AR on a track
>>>> without
>>>> lyrics/vocals.
>>>
>>> Would you leave them off altogether, or credit them as composers? If
>>> not
>>> credit as composers, then I think I should reconcile two issues:
>>>
>>> 1. They affected the composition by (at least) affecting note
>>> durations.
>>> Does this make them some kind of co-composer of the work?
>>>
>>> 2. They're credited on the instrumental performance, and I should
>>> justify omitting them from MB AR credits.
>>
>> I don't think a composition AR would be appropriate either.  For now,
>> I think we should live with leaving the lyricist AR off until we have
>> works, etc.  I'm not exactly sure how it will work... probably
>> different recorded versions of works (instrumentals, demos, live
>> recordings, acoustic recordings, etc.)
>
> I agree - including lyricist ARs on works without lyrics doesn't make
> a lot of sense.  As for works and lyrics, I don't know if we really
> need to split live/accoustic/etc, where the work itself isn't altered;
> that would seem a step down, at the (nowhere near implementation)
> "session" level, as it describes some particular performance version
> of a work, not something intrinsic to the work itself.
>
> Otherwise, we'll end up with separated works again when, say, someone
> takes that work for piano and performs a flute trio version.  ...Or
> maybe we want that?  (Or maybe it indicates a need for yet one further
> level between "work" and "session"?)

I meant many different recorded versions of one work.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Lyricists on instrumental performances

[Aaron Cooper]

On 13-Apr-08, at 6:57 PM, Paul C. Bryan wrote:
> On Sun, 2008-04-13 at 16:28 -0400, Aaron Cooper wrote:
>> It doesn't make much sense to me to put a Lyrics AR on a track  
>> without
>> lyrics/vocals.
>
> Would you leave them off altogether, or credit them as composers? If  
> not
> credit as composers, then I think I should reconcile two issues:
>
> 1. They affected the composition by (at least) affecting note  
> durations.
> Does this make them some kind of co-composer of the work?
>
> 2. They're credited on the instrumental performance, and I should
> justify omitting them from MB AR credits.

I don't think a composition AR would be appropriate either.  For now,  
I think we should live with leaving the lyricist AR off until we have  
works, etc.  I'm not exactly sure how it will work... probably  
different recorded versions of works (instrumentals, demos, live  
recordings, acoustic recordings, etc.)

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Lyricists on instrumental performances

[Aaron Cooper]

On 13-Apr-08, at 3:14 PM, Paul C. Bryan wrote:
> On Sun, 2008-04-13 at 14:24 -0400, Aaron Cooper wrote:
>
>> Quick response:  This would be a lot nicer to solve if we had WORKs
>> where we could put the Composition and Lyrics ARs.  Then when we  
>> see a
>> TRACK of that WORK without a Vocal performance AR we can assume it is
>> instrumental.
>
> Agreed. I look forward to WORKs. Meanwhile, I'd leaning towards it  
> being
> correct to credit lyricists as lyricists and not as composers in the
> case of instrumental performances.

It doesn't make much sense to me to put a Lyrics AR on a track without  
lyrics/vocals.

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Lyricists on instrumental performances

[Aaron Cooper]

On 13-Apr-08, at 2:21 PM, Paul C. Bryan wrote:
> Dear MB-stylists:
>
> I am consistently coming across works that are being performed
> instrumentally, and where composers/lyricists are being credited  
> without
> indicating which is composer, which is lyricist. In many cases, I know
> (or can definitively conclude) who was composer and who lyricist.
>
> My question is, how should lyricists be credited on works that are
> performed instrumentally (which is common in jazz performances)? I am
> inclined to credit lyricists as lyricists, especially in light of the
> fact that we're heading towards works, which will definitely want to
> capture this.
>
> Currently, http://wiki.musicbrainz.org/CompositionRelationshipClass is
> not explicit on this case, and I'll volunteer to capture what is
> determined in this thread in the Wiki page.
>
> Thanks,
>
> Paul


Quick response:  This would be a lot nicer to solve if we had WORKs  
where we could put the Composition and Lyrics ARs.  Then when we see a  
TRACK of that WORK without a Vocal performance AR we can assume it is  
instrumental.

Cheers,
-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] L-t-E-P-W-L-V-P-f-a-R

[Aaron Cooper]

On 8-Apr-08, at 7:33 AM, Kuno Woudt wrote:
> On Tue, Apr 08, 2008 at 08:36:57AM +0200, Lauri Watts wrote:
>> I prefer to distinguish 'it exists' and 'it exists and is useful'.
>
> I agree with this.
>
> But, assuming most of those mozart pages are reasonably well written,
> they're probably useful to those people who don't have english as a
> native language.  I think this is mostly an interface issue, and we
> shouldn't reject useful wikipedia links because our interface to
> interact with them sucks.  (we should fix the interface :).

I don't think someone who doesn't know some English would get very far  
in MusicBrainz (the site is entirely in English!)

At this point in time I don't really see a need for other languaged  
Wiki pages (except maybe that of the artist's native language).

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] L-t-E-P-W-L-V-P-f-a-R

[Aaron Cooper]

On 8-Apr-08, at 1:41 AM, Paul C. Bryan wrote:
> Hi all:
>
> I'm beginning to see more redundant Wikipedia links in various  
> languages
> in MB, and as I've seen voting in both directions when faced with such
> AR adds, I'm seeking to clarify what may become a reasonable policy  
> for
> Wikipedia ARs in MB.
>
> Perhaps to illustrate what I consider the worst case scenario I am  
> aware
> of, will all due respect to Brian,
> http://musicbrainz.org/show/artist/relationships.html?artistid=11285
> seems like the example of Wikipedia-links-run-amok in MB.
>
> I see there's a (slightly stale) policy under discussion in
> http://wiki.musicbrainz.org/WikipediaRelationshipType. If you believe
> it's more appropriate to host the discussion there, let me know.
>
> There are two options that seem to be generally considered  
> reasonable by
> various editors within MB:
>
> 1. Link to the Wikipedia language choice that is most appropriate,
> typically the language that is associated with the release. This  
> doesn't
> work so well for artists. If this option was accepted, I presume we
> should establish a Wikipedia AR addition policy.
>
> 2. Link to Every Possible Wikipedia Language Page for a Release (hence
> the title of this message). This results in a worst case scenario
> outlined above. If this option was accepted, I would propose we  
> develop
> an enhancement to the MB user interface to render the potential  
> reams of
> Wikipedia links in a more intuitive manner.
>
> At the moment, I don't consider this to be a burning issue for the MB
> community; it's something that, as I'm voting on edits, I am just
> becoming aware of. At the very least, your advice can help me decide
> whether I am a yes, no or abstain voter when I come across these types
> of edits.

I don't think the relationships are "wrong" so I'd have a hard time  
voting "No" but at the same time there is a lot of Wiki links on  
Mozart's page that I don't care to ever see.  Perhaps we need a  
language preference to hide all Wiki links other than your preferred  
language(s)?

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Change BoxSetNameStyle

[Aaron Cooper]

On 27-Mar-08, at 1:15 PM, Frederic Da Vitoria wrote:

> On Thu, Mar 27, 2008 at 5:58 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
> On 27-Mar-08, at 12:47 PM, Frederic Da Vitoria wrote:
> > I find very tiring to have to re-explain things, so I'll only ask
> > you to re-read some of my previous posts in this thread if you want
> > to understand why I don't like the idea of deregulating everything.
> > My reasons have not changed, I still don't like the idea of
> > accepting bundles. We don't even have any way to know if the PUIDs
> > sent to MB belong to a bundle or not, since the TOCs are identical.
>
> > If a user enters an AR to a bundled release, I'd very much like this
> > AR to appear in the stand alone release too, and I'd rather not wait
> > until NGS for this! Merging releases is the best way to ensure this.
> > If there are fewer releases, we increase the chances of completeness
> > of each of them. Granted, NGS will probably merge the ARs. But this
> > may not happen before a few years.
>
> We have a *lot* of duplication already thanks to different versions of
> the same album being released (standard, Japanese bonus tracks, UK-
> bonus tracks, online-only bonus tracks, remastered edition with
> outtakes, etc).  We are missing ARs on these already, adding box sets
> isn't going to make it any worse, as far as I'm concerned.
>
> I don't know when NGS is coming or if it ever will, but certainly we
> will not be making the AR situation any worse than it already is.
> Just think about recordings... we have thousands and thousands of
> tracks that have been released multiple times on compilations, albums,
> etc.  How many of these have correct ARs?  Maybe one if someone cared
> enough to enter the composition/production ARs on the earliest
> released track.  Our AR situation is *not good* and we will not see
> significant improvement until we group works/recordings/etc.
>
> I believe duplication is not so frequent in classical. So for  
> classical, the loss will be quite measurable IMO. In other kinds of  
> music, I agree it may not make a huge difference. But it is  
> classical I am most interested in.

Well, I don't know about that... Classical recordings can be reissued  
just like "pop" recordings.  The state of classical in MB is much  
worse (IMO) than "pop" artists so I think it would be easier for us to  
think that we don't have as much duplication.  We are missing a lot of  
performance ARs on classical stuff and I know from my own experience I  
don't often look at performer discographies to see if there is  
duplication.

I guess we don't see 180-disc box sets for "pop" artists though.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Change BoxSetNameStyle

[Aaron Cooper]

On 27-Mar-08, at 12:47 PM, Frederic Da Vitoria wrote:
> I find very tiring to have to re-explain things, so I'll only ask  
> you to re-read some of my previous posts in this thread if you want  
> to understand why I don't like the idea of deregulating everything.  
> My reasons have not changed, I still don't like the idea of  
> accepting bundles. We don't even have any way to know if the PUIDs  
> sent to MB belong to a bundle or not, since the TOCs are identical.

> If a user enters an AR to a bundled release, I'd very much like this  
> AR to appear in the stand alone release too, and I'd rather not wait  
> until NGS for this! Merging releases is the best way to ensure this.  
> If there are fewer releases, we increase the chances of completeness  
> of each of them. Granted, NGS will probably merge the ARs. But this  
> may not happen before a few years.

We have a *lot* of duplication already thanks to different versions of  
the same album being released (standard, Japanese bonus tracks, UK- 
bonus tracks, online-only bonus tracks, remastered edition with  
outtakes, etc).  We are missing ARs on these already, adding box sets  
isn't going to make it any worse, as far as I'm concerned.

I don't know when NGS is coming or if it ever will, but certainly we  
will not be making the AR situation any worse than it already is.   
Just think about recordings... we have thousands and thousands of  
tracks that have been released multiple times on compilations, albums,  
etc.  How many of these have correct ARs?  Maybe one if someone cared  
enough to enter the composition/production ARs on the earliest  
released track.  Our AR situation is *not good* and we will not see  
significant improvement until we group works/recordings/etc.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Change BoxSetNameStyle

[Aaron Cooper]

On 27-Mar-08, at 2:25 AM, Brian Schweitzer wrote:

> On Wed, Mar 26, 2008 at 8:35 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
>>
>> On 26-Mar-08, at 8:19 AM, Brian Schweitzer wrote:
>>> Aaron's suggestion a month ago still makes quite some
>>> sense to me.
>>
>> This discussion has gotten so overblown that I don't even remember
>> what this suggestion was!  Any chance you could restate it for us? :)
>
> "Live and let live".  :)  Let the unboxed and the boxed versions both
> exist as separate releases.

Ah!  I think I've seen a few people who seem to be supporting this  
idea (only name that comes to mind is Lauri).

Can't we just take this approach and deal with the corner cases as  
they show up?  Also, I assume one day we'd be able to group the  
releases somehow with NGS to get rid of the duplication.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Change BoxSetNameStyle

[Aaron Cooper]

On 26-Mar-08, at 8:19 AM, Brian Schweitzer wrote:
> Aaron's suggestion a month ago still makes quite some
> sense to me.

This discussion has gotten so overblown that I don't even remember  
what this suggestion was!  Any chance you could restate it for us? :)

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Change BoxSetNameStyle

[Aaron Cooper]

On 25-Mar-08, at 8:09 AM, Frederic Da Vitoria wrote:

> On Tue, Mar 25, 2008 at 12:00 PM, Lauri Watts <[EMAIL PROTECTED]>  
> wrote:
> On Tue, Mar 25, 2008 at 10:55 AM, Frederic Da Vitoria
> <[EMAIL PROTECTED]> wrote:
> > On Mon, Mar 24, 2008 at 10:46 PM, Lauri Watts  
> <[EMAIL PROTECTED]> wrote:
> >
> > > Sometimes it
> > > makes no sense to use any single title style on those, but  
> sometimes
> > > the contents get new cover art, or disc number designations they
> > > didn't originally have, and in those cases,   I don't see what  
> the big
> > > problem is in having duplicating them, so both sides get what they
> > > want.
> >
> > Ha! It happened even before I expected!
>
> I've been saying this from the start.  I don't know 'what happened',
> feel free to explain.
>
> I don't think every one can be happy at the same time. I think that  
> is why there are freedb, discogs and MB. None of these can have  
> everyone happy and each has it's use. I am certainly not saying any  
> of these is bad. We use freedb and discogs, which is proof they have  
> their merits. But I believe all these exist at the same time partly  
> because each answers a specific and different need. The taggers are  
> often happy with freedb, the collectors with discogs. I am not a  
> frenetic tagger (I know what I own well enough that I don't mind a  
> few mistakes in the tags), and I am certainly not a collector (if I  
> don't like a release, I certainly won't buy it because I have all  
> other releases from the same artist). What I am interested in is the  
> general music database part. The more we work for the taggers or the  
> collectors, the more we walk on freedb's or discogs' toes, the less  
> we are original, the less we work towards the general music database.

> It's a question of balance. We all know we don't have infinite  
> resources, development-wise or voting-wise. We are already  
> complaining we don't have enough voters, multiplying the number of  
> releases is not going to improve things. And in this time when music  
> companies have problems explaining why they are not increasing their  
> market parts, the number of fake re-releases is bound to increase.  
> If you can't sell something new, sell something old as if it was  
> new. This has been increasing for a few years now, and I don't see  
> why it would not go on. So we are going to have re-releases with new  
> art, new liner notes, new CD engraving, new box... But once in the  
> CD player, most of the times, it will be exactly the same. And I  
> mean the same, not only it will sound the same, it will BE the same.
>
> So not only I don't see the any use in going in that direction (once  
> again, I believe discogs is better suited and does it much more  
> systematically) but I don't like this direction. In other threads, I  
> suggested that if we went in this direction, MusicBrainz should be  
> renamed to CDBrainz. Or MajorBrainz. Of course, I was only teasing,  
> but I hope you see what I was meaning. IMO, Music is not in the  
> commercial decisions of the majors. It is not in the fact that a CD  
> was released 3 days later in this or that country. It is not in the  
> cover art (although cover art is sometimes art, but not music). Of  
> course, all these things are related to music. Bach and Mozart had  
> to eat, and this often had a major influence on their music. But it  
> is not my main interest, I don't want it in my way when I am  
> listening to music, and I feel that if we went that way, the "Music"  
> in MusicBrainz would become a kind of misnomer.


I think our problem is that MB's database is release-centric.  This  
forces us to have these BoxSet marathon discussions and be concerned  
with releases rather than "songs" or "works".  Do we really care what  
physical (or digital) album a song comes from?  Of course we do for  
cover art and so there's something in our "Album" ID3 tag and so we  
can relate songs together that were released together... but wouldn't  
it would be better if we just had one recording of a song and then it  
had 15 album names associated with it so if we felt like listening to  
a greatest hits package it would be included there and then if we felt  
like listening to the original copy on an album we could listen to it  
there in that context as well.  The thing is, albums aren't the only  
way music is distributed (especially thanks to the internet and single- 
song purchases).

For many styles of music that have found a home in the MB database  
(OCR, video game music, classical, etc.) it would be a lot easier if  
we took a work-centric approach.

I think we'd have an easier time creating a "general music database"  
if we made songs/works our focus rather than releases, cover art,  
liner notes, etc.

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/mus

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 23-Mar-08, at 3:07 AM, David K. Gasaway wrote:

> On 22 Mar 2008 at 23:23, David K. Gasaway wrote:
>
>> Let me be more be more clear: The links to the sample data I posted  
>> were
>> a test for the ideas (suggested by Aaron) that the wiki pages could  
>> be
>> used to address questions raised by me regarding translation,
>> organization, and the like.
>
> D'oh!  Upon review, I see it was primarily Frederic's idea.  Sorry,
> Frederic and Aaron!

I was going to say... "I don't remember proposing that idea!"  :)

No worries.

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Bach passions and CSG

[Aaron Cooper]

On 20-Mar-08, at 7:17 PM, Leiv Hellebo wrote:

> Hi list,
>
> Easter time is Bach passion time for me - especially since the flu
> prevents my family from going skiing :(
>
> So, I just spent the last hours adding a new recording of the St.
> Matthew Passion.
>
> This has 101 tracks played in about 161 minutes, and 25 tracks are  
> less
> than half a minute, 13 last for less than 15 seconds. Because of this,
> it's imperative that the most important parts of the movement title
> sticks out properly from the track titles.
>
> So, I thought, how can this best be done?
>
> I ended following the booklet, and the tags provided by the label  
> (it's
> a download). In the process I radically downplayed the common stuff  
> that
> we pad the titles with (work names and part indication), and ended  
> up with:
>
> http://musicbrainz.org/release/92fa1794-7a7e-48cd-a322-10a5def12cf1.html
>
> (reference: http://www.linnrecords.com/recording-matthew-passion.aspx)
>
> Now I don't want to start another quarrel, and I didn't really want to
> start another discussion on keeping out the WorkName from titles just
> yet, but I had time to add this now, so
>
> thoughts?

I think it's missing a lot of important information like the stuff  
from OperaTrackStyle.  Because classical stuff is released on CDs and  
not as "works" I think work info is necessary in track titles (as does  
the CSG).  If we just had a "Symphony No. 5 in C minor" work-release,  
then we wouldn't really need to put "Symphony No. 5 in C minor" in  
each track title–but we don't so we have to ;)

I think these titles should be at least:

Matthew Passion, BWV 244: Choral "Herzliebster Jesu, was hast du  
verbrochen"
Matthew Passion, BWV 244: "Da das Jesus merkete" (Evangelista, Jesus)
etc.

Copying directly from http://wiki.musicbrainz.org/CSGStandard/JSBach  
would make things a lot better, too.

-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Band name changes (was [mb-devel] Panic! at the Disco)

[Aaron Cooper]

On 19-Mar-08, at 12:57 PM, Lauri Watts wrote:

> On Wed, Mar 19, 2008 at 4:06 PM, Bram van Dijk
> <[EMAIL PROTECTED]> wrote:
>> Well, http://www.aelius.com/njh/tmp/musicbrainz_summit8_schema.pdf
>> seems to indicate that we will (eventually) get something like  
>> Discogs'
>> ANV system.
>>
>> But I agree that until then, it may be better  to keep the releases
>> together.
>
> I actually think the opposite: Until we can indicate which is by which
> name when they're on the same page, it's better to keep them separate.
>
> Untangling which release has which name from all those compilations
> alone, is going to be a nightmare for some of these artists.  If we
> kept them separate now, but AR'ed, users could still follow the trail,
> albeit not as easily as if they were all on one page, and we aren't
> setting up yet another pile of rather tedious work once NGS is
> available.

Just want to say that as much as I want to see all releases by a band  
that has changed names under one "roof", I agree with what Lauri has  
said here - we need to keep them under their "correct" names and get  
an AR in place.  Once we have those ARs connecting the two names, we  
can make changes to the website to show all albums.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 11-Mar-08, at 11:54 AM, Frederic Da Vitoria wrote:

> On Tue, Mar 11, 2008 at 4:27 PM, Brian Schweitzer <[EMAIL PROTECTED] 
> > wrote:
> On Tue, Mar 11, 2008 at 9:01 AM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
> >  I would have thought this:
> >
> >
> >  Track is an instance of TrackMaster
> >  TrackMaster is a recording of Session
> >  Session is a performance of Work
>
> That makes sense to me.  So if we're soon to have track masters, and
> sooner to have works, but also planning to eventually have sessions in
> the long term, what AR are we then going to use, near term, to link
> tracks directly to works, and how would that change when track masters
> are added in, before sessions are added in to complete the structure?
> One/two of those 3, or some other temporary AR that we eventually
> depricate as the full entity structure becomes available?
>
> I suggest we use the temporary AR, because this AR is equivalent to  
> a shortcut to the full series of 3 future ARs and when the full  
> structure is implemented, I believe we will be happy we are able to  
> separate true fully detailed ARs from our current temporary ones.  
> Maybe this temporary AR is even going to stay because we will not  
> always be able to find the master or the session, and inputting the  
> 3-steps AR will then be impossible.
>
>
> Also, to add to that list, too, I'd add in the current three (four)  
> ARs:
>
> Work is the earliest version of work
> Track is the earliest release of ???
> Work is a parody of work
> Track is a cover of work
>
> For the earliest release of AR, would a track be the earliest release
> of a track, of a track master, of a session or of a work?  Or perhaps
> it's really three different concepts - a track as the earliest release
> of a track master, a track master as the earliest released recording
> of a session, and a session as the earliest performance of a work?
>
> For the last one of these four, under a structure which contains a
> work concept, do we then even have a need for a special cover AR?
> Isn't a track instance / track master / session of a work by
> definition a cover, if the track artist and the work artist are not
> the same?
>
> Are the "earliest" ARs such good ideas? If someone discovers there  
> was actually an earlier something, we could forget to remove the  
> older incorrect AR. Couldn't we just use dates? The "earliest" AR  
> could be easily deduced by the system by comparing them.

I don't like "earliest" ARs either.  It's going to be extremely  
difficult tracking down this sort of performance information and  
recording information even for popular and well-documented/well- 
followed bands like Metallica.  Even though we have extensive bootleg/ 
concert/tour information, are we sure that it is complete?  Can we say  
that a particular performance is the earliest?  I don't think we can  
do that with much accuracy.

I'd rather we say things like:

WORK is a {acoustic | live | demo | unfinished | etc} version of WORK
TRACK is a release of TRACKMASTER
WORK is a parody of WORK

I'm not sure about the cover AR though.  Doesn't seem write to link it  
to a track.  Maybe a performance?  Or maybe we need "works" in the  
cases of covers then we can keep the works linked together with the  
Cover AR and not have to link every single track or performance to the  
original.

Just some thoughts,
-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 11-Mar-08, at 8:00 AM, Mike Morrison wrote:

>
> On Tue, 11 Mar 2008, Brian Schweitzer wrote:
>> The only objection I recall is the wording of the AR for works lists
>> to tracks.  Personally, it may sound overly academic, but I prefer  
>> "is
>> an instance of" over "contains a recording of", if only because I
>> think, if/when we do add sessions as the NGS entities between track
>> masters and work lists, I think we'd want to save that particular
>> 'contains a recording of' wording for the AR we'd then use to link  
>> the
>> session to the work list.  Can anyone suggest any other alternate
>> wording, besides 'an instance of', which wouldn't cause us confusion
>> with track masters or sessions later down the line?
>>
>> Brian
>
> Just so I understand, if/when we have sessions, what would be the AR
> wording? Would the chain go something like this?
>
> Track is an instance of Track Master
> Track Master is a  of Session
> Session contains a recording of Work

I would have thought this:

Track is an instance of TrackMaster
TrackMaster is a recording of Session
Session is a performance of Work

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 5-Mar-08, at 5:07 PM, Brian Schweitzer wrote:

> On Wed, Mar 5, 2008 at 4:41 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
>>
>> On 5-Mar-08, at 4:35 PM, David K. Gasaway wrote:
>>
>>> Brian Schweitzer wrote:
>>>
>>>> Thus, actually, why I'd opposed the implementation of the parody AR
>>>> as
>>>> an attribute to the cover AR.  The cover AR is distinctly a "song
>>>> instance"-"work listing" AR, linking from one artist's recording  
>>>> back
>>>> to another artist's work listing.
>>>
>>> I didn't get a clear picture of how you would enter a cover.  Would
>>> the covering artist have an entry in the works list for the cover
>>> will an AR to the composition?  If not, I don't think it's fair to
>>> say that a cover is necessarily a cover of a composition.  It could
>>> be a cover of a specific performance (i.e., specific variation in
>>> lyrics, instrumentation, rhythm, or whatever else you could  
>>> imagine).
>>
>> The picture I see is both artists having a work in their worklists
>> with one linked to the other with a Cover AR.  The original
>> composition will also have Composition/Lyrics/Arranged/etc ARs but  
>> not
>> the cover version.
>
> I guess it depends on how we define "work".  Is a "work" a unique
> composition?  If so, then there ought to not be, imho, a listing also
> in the covering artist's workslist.  Or is a "work" simply an
> indication that an artist has played a song?  Then it would appear in
> that covering artist's workslist.
>
> Personally, I think the first is the cleaner - and better - solution.

Now that you mention it, I agree.  Things would get very ugly very  
quickly if we listed covers under both artists.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 5-Mar-08, at 4:35 PM, David K. Gasaway wrote:

> Brian Schweitzer wrote:
>
>> Thus, actually, why I'd opposed the implementation of the parody AR  
>> as
>> an attribute to the cover AR.  The cover AR is distinctly a "song
>> instance"-"work listing" AR, linking from one artist's recording back
>> to another artist's work listing.
>
> I didn't get a clear picture of how you would enter a cover.  Would  
> the covering artist have an entry in the works list for the cover  
> will an AR to the composition?  If not, I don't think it's fair to  
> say that a cover is necessarily a cover of a composition.  It could  
> be a cover of a specific performance (i.e., specific variation in  
> lyrics, instrumentation, rhythm, or whatever else you could imagine).

The picture I see is both artists having a work in their worklists  
with one linked to the other with a Cover AR.  The original  
composition will also have Composition/Lyrics/Arranged/etc ARs but not  
the cover version.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 4-Mar-08, at 11:09 PM, David K. Gasaway wrote:

> On 3 Mar 2008 at 9:25, Frederic Da Vitoria wrote:
>
>> I suggest we could create each work in more than one language, as the
>> need arises.
>
> The only concern I would have is organizing the lists to keep them
> managable.  If we can make your wiki idea workable (where we could  
> have
> one page per language, say), then that's fine.
>
> Here's an idea.  To see if we can really make this work, perhaps
> someone could batch a modest work list into a NAT list on the test
> server and let folks bang at it.

I've loaded Beethoven's first 6 opuses at 
http://test.musicbrainz.org/release/8ffd2068-a872-49b4-80f8-c4ce0a0f1b19.html

The artist is "Beethoven NAT-WorkLists" so that we could have a fresh  
NAT album.

One thing I've noticed is that we cannot create ARs to multitple works  
at once.  A small annoyance since we'll only be doing it once anyways.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 4-Mar-08, at 8:02 AM, Andrew Conkling wrote:

> On Tue, Mar 4, 2008 at 7:24 AM, Frederic Da Vitoria <[EMAIL PROTECTED] 
> > wrote:
> On Tue, Mar 4, 2008 at 1:14 PM, Aaron Cooper <[EMAIL PROTECTED]>  
> wrote:
>
> On 4-Mar-08, at 4:48 AM, Leiv Hellebo wrote:
>
> > Aaron Cooper wrote:
> > On the topic of languages, I think we should try to pick one
> >> language per composer  (as we've done with the wiki works lists)
> >
> > One language per work in Works lists sounds good. If the composer  
> e.g.
> > lived abroad and used another language during that period, it's to  
> be
> > expected that different languages might be best.
> >
> >
> > do
> >> reduce the duplication.
> >>
> >
> >
> > If you're talking about removing/merging releases with track
> > listings in
> > different languages, then I see no need to reduce duplication:  
> They're
> > not dupes.
>
> I meant duplication in the works lists.  But I do think that releases
> with identical music recordings but different title languages are
> duplicates because they duplicate ARs, they duplicate release dates,
> they duplicate the work to manage titles..
>
> I agree they are duplicates, but I believe we will have to wait  
> until the MB database evolves more before solving this problem.  I  
> think NGS specifically addresses this issue.
>
> Not that I disagree with what's being mentioned here, but can we  
> table this for now? This isn't really part of the RFC and is a huge  
> can of worms. I think what's been happening--leave it up to the  
> discretion of the editor (who usually uses his own language and/or  
> (one of) the language(s) on the release) and create pseudo-/ 
> transl*ation releases for other languages--has been working fine.
>
> If it hasn't been working fine, we can of course start discussing  
> it. But as mentioned on one of the other CSG-related threads  
> recently, this really isn't an issue specific to classical music (or  
> this RFC ;).

I think it is pretty classical-specific.  Pop songs are regularly  
referred to in their native language (I've seen/heard German  
broadcasters speak in German but say English song titles for Metallica  
broadcastings... "The Four Horsemen", etc).  I think Brian's term for  
many classical works was "titular" or "descriptive" but I wouldn't go  
so far as to call them UntitledTracks ;)

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 4-Mar-08, at 7:08 AM, Frederic Da Vitoria wrote:

> On Tue, Mar 4, 2008 at 12:26 PM, Leiv Hellebo  
> <[EMAIL PROTECTED]> wrote:
> Frederic Da Vitoria wrote:
> > On Tue, Mar 4, 2008 at 10:48 AM, Leiv Hellebo  
> <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Aaron Cooper wrote:
> > On the topic of languages, I think we should try to pick one
> >  > language per composer  (as we've done with the wiki works  
> lists)
> >
> > One language per work in Works lists sounds good. If the  
> composer e.g.
> > lived abroad and used another language during that period,  
> it's to be
> > expected that different languages might be best.
> >
> >
> > So Tchaikovsky in Cyrillic only? This is quite annoying. I love this
> > composer,
>
> hehe, I was listening to Viktoria Mullova playing his violin  
> concerto as
> this mail entered my inbox :)
>
>  but I don't intend to learn Cyrillic soon...
> >
>
> Sorry for the hasty formulation "one language per work sounds good", I
> don't have the solution to this problem. But my first thought is that
> Works ideally should be entered also in cyrillic. It might not be very
> practical, though.
>
> For tagging you should get most of what you need from the track  
> listing
> of your release. But we have a problem if strange characters in the
> Works make them difficult for editors to reliably find and use.
>
> Perhaps the opus numbers and other catalogue information can help?
>
> Yes, they could, provided the composer has a catalogue. Else, we  
> will have to set up some translation system soon. I agree the  
> original language makes the most sense, though. But sometimes, the  
> most logical choice is not the most user-friendly!

Do you think we might be able to set up automatic translation?  It  
wouldn't be too bad if we put a translation for each type of work  
(Cantata, Kantate, etc.) in a table with a LanguageId.  Keys could be  
translated pretty easily as far as I can see.  We don't normally  
change the form/tempo.  Is it safe to build titles using the same  
structure (see http://wiki.musicbrainz.org/BrianFreud/sandbox#CSGworkstructure) 
  across multiple languages?

I am not familiar with many, but I think generally German and English  
work titles look like they have the same structure.

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 4-Mar-08, at 4:48 AM, Leiv Hellebo wrote:

> Aaron Cooper wrote:
> On the topic of languages, I think we should try to pick one
>> language per composer  (as we've done with the wiki works lists)
>
> One language per work in Works lists sounds good. If the composer e.g.
> lived abroad and used another language during that period, it's to be
> expected that different languages might be best.
>
>
> do
>> reduce the duplication.
>>
>
>
> If you're talking about removing/merging releases with track  
> listings in
> different languages, then I see no need to reduce duplication: They're
> not dupes.

I meant duplication in the works lists.  But I do think that releases  
with identical music recordings but different title languages are  
duplicates because they duplicate ARs, they duplicate release dates,  
they duplicate the work to manage titles..

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 3-Mar-08, at 5:18 PM, symphonick wrote:

> 2008/3/3, Aaron Cooper <[EMAIL PROTECTED]>:
>>
>> On 3-Mar-08, at 4:34 PM, symphonick wrote:
>>
>>> 2008/3/2, Brian Schweitzer <[EMAIL PROTECTED]>:
>>>> Summary:
>>>> Proposal: Add pre-NGS works lists, change the intent of CSG [snip]
>>>
>>> Interesting!
>>> I'm listing 3 movements as they appear on the cover ("real"  
>>> examples).
>>> Can you, for every mvt, list:
>>> a) the "tracktitle"
>>> b) the "worklist/NGS"-title
>>> Just to get the big picture, we can argue about details later :-)
>>>
>>> Ex. 1:
>>> Sonate e partite per Violino Solo
>>> Disco 1
>>> Sonata n. 1 BWV 1001, in sol minore.
>>> ---
>> Work: Sonata for Violin No. 1 in G minor, BWV 1001: {movement #}.
>> {movement tempo}
>> - I don't know where the movement name is here...
>> Title: I'd really have to see the cover I guess, I can't interpret
>> that information.
>>
> Ah, it's one track for the whole sonata here.

Oh well, then I'd link the track to all 3 (or 4) movements of the  
sonata work and the title would just be "Sonate n. 1 BWV 1001, in sol  
minore" I guess.

>
>
>>
>>> Ex. 2:
>>> Konzert für Klavier, Violine, Violoncello und Orchester C-dur op. 56
>>>>> Tripelkonzert<<
>>> Concerto for Piano, Violin, Violoncello amd Orchestra in C major,  
>>> Op.
>>> 56 >>Tripel Concerto<<
>>> Concerto pour piano, violon, violoncelle et orchestre en ut majeur,
>>> op. 56 <>
>>> 2. Satz: Largo
>>> ---
>>
>> Work: Concerto for Piano, Violin, Cello, and Orchestra in C major,  
>> Op.
>> 56 "Triple Concerto": II. Satz. Largo
>> - (I don't know what "Satz" means though)
> "movement"
>
>
>> Title: "Concerto for Piano, Violin, Violoncello amd Orchestra in C
>> major, Op. 56 <> - ...and I throw up at the idea of that being in someone's track  
>> title
>> field.
> :) Well, it's exactly what's written on the cover... BTW why did you
> choose English for the first half?

Because it was easier for me to write it out in English than try in  
German.  On the topic of languages, I think we should try to pick one  
language per composer (as we've done with the wiki works lists) do  
reduce the duplication.

-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 3-Mar-08, at 4:34 PM, symphonick wrote:

> 2008/3/2, Brian Schweitzer <[EMAIL PROTECTED]>:
>> Summary:
>> Proposal: Add pre-NGS works lists, change the intent of CSG [snip]
>
> Interesting!
> I'm listing 3 movements as they appear on the cover ("real" examples).
> Can you, for every mvt, list:
> a) the "tracktitle"
> b) the "worklist/NGS"-title
> Just to get the big picture, we can argue about details later :-)
>
> Ex. 1:
> Sonate e partite per Violino Solo
> Disco 1
> Sonata n. 1 BWV 1001, in sol minore.
> ---
Work: Sonata for Violin No. 1 in G minor, BWV 1001: {movement #}.  
{movement tempo}
  - I don't know where the movement name is here...
Title: I'd really have to see the cover I guess, I can't interpret  
that information.


> Ex. 2:
> Konzert für Klavier, Violine, Violoncello und Orchester C-dur op. 56
>>> Tripelkonzert<<
> Concerto for Piano, Violin, Violoncello amd Orchestra in C major, Op.
> 56 >>Tripel Concerto<<
> Concerto pour piano, violon, violoncelle et orchestre en ut majeur,
> op. 56 <>
> 2. Satz: Largo
> ---

Work: Concerto for Piano, Violin, Cello, and Orchestra in C major, Op.  
56 "Triple Concerto": II. Satz. Largo
- (I don't know what "Satz" means though)
Title: "Concerto for Piano, Violin, Violoncello amd Orchestra in C  
major, Op. 56 < Ex. 3:
> КОНЦЕРТ
> ДЛЯ СКРИПКИ И ВИОЛОНЧЕЛИ
> С ОРКЕСТРОМ
> ля мцнор, соч. 102
> 1. Allegro
Work: Concerto for Violin, Cello, and Orchestra in {the key}, Op. 102:  
I. Allegro
Title: Again, I can't parse that info (I can just copy and paste to  
translate.google.com)

-Aaron (cooperaa)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 3-Mar-08, at 2:18 AM, David K. Gasaway wrote:

> On 2 Mar 2008 at 22:59, Frederic Da Vitoria wrote:
>
>> I guess we will have to create the appropriate work listing. So an
>> actual work (in the outside MB sense) may be represented by several
>> overlapping work listings.
>
> Let's see if I understand correctly.  If a movement is split across
> tracks, we will enter work list entries for the movement parts?  I
> think the theme and variation discussions earlier illustrate just how
> tricky this can be.  I've also encountered recordings where the tracks
> transitioned in a more-or-less arbitrary place.
>
> Also, I assume that we'll keep the full movement work list item - as
> opposed to requiring that a track AR to all of the movement parts in
> the case that the track is a single movement.  Which also means well
> need work list items for entire works - lots of recordings have
> sonatas, symphonies, etc. as single tracks.  Suddenly, we have a
> bloated list with lots of variations on the same work.  Ideas how to
> manage the bloat?

Enter only the movements (not complete works) and then we have the  
following situations:

1. A track with multiple movements linked to multiple works/movements  
(that's okay).
2. Several tracks comprising one movement all linked to a single work/ 
movement (that's okay, too)
3. A track with one movement linked to a single work/movement (that's  
perfect!)

-Aaron


___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Works lists (and other related changes then implied)

[Aaron Cooper]

On 2-Mar-08, at 9:11 AM, Frederic Da Vitoria wrote:
> On Sun, Mar 2, 2008 at 2:10 PM, Chad Wilson <[EMAIL PROTECTED]>  
> wrote:
> Will taggers be disabled from tagging against them somehow? How will  
> we
> vote on their addition/removal?



> I don't see what is scary here. A few technical issues should be  
> polished in order to make it work correctly, I agree, but even  
> before they are, it will still be an improvement:
> - no editing? then don't AR to it until you have the precise correct  
> work included.
> - if a tagger uses the work lists, so what? Even if someone inserts  
> a PUID on a work, the PUID will be obviously meaningless, that's  
> all. I agree this should not be possible, but preventing it could be  
> done later. Until then, all the users who will have done the mistake  
> (there should not be many of them anyhow) won't have broken anything.
> - I fail to see how defining the style guidelines for the work lists  
> would be more difficult than the current CSG!
> - this is not really a CSG proposal, since as Brian wrote, the  
> actual track titles would be entered as they are printed. It would  
> even restrict the CSG to the work list, thus allowing users who  
> don't know anything about classical and who don't really want to  
> learn it free to stay in blissful ignorance and still enter their  
> "classical" releases n MB!

I think we should disable PUID submissions to the WorkLists and keep  
the PUIDs associated only with recordings (tracks on releases).  As  
Brian mentioned, it makes sense to move composition/cover/etc ARs to  
the WorkLists while leaving production/recording/performance ARs on  
the recordings.

I also mentioned to Brian last night that it would be excellent if we  
could tag files against the WorkLists.  People who don't collect  
albums can tag their random files against the WorkLists and have clean  
Artist/Title tags.  If one of these people scan their files and  
generate PUIDs, assuming that the PUIDs are associated with tracks and  
the tracks are linked via "X is a recording of Y" AR to the WorkLists,  
they can grab WorkLists rather than the track titles (an option in  
Picard would be needed to choose WorkLists or Track Titles).

As mentioned tagging against the WorkLists would give classical  
editors who want full titles a way to do this with consistency.

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG compromise?

[Aaron Cooper]

On 1-Mar-08, at 2:16 PM, Brian Schweitzer wrote:



> So until that happy day of NGS support, how do we compromise?  How can
> we ensure that the data allows the BBC to identify the work from the
> track, allows Aaron and me to tag and not find the data "quite messy",
> allows Leivhe and David to tag and have complete but not "overly"
> complete data, and still allows Lauri and her mother-in-law to tag and
> have what she wants?  (Just using us as examples of general user-base
> opinions here.)



> If we're aiming for "as on the liner", which liner,
> which translation, and what still gets fixed - caps, typos, mislisted
> works, etc?  If we're aiming for CSG, how complete, which languages,
> and are we essentially admitting that classical track titles per
> liners are descriptions and not "titles" per say?  Where can we all
> compromise such that the (I think majority) who wants at least some
> structure in the titles isn't left waiting 1-2 years for NGS to
> replace CSG, plus all the quite likely years of editing work to
> actually implement it across our classical listings?

Proposition:

a) For "chillout classical" releases where tracks are titled "Andante"  
or "Allegro from Sonata No. 14" etc, enter the track titles in MB as  
they appear on the CD and follow regular MB guidelines 
(http://wiki.musicbrainz.org/PartNumberStyle 
, http://wiki.musicbrainz.org/SubTitleStyle, etc)

b) For "real classical" releases, use the CSGS lists for ease of  
entering the releases and consistency.

ProbIems with this?  People don't want long titles:
In the large majority of cases, very little "extra" information is  
added in the CSGStandard lists over and above of what is printed on  
CDs (as I mentioned in a previous email).  The rare and unusual works  
may have unusual track names, but oh well–how often do we listen to  
those rare and unusual works compared to the more popular works?   
Anyone who cares enough to listen to the rare works (and owns a copy!)  
probably wants the extra information in the titles anyways.

Thoughts?

-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG compromise?

[Aaron Cooper]

On 1-Mar-08, at 5:56 PM, Mike Morrison wrote:

>
> On Sat, 1 Mar 2008, Brian Schweitzer wrote:
> 
>> While there's perhaps some few 20th century classical composers
>> someone might be able to point to, one thing classical composer
>> generally have in common is that they didn't actually release LPs or
>> CDs - or NATs.  Perhaps it'd be simple to create a NAT-type of list
>> for use for works lists, I don't really know.  That would seem most
>> optimal.  But lacking that, could we not just use the NAT entry for
>> each classical composer to hold the works lists?  Create a new AR,
>> something like "is an instance of" to link release tracks to the NAT
>> tracks, store the CSG-style names in NATs and whatever the
>> liner-liking people like in the releases?  I'd think it'd be pretty
>> easy then to add an option to Picard/datafeed users/etc to allow them
>> to travel up to that NAT to get the CSG title.  Then we also can more
>> easily use the normal editing system, as well, to vet
>> corrections/changes within the NAT-work lists, with the goal of those
>> work lists being to make them the "complete" tiles.  When NGS comes
>> around, all the links and such already will be in place, we just
>> migrate them from the NAT listed track to a NGS entry for that work,
>> and (perhaps in some automated fashion which says "this NGS entry is
>> specifically the NAT entry we had over here") migrate those
>> work-instance links over to NGS?
>>
>> It would allow the dual track titles, it would satisfy both types of
>> data users, it would allow us now to start really working on
>> correcting noted typos and errors in work lists, and it would allow
>> us, likely 1-2 years ahead of time, to already start working on
>> linking instances back to work-masters.
>>
>> Brian
>
> I like this!

I don't think it's a bad idea either, but I'm generally not a fan of  
NATs.  Just throwing the idea out there... what about creating an  
album for each work?  Example:

Release Title: Trio for Piano, Violin, and Cello No. 1 in E-flat  
major, Op. 1 No. 1
#1 Track Title: I. Allegro
#2 Track Title: II. Adagio cantabile
#3 Track Title: III. Scherzo
#4 Track Title: IV. Finale. Presto

If we wanted ordered lists based on catalog number we could enter the  
release title as something like "Op. 1 No. 1: Trio for Piano, Violin,  
and Cello No. 1 in E-flat major".

Thoughts?

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG compromise?

[Aaron Cooper]

On 27-Feb-08, at 8:10 PM, Mike Morrison wrote:



OK, so once we have NGS everyone can have what they want, right?  
We'll have work titles and track titles. The work title can be full  
CSG(S), while the track title can be what's on the cover. So each  
track will have these two titles associated with it.


For now, how about if we use the track title field for one of the  
two titles, and annotations for the other? We need somewhere to  
store the "other" title for now anyway, right? I don't care which  
title goes in which spot. If the one I like better ends up in the  
annotations, I'll copy and paste it into my local files if need be.


Then when NGS is implemented, we can migrate the information from  
the annotations into the appropriate field.


I don't understand what we're discussing because classical works don't  
have "tracks" or "track titles"–they have "work titles".  A classical  
recording has tracks, but what do you use as the track titles?  As I  
gather from your email (and those of some other similar-minded  
editors) we want to put the "track title" in the "track title"  
field... so we look to the track listing on the CD... and we find  
"work titles" don't we? (serious question)


It's not like classical works have a work title (Symphony No. 5 in C  
minor, Op. 125: I. Allegro con brio) and then also a track title  
version.  The way we refer to that piece is with the work title unless  
we chop out the actual work name (Symphony No. 5 in C minor, Op. 125)  
and just write "I. Allegro con brio".


Are we debating whether we should copy from the CD "Symphony No. 5: I.  
Allegro con brio" or whether to add missing information to write  
"Symphony No. 5 in C minor, Op. 125: I. Allegro con brio"?


-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: Re: [mb-style] Musicbrainz-style Digest, Vol 34, Issue 86

[Aaron Cooper]

On Wed, Feb 27, 2008 at 1:00 PM, Lauri Watts <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 27, 2008 at 6:20 PM, Brian Schweitzer
>  >  And please, find me the consumer (I assume you mean taggers only,
>
>  Don't assume.

As much as I've tried to ignore some of your more asinine comments,
this one threw me over the edge.  This sort of thing contributes
absolutely nothing to the discussion and wastes all of our time.
Please let's try to leave our personal issues on the shelf when trying
to communicate on the mailing list...

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG Clean up - Let's have some action

[Aaron Cooper]

On 27-Feb-08, at 1:00 AM, Leiv Hellebo wrote:


Aaron Cooper wrote:

On 26-Feb-08, at 4:58 PM, Leiv Hellebo wrote:
Let me have a short go at it then: "If there is only one work on  
your
CD, and the WorkName is part of the ReleaseTitle, you don't have  
to

include the WorkName in the TrackTitles".


In my opinion, this wouldn't work


You might be right, but you're not explaining why it won't. What  
do you lose if the WorkName is not in the TrackTitle? Choose your  
own examples and show why we would want to avoid it :)
It won't work right now because the context for the track title "I.  
Allegro" will be ambiguous for the release "Symphonies Nos. 1, 2".   
If we had "work" groupings then I could see us separating this  
information.


Try again: "If there is *only one work on your CD*,..."


Aright, then I agree with the others who have said this would be a  
confusing exception.


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Don't read the C*S*G, smoke it!

[Aaron Cooper]

On 26-Feb-08, at 11:47 PM, Brian Schweitzer wrote:


If we can agree on this first chunk, let's move on to the next.

What do you think about doing it this way, Brian?

-Aaron


Sure; only reason I'd avoid doing it that way was to avoid a flood  
of RFCs.  :)


I'd would *much* rather wade through a flood of 1-liner RFCs than the  
CSG novels we've become accustomed to.  ;)


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG Clean up - Let's have some action

[Aaron Cooper]

On 26-Feb-08, at 4:58 PM, Leiv Hellebo wrote:


Aaron Cooper wrote:

On 26-Feb-08, at 7:58 AM, Frederic Da Vitoria wrote:

On Mon, Feb 25, 2008 at 9:04 PM, Leiv Hellebo wrote:
Let me have a short go at it then: "If there is only one work on  
your

CD, and the WorkName is part of the ReleaseTitle, you don't have to
include the WorkName in the TrackTitles".

Are you meaning this as a suggestion?


I've mentioned it a few times, so I've started playing with the  
idea, yes. (It might be a bad idea.) I didn't really want to discuss  
it now - I was ready for some CSG discussing, but this was tough as  
so many things were brought up at once.


But having said this, let me say a couple of words more. Feel free  
to ignore this, folks, and we'll get back to it later when other  
stuff cools off.


One of the first releases I added at MB was an 11-disc set of  
Couperins "4 livres de pièces de clavecin". I had some help, and the  
"Premier Livre" etc. ended up just fine in "(disc 1: Premier  
Livre)". It's not in my TrackTitles and I've never missed them.[1]


It is rather the other way round: I quite nearly always add the  
WorkName, often making the TrackTitles very long. I know I once  
thought this was a good idea, back when I for some brief time had  
hope for what scripting could make out of full complete titles. (I  
don't believe in that anymore: Move some years away from the core  
classical period, either forwards or backwards in time, and there's  
just too many strange things going on in the structure and the  
titles of things. This belief has just been strengthened the last  
year.)



In my opinion, this wouldn't work


You might be right, but you're not explaining why it won't. What do  
you lose if the WorkName is not in the TrackTitle? Choose your own  
examples and show why we would want to avoid it :)


It won't work right now because the context for the track title "I.  
Allegro" will be ambiguous for the release "Symphonies Nos. 1, 2".  If  
we had "work" groupings then I could see us separating this information.


-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Don't read the C*S*G, smoke it!

[Aaron Cooper]

On 26-Feb-08, at 8:26 PM, Olivier wrote:

Errr, since you said we "agreed on all", did you actually read that  
sentence?


"in any case, there is no need to answer that mail at all."

:-]


2008/2/27, Brian Schweitzer <[EMAIL PROTECTED]>:
just dump it in a big pile called "historical" to rot.  I fully  
agree,

the existing CSG docs are completely unreadable bork; that's why I'd
gone from the standpoint of new doc, not fix old doc.


Sorry, did you read that other sentence?
"[...] make the official documentation evolve *incrementally*"

A big "threw it all and start from scratch" doesn't work.
We have legacy. Part of it is valuable and can't just be ignored.
Throwing it entirely is the *guarantee* that people will disagree with
the new thing.


I don't think we're starting from scratch really.  Basically taking  
what we have (the collective knowledge and current practices which may  
not be explicitly documented) and writing it down.


Perhaps we could break it down into smaller chunks and work on passing  
BrianFreud/sandbox one chunk at a time.  Why don't we start at the top  
and work our way down?


Issue #1: What is CSG?  Brian has written the following:

"The "Classical Style Guidelines" (CSG) describe a structural  
framework which allows us to order the disparate data relating to a  
classical work into a structure which is consistent, logical, and  
comprehensible. Classical works are performed by many groups world- 
wide, yet often these works have no definitive title. CSG is intended  
to allow releases containing these works to be stored within the  
database and named in a clear and consistent manner."


If we can agree on this first chunk, let's move on to the next.

What do you think about doing it this way, Brian?

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG

[Aaron Cooper]

On 26-Feb-08, at 3:07 PM, symphonick wrote:


2008/2/26, Lukáš Lalinský <[EMAIL PROTECTED]>:

On Ut, 2008-02-26 at 18:48 +0100, Frederic Da Vitoria wrote:

[snip] A track name should always
contain the normalized work name followed by the normalized movement
name. Exactly what MB does in other musical domains. We only took  
our

reference somewhere else, outside what is printed on the releases,
because this varies so widely (and wildly) that we felt no rule  
based

on liner notes would really work.


I guess that leads to a question what is normalized and what is  
not? Is

changing "Piano Concerto", "Klavierkonzert" or "Klavírny koncert" to
"Concerto for Piano" really just normalization? Why should we  
prefer the

English title on a German release?



I've been wondering this too. I'd say that "Normalize" & "translate"
is 2 different things. If a title should be changed from what's
available on the release, I'd suggest trying to find out the
"original" title (what is written in the autograph / first edition /
urtext). IMHO we're losing stuff when translating "Sonata quasi una
Fantasia per il clavicembalo o pianoforte" to "Sonata for piano".

This could mean that one entry in the master list could be named
"Streichquartett" but the next entry is "Smyčcový kvintet". & that's
OK. :)


While I'm interested in seeing what the original titles were, I'm sure  
they'd be meaningless to most people because we lack a whole lot of  
context.  I've never seen the words (?) "Smyčcový kvintet" before and  
as a result they're absolutely meaningless to me.


I think we can all agree that the common practice on classical CDs is  
to write things like "Piano Sonata" or "Sonata for Piano" and I think  
this is demonstrated at http://en.wikipedia.org.  How important are  
the original titles?  I don't want to make a judgement, but I think if  
I had a choice between the two, I'd rather have a regular,  
understandable structure that we can fit classical work titles into.   
That's just my opinion though.


-Aaron (cooperaa)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG Clean up - Let's have some action

[Aaron Cooper]

On 26-Feb-08, at 7:58 AM, Frederic Da Vitoria wrote:

On Mon, Feb 25, 2008 at 9:04 PM, Leiv Hellebo  
<[EMAIL PROTECTED]> wrote:

Let me have a short go at it then: "If there is only one work on your
CD, and the WorkName is part of the ReleaseTitle, you don't have to
include the WorkName in the TrackTitles".

Are you meaning this as a suggestion?


In my opinion, this wouldn't work and is not appropriate unless we had  
a "work" object (like releases) and a "movement" object (like  
tracks).  If we could (using Picard) set the album tag = the work  
title and the title tag = the movement info, I would be all over this  
though.


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG

[Aaron Cooper]

On 26-Feb-08, at 11:23 AM, symphonick wrote:


2008/2/26, Andrew Conkling <[EMAIL PROTECTED]>:
I'm pretty sure you're agreeing with Aaron. I think he means you  
can't,
practically speaking, just say "Allegro con brio" for track 1  
without the
work title. He's saying the work title, e.g. "Symphony No. 3" is  
important

to identify the individual tracks.


Ah. Thanks, now I get it. In that case, I do agree that many classical
tracks can't be identified without a worktitle.  "Gute Nacht" & "Come
scoglio" etc. can be, but I wonder how searching will be affected [if
we were to remove the worktitle from the trackname]? Will I be able to
search for soprano arias in "Così" with this NGS stuff somehow?


Thanks Andrew, I think you've helped clarify what I was trying to say.

I hope we're not suggesting we just put the tempo indication in the  
"track title" field and I don't think we are.  If I understand  
correctly, luks is working on a schema to breakdown the work titles  
and I assume this means that we'll be able to construct our own  
"title" tags with as much or as little detail as we desire (correct me  
if I'm wrong).


-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG

[Aaron Cooper]

On 26-Feb-08, at 3:20 AM, Lauri Watts wrote:

On Tue, Feb 26, 2008 at 9:12 AM, Aaron Cooper <[EMAIL PROTECTED]>  
wrote:


The feeling I get from your post, Lauri, is that we may as well throw
away the ClassicalStyleGuide and replace it with 'Just copy your  
liner

notes'.  If we just wanted to copy liner notes then we wouldn't need
the CSG, we wouldn't have classical editors pointing out all the
stylistic issues with each new release added, and we wouldn't have
people creating work lists to standardize the titles.  The fact that
we do have a CSG and we do point out issues with people's additions
and that people are working on work lists shows that we care about
"correct" or "the most correct" titles and consistency.


I suggest you read Lukz post again.  Twice, if necessary.


I disagree with luks.  A work title not only identifies a larger work  
but also the individual "movements" of those works.  Classical "songs"  
don't have "titles", unless you consider common names like "Eroica" a  
title.


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSG

[Aaron Cooper]

On 25-Feb-08, at 7:36 PM, Lauri Watts wrote:


On Tue, Feb 26, 2008 at 12:28 AM, Brian Schweitzer
<[EMAIL PROTECTED]> wrote:

If I can be forgiven replying to all three at the same, I think they
boil down to the same thing:



These all then seem to argue for eliminating CSG.  CSG by it's very
nature disregards what is on the liner.  No matter where we source  
the

data from, that's what it boils down to.


I make no such argument. I just disagree a little in degree.  And all
of what Lukz said.

It doesn't have to be black and white.  There is a middle ground, of
tidying up track titles, expanding abbreviations, moving artist names
where applicable, and fixing capitalisation (ie, all the things we do
in non-classical)  without completely reconstructing them until they
no longer resemble the covers at all.

I prefer to be optimistic and think that  people _will_ work on work
lists even if they can't be applied immediately, if we make it clear
what they're going to be for.

I've actually considered starting a couple for some of the rock bands
I track, because they are well documented albeit extensive and
complicated with remixes, but it would be valuable when NGS comes
around to have them ready.  Having a head start on that data would let
us hit the ground running with a couple of well fleshed out example
artists, for one thing.  And if we make it clear that there will be

If you've had enough and don't want to work on any of this anymore,
fine, that's your decision.  But if the reason is you think nobody
values your work, that's simply not true.  I think the application of
it is a little hasty and misdirected, but the _works list_ is a
valuable thing to have in and of itself.  And if the reason you want
to stop is rather because it may not be used immediately, then I
respectfully ask you take a step back, and rethink that position.


The feeling I get from your post, Lauri, is that we may as well throw  
away the ClassicalStyleGuide and replace it with 'Just copy your liner  
notes'.  If we just wanted to copy liner notes then we wouldn't need  
the CSG, we wouldn't have classical editors pointing out all the  
stylistic issues with each new release added, and we wouldn't have  
people creating work lists to standardize the titles.  The fact that  
we do have a CSG and we do point out issues with people's additions  
and that people are working on work lists shows that we care about  
"correct" or "the most correct" titles and consistency.


My experience editing/voting tells me the CSG is *much* too  
complicated to simply say "Read the wiki and apply all the guidelines"  
- we've tried that and the result was many, many sloppy classical  
releases.  We can take all the guess work out of it by providing CSG- 
friendly titles via the CSGStandard lists and make adding and editing  
classical release significantly more efficient.


From my experience with Beethoven's list, I'm pretty confident that  
the majority of the titles and the most common works have nice, clean,  
orderly titles that don't have "too much information".  In fact, they  
look very similar to what we're entering now (see Beethoven's  
Symphonies, for example).  Should we trim "There are a small number of  
cases where there's a bizarre work that will have a longer title with  
more information to help explain or identify the work.  A small price  
to pay, if you ask me...


Anyways, that's enough ranting!  :)

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] The CSGS whirlwind

[Aaron Cooper]

On 24-Feb-08, at 8:58 AM, symphonick wrote:
I'll have one last try on this subject (but I won't promise  
anything ;-)

I did some vinyl housekeeping & checked what's actually used in
tracktitles (on the backside of the cover). I found 40 releases with
concerts for instrument & orchestra:
14 "X concerto"
21 "Concerto for X and orchestra"
3* "Concerto for X"
2 "Concerto"

* One release had 2 different formats: 1 "Vivaldi: Concerto fur 2
Violinen a-moll op. 3 Nr. 8 (PV 2)" & 3 concertos formatted "Bach:
Konzert fur 2 Violinen und Streichorchester d-moll BWV 1043"
So based only on my collection, I'd suggest sticking with the 2 most
common formats if we want to standardize titles: "Piano Concert" or
"Concert for piano and orchestra"


"Concerto for X and Orchestra" allows us to have consistent titles,  
too.  We won't have to flip the order of "instrument" and "concerto"  
from the single instrument example "PIano Concerto" to the multiple  
instrument example "Concerto for Violin, Piano, and Orchestra".


My vote is for "Concerto for X and Orchestra".

-Aaron (cooperaa)

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] The CSGS whirlwind

[Aaron Cooper]

On 23-Feb-08, at 3:50 AM, Leiv Hellebo wrote:


Aaron Cooper wrote:
On Fri, Feb 22, 2008 at 3:25 PM, Leiv Hellebo  
<[EMAIL PROTECTED]> wrote:

Aaron Cooper wrote:
> Pardon my late response, but I believe that by definition  
concertos

> feature an orchestra, however I wouldn't mind seeing "Concerto for
> Piano and Orchestra".
>
http://musicbrainz.org/release/e2975862-5d4c-4e81-ba0e-ecad588423b7.html

Are you sure that example is actually *just* piano and no orchestra?


I added that release, DiscId and all, and I can assure you there are  
no orchestras in there.


In an age without cars, lp-players and symphony orchestras in every  
town, many got to hear symphonies and concertos in their  
orchestrations for one (or more) pianos.


It's not that big a stretch to extend this to bypass the orchestra  
altogether and write something concerto-like in structure for a  
single instrument such as the piano. (But I'm out of my wits here as  
to why the label "sonata" wasn't used in stead.)


Well that's why I was double checking... I couldn't figure out why the  
composer wouldn't call it a Sonata!  :)


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] The CSGS whirlwind

[Aaron Cooper]

On Fri, Feb 22, 2008 at 3:25 PM, Leiv Hellebo <[EMAIL PROTECTED]> wrote:
> Aaron Cooper wrote:
>  > Pardon my late response, but I believe that by definition concertos
>  > feature an orchestra, however I wouldn't mind seeing "Concerto for
>  > Piano and Orchestra".
>  >
>  http://musicbrainz.org/release/e2975862-5d4c-4e81-ba0e-ecad588423b7.html

Are you sure that example is actually *just* piano and no orchestra?
To me that title is ambiguous... could mean just piano or could mean
just piano as in not a double piano concerto.

http://en.wikipedia.org/wiki/Concerto says "The term Concerto (plural
concertos or concerti) usually refers to a musical work in which one
solo instrument is accompanied by an orchestra."  Anyways, don't want
to argue about the definition of a concerto.  :)

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] The CSGS whirlwind

[Aaron Cooper]

On Thu, Feb 21, 2008 at 8:23 AM, symphonick <[EMAIL PROTECTED]> wrote:
> 2008/2/21, Aaron Cooper <[EMAIL PROTECTED]>:
>
> >
>  > On 20-Feb-08, at 10:35 PM, Andrew Conkling wrote:
>  >
>
> > > Some examples (limited to Mozart's œuvre):
>  > > http://musicbrainz.org/album/e4bf2166-b9f2-48ce-8850-c574ca44aa00.html
>  > > Did track 4 just get forgotten?
>  >
>  > Looks like it was forgotten. It should look like the rest.
>  >
>
>  Perhaps OT, but when looking at this, I realized that to me "Concerto
>  for piano" implies a concerto for piano solo. But I always interpret
>  "Piano Concerto" as a concerto for piano & orchestra. Maybe it's just
>  me?
>  I think I'd like to see the complete instrumentation ("Concerto for
>  piano and orchestra) if that (IMO) more formal expression is used.

Pardon my late response, but I believe that by definition concertos
feature an orchestra, however I wouldn't mind seeing "Concerto for
Piano and Orchestra".

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] [CSG] Ballet title style

[Aaron Cooper]

On 22-Feb-08, at 8:00 AM, Age Bosma wrote:


Hi,

I hope I'm not opening a can of worms here but I wasn't able to  
figure it out by going through the current wiki docs.


Some example titles:

The Nutcracker, Act I, Scene 1, No. 1: Scène: L'arbre de Noël
The Nutcracker, Act I, Scene 1, No. 2: Marche
The Nutcracker, Act II, No. 12a: Divertissement: Le chocolat (Danse  
espagnole)


According to http://wiki.musicbrainz.org/ClassicalTrackTitleStyle,  
taken from the examples at the top of the page, this would become  
something in the lines of:


The Nutcracker: Act I, Scene 1. "L'arbre de Noël"

Can anyone tell me where the parts like 'No. 1', the seconds 'Scene'  
in the first title and 'Divertissement' in the third title go in the  
new title? Best thing I can come up with would be:


The Nutcracker: Act I, Scene 1, No. 1. Scene: "L'arbre de Noël"

What's you opinion about this?


My quick thoughts before I run off to work:

Act II, Scene XIV not Scene 14.

I don't know what the No.'s are for or if they're useful at all, but  
your last example (The Nutcracker: Act I, Scene I, No. 1. Scene:  
"L'arbre de Noël") looks good.


-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] The CSGS whirlwind

[Aaron Cooper]

On 20-Feb-08, at 10:35 PM, Andrew Conkling wrote:

So I started poking around to see how all these CSGS edits would  
impact my collection and found a lot that seem to be worse than they  
were before.


Some examples (limited to Mozart's œuvre):
http://musicbrainz.org/album/e4bf2166-b9f2-48ce-8850-c574ca44aa00.html
Did track 4 just get forgotten?


Looks like it was forgotten.  It should look like the rest.

http://musicbrainz.org/album/a3523d3e- 
b172-4164-8406-5dda5eea7a28.html (tracks 5-8)
Is this really a track-level detail? I know there are (more or less)  
two camps on this, but even for those who want all details in track  
names... really? (Also, how would you be able to tell? I wouldn't  
expect anyone to be able to tell whether there are clarinets or not.)


There was a *huge* discussion about this piece in particular.  It is  
considered by some to be integral "version info", if you will, because  
there are two versions (with and without clarinets) that have the same  
catalog number.


http://musicbrainz.org/album/3883f2fd-44b1-4174-82a0- 
c1fb8dc1c8db.html (tracks 1-2)
Tracks 1 and 2 are performed "together", but the track list doesn't  
show that. Does it turn out that they're from different works of  
Mozart's? How are we supposed to know that? And why three different  
ways to list a horn concerto?


This is probably a sign that the CSGStandard page needs some checks  
for consistency.


I realize I'm kinda jumping into the middle of a whirlwind of  
discussion, so please help guide me and don't let me rehash old  
discussions. ^_^


Cheers,
Andrew


-Aaron
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] CSGStandard?

[Aaron Cooper]

On 18-Feb-08, at 9:39 PM, Andrew Conkling wrote:


Hi Leiv,
Thanks for the reply and the re-welcome. I haven't left MBz, just  
stopped participating in the discussion.


On Feb 18, 2008 5:23 PM, Leiv Hellebo <[EMAIL PROTECTED]> wrote:
But I should also mention that recently a few new twists have been
introduced in the edit at
http://musicbrainz.org/show/edit/?editid=8347705.  Here people have
broached the subject of how the NGS might affect how we deal (or  
should

deal) with classical titles. I'm sorry to say I don't understand that
stuff yet.

...and I see I've missed a lot. :D In the context of that discussion  
there, I tend to fall on the side of getting all the names (fully)  
consistent, so this CSGStandard sounds like a good idea.


Curious if there are any other details, but would also like some  
pointers on where to jump in :)


Anywhere!  When adding new CDs, check to see if the works are listed  
on the composer's CSGStandard page and if not, something is always  
better than nothing!  :)


-Aaron (cooperaa)

PS:  Good to see you back!

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: StylePrinciple Reasoning

[Aaron Cooper]

On 17-Feb-08, at 1:44 AM, Leiv Hellebo wrote:
That's what we probably should be doing with the classical stuff as  
well. Uppercase "Op.", remove unnecessary brackets around cat. nos.  
and correcting (the fictive)


"Mazurka No. 3 in E major, Op. 20" to
"Mazurka in E major, Op. 20 No. 3"


Sorry for taking the discussion off-topic here, but I believe the  
correct(er) title would be:


"Mazurka, Op. 20 No. 3 in E major"

…assuming that the other Mazurkas in Op. 20 are not all in E major.

-Aaron (cooperaa)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: StylePrinciple Reasoning

[Aaron Cooper]

On Fri, Feb 15, 2008 at 9:26 AM, Lauri Watts <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 15, 2008 at 3:12 PM, Aaron Cooper
>  >  Can you give a couple examples of what you think we should be fixing?
>
>  We normalise capitalisation, switch out dashes for colons, put feat's
>  in brackets.  Basically all the normalisation and standardisation we
>  do, even though it isn't materially changing the track titles.

Thanks Lauri, I must need another coffee... I don't know what I
thought that email was regarding but it makes a lot more sense now.
Please disregard my concern.  This sounds good.

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: StylePrinciple Reasoning

[Aaron Cooper]

On Fri, Feb 15, 2008 at 7:30 AM, Philip Jägenstedt <[EMAIL PROTECTED]> wrote:
> Having read http://wiki.musicbrainz.org/StylePrinciple I thought the
>  "Reasoning" section was pretty poorly phrased.
>
>  Current:
>
>  There are enough cases of record companies mucking up track listings
>  or even artist names (see some of the Front Line Assembly releases
>  sometime), or creating new imaginary words for stylistic purposes that
>  it makes much more sense to fix these things. I think that we
>  generally value spelling and punctuation correctness over cover
>  accuracy.
>
>  Suggestion:
>
>  There are many cases of record companies making errors with track
>  titles or even artist names (e.g. some of the Front Line Assembly
>  releases), or creating new imaginary words for stylistic purposes. In
>  such cases it often makes sense to fix the errors, valuing spelling
>  and punctuation correctness over cover accuracy.
>
>  Comments?
>
>  Philip (foolip)

Can you give a couple examples of what you think we should be fixing?

-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] [Clean up CSG] Release Title

[Aaron Cooper]

On 15-Feb-08, at 12:30 AM, Brian Schweitzer wrote:

When classical discs are reissued with new cover art or new
"spellings" of the works on the disc, 
http://wiki.musicbrainz.org/ClassicalReleaseTitleStyle
 provides a means of grouping them all together under one release
with a common release title derived from the works on the release  
in a

specified format.

Otherwise we might get the following:

Symphonies Nos. 1, 2, 3
Symphonies Nos. 1-2-3
Beethoven: Symphonies No. 1 / No. 2 / No. 3
Symphonies 1-3
... and so on.

ClassicalReleaseTitleStyle let's us group these all under one release
(assuming same performers and same recording) as "Symphonies Nos.  
1-3".


Yes, and I think what then needs to be clarified is that CSG's Release
title guidelines are intended to help guide to some consistency (just
like, say, "vol." --> ", Volume"), to avoid the above, not to
completely replace the title.

The question then is, given "The Five Symphonies" on one release, if
the reissue is just "Symphonies 1-5", how does that work into this
concept?  Do we keep "The Five Symphonies" as somehow a more "real"
title than "Symphony Nos. 1-5"?  And how would we describe this so
it's non-ambiguous?


Good question.

"The Five Symphonies" seems like a more "real" title than "Symphony  
Nos. 1-5"... but it only identifies the works on the disc.  Both  
titles ultimately mean the same thing.  It wouldn't bother me if we  
decided to change what's printed ("The Five Symphonies") to  
"Symphonies Nos. 1-5".  Something like "The Quiet Symphonies" or "The  
Relaxing Quartets" or something that doesn't simply identify the work  
numbers I would think we'd keep.  If the printed title is just  
identifying the pieces on the disc, I don't see why we can't take some  
creative liberties and format the title to follow our style guidelines.


-Aaron

___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style