Re: [mb-style] Multiple alternate translations for track names and release titles

On 01/13/2015 05:50 PM, Nicolás Tamargo de Eguren wrote: > So, in the above example, track one would be: > > [English]: The Planets, op. 32: Mars, the Bringer of War. Allegro > [German]: Die Planeten, op. 32: Mars, der Kriegsbringer. Allegro > [French]: Les Planètes, op. 32: Mars

Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?

On 11/27/2014 05:08 AM, ListMyCDs wrote: > I see little benefits for splitting hybrid SACD discs to multiple > mediums. We currently have "Hybrid SACD" as a medium format which > already means there's also standard CD layer available. It could also be > extremely confusing to see "1xCD, 2xSACD"

Re: [mb-style] Style for classical track titles (STYLE-344)

On 10/29/2014 05:11 PM, David Gasaway wrote: >> I'm all for removing standardization on classical track titles (apart from >> prepending the work name as recommended in your draft). > > Not I. I would like *some* consistency from release to release. > >> If a user wants to use >> some kind of st

Re: [mb-style] Style for classical track titles (STYLE-344)

On 10/29/2014 01:32 PM, Nicolás Tamargo de Eguren wrote: > Right now it does not mention movement numbering at all. That's > intentional (I feel 1. vs. I. is fairly minor and can be left to > people's preference or used as on the release) but if people think it > should be standardised, we can do

Re: [mb-style] RFC: STYLE-335: Add "Box set" as a primary type of Release Group

On 08/25/2014 07:09 AM, Rachel Dwight wrote: > > What I meant was I have seen box sets that consist entirely of reissued > singles instead of albums > (example: > http://musicbrainz.org/release-group/cad99d90-fc2e-46b6-b3b4-4b06b0f05ad8). > I guess I wasn’t clear. I don’t think that would be a g

Re: [mb-style] box sets etc.

On 08/04/2014 01:32 PM, bflaminio wrote: > Intuitively I perceive a distinction between a "compilation", "box set", and > "anthology"; but I have no idea how to unambiguously define each. Might be ambiguous, but: Compilation: collection of recordings from a variety of sources, possibly by several

Re: [mb-style] RFC: Make 2-on-1 (or generically, M-on-N) release groups "Compilations"

On 08/03/2014 10:01 PM, bflaminio wrote: > The proposal is to remove the line "A release containing two albums and/or > EPs." from the official style guide and associated documents. +1 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbr

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/17/2014 08:24 AM, jesus2099 wrote: > Alex Mauer wrote >> the way the fullwidth parenthesis fakes it by including the space as >> part of the parenthesis character, is the problem. > > there is no faking, all characters are put in a same sized box, it’s the > princ

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/10/2014 01:10 PM, Kuno Woudt wrote: >>> No, it is normal that 恋の子守歌/焼鳥を食べるな!(カラオケ) looks awkard it’s not a brwoser >>> bug. >>> You have to use ばか馬の子守歌／焼鳥を食べるな！（カラオケ） like printed as it’s made for that >>> especially. >> They both look fine in Thunderbird (though I would insert a space before

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/10/2014 08:30 AM, jesus2099 wrote: > Alex Mauer wrote >> If it looks awkward, that means the browser (or whatever is displaying >> the text) needs its text rendering fixed. I don’t think it’s the >> responsibility of Musicbrainz editors to work around text rendering &g

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/08/2014 10:08 AM, jesus2099 wrote: > it’s just a matter of copy what we see, knowing that it will most often be > the CJK punctuation and fullwidth punctuation that was in use. As otherwise > it looks rather awkard most often. If it looks awkward, that means the browser (or whatever is displ

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/07/2014 09:12 AM, jesus2099 wrote: > IMO, we don’t need rules, we don’t need no more headaches, we just need to > follow what is printed, except mistakes. The caps are already followed as is > for japanese tracklists anyway. > Except mistakes, we go on using ! if ! is printed (halfwidth) and

Re: [mb-style] RFC STYLE-326: New packaging type: Longbox

On 07/07/2014 12:22 AM, Rachel Dwight wrote: > I guess I wasn’t clear. We already vetoed Slipcase and Box as cover > art types on the grounds that they do not house the medium itself. I don’t think those have ever been proposed as cover art types. They weren’t vetoed but withdrawn because I didn’

Re: [mb-style] RFC STYLE-326: New packaging type: Longbox

On 7/6/2014 6:39 PM, Lotheric wrote: > RFC expected expiration date: 2014-07-14. > > I would like the Longbox packaging type to be added. +1, I see no reason not to have this. It should perhaps also be a cover art type as Rachel suggested though. ___

Re: [mb-style] Pre-RFC Japanese extra title information

On 07/03/2014 09:09 AM, Rachel Dwight wrote: > I agree with using 。and 、but I’m on the fence about ！and ？. They are > huge and clunky, but substituting ! and ? sometimes screws up character > spacing. I have compensated for this by adding a space after such > characters (like is normally done for E

Re: [mb-style] Ranged catalog numbers

On 06/25/2014 12:50 PM, jesus2099 wrote: > BTW i saw Hawke’s concern about searches if we keep split catalogue numbers > (per medium) in another topic. > The searches are usually performed on first medium’s catalogue number anyway > so np imo. > > ex. for KIZC-101〜113 > > https://duckduckgo.com/?

Re: [mb-style] Ranged catalog numbers

On 06/25/2014 09:24 AM, Rachel Dwight wrote: > Many multi-disc releases have catalog numbers that are printed as > -12345~6 or -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 cur

Re: [mb-style] Pre-RFC Japanese extra title information

On 06/24/2014 09:50 PM, Rachel Dwight wrote: > Ditto. I don’t know if you caught it but I did mention that we need to > stop using ranges for catalog numbers. A range is a placeholder for > multiple catalog numbers. Now that we can add more than one catalog > number to a release, we should take adv

Re: [mb-style] Pre-RFC Japanese extra title information

On 06/21/2014 09:19 PM, Lemire, Sebastien wrote: > 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

Re: [mb-style] RFC STYLE-318: Rights society affiliation relationships

On 6/2/2014 2:15 AM, Rachel Dwight wrote: > OK, I added a little more clarification of the word “affiliation.” > http://wiki.musicbrainz.org/User:HibiscusKazeneko/Rights_society_affiliation The definition definitely makes it more understandable. +1. A couple of thoughts: Split the description i

Re: [mb-style] Classical title style: untitled works / update for "Series"

On 05/16/2014 12:28 PM, SwissChris wrote: > That's just doubling the work. ''Discussing'' > how we should handle the new features is ok, but mingling with the data > (as auto-edits!) against the guidelines before there has been a > discussion is abusive. First, if anything this is doubling the wor

Re: [mb-style] Classical title style: untitled works / update for"Series"

On 05/16/2014 06:45 AM, Brant Gibbard wrote: > I agree, I do not want to see catalogue numbers removed from the work > titles until there is a way to search them. I am thinking particularly > of composers like Vivaldi or Bach with very large catalogues and many > works with very similar, or sometim

Re: [mb-style] Classical title style: untitled works / update for "Series"

I basically agree with everything you said. Comments inline. On 05/15/2014 12:38 PM, Maurits wrote: > I still think just > the work title should give the user enough information to be fairly sure > what he/she is looking at. That’s the problem: if a tracklisting just says “Strauss: Horn Concerto

[mb-style] 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 w

Re: [mb-style] Japanese catalog numbers

On 05/13/2014 08:50 AM, Rachel Dwight wrote: >> Based on the actual releases, if anything we should "standardize" on a >> space, not a dash. >> >> Or are we just looking at the wrong labels, maybe? > > King Records is a tricky case. I’ve seen certain imprints of theirs > where they did use dashes o

Re: [mb-style] Japanese catalog numbers

On 5/12/2014 12:41 PM, Duke Yin wrote: > https://docs.google.com/spreadsheets/d/1Dkeoj6eqy_YG0CM6WmqGYo_0xN1b67B80uRrEaUXF8s/edit?usp=sharing > > This does not cover every release ever distributed, but it should cover > the vast majority of the last 20+ years. 85% of these releases are > already s

Re: [mb-style] Japanese catalog numbers

On 5/11/2014 3:08 AM, Rachel Dwight wrote: > > On May 11, 2014, at 2:55 AM, Frederik Freso S. Olesen > wrote: > >> Den 11-05-2014 09:04, Rachel Dwight skrev: >>> Yes, this issue came up again. The community is split down the >>> middle as to how to handle Japanese catalog numbers. Currently we >>>

Re: [mb-style] RFC add ISBN to works

On 4/9/2014 7:52 AM, Daniel Sobey wrote: > Expected expiration date: 23rd of April 2014 > Ticket: STYLE-314 http://tickets.musicbrainz.org/browse/STYLE-314 > > An isbn is a barcode used for books. > For recordings of audiobooks we can have a work representing the prose. > I would like to add ISBN a

Re: [mb-style] RFV STYLE-311: Add 'Demo' as secondary release group type

On 3/31/2014 2:46 PM, lixobix wrote: > Add 'Demo' as secondary release group type. This would allow demos and > (non-live/broadcast) studio sessions to be categorised correctly. > > Definition: > > A demo is a release that contains preliminary material by an artist, with > the intention that some o

Re: [mb-style] RFC-309: Add work attribute "first publication"

On 3/20/2014 8:52 PM, ListMyCDs wrote: > On 21.3.2014 2:29, jesus2099 wrote: >> Maybe it’s a stupid answer but can’t we simply set the work-label PUBLISHER >> relationship date ? > > I'm proposing to store FIRST publication date. I agree that same > information could be stored by using relationship

Re: [mb-style] RFC-309: Add work attribute "first publication"

On 3/21/2014 12:16 AM, Tom Crocker wrote: > Sorry to go off topic, but I like imslp's average duration. Maybe we > could automagic that in the same kind of way as planned for recordings That would be awesome. 'median' might be a better choice though.

Re: [mb-style] RFC-STYLE-273. New relationship attribute : “unsure”

On 3/6/2014 10:30 PM, Rachel Dwight wrote: >> Though I think it should probably be called "maybe" (e.g. "maybe drums" >> rather than "unsure" -- "unsure drums" sounds weird) > > Maybe “unconfirmed” would be better? "unconfirmed drums"? a little weird, but better than "unsure", yeah. ___

Re: [mb-style] RFC-STYLE-273. New relationship attribute : “unsure”

On 3/6/2014 9:17 PM, Alex Mauer wrote: > On 3/6/2014 5:33 AM, jesus2099 wrote: >> could be called unsure, unverified, etc. I let the english speakers find the >> appropriate work. >> >> for cases like « The song is sometimes co-credited to Reginald Connelly » >> b

Re: [mb-style] RFC-STYLE-273. New relationship attribute : “unsure”

On 3/6/2014 5:33 AM, jesus2099 wrote: > could be called unsure, unverified, etc. I let the english speakers find the > appropriate work. > > for cases like « The song is sometimes co-credited to Reginald Connelly » > but not only — for guesses too for instance. > please refer to http://tickets.musi

Re: [mb-style] RFC STYLE-298: New packaging type: Brilliant Box

On 3/3/2014 5:31 PM, Marko wrote: > RFC expected expiration date: 2014-03-11. > > I would love to see Brilliant Box as a new packaging type. It’s like a > Jewel Case from the outside, but inside it fits 2 discs, as it has extra > plastic piece inside, that can hold 1 disc on each side. > It can be

Re: [mb-style] RFC-STYLE-296. remove bogus attribute work-work version TRANSLATED

On 3/1/2014 4:10 AM, Nicolás Tamargo de Eguren wrote: > I think part of the problem here is that "translation" is currently used > pretty much as "some lyrics in a different language" whether it's a > translation or not (which IMO is a mistake) rendering it meaningless. If > we did indicate actual

Re: [mb-style] RFC STYLE-287: Move USB and slotMusic formats out of Digital Media

On 1/27/2014 6:02 PM, Nicolás Tamargo de Eguren wrote: > So, any strong opposition to move USB and slotMusic under "Other" > instead? I'll give it a couple more days (until the 30 or so) and RFV if > I have received at least a +1 for this specific change and no strong > opposition :) +1

[mb-style] post-RFV STYLE-283: “Imprint” label type / AR

On 01/27/2014 03:20 AM, Nicolás Tamargo de Eguren wrote: > Relationship added. Type will be added when the devs are around. Please > update http://wiki.musicbrainz.org/Label/Type in the meantime :) Done. I may have strayed a bit into -style territory with the “Imprint vs. Company” section, but I

Re: [mb-style] RFV STYLE-283: “Imprint” label type / AR

On 1/24/2014 11:44 AM, Alex Mauer wrote: > STYLE ticket: http://tickets.musicbrainz.org/browse/STYLE-283 > Proposed AR documentation: > http://wiki.musicbrainz.org/User:Hawke/Proposal/Imprint_AR > Previous discussion: > http://chatlogs.musicbrainz.org/musicbrainz/2014/2014-01/2014

[mb-style] RFV STYLE-283: “Imprint” label type / AR

STYLE ticket: http://tickets.musicbrainz.org/browse/STYLE-283 Proposed AR documentation: http://wiki.musicbrainz.org/User:Hawke/Proposal/Imprint_AR Previous discussion: http://chatlogs.musicbrainz.org/musicbrainz/2014/2014-01/2014-01-14.html#T01-14-41-677717 Expiration date: 2014-01-26 As the R

Re: [mb-style] RFV STYLE-282: add "mini-album" primary type

On 1/22/2014 10:03 AM, Kuno Woudt wrote: > Hello, > > On 01/22/2014 04:33 PM, Mihai Spinei wrote: >> Got a couple of +1s for mini-albums, so I'd suggest to add just them for >> now, will debate maxi-singles later. RFV > > I'm not convinced difference between EP and mini-album is significant > enoug

Re: [mb-style] RFC STYLE-287: Move USB and slotMusic formats out of Digital Media

On 01/20/2014 11:29 AM, Nicolás Tamargo de Eguren wrote: > Under *that* point of view, they shouldn't necessarily be listed > together just because of it anyway, since those three aren't. Heh, fair enough. Maybe they should both be placed under “other” given how rare they are? Especially so for

Re: [mb-style] RFC STYLE-287: Move USB and slotMusic formats out of Digital Media

On 01/20/2014 11:22 AM, Nicolás Tamargo de Eguren wrote: > Under that point of view, they are packagings, not formats, and should > just disappear from the format tree. Which I'd also probably agree with, > myself, but if they were put there I imagine it's because someone > considered them formats.

Re: [mb-style] RFC STYLE-287: Move USB and slotMusic formats out of Digital Media

On 01/20/2014 04:04 AM, Nicolás Tamargo de Eguren wrote: > "Digital Media" is effectively "Download" - but having USB and slotMusic > (microSD) under it makes it much less obvious. The current hierarchy > never went through style. Discussion of STYLE-177 >

Re: [mb-style] RFC STYLE-286: "Radio Drama" Work type

On 1/17/2014 8:27 PM, Rachel Dwight wrote: > I think “Radio Drama” or “Audio Drama” would work best, as I’ve seen > “Radio Play” used to mean general airplay. I would definitely prefer "Audio drama", since many/most of them actually are not usually broadcast over the radio these days. Also: woul

Re: [mb-style] RFC STYLE-283: “Imprint” label type / AR

On 01/16/2014 09:17 PM, Duke Yin wrote: > +1 for a Label-Label "has imprint" relationship. > > However, I don't fully understand how you intend to define the > (modified) label types. I have an idea, but I'd like to confirm whether > you are thinking the same thing: > > 1) A "(Original) Production

Re: [mb-style] RFC STYLE-283: “Imprint” label type / AR

On 01/16/2014 11:39 AM, Alex Mauer wrote: > I propose adding a new label type “Imprint” for label entities which are > merely a logo, and have no company behind them. Just realized this is poor wording: I didn’t mean to say that they are not owned/backed/created by a company — just th

[mb-style] RFC STYLE-283: “Imprint” label type / AR

STYLE ticket: http://tickets.musicbrainz.org/browse/STYLE-283 Proposed AR documentation: http://wiki.musicbrainz.org/User:Hawke/Proposal/Imprint_AR Previous discussion: http://chatlogs.musicbrainz.org/musicbrainz/2014/2014-01/2014-01-14.html#T01-14-41-677717 Expiration date: 2014-01-23 I propos

Re: [mb-style] RFC STYLE-227 Add new artist type "Character"

On 12/30/2013 01:27 PM, Calvin Walton wrote: > A minor update: hawke spotted a wording issue in the Style/Artist page > relating to character gender. > With that change: +1 I also prefer the proposed 'fictional' attribute, but this is a good start, and will allow an automated transition if/when

Re: [mb-style] RFC STYLE-279: Add "Place of Worship" as place type

On 01/02/2014 09:58 AM, Frederic Da Vitoria wrote: > A place that has live artistic performances as one of its primary > functions, such as a concert hall or multi-purpose arena. Is that not the case for churches? They may not be musical (though music is often included!) but I would coun

Re: [mb-style] RFC STYLE-276: Remove attributes from the performing orchestra relationship

On 12/27/2013 09:50 AM, Nicolás Tamargo de Eguren wrote: > The option to select "chamber" or "symphony" ends up being pretty much a > random "well it's on the orchestra name so it will probably be right" > pick, and it doesn't really offer any useful info. Can we get rid of it? > (I have seen many

Re: [mb-style] Classical FAQ

On 11/27/2013 11:36 AM, Frederic Da Vitoria wrote: > You are right, and I already saw this but I forgot about it. This part > comes from the previous version and obviously needs to be upgraded. > Could someone who really knows what Picard is currently able to do > upgrade this part? And at the same

Re: [mb-style] Classical FAQ

On 11/27/2013 04:14 AM, Frederic Da Vitoria wrote: > Hello, > > I started creating an updated version of > http://wiki.musicbrainz.org/Classical_Music_FAQ here: > http://wiki.musicbrainz.org/User:DavitoF/Classical_Music_FAQ. > > I only ensured that the points were still relevant and their solutio

[mb-style] RFV STYLE-257: Correct mistake in soundtrack style

This is RFV STYLE-257. It expires on 2013-10-17. The proposal has not changed since the RFC. This proposal is to correct some confusing wording in the soundtrack style guideline, http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Soundtrack Currently the Soundtrack style for tracks sa

Re: [mb-style] RFC STYLE-257: Correct mistake in soundtrack style

On 10/08/2013 04:43 PM, Rachel Dwight wrote: > A lot of musical theatre soundtracks don't have per-track credits. > That's my point. Under the standing guideline we have to put the > composer as the artist on all recordings in such a release even > though actors and musicians other than the comp

[mb-style] RFC STYLE-257: Correct mistake in soundtrack style

This is RFC STYLE-257. It expires on 2013-10-15. This proposal is to correct some confusing wording in the soundtrack style guideline, http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Soundtrack Currently the Soundtrack style for tracks says: "If the cover lists specific artists for

Re: [mb-style] RFV STYLE-254: make instrument attribute optional

On 09/27/2013 11:31 AM, Alex Mauer wrote: > Having received a +1 and no objections, this is ready to go to RFV. > > Occasionally it is necessary to credit "all|any instruments" to indicate > that a person performed non-specific instruments on a track. There is no > way

[mb-style] RFV STYLE-254: make instrument attribute optional

Having received a +1 and no objections, this is ready to go to RFV. Occasionally it is necessary to credit "all|any instruments" to indicate that a person performed non-specific instruments on a track. There is no way to do this within the AR system at the moment. "performed" is not viable since

Re: [mb-style] RFV: STYLE-228 updates to Live ENTITIES guide

On 09/24/2013 09:54 PM, th1rtyf0ur wrote: > > So then which do we want for the RG in case of an official live release: > - Oceania 3D in NYC > - 2012-12-10: Oceania 3D in NYC: Barclays Center, Brooklyn, NY, USA My objection to the latter is that official live releases will tend to get lost in a s

[mb-style] RFC STYLE-254: make instrument attribute optional

Occasionally it is necessary to credit "all|any instruments" to indicate that a person performed non-specific instruments on a track. There is no way to do this within the AR system at the moment. "performed" is not viable since it doesn't exclude vocals. Therefore, this proposal is to make the s

Re: [mb-style] RFV: STYLE-230 - Recording Title Guidelines

On 09/03/2013 11:34 AM, Frederic Da Vitoria wrote: > I guess your mail client does not display quote levels correctly :-) Edited > quoting: It (Thunderbird) does, but I was viewing the plain text version, which had no quote indicators at all. Great job, gmail!~ __

Re: [mb-style] RFV: STYLE-230 - Recording Title Guidelines

On 09/02/2013 04:14 AM, Ben Ockmore wrote: > No opposition, so RFV has now passed. I will be updating the recording > page soon. > > The RFV is now open again. Nothing has changed since the previous cancelled > RFV. > > Original: So is it open, or has it passed? __

Re: [mb-style] RFC STYLE-97: Move "medley" to an attribute of "recording of" v2

On 08/22/2013 11:22 AM, Tom Crocker wrote: > Philip Jägenstedt and Hawke: > Are you happy for someone else to take this on, or to pick it up again? Feel free to take this one on if you like. signature.asc Description: OpenPGP digital signature ___ Mu

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 2013-08-22 06:00, lixobix wrote: > Perhaps this would work for now: > > Live Release Groups, and untitled live Releases, should be named by > concatenating the date and location. With the exception of state, which has > special rules below, include as much information as is known, following the

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/21/2013 05:42 PM, Tom Crocker wrote: > Maybe it could be organised better but it's there. > > "Live concerts with a single, unique release title should extend the > title of the release group with date and location information as above, > using the syntax "[-MM-DD: ]Title[: Location]". I

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/21/2013 04:35 PM, Tom Crocker wrote: > Handling of multiday events doesn't seem to be catered for, but the > release group title would have "'Live' Bullet" in between the date and > location. > [snip] > Anyway, > I'd be happy either way, though I think what's currently proposed is > better. R

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/21/2013 02:25 PM, Tom Crocker wrote: > I agree that we seem to be making a mountain out of a mole hill with the > State issue. I'd just make it optional and trust to common sense, since > we should have locations soon to do it properly. +1. That plus some examples should be enough, I think.

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/21/2013 12:41 PM, lixobix wrote: > "State is a subdivision between city and country, and may be referred to as > /prefectures/. in some countries. It should be included whenever > possible/appropriate for the country. For example, Sakura, *Chiba*, Japan > and Sakura, *Tochigi*, Japan. See her

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/21/2013 04:49 AM, th1rtyf0ur wrote: > On a side note, & to complicate things even further, some cities are > duplicated even in the same state, so we'd also need something like > "Franklin, Franklin County, NY, US" vs "Franklin, Delaware County, NY, > US" in some cases. I think in most cases

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/20/2013 11:02 AM, Sheamus Patt wrote: >> Why does it matter if it’s used in the address? > It matters precisely because editors might not know it's unique. E.g. > few editors would know that Pasadena, USA might be referring to > Pasadena, TX, USA and not the better known Pasadena, CA, USA. If

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 08/20/2013 10:30 AM, Sheamus Patt wrote: > - State is the state or province that the location is part of, in > countries which includes this subdivision in addresses. It should be > omitted in those countries which have no such subdivision as part of > an address. See State abbre

Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines

On 08/16/2013 05:42 PM, Frederic Da Vitoria wrote: > Yes, but there could be two different remixes with the same name. > Uniqueness is not always easy to define. Actually, I find easier to > imagine 2 remixes of the same work by the same artist than 2 > performances of the same work the same day a

Re: [mb-style] RFC STYLE-237 (Style/Titles): Prefer plain text over artwork

On 08/16/2013 11:36 AM, SwissChris wrote: > I hope not and I don't think it should. It's a very old consensus on MBz > that capitalization is normalized, following the language specific > capitalization rules, unless obvious Artist Intent can be documented. Correct, I would not apply that to capi

Re: [mb-style] RFC STYLE-237 (Style/Titles): Prefer plain text over artwork

On 08/16/2013 05:17 AM, Kuno Woudt wrote: > I think the release itself should take precedence. I'm OK with using > the spine or booklet, but not sources external to the physical release. This. But I don’t see why some random page # in the liner notes should take precedence over the actual front

Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines

On 08/13/2013 12:36 PM, lixobix wrote: > There's currently no way to append (live, 1990-02-09: Pine Street Theatre, > Portland, OR, USA) without the extra (live), because I can't access the > recording title from Picard. Yes. That is something that should be changed in Picard. signature.asc D

Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines

On 08/13/2013 11:44 AM, lixobix wrote: > Yes, but since every recording ought to have a unique title, I don’t think this is correct. > Otherwise, with multiple live recordings of a > work, they would all be called "Title" in your media player: Not what I > would want. Translating from musicbra

Re: [mb-style] Documentation Review Team

On 08/12/2013 03:16 PM, LordSputnik wrote: > Please let me know here if you'd like to help! Love to! signature.asc Description: OpenPGP digital signature ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrai

Re: [mb-style] RFC STYLE-232: Classical works part II (Other problems)

On 08/09/2013 02:12 PM, symphonick wrote: > Now that you mention artist intent, my advice about original titles > looks problematic too. If artist intent overrides, we can't change the > title given by the composer? Good question. We do need the title to be recognizable in the search results. Th

Re: [mb-style] RFC-STYLE-234. Work lyrics option : translated→adapted

On 08/09/2013 11:14 AM, jesus2099 wrote: > I’ve been using translated optuion as just a keyword saying this work is in > other language but have been criticised it was not real translations. > Ultiumately, we don’t even need such an option if it doesn’t just mean other > language as we already have

Re: [mb-style] RFC STYLE-232: Classical works part II (Other problems)

On 08/09/2013 10:46 AM, symphonick wrote: > updated Much better! General comments: I think “secondary alias” is confusing (there is no mention of “secondary” in the interface. I would use “non-primary alias” instead, or “search hint alias” if applicable.) There are a few places where you say “c

Re: [mb-style] RFC STYLE-232: Classical works part II (Other problems)

On 08/08/2013 01:30 PM, symphonick wrote: > I can move the non-existent fields to notes, like "this is a > temporary solution, keys will eventually have their own fields". I would actually suggest simply documenting how it should be handled *now*. Leave the 'own fields' stuff for when we actually

Re: [mb-style] RFC STYLE-232: Classical works part II (Other problems)

On 08/08/2013 11:39 AM, Alex Mauer wrote: > On 08/08/2013 05:14 AM, symphonick wrote: >> OK, you asked for it ;-) >> >> http://tickets.musicbrainz.org/browse/STYLE-232 >> http://wiki.musicbrainz.org/User:Symphonick/CSG_Work_Titles >> >> Not quite finished,

Re: [mb-style] RFC STYLE-232: Classical works part II (Other problems)

On 08/08/2013 05:14 AM, symphonick wrote: > OK, you asked for it ;-) > > http://tickets.musicbrainz.org/browse/STYLE-232 > http://wiki.musicbrainz.org/User:Symphonick/CSG_Work_Titles > > Not quite finished, needs more examples. But I'm sure there will be lots > to discuss anyway. Aside from the

Re: [mb-style] RFC STYLE-233: New cover art types

On 08/08/2013 07:15 AM, Rachel Dwight wrote: > Poster: a poster included with a release. May be the same size as the > packaging or larger (in this case it would fold out). > Liner: a protective sleeve surrounding a medium (usually a vinyl record, > but sometimes a CD); often printed with notes o

Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines

On 2013-08-07 09:38, lixobix wrote: > What I'm getting at is that http://musicbrainz.org/doc/Style/Titles should > not mention any specific entities, but should apply to all entities. Rules > that apply to specific entities should be placed in the relevant section. > Perhaps "Titles" should be rena

Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines

On 2013-08-07 08:45, lixobix wrote: > For example, I don't understand why "Format designations in titles" is on > there, as that is a specific rule for release titles, not a general rule for > all titles: it's not something I need to know when I'm doing titles for > tracks or recordings. Similarly,

Re: [mb-style] RFV STYLE-227: More new packaging types

On 07/29/2013 08:13 AM, Ben Ockmore wrote: > You may be able to upload the cover images to CAA as cover art for a > release (if it exists in mb). Then we can just link to the CAA images in > the wiki. Why not just upload them to the wiki itself? signature.asc Description: OpenPGP digital signat

Re: [mb-style] RFV STYLE-227: More new packaging types

On 07/29/2013 07:40 AM, Nicolás Tamargo de Eguren wrote: > Wondering what the difference is between that snapcase photo and a > digipak... I'd certainly have used digipak for that (and just cardboard > sleeve for the vinyl, but there at least there's a clear difference) The difference is that the

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 07/22/2013 10:35 PM, th1rtyf0ur wrote: > Expected Expiration: 2013-07-30. > > wiki: > http://wiki.musicbrainz.org/User:Th1rtyf0ur/Style/Specific_types_of_releases/Live_bootlegs Made a couple of minor changes to that page, just wording changes and (I think) only stuff that was in the old guide

Re: [mb-style] RFC: STYLE-228 updates to Live Bootlegs guide

On 07/23/2013 02:40 PM, lixobix wrote: > One of the goals of the database is uniformity in divergent information > across releases (e.g. using the correct track titles, rather that different > ones where there are inconsistencies across similar releases). We do not override track titles based on

Re: [mb-style] RFV STYLE-225: packaging: slipcover, book, cassette case, box

On 07/03/2013 03:34 PM, Nicolás Tamargo de Eguren wrote: > I'm unsure if such a general wording > makes sense - it certainly does for, say, boxsets where you have n jewel > cases in a box, but does it make sense for everything? Nikki's "just > pick "other" for everything then, since everything come

[mb-style] RFV STYLE-225: packaging: slipcover, book, cassette case, box

This RFV expires 2013-07-05. http://tickets.musicbrainz.org/browse/STYLE-225 Changes since RFC: updated slipcover definition to match Tom Crocker’s suggestion. I would like to propose the addition of the following packaging types: slipcover: A box-shaped sleeve with one or two sides open. Often

Re: [mb-style] RFC STYLE-225: new packaging types

On 06/26/2013 04:59 PM, Tom Crocker wrote: > For slip cover, would: > A box-shaped sleeve with one or two sides open. Often made of cardboard > or plastic. > Be easier to understand? Looks good to me. I’ll change it to that before RFV if no one has any objections. __

Re: [mb-style] Recording Titles and Related Stuff

On 06/26/2013 04:31 PM, Tom Crocker wrote: > The classical release title guidelines looked like a good place to start > for general release title guidelines. Those and discogs. I've put > together some example release and track title guidelines. Feel free to > do whatever you like with these - I'm

Re: [mb-style] RFC STYLE-225: new packaging types

On 06/26/2013 03:39 PM, Tom Crocker wrote: > Yep, that's what I meant. The only problem for me with cassette case is > it could mean any thing a cassette comes in. That’s why I used the phrase “designed to hold a compact cassette”. I guess you could argue that a cardboard slipcover of the proper d

Re: [mb-style] RFC STYLE-225: new packaging types

On 06/26/2013 12:43 PM, Ben Ockmore wrote: > I'm also confused by slipcover... Perhaps we could add pictures to the > packaging page? :P That sounds good, but it’s easier said than done. If you can find some good pictures, add them by all means. signature.asc Description: OpenPGP digital sign

Re: [mb-style] RFC STYLE-225: new packaging types

On 06/26/2013 11:51 AM, Rachel Dwight wrote: > I think he means a slipcase like would be found on a CD (usually fitting > over a jewel case). The base package might still need to be stipulated > in that instance, e.g. "Jewel case w/slipcase). I do mean that, but note that a lot of cassettes (espec

[mb-style] RFC STYLE-225: new packaging types

This RFC expires 2013-07-3. http://tickets.musicbrainz.org/browse/STYLE-225 I would like to propose the addition of the following packaging types: slipcover: a sleeve covering an inner package on 4 or 5 sides. Often made of cardboard or plastic. book: any bound set of pages or sleeves. cassette

Re: [mb-style] Recording Titles and Related Stuff

On 2013-06-26 04:15, symphonick wrote: > Please tell me more about post-CSG! :-) Whoops, got my TLAs mixed. Meant "post-NGS". :-D ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/

Re: [mb-style] Recording Titles and Related Stuff

On 06/21/2013 05:04 PM, Ross Tyler wrote: > Pre-NGS (pre-MB-recordings, where one MB release reflected may > real-world releases) we had guidance to address the exact problem. > http://wiki.musicbrainz.org/History:Consistent_Original_Data > +1 to this. Can we simply resurrect this guideline, mo

  1   2   3   4   5   6   7   >