[mb-style] Release Artist for Soundtrack

[Yin Izanami]

Hi all,
I've got a disagreement here at edit #14579974.  This is for the StarCraft
II game soundtrack.  Currently it's listed under "Various Artists", but I'd
like to change it to the artists who are printed prominently on the first
page of the jacket, "Glenn Stafford, Derek Duke, Russell Brower, Neal
Acree".  (Note that there are additional composers credited for the music in
the soundtrack not listed there.)

The first two voters clearly disagree with me however.  I tried to
understand his position but he goes as far as to suggest that the Gladiator
soundtrack, currently listed under "Hans Zimmer and Lisa Gerrard" as on the
cover, should be changed to "Various Artists"!

So where is the distinction drawn between a Various Artists release artist
and a release attributed to all the major artists listed on the
cover/jacket/big text?  Is there a concrete guideline for this or is it, as
my gut tells me, "go with the big text"?

Thanks,
DY

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

[mb-style] Artist sort name for a fairly special case

[Yin Izanami]

The artist "AAA" is literally and physically sorted as "TORIPURU-EE" /
"Triple A" in Japan.  You can see this in Japanese bookstores and on
avexnet's listing of all its artists - it is sorted under the "TO"
character, not "A" or "E" or the like.

I realize artist sort name is not supposed to be used for pronunciation, and
"AAA" is also already in Latin script.  However, this would not be the first
time that the artist name and sort name don't actually say the same thing -
for example,
蔡宜翎 (Tsai Yi Ling) is sorted as "Tsai, Jolin"
周杰倫 (Chou Jie Lin) is sorted as simply "Chou, Jay", with no indication of
the 3rd character.

If you agree / disagree with this "sortname doesn't match Latin-for-Latin to
the artist name", then I'd like to hear what others think about it.

Thanks,
DY
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC-324 v2: Official Website and Discography Entry ARs for Releases/Release Groups

[Yin Izanami]

What happens if a label changes the URL structure of their website?  I'm
concerned this will eventually lead to a countless number of dead links, if
said changes aren't fixable by a simple script.

On Fri, Jun 10, 2011 at 10:21 AM, jacobbrett  wrote:

>
> Calvin Walton-2 wrote:
> >
> > Now with infinitely more wiki page templates, and its very own RFC
> > number!
> >
> > This proposal is to add or change two ARs:
> >
> >   * Official Homepage
> >
> http://wiki.musicbrainz.org/User:Kepstin/Official_Homepage_Relationship_Type_Proposal
> >
> > A new Release Group → URL relation will be added to the Official
> > Homepage relationship type, to allow linking releases groups to
> > an official website published by the artist or label.
> >
> >   * Discography Entry
> >
> http://wiki.musicbrainz.org/User:Kepstin/Discography_Entry_Relationship_Type
> >
> > A new Release → URL relationship type, to allow linking
> > individual versions of releases to sub-pages of discography
> > sites.
> >
> > I'm still not entirely sure what to do with the wording on the Official
> > Homepage relation: should I use a different wording for release groups
> > than the other types? Or should I change them all to be consistent?
> >
> > Discuss!
> >
> > --
> > Calvin Walton 
> >
> >
> > ___
> > MusicBrainz-style mailing list
> > MusicBrainz-style@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> >
> Perhaps "has an official homepage at" (and vice versa) should be used
> instead, as:
>
> Firstly, IMO "website" isn't consistent terminology with "homepage"; it
> should be "webpage".
>
> Though, then my concern is that "official webpage" may be confused with any
> release listing on an artist's website.
>
> Thus, "official homepage" is probably more apt than "official website".
>
> Is that too pedantic? :P
>
> --
> View this message in context:
> http://musicbrainz.1054305.n4.nabble.com/RFC-324-v2-Official-Website-and-Discography-Entry-ARs-for-Releases-Release-Groups-tp3585730p3588549.html
> Sent from the Musicbrainz - Style mailing list archive at Nabble.com.
>
> ___
> 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

[mb-style] RFC: Add "8cm CD" format (Mini CD / 3" CD) as a subtype of CD format

[Yin Izanami]

Proposal is to add "8cm CD" as a subtype of CD in the medium format list.

http://en.wikipedia.org/wiki/Mini_CD_single
http://ja.wikipedia.org/wiki/8%E3%82%BB%E3%83%B3%E3%83%81CD

I'd prefer seeing "8cm CD" if no one objects to this, since the format was
most successful/used in Japan (it was widely used for over a decade).

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

Re: [mb-style] RFC: Add "8cm CD" format (Mini CD / 3" CD) as a subtype of CD format

[Yin Izanami]

Maybe we should split "Format" into some form of "Physical Format" and
"Digital Format" (not interpreted literally though)?  In the case of CD, for
physical we'd have 12cm and 8cm, and for digital we could have...
-CDDA
-Data (not sure how -ROM and -R should be split)
-HDCD
anything else I don't know about (wikipedia has a lot of articles)

This could also help other formats I assume.

On Sun, Jun 12, 2011 at 11:46 AM, Calvin Walton wrote:

> On Sun, 2011-06-12 at 12:02 +0100, Christopher Key wrote:
> > On 12 Jun 2011, at 09:46, Kuno Woudt  wrote:
> > > So, I think the full list should be:
> > >
> > > CD
> > >   12cm CD
> > >   12cm CD-R
> > >   8cm CD
> > >   8cm CD-R
> > >   HDCD
> > >
> >
> > Slight nit, HDCD encoding is independent of the CD size or technology, so
> any of the other four could be HDCDs too.
>
> Yeah, It's unclear in the list whether we are describing only the
> physical medium, or both the physical medium and encoding.
>
> For example, why do we have both DVD-Audio and DVD-Video but not CDDA,
> CDROM, and VCD?
>
> (I have seen some bonus tracks included as mp3 files on a CDROM portion
> of a disc before...)
>
> This could really use some cleaning up.
>
> --
> Calvin Walton 
>
>
> ___
> 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] musings on title normalization

[Yin Izanami]

@Bogdan B,
I take issue with your very first statement.  How is it harder for an
arbitrary user to determine "what the cover says" than to determine "what
the guidelines say"?  Assuming the user actually owns the release or has
access to all the resources of the release (i.e., VGMdb for most game
soundtracks), it should be significantly easier to determine what the cover
(which I assume you mean the jacket/booklet) says than what a bunch of
contradictory and vague Musicbrainz guidelines say.

e.g., deprecated Versus Style implying things about (deprecated?) Remix
Style which aren't stated there; deprecated Soundtrack things contradicting
with Abbreviation Style; and of course editors misinterpreting guidelines
and voting based on an incorrect understanding.

Contrarily, it's a little difficult to misunderstand the jacket if it's
printed in plain text.  (I do understand and have seen many English releases
with fancy styled art/text rather than plain text - I have no problem
entering those with normalized English capitalization.  I only have problems
when editors try applying Anglo-centric standards on non-English countries,
especially when art/logo design isn't involved and we're just dealing with
plain text.)
On Mon, Jun 13, 2011 at 8:45 AM, Frederic Da Vitoria wrote:

>   2011/6/12 Bogdan Butnaru 
>
>> Executive summary:
>>
>> Fact: For an arbitrary release, it is much harder for an arbitrary
>> user to determine the correct answer to “what the cover says” than to
>> “what the guidelines say”.
>>
>> Fact: The amount of *correct* “what-the-cover-says” information is
>> *minuscule* in comparison to correct “normalized” information.
>>
>> Opinion: The amount of *correct* “what-the-cover-says” information
>> will always be much smaller than the correct “normalized” information.
>>
>> Opinion: In general, MusicBrainz is more useful because it provides
>> normalized-according-to-guidelines titles than for its
>> what-the-cover-says titles.
>>
>> Opinion: Having the default info be “what-the-cover-says” will
>> decrease data quality, *both* the cover data and the normalized data.
>>
>> Suggestion: Put the normalized-according-to-guidelines titles in the
>> fore-front, and make the what-the-cover-says titles harder to find.
>> This way, only people who really want them and know what they’re doing
>> will get to them, and the most useful data is the easiest to access.
>>
>> 
>> Hello everyone!
>>
>> First of all, sorry if there are inaccuracies in this email: I don’t
>> have time right now to follow the day-to-day discussions after the
>> NGS, so I’m mostly keeping to the sidelines until things stabilize a
>> bit.
>>
>> I wanted to comment on the issue of title normalization. If I
>> understand correctly, the current general plan is that:
>>  - on mediums, the titles are “mostly as on the cover” (very little
>> normalization);
>>  - on works/recordings, the titles should be normalized, pretty much
>> according the the good old guidelines.
>>
>> (I’m not sure what the difference is between the work/recording levels, if
>> any.)
>>
>> The taggers allow (or will allow) users to tag files with the level of
>> normalization they want, but AFAIK the current default, both for
>> tagging and for what is displayed on the site when you look at a
>> release, are non-normalized titles.
>>
>> While I don’t have a problem in general with keeping the “what’s on
>> the cover” information somewhere, I think the way the levels are used
>> right now is very bad from a data quality viewpoint.
>>
>> Pre-NGS, when looking at a release, it was possible for an editor to
>> tell at a glance if it was well normalized or not, and easy to fix it
>> right away. If I noticed a release with messy capitalization, even if
>> I didn’t care much about the artist or release in particular, I could
>> just click “edit all”, “guess case”, edit whatever was still messy by
>> hand, then “save”, even if I only had five minutes to spare. I could
>> (and did) improve the database casually.
>>
>> With the tracklist-fist approach of NGS, the barriers are much higher.
>> If I peruse the edits list and see an added release, I can’t tell at a
>> glance if its titles are correct. I’d need to look for a scan of the
>> cover (that was the exception previously, it’s the rule now). 99% of
>> our edits *don’t* get cover scans attached, we’re working most of the
>> time from info on the web, which means that the *first* thing the
>> server asks when adding a title is the *hardest* to find and check.
>> Secondly, I don’t *actually* care about “as-on-the-cover” title, and I
>> suspect most of the more active editors don’t either.
>>
>> So, the “as on the cover” set of titles are harder to check and less
>> interesting for the editors who care about clean, normalized data,
>> which are AFAIK the core of MusicBrainz. By making it the first and
>> easiest to see and edit I think we’re on the path of having most new
>> things added get in with pretty much no chec

Re: [mb-style] Normalization of release-level data NGS

[Yin Izanami]

I have major objections to recent comments.

>jacobbrett wrote:
> In my opinion:
>
> Track/Release Titles:
> *Typographical errors
> *Incorrect titles (e.g. bootleg prints title as a line from the
lyrics,
> or two track titles are swapped)
> *Poor capitalisation (ALL-CAPS, all-lowercase etc., barring Artist
> Intent or Japanese/foreign exception)
> *Subtitle (Japanese/foreign exception)
> *Series/Volume/Part numbers (Japanese/foreign exception)
> *Extra title information:
>*"Song Name remix name" → "Song Name (remix name)"
>*"Song Name 〜remix name〜" → no change (Japanese/foreign exception)
> *Some abbreviations:
>*"w/" → "with"
>*"ft." → "feat."
>
> If any affected features "as printed" are important for identifying a
> particular release, a note can be made in the release annotation.
>

I don't understand your post.  Are all those things that you would _fix_?
Because if you're going to go that far, how exactly will Tracklist Titles
and Tracklist Artist Credits differ from Release Titles and Release Artist
Credits?

If you're going to make Tracks and Recordings nearly identical, then as I
understand it, you defeat the purpose of NGS splitting tracks (in a
tracklist) from Recordings.  Without the permission for track and recording
fields to differ, the only thing left would be to give editors headaches
synchronizing 2 titles, 2 artist credits, and 2 track lengths between each
other.  (This is already a major pain for releases added without track
lengths.  Times filled in for the release's tracklist won't be reflected in
the recordings, they need to be done separately.  Why require the extra work
if in fact Tracks and Recordings should both be normalized to similar or
identical values?)

>jacobbrett wrote:
> I think the above rules would sufficiently retain the titling as intended
on
> a particular release, while making it more useful/less erroneous and
> standardised. The recording title could take the above further by having
> further normalisation applied ("with" → "feat."? Perhaps a better example
is
> needed here...),

So you want to normalize "A with B" to "A feat. B"?  Will you stop there, or
will you also change "A starring B", "A & B", "AxB", "A-B", "A+B", "AとB"
(that's a Japanese character if you get a question mark), "A Lovers B", or
whatever other combining word the artists came up with, to also be "A feat.
B"?  If you're not willing to convert every language and every word to
"feat.", then what makes "with" synonymous with "featuring" in a way that
other phrases aren't?

>>Andii Hughes wrote:
>>The recording title should be the most complete possible title (i.e.
>>with all feat. attributions, etc.) and normalised (e.g. with->feat as
>>you say).

I thought there was widespread agreement that Recording titles should NOT
contain artists, and that featured artists should be moved into Recording
artist credits.

On Mon, Jun 13, 2011 at 8:09 PM, Andii Hughes wrote:

> On 12 June 2011 12:11, jacobbrett  wrote:
> >
>
> snip...
>
> > In my opinion:
> >
> > Track/Release Titles:
> > *Typographical errors
> > *Incorrect titles (e.g. bootleg prints title as a line from the
> lyrics,
> > or two track titles are swapped)
> > *Poor capitalisation (ALL-CAPS, all-lowercase etc., barring Artist
> > Intent or Japanese/foreign exception)
> > *Subtitle (Japanese/foreign exception)
> > *Series/Volume/Part numbers (Japanese/foreign exception)
> > *Extra title information:
> >*"Song Name remix name" → "Song Name (remix name)"
> >*"Song Name 〜remix name〜" → no change (Japanese/foreign exception)
> > *Some abbreviations:
> >*"w/" → "with"
> >*"ft." → "feat."
> >
> > If any affected features "as printed" are important for identifying a
> > particular release, a note can be made in the release annotation.
> >
>
> This seems a good list of things to clean up.  My main use for MB is
> to obtain data on a release that has been sanitised and explicitly to
> avoid having the title and artist of a track vary between different
> releases.  If you really want a database of cover replicas, there's
> already Discogs.
>
> > I think the above rules would sufficiently retain the titling as intended
> on
> > a particular release, while making it more useful/less erroneous and
> > standardised. The recording title could take the above further by having
> > further normalisation applied ("with" → "feat."? Perhaps a better example
> is
> > needed here...), as well as Consistent Original Data [1] (so that it
> would
> > act as the "canonical" title).
> >
>
> The recording title should be the most complete possible title (i.e.
> with all feat. attributions, etc.) and normalised (e.g. with->feat as
> you say).
>
> > I previously rationalised some of these points here:
> >
> http://musicbrainz.1054305.n4.nabble.com/VolumeNumberStyle-in-NGS-td3573712i20.html#a3588251
> >
> > [1] http://wiki.musicbrainz.org/History:Consistent_O

Re: [mb-style] Normalization of release-level data NGS

[Yin Izanami]

Sorry, in "Tracklist Titles and Tracklist Artist Credits differ from Release
Titles and Release Artist Credits", "release" should be "recording".

On Mon, Jun 13, 2011 at 8:43 PM, Yin Izanami  wrote:

> I have major objections to recent comments.
>
>
> >jacobbrett wrote:
> > In my opinion:
> >
> > Track/Release Titles:
> > *Typographical errors
> > *Incorrect titles (e.g. bootleg prints title as a line from the
> lyrics,
> > or two track titles are swapped)
> > *Poor capitalisation (ALL-CAPS, all-lowercase etc., barring Artist
> > Intent or Japanese/foreign exception)
> > *Subtitle (Japanese/foreign exception)
> > *Series/Volume/Part numbers (Japanese/foreign exception)
> > *Extra title information:
> >*"Song Name remix name" → "Song Name (remix name)"
> >*"Song Name 〜remix name〜" → no change (Japanese/foreign exception)
> > *Some abbreviations:
> >*"w/" → "with"
> >*"ft." → "feat."
> >
> > If any affected features "as printed" are important for identifying a
> > particular release, a note can be made in the release annotation.
> >
>
> I don't understand your post.  Are all those things that you would _fix_?
> Because if you're going to go that far, how exactly will Tracklist Titles
> and Tracklist Artist Credits differ from Release Titles and Release Artist
> Credits?
>
> If you're going to make Tracks and Recordings nearly identical, then as I
> understand it, you defeat the purpose of NGS splitting tracks (in a
> tracklist) from Recordings.  Without the permission for track and recording
> fields to differ, the only thing left would be to give editors headaches
> synchronizing 2 titles, 2 artist credits, and 2 track lengths between each
> other.  (This is already a major pain for releases added without track
> lengths.  Times filled in for the release's tracklist won't be reflected in
> the recordings, they need to be done separately.  Why require the extra work
> if in fact Tracks and Recordings should both be normalized to similar or
> identical values?)
>
>
> >jacobbrett wrote:
> > I think the above rules would sufficiently retain the titling as intended
> on
> > a particular release, while making it more useful/less erroneous and
> > standardised. The recording title could take the above further by having
> > further normalisation applied ("with" → "feat."? Perhaps a better example
> is
> > needed here...),
>
> So you want to normalize "A with B" to "A feat. B"?  Will you stop there,
> or will you also change "A starring B", "A & B", "AxB", "A-B", "A+B", "AとB"
> (that's a Japanese character if you get a question mark), "A Lovers B", or
> whatever other combining word the artists came up with, to also be "A feat.
> B"?  If you're not willing to convert every language and every word to
> "feat.", then what makes "with" synonymous with "featuring" in a way that
> other phrases aren't?
>
>
> >>Andii Hughes wrote:
> >>The recording title should be the most complete possible title (i.e.
> >>with all feat. attributions, etc.) and normalised (e.g. with->feat as
> >>you say).
>
> I thought there was widespread agreement that Recording titles should NOT
> contain artists, and that featured artists should be moved into Recording
> artist credits.
>
>
> On Mon, Jun 13, 2011 at 8:09 PM, Andii Hughes 
> wrote:
>
>> On 12 June 2011 12:11, jacobbrett  wrote:
>> >
>>
>> snip...
>>
>> > In my opinion:
>> >
>> > Track/Release Titles:
>> > *Typographical errors
>> > *Incorrect titles (e.g. bootleg prints title as a line from the
>> lyrics,
>> > or two track titles are swapped)
>> > *Poor capitalisation (ALL-CAPS, all-lowercase etc., barring Artist
>> > Intent or Japanese/foreign exception)
>> > *Subtitle (Japanese/foreign exception)
>> > *Series/Volume/Part numbers (Japanese/foreign exception)
>> > *Extra title information:
>> >*"Song Name remix name" → "Song Name (remix name)"
>> >*"Song Name 〜remix name〜" → no change (Japanese/foreign
>> exception)
>> > *Some abbreviations:
>> >*"w/" → "with"
>> >*"ft." → "feat."
>>

Re: [mb-style] RFC: Add "Keep case" to release packaging list

[Yin Izanami]

+1.  I think I might have added some keep cases as jewel cases by accident.

On Sun, Jun 19, 2011 at 11:38 AM, Michael Wiencek  wrote:

> I see this as a fairly obvious and straightforward addition.
>
> http://en.wikipedia.org/wiki/Keep_case
>
> We have several DVD formats available to use in the medium format list.
> It makes sense to add the release packaging most common to DVDs.
>
> The RFC will expire on June 26.
>
> ___
> 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

[mb-style] RFV: Add "8cm CD" as a subtype of "CD" format

[Yin Izanami]

Background:
http://en.wikipedia.org/wiki/Mini_CD_single
8cm CD was commonly used by major Japanese labels for a decade.  There is a
clear use for it in Musicbrainz, considering "8cm CD" shows up on
Musicbrainz' top tags page (
http://musicbrainz.org/tag/8cm%20cd/release-group).

RFC discussion:
http://comments.gmane.org/gmane.comp.audio.musicbrainz.style/10744

Proposal:
Add "8cm CD" as a subtype to "CD".  (Currently, CD has subtypes "HDCD" and
"CD-R".)

Although it seems a redesign of the format tree would be a good idea in the
future (a tree doesn't seem like a good idea for CD with "physical" and
"data" aspects), 8cm CD should not cause any major migration issues should
the tree get changed into not-a-tree.

This RFV expires 2 days from today (June 19 here), on June 21.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: Add "Keep case" to release packaging list

[Yin Izanami]

I can confirm at least two CD keep case releases:
http://musicbrainz.org/release/567afae8-3d72-4ad8-8223-1c0dbbd09403
http://musicbrainz.org/release/9f800a2a-2a6e-490c-95c7-b5b6d380a743

Instead of writing "Keep Case (DVDs)", why don't we just put up a Packaging
wiki page with a sample picture of a keep case (along with all the other
formats).  That way the list can look cleaner (and be less inaccurately
precise).
On Mon, Jun 20, 2011 at 1:28 PM, Alex Mauer  wrote:

> On 06/20/2011 12:22 PM, Simon Reinhardt wrote:
> > I like "Keep Case (DVDs)" but I'm wondering if there are any releases
> with CDs in Keep Cases.
>
> There probably are, but I’m not sure that it matters as Musicbrainz does
> keep information about DVDs as well, and they often do come in keep cases.
>
> —Alex Mauer “hawke”
>
>
> ___
> 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 “Box” to release packaging list

[Yin Izanami]

As Nikki pointed out in the Keep Case RFC, Musicbrainz does not currently
support multiple packages.  The way you have worded your Box RFC suggests
Box should take precedence over Jewel Case, Mini Jewel Case, and the like.
(And I know of many boxes with varying package formats inside.)

On Mon, Jun 20, 2011 at 2:14 PM, Alex Mauer  wrote:

> The box is a pretty standard package for piano rolls.
>
> In addition, as NGS stores releases instead of individual discs, it is
> not uncommon for all vinyl discs or all CDs to be in a box, even if an
> individual disc is packaged in a sleeve or a jewel case.
>
> This RFC will expire on 2011-7-27.
>
> —Alex Mauer “hawke”
>
>
> ___
> 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 “Slipcase” to release packaging list

[Yin Izanami]

I also disagree with this strongly because the logic here is easy to
extrapolate ridiculously.

Nearly all Japanese releases are "packaged" in an Obi, some of which extend
the full width of the jewel case, so would you propose to change those
mini/jewel cases to "Obi" just like this "Slipcase" proposal suggests?  Or
would you only change those with full-width Obis, but leave half-width and
shorter Obi releases as jewel cases?  And if you wouldn't support Obis at
all, how does it then differ from Slipcases?  Because it only surrounds 3
sides of the release rather than 4 sides?

(I don't consider Obis packaging, but I fail to see how a slipcase differs
significantly that it is "packaging" similar to jewel cases.)
On Mon, Jun 20, 2011 at 2:39 PM, Alex Mauer  wrote:

> On 06/20/2011 01:34 PM, Simon Reinhardt wrote:
> > Similarly to "box" I'm against this because it often contains other
> > things in it. For example when there's a Jewel Case with one CD in it
> > and it has a cardboard slipcase around it I would just set it to
> > Jewel Case. But if there are several different things inside the
> > slipcase I'd use "other" rather than the outermost packaging.
>
> Again, this is release packaging and not disc packaging.  It is common
> for a *release* to be packaged in a slipcase, even if individual discs
> may be packaged in other things.
>
> —Alex Mauer “hawke”
>
>
> ___
> 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 "Super Jewel Box" to release packaging list

[Yin Izanami]

I don't think you can technically "-1" a RFC.

As for me, +1.  I've seen it used, and it's significantly different from a
Jewel Case, of which we more similar formats already in Musicbrainz (like
the mini-jewel case, where the major differences in my experience relate to
the booklet/jacket design).

For one, the Super Jewel Case opens differently than a jewel case / cassette
jewel case / keep case / digipak, which is already a huge difference.

On Mon, Jun 20, 2011 at 5:08 PM, Simon Reinhardt
wrote:

> Alex Mauer wrote:
> > As I see it it’s just a variant form of jewel case, of which there have
> > been dozens over the years.
> >
> > We don’t need to add a new packaging type every time some company adds
> > their own Special Sauce and adds a ™ or an ® on the end.
>
> It's quite different to a Jewel Case though. And I think it's being used
> often enough to justify being recognised as more than just a random product
> by some random company.
>
> Regards,
>Simon
>
> ___
> 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] Packaging types

[Yin Izanami]

What do you mean by "a slim jewel case is the product of more than one
company" / "a super jewel case is the product of only one company"?  Because
"Super Jewel Box" isn't the only company that makes them.

Verbatim also sells them:  http://www.amazon.com/gp/product/B6OX99
Pentavision, a Korean company, uses them:
http://ruliweb.daum.net/data/rulinews/read.htm?page=&num=17594

I'm curious, have you ever actually held a Super Jewel Case in your hands?
It's not just the "rounded corners" you quote that makes them different from
jewel cases.

On Mon, Jun 20, 2011 at 6:46 PM, Alex Mauer  wrote:

> On 06/20/2011 03:59 PM, Simon Reinhardt wrote:
> > A Slim Jewel Box is a variant of a Jewel Case and yet we have it in
> > the list. :-) To me it's not really a variant of it but a new
> > product, just like the Keep Case is a different product, and it just
> > happens to be made of the same stuff.
> >
> > The cassette one is not a jewel case at all - it's also just made of
> > the same stuff (most times).
>
> They share some obvious similarities beyond the material, though.  The
> Jewel Case basically looks like what you’d come up with if you took a
> cassette case and scaled it to a size appropriate for a CD, and then
> added something to keep it from sliding around and getting scratched.
>
> A Super Jewel Box looks like what you’d get if you saw the problems of
> jewel case hinges breaking and came up with a better hinge system—and
> then made a couple more tweaks because hey, while you’re redesigning it
> you might as well, right?
>
> Now I’m not saying that the Super Jewel Box isn’t an awesome thing (I
> have plenty of CDs with broken hinges), but when the name itself says
> essentially “It’s a jewel case but *better*”, and the marketing gives
> “it has rounded corners” as one of the features that makes it “Super”
> then why argue with that?
>
> I actually feel pretty much the same about the slim jewel case “It’s a
> jewel case, but thinner!” but at least it appears to be an independent
> design and isn’t just a product of one company.
>
> > I can't quite follow your reasoning. Do you aim to only make a
> > difference between materials? Probably not as you don't want
> > differentiate between paper and cardboard sleeve. Different styles of
> > packaging? How specific though? Or just broad generic terms? How
> > generic? Would you rather remove Slim Jewel Case from the list and
> > just have terms like "sleeve", "box", "case"? I just can't quite see
> > where you're going. :-)
>
> I’m trying to be reasonably generic, without being too generic. :-)
>
> And yes, I’d rather remove slim jewel case from the list than try to
> list every company’s own variant on the jewel case
>
> On one extreme we have “sleeve” and “box”
>
> On the other extreme we have levels of specificity which can be left
> only to our imaginations.
>
> I prefer “sleeve” over listing the many materials from which sleeves can
> be made.
>
> I’d prefer “box” which can be used for everything from piano rolls to
> the gold-plated tin box with embossing used on The Super Mega Exclusive
> Awesome Deluxe Edition, over needing half a dozen “box” types just to
> cover the common cases (I can think of “cardboard piano roll box”,
> “cardboard 12-inch vinyl disc box”, “cardboard 7-inch vinyl disc box”,
> and “tin CD box” just among the ones I have which are more than just a
> one-off.
>
> I prefer “Jewel case” which can be used for everything from slim jewel
> cases to polystyrene cassette cases, over “jewel case”, “Super Jewel
> Box”, “Minidisc jewel case”, “Zip disc Jewel Case”, “lift-lock case”[1],
> “eco pack” and a thousand other variations.
>
> > Hm, paper and cardboard are not the same to me so I wouldn't want to
> > reuse paper for cardboard ones. So either we rename paper sleeve to
> > something more generic or we do go into more detail.
>
> I agree, they’re not the same but to me at least there is no clear line
> where “thick paper” becomes “thin cardboard” — any particular release
> would require a judgement call as to which it is.
>
> 1. http://en.wikipedia.org/wiki/File:Liftlockcdcase.jpg
>
>
> ___
> 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] Merge Slim Jewel Case into Jewel Case (was: Re: RFC: Add "Super Jewel Box" to release packaging list)

[Yin Izanami]

I am opposed to merging "Slim Jewel Case" into "Jewel Case".  I believe this
is a significant loss of information.  For example, if someone were using
Musicbrainz data to look for a release in a store, and CD's were filed on
shelves with the spine facing outwards rather than the front cover (there
are many stores like this), the fact that something is a 1-disc-slim jewel
case is extremely useful information.  If it were merged such that they now
only know it is a 1-disc-jewel case, the information is useless.

If we're going to allow for uncommon medium formats (e.g., HD-DVD), uncommon
instruments which are nearly identical to other instruments, etc., I don't
see why we want to lose information about a disc packaging that is extremely
common around the world.

(And to the other message talking about cassette jewel cases vs. CD jewel
cases - the medium format already dictates that the size of the jewel cases
differ.  There would be no distinction for CD's if Slim Jewel Case were
merged into Jewel Case.)

On Wed, Jun 22, 2011 at 4:35 AM, Frederic Da Vitoria wrote:

> 2011/6/22, Nicolás Tamargo de Eguren :
> > On Wed, Jun 22, 2011 at 11:11 AM, Kuno Woudt  wrote:
> >> Hello,
> >>
> >> On 20/06/11 22:12, Alex Mauer wrote:
> >>> On 06/20/2011 02:46 PM, Simon Reinhardt wrote:
>  The Super Jewel Box has several varieties, see e.g.
>  http://www.superjewelbox.com/?pagina=products&cat=1 - but adding them
>  all would explode our list and I think we could already gain a lot
>  just from adding the generic term.
> >>>
> >>> -1.
> >>>
> >>> As I see it it’s just a variant form of jewel case, of which there have
> >>> been dozens over the years.
> >>
> >> -1 from me as well.  There are many variations of jewel boxes, this is
> >> just
> >> one of them, I see no need to distinguish between them.
> >
> > Should we merge "Slim Jewel Case" into "Jewel Case" too, in your
> > opinion? (I wouldn't mind it myself either way, but if not it feels
> > weird)
>
> I am not so sure, but there is one difference: the Slim Jewel Case
> does not allow for a booklet. Of course, Jewel Case releases sometimes
> come with a simple single sheet too...
>
> --
> Frederic Da Vitoria
> (davitof)
>
> 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] RFC: Add “Slipcase” to release packaging list

[Yin Izanami]

>> Specifically for releases like a CD jewel box inside a slipcase, we'll
>> have to pick one.  Simon obviously thinks the jewel box should take
>> precedence over slipcase in that situation. I personally don't have an
>> opinion either way, except that we should consistently apply whichever of
>> those two we pick --- hence I think we need a short sentence (probably in
>> the Style/Release guideline).
>
>I would say “use the smallest/most deeply nested/something packaging
>that contains all mediums included in the release”  So a jewel case
>inside a slipcase would be “jewel case”, but two jewel cases inside a
>slipcase would be “slipcase”

I would be okay with this given examples.  Guideline pages are
most effective with examples (useless without examples, really), so if I
understand right:
-A release that is 1 disc in a jewel case, inside a slipcase, should have
the packaging type "Jewel Case"
-A release that is 2 discs in separate jewel cases, bound together in a
slipcase, should have the packaging type "Slipcase"

(the first example was not defined in your initial message, then was brought
up by Simon but not clearly addressed (in my opinion), hence confusion on my
end.)

Additional thoughts:  I wonder if now is the time to file an RFC for adding
medium-level packaging?  (If so, the 1st example would be void.)  My
preliminary thoughts on this would be to have a "plus" button next to
package type as with labels and artist credits for packaging, but the plus
would be to add "subtypes", rather than equal types.  Somewhere (order could
be an issue here) allow each sub-packaging type to be associated with
mediums.
On Wed, Jun 22, 2011 at 1:10 PM, Alex Mauer  wrote:

> On 06/22/2011 03:06 AM, Kuno Woudt wrote:
> > Having said that, I think we will have to establish a guideline on how to
> > use this particular packaging, and I think that should be part of this
> RFC.
>
> I agree.  Should I make a proposal page and a proper RFC-number to
> change Style/Release? (I’m not a fan of that system, but it’s what we have)
>
> > Specifically for releases like a CD jewel box inside a slipcase, we'll
> > have to pick one.  Simon obviously thinks the jewel box should take
> > precedence over slipcase in that situation. I personally don't have an
> > opinion either way, except that we should consistently apply whichever of
> > those two we pick --- hence I think we need a short sentence (probably in
> > the Style/Release guideline).
>
> I would say “use the smallest/most deeply nested/something packaging
> that contains all mediums included in the release”  So a jewel case
> inside a slipcase would be “jewel case”, but two jewel cases inside a
> slipcase would be “slipcase”
>
> Not sure how best to phrase that “smallest/most deeply nested” concept
> though, or if it’s really necessary.
>
> Maybe just tell people “use the packaging that includes all mediums” and
> leave it up to them to use whichever they prefer if there are
> several—that can be cleaned up if/when we have multi-packaging options.
>
> —Alex Mauer “hawke”
>
>
> ___
> 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] iTunes Store: No longer for exclusives?

[Yin Izanami]

Allowing iTunes as a label will open the door for Walmart to be a label
(exclusive tracks on disc), Target to be a label (exclusive tracks on disc),
specialty stores to be a label, etc.

Being able to view a collection of iTunes releases might be useful, but I
think that's bending the label concept in a bad way.

2011/6/22 Nicolás Tamargo de Eguren 

> On Thu, Jun 23, 2011 at 2:45 AM, Lemire, Sebastien 
> wrote:
> > I had a look at the edit notes and I agree with the others. I see iTunes
> as
> > a store/retailer/distributor. Unless an artist is exclusively signed to
> > Apple/iTunes.
> > I'm not religiously involved with Steve Jobs so I don't use iTunes, but
> > doesn't it show the label information? What does it show for the release
> in
> > question?
> > Even if it's an iTunes exclusive, it doesn't mean iTunes is the label.
> > Unless they own the rights to the song.
> > Anyway my take on it...
> > Sebastien
>
> There's absolutely no reason to use iTunes as the label. On the other
> hand, I'd have no problem with people linking to the iTunes store,
> without making them swear the release can't be bought anywhere else.
>
> >
> > On Wed, Jun 22, 2011 at 7:08 PM, Alex Mauer 
> wrote:
> >>
> >> What does the style council think about the idea of widening the
> >> application of the iTunes store?
> >>
> >> It seems to me now that releases can have multiple labels, it would be
> >> good to be able to assign it to more releases, especially where there is
> >> something else distinguishing the release from other digital media
> >> releases (e.g. if an album is available on iTunes on a different date
> >> than other places)
> >>
> >> This post was suggested in discussion on an edit[1]
> >>
> >> 1. http://musicbrainz.org/edit/14691469
> >>
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Nicolás Tamargo de Eguren
>
> ___
> 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

[mb-style] Birthdates without years (aka birthdays)

[Yin Izanami]

Is Musicbrainz interested in capturing birthdays without birth years?
(since it currently doesn't allow a month and date without a year)  Since it
is fairly well known that many countries' SSN are not secure enough (numbers
can sometimes be generated correctly from full birthdates and locations of
birth) many artists do not list their birth year on their online profiles,
but just the date.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] iTunes Store: No longer for exclusives?

[Yin Izanami]

I disagree with having a separate release per lossy/lossless encoding
format.  For example, there is essentially zero audible difference between
Amazon MP3's in high-bitrate VBR and iTunes Plus AAC files at ~256kbps.
Plus, editors are already merging CDDA recordings whose volume levels are
different - it would then not make sense to have separate recordings per
"identical" sounding digital media formats.

In my opinion, the proper place to store encoding information is not in a
separate release per encoding, but in the "can be downloaded from website"
relationship being able to have attributes for common encoding types.  (MP3,
AAC, Vorbis, WMA lossy, WMA lossless, ALAC, FLAC, WAV, I think would be a
comprehensive starting point.)
On Mon, Jun 27, 2011 at 11:35 AM, Johannes Weißl  wrote:

> Hello,
>
> On Mon, Jun 27, 2011 at 05:23:47PM +0200, Kuno Woudt wrote:
> > But if the retailer does their own mp3/whatever encoding, the audio data
> > will have subtle differences when compared with a digital retailer which
> > uses a different audio format, a different bitrate or different encoding
> > software.
> >
> > In general if the audio is not identical, it is a different release.
>
> But what about shops where you can select your own encoding options
> (e.g. bandcamp)? Would we add 5 different releases (or unlimited if you
> could choose the bitrate yourself...)? Of course you can argue that all
> encoded data is from the same PCM data, but this may (probably) be also
> the case for different online shops...
>
> I think if the tracklist and audio data (not the encoded data, but the
> PCM data in the sense as we differentiate recordings) is the same, it
> should only be one release...
>
>
> Johannes
>
> ___
> 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] iTunes Store: No longer for exclusives?

[Yin Izanami]

You're right, my language was not exactly correct.

My point still stands though:  if the release date, release label, release
title, and tracklist's attached recordings are _all identical_ between 2 or
more Digital Media releases, what exactly is stopping us from merging them
into a single release?  If you put it up to a vote, I think the releases
would end up being merged.

But another reason different encodings of the same recording shouldn't be
separate recordings:  PUID's should be identical between them.
On Mon, Jun 27, 2011 at 3:04 PM, Stephen  wrote:

>
> On Jun 27, 2011, at 11:51 AM, Yin Izanami wrote:
>
> > I disagree with having a separate release per lossy/lossless
> > encoding format.  For example, there is essentially zero audible
> > difference between Amazon MP3's in high-bitrate VBR and iTunes Plus
> > AAC files at ~256kbps.  Plus, editors are already merging CDDA
> > recordings whose volume levels are different - it would then not
> > make sense to have separate recordings per "identical" sounding
> > digital media formats.
>
> Be careful in your language. I agree that the recordings should be the
> same, for both of the cases that you mention, but I'm not convinced
> that they should be identical releases.
>
>
> > In my opinion, the proper place to store encoding information is not
> > in a separate release per encoding, but in the "can be downloaded
> > from website" relationship being able to have attributes for common
> > encoding types.  (MP3, AAC, Vorbis, WMA lossy, WMA lossless, ALAC,
> > FLAC, WAV, I think would be a comprehensive starting point.)
>
> Here's a true case where I'd like to store encoding information that
> would be poorly served by this model: I have some songs that were
> released by the artist directly to the internet, after the breakup of
> the band. The band just put them as mp3s up on a random file hosting
> site for anyone to download, since they were never going to get around
> to a proper release, and the original link doesn't work anymore. You
> can still find the files, since fans have reposted the original files
> to keep them available. I'd be hesitant to link to one of those from
> MB. They're far from official and not likely to be too stable. It's
> also easy to imagine there not being a link I could use at all in the
> future. There's a different case where I was sent some mp3s of
> otherwise unreleased stuff as an email attachment by a (also broken
> up, different) band after I'd bought their CD. There's no link
> anywhere, and there's a good chance that until I add them to MB,
> there'll be no mention of their existence either.
>
> I'd want MB to store not only the format information, but also the
> byterate or any other useful information. If I lose the files and need
> to recover them from the web again, I'd like to be able to tell if
> something is a re-encode (meaning data lost) or if it preserves the
> original data quality. I think that's pretty useful information, and
> MB is a good place to store it.
>
> Another, similar case: live recordings. Often circulates with no real
> download link, and while it's generally obvious if it's been re-
> encoded to a lower bitrate since there's almost always lossless
> available somewhere, it's not obvious if a particular copy has gone
> through an analog transfer at some point, which can be guarded against
> by tracking flac fingerprints. If an audio-only fingerprinting
> solution existed for lossy audio I'd use that too probably.
>
> Now obviously these are some extreme cases, but this sort of situation
> isn't unusual as you get to the lower end of the obscurity scale. For
> more normal types of releases, I'm not as worried about it, because
> usually you can source from lossless copies reliably (buy the CD, buy
> it on bandcamp, whatever). And maybe this is information that MB just
> isn't going to track either, which is fine, I can continue to put this
> sort of information in notes, but I do object to the notion that
> encoding information is necessarily reducible to file format
> information, and that it can always live on a download link.
>
> Anyway, I tend to agree with Kuno that different releases are called
> for, although I think it is save to merge all of the different
> Bandcamp encoding options into one, for instance.
>
> -Stephen
>
> ___
> 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] Partial performances of aggregate works

[Yin Izanami]

I would suggest using tags to mark them temporarily if there's really that
much voter resistance.  (It doesn't matter how long your tag is, it could be
a sentence...)

2011/6/29 Nicolás Tamargo de Eguren 

> On Thu, Jun 30, 2011 at 1:21 AM, symphonick  wrote:
> >
> >
> > 2011/6/29 Alex Mauer 
> >>
> >> Though RFC-322 (Partial performances) seems to have been
> >> uncontroversial, it seems that there are still objections being raised
> >> in actual edits[1] on the grounds that some works (those which have
> >> parts) cannot have partial performances.
> >>
> >
> > Just a very short answer for know: a super-work / agregate work is not =
> a
> > work.
>
> A release is also not a recording, but when we don't know to what
> recording something applies we add it to the release. I see a
> parallelism here, so I wouldn't object using the super-work for these
> issues.
> > /symphonick
> >
> > ___
> > MusicBrainz-style mailing list
> > MusicBrainz-style@lists.musicbrainz.org
> > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
> >
>
>
>
> --
> Nicolás Tamargo de Eguren
>
> ___
> 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-Something: Instrumental Attribute for Performance Relationship Type

[Yin Izanami]

I did read the guildeline, but it is unhelpful and confusing in a different
area than you've pointed out.

"Do not use the instrumental attribute for karaoke recordings, see Karaoke
Version Relationship Type instead."

That statement doesn't even begin to lead an editor to the answer of why the
instrumental attribute shouldn't be used to relate a karaoke recording to a
work.  The part after the comma needs to be clarified - Why is a guideline
about Work-Recording relationships telling you to see/use a guideline about
Recording-Recording relationships instead?
On Tue, Jul 5, 2011 at 10:22 AM, Calvin Walton wrote:

> On Tue, 2011-07-05 at 17:17 +0300, Nicolás Tamargo de Eguren wrote:
> > On Tue, Jul 5, 2011 at 5:14 PM, Calvin Walton 
> wrote:
> > > On Mon, 2011-06-27 at 10:12 +0300, Nicolás Tamargo de Eguren wrote:
> > >> The proposal:
> http://wiki.musicbrainz.org/User:Reosarevok/Performed_Relationship_Type_Instrumental_Attribute
> > >
> > > “instrumental”
> > >This indicates that the recording is of an instrumental
> > >arrangement of a work which originally included vocals.
> > >
> > > Hopefully, the mention that it would have to be a new arrangement
> should
> > > be enough to clarify things. (It also clarifies the case of a
> > > performance of a work which was originally instrumental, which was a
> > > little ambiguous previously.)
> >
> > heh. Hip hop songs are normally recorded as two tracks, the
> > instrumental (beat) and the vocal, which are later mixed. So their
> > instrumental versions are not new arrangements: they're just one of
> > the two tracks without the other…
>
> Huh. This is actually surprisingly similar to modern pop song karaoke
> versions, just with a different emphasis. Most modern karaoke tracks are
> made during mixing by simply not including the lead vocal track, leaving
> behind only the backing instrumental portion. Instead of a composition
> of a backing beat + vocals like the hip hop songs, it’s more of a
> decomposition of a complete song into the backing (and sometimes, but
> rarely) vocal tracks.
>
> --
>  Calvin Walton 
>
>
> ___
> 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-Something: Instrumental Attribute for Performance Relationship Type

[Yin Izanami]

If the Instrumental attribute for a Recording-Work is supposed to exclude
the "Lyrics written by" relationship from showing up on that instrumental
recording, then I have no problem with the use of this new attribute.

What I don't understand is why a mention to "Karaoke Version" relationship
is there at all.  That Recording-Recording relationship can't be used with
Works, so why is it mentioned?  What is an editor supposed to learn from
that page as related to the Instrumental attribute of a Recording-to-Work?
2011/7/5 Nicolás Tamargo de Eguren 

> Yin, I kinda agree, and that is why I gave the RFC a second week
> asking for anyone to comment / help with the wording. And nobody did
> :(
> Still, better late than never, I guess. Please discuss the wording :)
>
> On Tue, Jul 5, 2011 at 5:29 PM, Yin Izanami  wrote:
> > I did read the guildeline, but it is unhelpful and confusing in a
> different
> > area than you've pointed out.
> >
> > "Do not use the instrumental attribute for karaoke recordings, see
> Karaoke
> > Version Relationship Type instead."
> >
> > That statement doesn't even begin to lead an editor to the answer of why
> the
> > instrumental attribute shouldn't be used to relate a karaoke recording to
> a
> > work.  The part after the comma needs to be clarified - Why is a
> guideline
> > about Work-Recording relationships telling you to see/use a guideline
> about
> > Recording-Recording relationships instead?
> > On Tue, Jul 5, 2011 at 10:22 AM, Calvin Walton  >
> > wrote:
> >>
> >> On Tue, 2011-07-05 at 17:17 +0300, Nicolás Tamargo de Eguren wrote:
> >> > On Tue, Jul 5, 2011 at 5:14 PM, Calvin Walton <
> calvin.wal...@kepstin.ca>
> >> > wrote:
> >> > > On Mon, 2011-06-27 at 10:12 +0300, Nicolás Tamargo de Eguren wrote:
> >> > >> The proposal:
> >> > >>
> http://wiki.musicbrainz.org/User:Reosarevok/Performed_Relationship_Type_Instrumental_Attribute
> >> > >
> >> > > “instrumental”
> >> > >This indicates that the recording is of an instrumental
> >> > >arrangement of a work which originally included vocals.
> >> > >
> >> > > Hopefully, the mention that it would have to be a new arrangement
> >> > > should
> >> > > be enough to clarify things. (It also clarifies the case of a
> >> > > performance of a work which was originally instrumental, which was a
> >> > > little ambiguous previously.)
> >> >
> >> > heh. Hip hop songs are normally recorded as two tracks, the
> >> > instrumental (beat) and the vocal, which are later mixed. So their
> >> > instrumental versions are not new arrangements: they're just one of
> >> > the two tracks without the other…
> >>
> >> Huh. This is actually surprisingly similar to modern pop song karaoke
> >> versions, just with a different emphasis. Most modern karaoke tracks are
> >> made during mixing by simply not including the lead vocal track, leaving
> >> behind only the backing instrumental portion. Instead of a composition
> >> of a backing beat + vocals like the hip hop songs, it’s more of a
> >> decomposition of a complete song into the backing (and sometimes, but
> >> rarely) vocal tracks.
> >>
> >> --
> >> Calvin Walton 
> >>
> >>
> >> ___
> >> 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
> >
>
>
>
> --
> Nicolás Tamargo de Eguren
>
> ___
> 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] Use of recording comment

[Yin Izanami]

If you really want your tagger to remove ETI from the title tag, why can't
you just use the Work Name instead of the Recording Name?

Moving so much information out of the title and into the comment (which I
believe to be far too radical to reasonable extend beyond "album version"
and "live".. even then there will be exceptions) is only going to create
more work for everyone and make editing even more complicated than it
already is.  With this way, ALL recordings would ideally need to be
pre-created before adding a release, unless the editor wants to wait 3 weeks
for title edits to go through.

On Wed, Jul 6, 2011 at 11:13 PM, Michael Wiencek  wrote:

> On Jul 6, 2011, at 7:54 PM, Johannes Weißl wrote:
>
> > That is why I called it "rule of thumb". It is certainly not meant to
> > cover all possibilities. But if a recording appears on several releases,
> > and removing ETI would cause recording names on one release to clash,
> > this is a good indicator that the recording is different enough to
> > justify the ETI in the name...
>
> If there's a clash on a release somewhere, I'd look at the context
> before deciding what the ETI indicates for the title.
>
> If we include too much version information in recording titles based
> on this method, it might cause the opposite problem for people using
> standardized titles in Picard (having version information that is
> superfluous or of a different context on other releases).
>
> > I have problems with this approach. The comment isn't some normalized
> > information (with style guidelines), it is a comment. It can be e.g.
> > "recorded with a stylus on concert X". I wouldn't want the comment in my
> > track titles (but maybe as COMMENT field in ID3/Vorbis), just as I don't
> > want the artist comment in my artist names. Why should they be handled
> > differently?
>
> They can be normalized if we want them to be. We already have a
> guideline for standardizing the comments of live recordings:
>
>
> http://wiki.musicbrainz.org/Style/Specific_types_of_releases#Live_recordings
>
> I would say "recorded with a stylus on concert X" is more suitable for
> the annotation than the comment field.
>
> > Also, plugins should offer some extra functionality, not fix things that
> > are broken otherwise. If some option in Picard works only with an
> > additional plugin, either Picard or the database needs to be fixed...
>
>
> At least one group of people will consider it broken no matter what the
> guideline is. ;) How might you fix it? Separate fields for "extra title
> information" and "disambiguation comment" in the database?
>
> Michael
> ___
> 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

[mb-style] RFC: Allow multiple ISWC codes per musicbrainz Work

[Yin Izanami]

It may be that a single work isn't supposed to have multiple ISWC codes, but
in reality I believe it is the case that many single works do in fact have
multiple ISWC codes.

I've been searching the ASCAP database (
http://www.ascap.com/ace/search.cfm?requesttimeout=300) for Pokemon
(USA) theme song ISWC codes.  Many if not all of the Pokemon (USA) theme
songs are listed multiple times, and they have multiple ISWC codes for what
is ultimately the same song with same composition and lyrics.

e.g., check writer "ROLFE DAVID KOS" (David Rolfe) and see how many times
"Pokemon Advanced" (Season 6 theme) and "Unbeatable" (Season 8 theme) are
listed.

Thus, it is loss of information if only one ISWC code can be used on a Work.

(I know there's a ticket MBS-2885 for this but there are zero comments on
it.  I figure putting this through RFC/RFV might get it more attention it
needs.. and I assume it should be trivial to get the database to allow
multiple ISWC entries since we can have recordings with multiple ISRC
codes.)
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] policy on merging of recordings

[Yin Izanami]

As long as mastering/mixing/engineering relationships apply to the Recording
level, and can't be moved to a Track/Tracklist level (Release level doesn't
work, because each recording could have different involved people), then
there is absolutely no way you can merge (1) and (2).

This is why I disagree with merging recordings with different volume/peak
levels as well even if they sound the same with volume adjusted.

As for (3), I'd say different encoding types are the same recording, even if
one is lossy and one is lossless, if the number of channels of audio is the
same.  (Can't logically argue that a 7.1 surround sound track is identical
to a mono track.)
On Mon, Jul 11, 2011 at 3:23 PM, Paul C. Bryan  wrote:

> **
> Three examples:
>
> 1. Remasters take original source material, transfer those to digital
> medium, with levels typically adjusted¹ (often to the detriment of the
> recording's dynamic range), then use this new master recording as the basis
> for releases. In most cases, I would expect such a recording have the same
> fingerprint over its multiple releases. Same recording as the original
> release?
>
> 2. I have demonstrable examples where a known recording was transferred
> from master to digital medium more than once. This is not a remaster per
> se—it's the exact same master recording—but levels were appreciably
> different because the audio data was sampled under different circumstances,
> and track time is occasionally different (e.g. slightly different
> fade-outs). Depending on what audio fingerprinting algorithm you use, each
> could have a different fingerprint. Are these the same recording?
>
> 3. The same recording is released with multiple encodings, each of which
> exhibits its own its own (arguably audible) artifacts: DSD, 96 kHz 24 bit
> PCM, 44.1 kHz 16-bit PCM, MP3, AAC, Vorbis. Are these all the same
> recording?
>
> I would lean toward having all of these examples be considered the same
> recording, though I expect someone will probably make a case that the
> remastered release is notable enough to warrant a separate recording. To me,
> it's kind of a content vs. presentation question—do we consider mixing
> levels, for example, to be content? If we do decide to make such
> distinctions, then it's important to come up with some objective methods of
> distinguishing between different recordings, including a textual method for
> expressing such differences.
>
> Paul
>
> ¹  I was tempted to say "remixed" here, but I'm not implying a change to
> the content, just the mixing levels.
>
> ___
> 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-326: Add Artist Type "Other"

[Yin Izanami]

+1, but this needs guidelines / serious thought first.

Gender:  I believe this should be allowed.  Some fictional characters may be
a different gender than the voice actor/actress behind him/her.  It can only
be helpful.

Country:  If we allow this for "other" genders, there need to be guidelines
on fictional characters.  Country the fictional character was created in/for
is not always the same as the country the fictional character is from in the
fictional world.  One or the other must be decided upon.  (I'd prefer the
former.)

Date period:  I'm not sure this should be allowed for fictional characters.
Nothing bothers me more than going to Musicbrainz' "Ranka Lee" artist page
and seeing "Born:  2044 (-32 years ago)".

On Mon, Jul 11, 2011 at 8:54 PM, Johannes Weißl  wrote:

> On Mon, Jul 11, 2011 at 10:55:02PM +0200, Philip Jägenstedt wrote:
> > Sounds good, I guess we'd make most special purpose artists into other.
>
> What about the attributes for the "Other" type? Any suggestions? Should
> these be restricted or completely editable?
>
> Name/Sort name/Comment: Of course allowed.
>
> Gender:  I'm not sure... do we need to express the "fact" that
> "Mickey Mouse" is male? I would reserve this for real
> persons only.
> Country: Difficult... could be used for companies, but might not
> be needed/wanted.
> Date Period: Same as for "Country".
> IPI code:Can non-groups/non-persons have an IPI code? If not, this
> can be greyed out.
>
>
> Johannes
>
> ___
> 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: Allow multiple ISWC codes per musicbrainz Work

[Yin Izanami]

I don't know why you can't see them.  I just reproduced it easily.

Pokemon Advanced:
Work ID: 460645883, ISWC: T0726736339
Work ID: 460601563, ISWC: T0726733807
Work ID: 460591422, ISWC: T0726733181

Unbeatable:
Work ID: 461643534, ISWC: T0727508191
Work ID: 510692156, ISWC: T9057933490
Work ID: 510172708, ISWC: T0727129658
Work ID: 510403735, ISWC: T0727547252

I didn't even go looking specifically for the movie themes, which in later
Pokemon USA movies, aren't even covers but simply extended arrangements.

Besides which, even if they are "arrangements" (I highly suspect the only
difference is +/- 20 seconds), in terms of Musicbrainz they aren't different
works.  The exact same people are involved and again, I highly suspect the
only difference is the removal or addition of parts of verses.

On Tue, Jul 12, 2011 at 2:35 AM, Aurélien Mino  wrote:

> On 07/11/2011 09:27 PM, Yin Izanami wrote:
> > It may be that a single work isn't supposed to have multiple ISWC
> > codes, but in reality I believe it is the case that many single works
> > do in fact have multiple ISWC codes.
> > I've been searching the ASCAP database
> > (http://www.ascap.com/ace/search.cfm?requesttimeout=300) for Pokemon
> > (USA) theme song ISWC codes.  Many if not all of the Pokemon (USA)
> > theme songs are listed multiple times, and they have multiple ISWC
> > codes for what is ultimately the same song with same composition and
> > lyrics.
> > e.g., check writer "ROLFE DAVID KOS" (David Rolfe) and see how many
> > times "Pokemon Advanced" (Season 6 theme) and "Unbeatable" (Season 8
> > theme) are listed.
>
> Could provide a concrete example? (ASCAP work ids, and related ISWCs).
> I tried to reproduce, but I don't see so many times "Pokemon Advanced"
> and "Unbeatable".
>
> > Thus, it is loss of information if only one ISWC code can be used on a
> > Work.
> > (I know there's a ticket MBS-2885 for this but there are zero comments
> > on it.  I figure putting this through RFC/RFV might get it more
> > attention it needs.. and I assume it should be trivial to get the
> > database to allow multiple ISWC entries since we can have recordings
> > with multiple ISRC codes.)
>
> I have a problem with your proposal:
> While your example is probably showing (I can't really judge) that a
> work might have multiple ISWCs because rights management societies are
> not doing their job correctly,
> in most cases a work should have only one ISWC code.
> And if you find a second ISWC for the same work, you should investigate
> and you often realize that there are in fact 2 distinct works (e.g. with
> a new arrangement or orchestration).
>
> I fear that just allowing multiple ISWCs on a work will lead to distinct
> works being incorrectly represented by only one work in DB.
>
> So my prerequisites to this proposal are:
> - adding a second ISWC should be strongly discouraged in the user
> interface (including when you're going to merge works with different ISWCs)
> - have a way to easily split a work (like what is proposed here:
> http://tickets.musicbrainz.org/browse/MBS-2095)
>
> - Aurélien
>
> ___
> 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: Allow multiple ISWC codes per musicbrainz Work

[Yin Izanami]

Just in case it wasn't clear - Arrangement relationship can't be attached at
the Work level in Musicbrainz.  hence why they aren't new Musicbrainz works.

On Tue, Jul 12, 2011 at 6:51 AM, Yin Izanami  wrote:

> I don't know why you can't see them.  I just reproduced it easily.
>
> Pokemon Advanced:
> Work ID: 460645883, ISWC: T0726736339
> Work ID: 460601563, ISWC: T0726733807
> Work ID: 460591422, ISWC: T0726733181
>
> Unbeatable:
> Work ID: 461643534, ISWC: T0727508191
> Work ID: 510692156, ISWC: T9057933490
> Work ID: 510172708, ISWC: T0727129658
> Work ID: 510403735, ISWC: T0727547252
>
> I didn't even go looking specifically for the movie themes, which in later
> Pokemon USA movies, aren't even covers but simply extended arrangements.
>
> Besides which, even if they are "arrangements" (I highly suspect the only
> difference is +/- 20 seconds), in terms of Musicbrainz they aren't different
> works.  The exact same people are involved and again, I highly suspect the
> only difference is the removal or addition of parts of verses.
>
> On Tue, Jul 12, 2011 at 2:35 AM, Aurélien Mino  wrote:
>
>> On 07/11/2011 09:27 PM, Yin Izanami wrote:
>> > It may be that a single work isn't supposed to have multiple ISWC
>> > codes, but in reality I believe it is the case that many single works
>> > do in fact have multiple ISWC codes.
>> > I've been searching the ASCAP database
>> > (http://www.ascap.com/ace/search.cfm?requesttimeout=300) for Pokemon
>> > (USA) theme song ISWC codes.  Many if not all of the Pokemon (USA)
>> > theme songs are listed multiple times, and they have multiple ISWC
>> > codes for what is ultimately the same song with same composition and
>> > lyrics.
>> > e.g., check writer "ROLFE DAVID KOS" (David Rolfe) and see how many
>> > times "Pokemon Advanced" (Season 6 theme) and "Unbeatable" (Season 8
>> > theme) are listed.
>>
>> Could provide a concrete example? (ASCAP work ids, and related ISWCs).
>> I tried to reproduce, but I don't see so many times "Pokemon Advanced"
>> and "Unbeatable".
>>
>> > Thus, it is loss of information if only one ISWC code can be used on a
>> > Work.
>> > (I know there's a ticket MBS-2885 for this but there are zero comments
>> > on it.  I figure putting this through RFC/RFV might get it more
>> > attention it needs.. and I assume it should be trivial to get the
>> > database to allow multiple ISWC entries since we can have recordings
>> > with multiple ISRC codes.)
>>
>> I have a problem with your proposal:
>> While your example is probably showing (I can't really judge) that a
>> work might have multiple ISWCs because rights management societies are
>> not doing their job correctly,
>> in most cases a work should have only one ISWC code.
>> And if you find a second ISWC for the same work, you should investigate
>> and you often realize that there are in fact 2 distinct works (e.g. with
>> a new arrangement or orchestration).
>>
>> I fear that just allowing multiple ISWCs on a work will lead to distinct
>> works being incorrectly represented by only one work in DB.
>>
>> So my prerequisites to this proposal are:
>> - adding a second ISWC should be strongly discouraged in the user
>> interface (including when you're going to merge works with different
>> ISWCs)
>> - have a way to easily split a work (like what is proposed here:
>> http://tickets.musicbrainz.org/browse/MBS-2095)
>>
>> - Aurélien
>>
>> ___
>> 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-326: Add Artist Type "Other"

[Yin Izanami]

Actually I know of a couple cases where fictional characters are assigned
composition credits.  _Maybe_ with research the real people could be
discovered, but it's also possible you wouldn't find anything.

e.g.,
http://musicbrainz.org/artist/c6eda16b-1cc1-4c82-8ab7-50a18aac5791/relationships
(this is a fictional character credited as a lyricist).  And yes, even
JASRAC credits the fictional artist.  (See JASRAC work code 159-6996-7)

On Tue, Jul 12, 2011 at 4:25 AM, Johannes Weißl  wrote:

> Hello Nicolás,
>
> On Tue, Jul 12, 2011 at 10:42:22AM +0300, Nicolás Tamargo de Eguren wrote:
> > > IPI code:Can non-groups/non-persons have an IPI code? If not, this
> > > can be greyed out.
> > Labels do have an IPI code, and there are a few cases where we need to
> > add them as artists now (for some exec producer or even normal
> > producer credits, for example). The rest of the examples probably
> > wouldn't have, as an imaginary character, for example, can't write a
> > song…
>
> Ok, since all attributes could be of use for "Other", I have updated the
> proposal [1]:
>
>All attributes / link phrases etc. should be the same as with type
>"Unknown".
>
> [1] http://wiki.musicbrainz.org/Proposal:Artist_Type_Other
>
>
> Johannes
>
> ___
> 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-327: Featured Artists

[Yin Izanami]

If we go this literally with "as on cover" for tracklists, and therefore
normalize recordings to have all artists in the artist field, not in the
title field, then...

Can the server look at the recordings attached to a release's tracklist to
see the artist credits of the recordings?  If so, the server could
theoretically list the release on the pages of artists which show up in the
recordings but are missing in the tracklist.

On Mon, Jul 18, 2011 at 1:02 PM, Alex Mauer  wrote:

> On 07/18/2011 05:30 AM, Andii Hughes wrote:
> > 1. If the cover says 'X (feat. Y)' by Z, then artist credit is Z,
> > title is 'X (feat. Y)'
> > 2. If the cover says 'X' by Z feat. Y then artist credit is Z +
> > join-phrase ' feat. ' + Y and title is 'X'
> > 3. If the cover says 'X (with new singing sensation Y)' by Z, then
> > artist credit is Z, title is 'X (with new singing sensation Y)'
> > 4. If the cover says 'X' by Z with his best friend Y, then artist
> > credit is Z + join-phrase ' with his best friend ' + Y and title is
> > 'X'.
> > and so on...
> >
> > i.e. whatever is on the cover...
>
> +1 to all of this.
>
> Those of us (myself, for one) who want more normalized titles can have
> their tagger look at the recordings or the works instead of the tracklists.
>
> The one downside I can see to this is that the feat. artist will not
> have that release appear in their releases because they don’t have an
> artist credit on it (it will only appear in relationships).  I don’t
> know if that’s enough of a problem for it to mean we need an exception
> guideline to the “as on the cover” concept.
>
> —Alex Mauer “hawke”
>
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@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