Rachel Dwight | 18 Aug 17:53 2014

RFC STYLE-332: Even more new packaging types

As we are all aware, there are a plethora of packaging types that we have yet to account for in MB. Here are two big ones:

SnapPack - The classic 8cm CD packaging. A plastic frame with a cardboard outer cover (sometimes with an additional plastic outer shell), designed so it can fold ("snap") in half. Sometimes mistakenly called "snap case."
Image: https://en.wikipedia.org/wiki/Mini_CD_single#mediaviewer/File:Japanese_CD_Single_6-by-3-in_cover,_opened.JPG

Library case - A box designed to hold a VHS tape. Usually made of hard plastic but some (usually tapes containing feature films) were made of vinyl with padding inside. May or may not have hubs inside to hold the tape spools in place. While this packaging was mainly used for VHS, smaller versions were sometimes used for audio cassettes. 
Image without hubs: http://ep.yimg.com/ay/ldb-cdpackaging/clear-vhs-library-case-video-case-full-sleeve-no-hub-psv14-100-pcs-9.gif 
Image with hubs: http://ep.yimg.com/ay/ldb-cdpackaging/100-pcs-vhs-library-case-with-hub-clear-full-sleeve-psv14hub-3.gif
Image of compact cassette-size case: http://auctions.c.yimg.jp/img339.auctions.yahoo.co.jp/users/0/4/8/5/teruakiteru_60-img553x600-1376211776swzxs741319.jpg

Ticket: http://tickets.musicbrainz.org/browse/STYLE-332
Expected expiration date: 2014-8-24
MusicBrainz-style mailing list
Rachel Dwight | 15 Aug 06:49 2014

Pre-RFC: Rename disambiguation field "Description"

https://musicbrainz.org/doc/Disambiguation_Comment states that disambiguation comments are intended to differentiate between/among 2 or more identically named artists/labels/entities. It explicitly states that the field is not to be used as a general description field, yet some editors are dead set on using it for this purpose. They claim it’s a pre-emptive strike, but I don’t buy it. If we’re going to abuse the disambiguation field in this manner, it should be renamed to better suit its purpose.

This thread is to only be used to discuss renaming the disambiguation field. If enough support is shown I will open a new thread to alter the disambiguation document to allow for similar or confusing names.
MusicBrainz-style mailing list
caller#6 | 6 Aug 20:17 2014

RFC: STYLE-331 "add 'composite reissue' relationship"

Hi all,

This proposal would add a relationship linking original release-groups 
with what I'm calling 'composite reissues', (e.g. box sets, 2-in1s etc).

The purpose would be: to indicate that an earlier release-group is/was 
also availble as part of a later, larger release-group. This will become 
more important if 2-in-1s are reclassified as compilations (where they 
might become lost in a long list of "best of" titles).

The appropriate use for this relationship would be: when a composite 
reissue reproduces cover art, track lists and release titles from 
previous release-groups. So, merely including a single in a generic 
"best of" compilation would not be an appropriate use (since that is 
already clear when looking at the recording).

I'm not super-happy with the term 'composite reissue'. Please suggest 
something better!

(I'm not crazy about 'bundle' either, mostly because it implied (to me) 
several products bundled together at a reduced price)

Alex / caller#6


     proposal to reclassify 2-in-1s as compilations:

    relevant forum thread:
Tom Crocker | 4 Aug 19:04 2014

box sets etc.

I'm starting a separate thread for all discussion of a new type (be it primary or secondary) for box sets (or whatever we might call them) so bflaminio's RFC [1] doesn't get hijacked.
There's some existing discussion on this at [2]

Personally, I'd be in favour of this as a primary type. I think box set is a good choice of name because it's recognisable and understood in the sense we mean [3] but a bad choice because it conflates packaging and release group content. Perhaps just 'set' would do, but I still think it's difficult to define in a useful way.
MusicBrainz-style mailing list
Patrick Hubenthal | 4 Aug 08:29 2014

Auto Response

From July 27–August 10, I'll be traveling and will be checking my e-mail only occasionally.  I'll respond as soon as possible after I get back.

MusicBrainz-style mailing list
bflaminio | 4 Aug 05:01 2014

RFC: Make 2-on-1 (or generically, M-on-N) release groups "Compilations"

The Release Group style guide indicates that the following is not considered
a "compilation":

"A release containing two albums and/or EPs." (1)

Musicbrainz defines a compilation as:

"a collection of recordings from various old sources (not necessarily
released) combined together." (2)

A 2-on-1 release fits this definition precisely, and is only excluded from
being a compilation because the style guide says so, and not for any
particularly logical reason.

Furthermore, if we ignore the number of discs as being significant, there
are a great many "M-on-N" releases, with all but the 2-on-1 variety already
considered compilations without question.


2-on-1 :
4-on-2 :
5-on-5 :

All the way up to releases like this:

The 2-on-1 is different only in the sense that it is a single disc, but it
is still a collection of previously released recordings, and not a new
release, and therefore it should be a compilation.

The proposal is to remove the line "A release containing two albums and/or
EPs." from the official style guide and associated documents.

(1) https://musicbrainz.org/doc/Style/Release_Group#Secondary_types
(2) http://musicbrainz.org/doc/Release_Group/Type

View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Make-2-on-1-or-generically-M-on-N-release-groups-Compilations-tp4667103.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
Per Starbäck | 3 Aug 21:12 2014

Sorting of fictitious names

Earlier a fictitious name like "Mickey Mouse" should be sorted as
"Mickey Mouse", and not "Mouse, Mickey" as if it was a real person,
but RFC 203 aimed to change that.

See http://lists.musicbrainz.org/pipermail/musicbrainz-style/2010-March/008876.html
where that is mentioned, and
where this clause is removed.

* For artist names that are ficticious names, the sort name is the
same as the artist name.

One problem here is that after this edit nothing is said about the
sorting of names like this. I guess those supporting this RFC thought
the special handling of fictitious names was a strange anomaly in the
guidelines, so by removing the clause it would still be evident how to
sort these names. But sorting fictitious names as we did previously is
really the traditional way, so I think this needs to be explicitly
stated regardless of which way we want to do it!

 I see that Wikipedia also normally sorts in the non-traditional way.
(At http://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Fictional_characters/Archive_2#DEFAULTSORT:
argues against it without result.) Maybe this is the new emerging
standard, but I still think you wouldn't find many books which will
put "Mouse, Mickey" in the index, and there are still lots of old
geezers like me around, so please state this new rule explicitly!
Lotheric | 7 Jul 01:39 2014

RFC STYLE-326: New packaging type: Longbox

RFC expected expiration date: 2014-07-14.

I would like the Longbox packaging type to be added.


Longbox: A large cardboard box used to package for retail sale music CDs
(and their jewel box)
in order to fit in store fixtures designed for vinyl records. It was used in
North America
and was phased out during the mid-90's. Aside from the occasional box-set or
vanity CD packaging,
longbox packaging is largely obsolete.


- Lotheric

View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-326-New-packaging-type-Longbox-tp4666528.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
Rachel Dwight | 25 Jun 16:24 2014

Ranged catalog numbers

This is a continuation of a discussion that sprang up in http://musicbrainz.1054305.n4.nabble.com/Pre-RFC-Japanese-extra-title-information-td4666219.html and caused that thread to veer off course.

Many multi-disc releases have catalog numbers that are printed as XXXX-12345~6 or XXXX-12345/6. These numbers are referred to as “ranges” because they indicate the presence of multiple catalog numbers on the release, one for each disc. We are currently split on how to handle their display. Previously it was only possible to add one label and catalog number per release, so having a range of catalog numbers was useful. Now it is possible to add more than one label and catalog number per release. 
I am in the camp that says we should take advantage of this feature by listing each individual catalog number. This is useful in the case of box sets where each medium comes in its own container and has its own catalog number. For other multi-disc releases (e.g. a CD single bundled with a DVD), however, it can cause some confusion because unwary users might not know where the second number came from. I can understand where this comes from, and am willing to figure out a compromise or a way to explain the phenomenon, such as a user’s guide.

Thoughts/discussion welcome. Let’s just please keep it confined to this thread.
MusicBrainz-style mailing list
Lemire, Sebastien | 22 Jun 04:19 2014

Pre-RFC Japanese extra title information

Hi guys, I'd like to bring some clarification on some specific Japanese style points that are not mentioned in the official Japanese style.

Hi guys

I'm currently cleaning/merging the サザンオールスターズ works/recordings/tracks and find some inconsistencies as to how to extra title information is handled. Basically, I'm pretty sure there's no standard for this in Japan and we get variations depending on the source and it's often not clear even on the cover. As such, I think it would be a good idea to standardize for us so that we have consistent work, recording and track names.

The first has to do with the adding of information after the track title in between ~ characters.

1.) あなただけを ~Summer Heartbreak~ vs あなただけを~Summer Heartbreak~ (no space) vs あなただけを〜Summer Heartbreak〜
2.) 愛の言霊 ~Spiritual Message〜 (Exact same problem)

I think we should standardize on two things:
1.) do we use the ~ or the 〜? (I think there was a discussion somewhere on this but couldn't find it, it might have been in edits) (there's also the english ~ but that one really shouldn't be used)
2.) Do we include a space or not between the two parts?

The second point has to do with additional information (sometimes a kana reading) added within () either somewhere in the middle, or in the end. Do we use the Japanese ()or the english ()? Secondly,should we include a space to separate the main title and the added detail?

1.) JAPANEGGAE (ジャパネゲエ) vs JAPANEGGAE(ジャパネゲエ)
3.) 愛する女性(ひと)とのすれ違い vs 愛する女性 (ひと) とのすれ違い

I'd like in this Pre-RFC phase to discuss what you guys think, come up with a standard so that a proper RFC can be put made to update the offical Japanese style

Personally, for ~ or the 〜. I don't honestly know the difference and either is fine with me. For the ()vs (), I strongly prefer the Japanese (). Finally regarding the spaces, I don't really care much one way or another. Either is fine with me.


MusicBrainz-style mailing list
Alex Mauer | 15 May 18:36 2014

Classical title style: untitled works / update for "Series"

With the new schema release, we have a new option for recording 
information about classical catalogs.

But this along with some other changes brings a new problem for work 
titles: Many of them don’t have a title per se.

For example the work which is completely (?)
“Suite in B-flat major for 13 wind instruments, op. 4, TrV 132”

We can now drop the “op. 4” and “TrV 132” as they belong to their 
respective catalogs. We can drop “in B-flat major” as that is a work 
attribute. “Suite” is the work type. That leaves “…for 13 wind 
instruments” but that doesn’t really stand on its own. So we really need 
the work type in the title.

So, how much is the right amount to keep in the title?

I think at the least we should drop the various catalog numbers (op. 4, 
TrV 132) because when there are several catalogs involved the title gets 
very long and ugly. They do need to be moved to disambiguation for now 
though so that they remain identifiable in search results.

That leaves type, instrumentation, and key.

Instrumentation gets weird when an performance is on a different 
instrument than the work was originally created (is it still “Concerto 
for clarinet” when it’s performed on a flute?) so I would be OK with 
dropping that.

Anyone else have thoughts on the matter?