Re: [mb-style] Remove honorary titles
On Fri, Mar 20, 2015 at 6:55 PM, bflaminio bflami...@gmail.com wrote: I agree with Trevor Downs. If an artist makes a point to include the title, and if the title is used on cover art, liner notes, and other artifacts of music production; then it's reasonable to include the title in the artist name. Here is a release of mine that has only Simon Rattle on the cover, but the current artist name is Sir Simon Rattle. http://musicbrainz.org/release/18b06ece-4115-40ac-9fc7-41ff6953a1cb/cover-art Either way we do it, these inconsistencies are going to happen. I can't think of a reason why it's better to have this in the artist name than in the ACs for the releases where it's used. Is it an offical part of the person's legal name or something like that? These can be decided on a case-by-case basis. I'd rather see it codified, whichever way the decision goes. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Remove honorary titles
On Fri, Mar 20, 2015 at 8:26 PM, SwissChris swissch...@gmail.com wrote: http://musicbrainz.org/edit/11528485 OK, so there's an example of where the title is not in the name even though it appears on artwork, including this one: http://musicbrainz.org/release/0b4fbcc2-18a3-47f5-83a7-c198ed36cb98 Unfortunately, that particular edit pre-dates ACs, so anybody that voted on/debated that edit may have differing viewpoints on the question today. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Remove honorary titles
On Sat, Mar 21, 2015 at 2:15 PM, Alexander VanValin caller...@gmail.com wrote: I should add, my real question is what makes honorific titles a special case? What is problematic for me is that the artist name will change after the title is bestowed. Then I end up with tags with distinct values. YMMV. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Remove honorary titles
On Sat, Mar 21, 2015 at 4:45 PM, Alexander VanValin caller...@gmail.com wrote: Well, right. The same thing might happen if e.g. an artist marries. Won't all minor name variations create the same problem? So, I'm not saying that it's a non-issue. I'm merely saying that it doesn't seem like a special case. There are different solutions to these problems, like creating a separate performance name that relates to a legal name. Or using Artist Credits to record name variations that appear on physical releases. I'm proposing the latter. It's not really that special. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Remove honorary titles
http://tickets.musicbrainz.org/browse/STYLE-487 On Fri, Mar 20, 2015 at 3:26 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: Hi! It's fine to have discussion here, but please also add a style ticket :) You know, I started to create a ticket, but when none of the available Components fit what I was proposing, I wasn't sure anymore if that was the right thing to do. :) http://tickets.musicbrainz.org/browse/STYLE-487 I personally don't mind it either way to have it or not as part of the name. One doubt I have is whether you see this also affecting other names like X, King of Y or Alfred, Lord Tennyson, or it's only Sir/Dame that you have in mind. Well, Sir was the only example that came to mind, and probably the only I've seen in use at MusicBrainz, but your other examples would probably also fit my criteria. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Remove honorary titles
Hi, I'd like to propose that we remove honorary titles from artist names, i.e., Sir Thomas Beecham [1] should be simply Thomas Beecham. They are not really part of the artists' names, and should not apply to times before the titles were bestowed. ACs can be used to indicate the title if they are featured on a release, of course. I'd like to see this added to Style/Artist. [1] http://musicbrainz.org/artist/0e6ccc63-41cb-4903-8b7d-60846aca6d58 -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
On Thu, Oct 30, 2014 at 1:25 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: That's solved easily enough by, well, adding an alias :) It might be a bit more work short-term maybe, but it should eventually need less effort anyway since they'll already be there for any other releases of the same work. It's more than a bit more work, especially if we're talking about a opera, oratorio, or something else similarly massive. :) Anyway, let me cut to the chase. I'm not asking for a return of pre-NGS track titles or fancy features in Picard. I've long since accepted that I'm going to have to make my own titles for classical. Still, I would like to see a minimal amount of editing (punctuation and numbering, primarily) for the sake of consistency. This also makes it a lot easier to write scripts to massage the data into something closer to the end product. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
On Wed, Oct 29, 2014 at 11:32 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: That's mostly fine, but it should still be codified, and slightly adapted to take the existence of works into account (which allow tracks to follow the release a bit better). Not really, as it's still very difficult to get standardized titles in the appropriate language from work titles. Evolving draft at http://wiki.musicbrainz.org/User:Reosarevok/Classical_Track_Titles This document is vague about where on the release to source this information. Was that intentional? There could be arguments about an editor using what is printed in the liner notes versus the track listing on the back. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
On Wed, Oct 29, 2014 at 11:39 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: Forgot to mention, also, that part of the idea is to get rid of http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Opera at the same time, since that basically only says put as much info as possible on opera track titles, even if not on the release which seems to mostly go against what we're moving towards with NGS. I've never liked that guide much. If anything, it should be applied to work titles, but not track titles. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
On Wed, Oct 29, 2014 at 12:47 PM, Frederic Da Vitoria davito...@gmail.com 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 standardization, let him do it too. If that's what users want, so be it, but there was a time when MusicBrainz actually made it easier to tag my classical files. In a way, it differentiated MusicBrainz from other databases like Discogs or CDDB. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Style for classical track titles (STYLE-344)
On Wed, Oct 29, 2014 at 4:10 PM, Alex Mauer ha...@hawkesnest.net wrote: I think you could do this by just using the %work% or %_recordingtitle% tags in Picard, no? %work% might, if: 1) The work has a title alias for the locale matching my release. (not likely!) 2) Picard places that alias into %work% instead of the work title. %_recordingtitle% might, if: 1) The recording title was stardardized. Is there something in Style that says to do that? I haven't seen it. Even if there is, it's unlikely that someone as bothered, given how difficult it is to work with recording titles. 2) The recordings weren't created from a release in a different language (all releases in all territories should use the same recordings, as far as I know). Recordings don't even have an option for locale-specific aliases. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changes to our style process (Important)
On Sun, Oct 19, 2014 at 10:42 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: tl;dr: Style system has changed, new info at http://musicbrainz.org/doc/Proposals Hi. How should an editor keep abreast of style changes under the new system? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Classical title style: untitled works / update for Series
On Thu, May 15, 2014 at 9:36 AM, Alex Mauer ha...@hawkesnest.net wrote: Anyone else have thoughts on the matter? Any comments on how this will/will not impact data consumers? (not taggers, but customers/partners) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] No official work documentation?
On Sun, Apr 13, 2014 at 1:34 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: We don't have any official documentation - only Style. The rest is supposed to be able to be changed without needing list approval. All that team line means is the page isn't transcluded to lock it in a specific revision for /doc. Ok, we don't have any official Style for works then, unlike all the other major entities. And unlike works for Classical music, which do have a Style page. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] No official work documentation?
On Sun, Apr 13, 2014 at 5:06 AM, symphonick symphon...@gmail.com wrote: My latest RFC from a while ago: http://musicbrainz.1054305.n4.nabble.com/RFC-STYLE-263-Works-titles-guideline-td4658896.html Yeah, I remember that, though it seemed premature. It would be nice to have a general guideline in place first before adopting specifics, IMO. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] No official work documentation?
In a discussion with another editor on an edit, it came to my attention that there is no official documentation for work entities that I can see. We have this page: http://musicbrainz.org/doc/Work But it's not official correct? (This page has not been reviewed by our documentation team). Given that works are a major MusicBrainz entity, it would seem prudent to fix this problem. What needs to happen? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording types
On Thu, Apr 3, 2014 at 10:40 AM, lixobix arjtap...@gmail.com wrote: The advantage would be similar to that of having different RG types, i.e it would be possible to group recordings according to type. So you could have a list of all studio recordings, without live recordings and remixes mixed in. Or you could see how many remixes of an artists works there are. A free text box would not allow for such organisation. Yup, I understood that part. But my preferred way to mark a recording as a demo or whatnot, is to add an attribute to the recording-of AR. That way, things like the following are possible: Recording A (demo recording of) Work A Recording B (medley containing demo recording of) Work B Recording B (medley containing partial live recording of) Work C -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording types
On Wed, Apr 2, 2014 at 6:44 AM, lixobix arjtap...@gmail.com wrote: How about adding types to recordings, corresponding to release types (or most of them)? We already have a 'Specific recording types' section in the Recordings guide, currently with only 'live' listed. The following could possibly be used: Spokenword Interview Audiobook Live Remix Edit DJ-mix Demo (subject to discussion) Studio (ditto) Recording types could make artists' 'Recordings' pages easier to navigate, by making clearer the different types of recordings that exist for each work. Thoughts? I would like to see some of the above as additional attributes on the recording-of AR. Of course, it would be silly to have the same list of types on both the Recording and the AR. And, I don't know how adding attributes to the AR solves what you're looking for (organizing the artist Recording list). -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changes to #Compilation in Release Group/Type
On Mon, Mar 31, 2014 at 11:33 AM, SwissChris swissch...@gmail.com wrote: I agree with Jesus that a simple Greatest Hits of best of compilation of a single artist definitely is NOT (and should not be called) an anthology. In the real world, it happens (see link below), probably generally with compilations with more than one medium. Not that we have to label these releases as an anthology just because the cover says so. :) http://musicbrainz.org/release/94c5881c-e47a-42ba-bea0-d9ff8cb79dd1 -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [unknown] for places
On Thu, Oct 31, 2013 at 7:57 AM, ListMyCDs.com musicbra...@listmycds.comwrote: I'm not fully against of having [unknown] for places but without good guidelines it could be complete useless. Visitors and bots share this information as a fact and wrong information is spreading widely. I think we are also responsible of providing valid and factual data. If an editor has a source for a date, we shouldn't discourage entering the date. We could come up with another special purpose place like [undetermined], but I'd rather not go there. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-264: Add premiere-relationship between work and place
On Tue, Oct 29, 2013 at 10:30 PM, ListMyCDs.com musicbra...@listmycds.comwrote: Many Wikipedia pages about classical works (and often also imslp.org) record information about first performances (data place) of work. I'm proposing us to start storing this information with new work-place relationship. Naturally usage of it isn't limited only to classical music. Wiki: http://wiki.musicbrainz.org/User:ListMyCDs.com/Premiere_Relationship_Type JIRA: http://tickets.musicbrainz.org/browse/STYLE-264 Expiration: 2013-11-07 ListMyCDs / Timo Martikainen I love this idea. A few notes/questions: 1) Performance Relationship Class doesn't seem right. In fact, PRC is described as used to credit musicians who contribute actual sounds to the music. 2) There is an obvious use for the dates here, so why do the two date attributes say There is no guideline yet for how the [begin|end] date fields might be used.? 3) If the premiere date is known but the place is not, would this be usable with a special purpose place like [unknown]? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-264: Add premiere-relationship between work and place
On Wed, Oct 30, 2013 at 3:22 AM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: Ignore relationship classes, we don't really use them at all anyway once the relationship is entered into the site. Similarly for the dates, that won't show when it's added so as long as it's clear that we should use the dates, that's fine. I don't understand what you guys mean when you say these things won't show. When I look at an existing AR doc, they do show: http://musicbrainz.org/doc/Performance_Relationship_Type -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-264: Add premiere-relationship between work and place
On Wed, Oct 30, 2013 at 2:38 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: Those horrible pages take more than we'd like to finally kill, but yeah - http://musicbrainz.org/relationship/628a9658-f54c-4142-b0c0-95f031b544da Ah, I hadn't heard about this! Is there a Jira ticket with more info? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (was RFV): STYLE-228 updates to Live ENTITIES guide (was: Live Bootlegs guide)
On Tue, Oct 8, 2013 at 7:20 PM, th1rtyf0ur ea...@spfc.org wrote: On Tue, Oct 08, 2013 at 10:52:37AM -0700, David Gasaway wrote: So you are still proposing that RGs with official titled releases be in the -MM-DD: [Title: ][Event, ][Venue, ]City, [State, ]Country format? I would prefer to see them put in different RGs. Why? Bootlegs of non-live albums go in the same release group as the actual album, so why not put bootlegs of the same concert in the same release group as official live releases? The bigger concern with the proposal to put them together, as I see it, is the title of the RG. That's why your booleg album analogy isn't the perfect fit: the RG would still be given the title of the album, not a title based on the above formula that hides the official release title. If the live RG was given the name of the official live release, there might not be much of an issue. Keeping the RGs separate skirts this problem. Honestly, I'm not clear on the value in merging the RGs. Otherwise, maybe I could propose other solutions using ARs or some such. Remember, I may have missed pertinent discussion on this topic back when I thought the thread was strictly about bootlegs. Even for multi-date live releases there can be both official and bootleg versions of the same release, e.g. Earphoria: http://musicbrainz.org/release-group/503d32cd-a1eb-387d-9a39-f91f4541ee5e (no bootleg entries currently entered in MB, although they're mentioned in the wiki excerpt at the top). And while it's not unusual for live albums to consist of multiple dates, it certainly doesn't mean all are that way (as with the Oceania Live in NYC example, Nirvana's MTV Unplugged, etc.). The point was this: I don't like the idea of having a situation where some official live releases (multi-date, say) are in RGs titled the same as the release, and other official live releases are in RGs that follow different rules. As for the last statement about it being easier, I don't think that's necessarily true, or a good reason, either. For single-concert live releases, that would require a special exception, and would defeat the whole point of grouping releases from the same concert together. Maybe I misunderstand your point, but I'm not proposing any kind of special exception that would be required for single-concert live releases. Rather, I'm trying to remove special exceptions by proposing a very simple rule: Official live releases in one RG, bootlegs in another. That is what I describe as easier. Anyway, are you sure that you've actually addressed the concern that lead to the veto on the initial RFV? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (was RFV): STYLE-228 updates to Live ENTITIES guide (was: Live Bootlegs guide)
On Wed, Oct 9, 2013 at 6:04 AM, Tom Crocker tomcrockerm...@gmail.comwrote: @David Gasaway Okay. I didn't understand why you thought it was easier. I still don't agree because of the way release groups are organised. The way release groups are organized? I don't understand. Could you please elaborate? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (was RFV): STYLE-228 updates to Live ENTITIES guide (was: Live Bootlegs guide)
On Tue, Oct 8, 2013 at 12:24 AM, th1rtyf0ur ea...@spfc.org wrote: Updated to reflect this, and added the Oceania Live in NYC release group to the examples (although the actual RG title has not yet been updated, as that still depends on this passing- the RG will eventually also contain an audience bootleg recording of the same show (again, pending approval)) http://wiki.musicbrainz.org/User:Th1rtyf0ur/Style/Specific_types_of_releases/Live_bootlegs So you are still proposing that RGs with official titled releases be in the -MM-DD: [Title: ][Event, ][Venue, ]City, [State, ]Country format? I would prefer to see them put in different RGs. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (was RFV): STYLE-228 updates to Live ENTITIES guide (was: Live Bootlegs guide)
On Tue, Oct 8, 2013 at 10:52 AM, David Gasaway d...@gasaway.org wrote: On Tue, Oct 8, 2013 at 12:24 AM, th1rtyf0ur ea...@spfc.org wrote: Updated to reflect this, and added the Oceania Live in NYC release group to the examples (although the actual RG title has not yet been updated, as that still depends on this passing- the RG will eventually also contain an audience bootleg recording of the same show (again, pending approval)) http://wiki.musicbrainz.org/User:Th1rtyf0ur/Style/Specific_types_of_releases/Live_bootlegs So you are still proposing that RGs with official titled releases be in the -MM-DD: [Title: ][Event, ][Venue, ]City, [State, ]Country format? I would prefer to see them put in different RGs. I just had another thought: It's not unusual for an official live release to contain material from multiple shows on a tour (and not always clearly indicated with the release). In which case, they'll have to be different RGs anyway, so it's just easier to have them in different RGs all the time, IMO. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (was RFV): STYLE-228 updates to Live ENTITIES guide (was: Live Bootlegs guide)
On Tue, Oct 8, 2013 at 3:21 PM, Tom Crocker tomcrockerm...@gmail.comwrote: On Oct 8, 2013 6:55 PM, David Gasaway d...@gasaway.org wrote: I just had another thought: It's not unusual for an official live release to contain material from multiple shows on a tour (and not always clearly indicated with the release). In which case, they'll have to be different RGs anyway, so it's just easier to have them in different RGs all the time, IMO. As I read the current and proposed rules, that makes it a live compilation so the rules don't apply. It wouldn't even sit in the same RG category. Even if it hadn't been spotted that it wasn't a single gig it would be unlikely someone would have stuck a bootleg in with it because there wouldn't be a matching date - so I'm not sure how much of a problem that is. Um, that's pretty much what I was saying. The important bit was at the end: so it's just easier to have [official live releases] in different RGs all the time, IMO. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: STYLE-228 updates to Live Bootlegs guide
On Thu, Sep 19, 2013 at 4:17 AM, lixobix arjtap...@aol.com wrote: Nicolás is right, there should be some examples of official releases too. jesus2099, the proposal is not to change official release titles, but to change official RG titles. If you intend to change RG titles for official live releases, then I don't think it's fair that all discussion leading to this RFV (including the RFV) has been titled updates to Live Bootlegs guide. Folks that care about official live releases but not bootlegs may not have been following along. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: STYLE-228 updates to Live Bootlegs guide
On Thu, Sep 19, 2013 at 5:32 PM, David Gasaway d...@gasaway.org wrote: On Thu, Sep 19, 2013 at 4:17 AM, lixobix arjtap...@aol.com wrote: Nicolás is right, there should be some examples of official releases too. jesus2099, the proposal is not to change official release titles, but to change official RG titles. If you intend Sorry, lixobix, I didn't mean to direct that at you. :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines
On Mon, Jul 29, 2013 at 2:04 AM, Tom Crocker tomcrockerm...@gmail.com wrote: For 2. live performances are usually covered by the existing rules, but I would go further. I've just added a bunch of different recordings for a live performance. This included several sources, it also included different versions of the same song, and the titles aren't disambiguated on the release. I'd propose something like [Performance: ][Version: ][Mix]. So, in the extreme you might have a disambiguation comment like: live, 1995-10-21: The Palace, Hollywood, CA, USA: reprise: multi-source mix Some of this can be recorded in the recording-of AR. The reprise bit I would usually expect to be in the title. Of course, you say the release does not disambiguate the titles, so perhaps length can serve that purpose. Then multi-source mix is about all I would expect to see in the disambiguation comment. Is there some other reason to put all this in the disambiguation comment that I'm not seeing? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines
On Mon, Jul 29, 2013 at 12:24 PM, Tom Crocker tomcrockerm...@gmail.com wrote: On 29 July 2013 19:24, David Gasaway d...@gasaway.org wrote: On Mon, Jul 29, 2013 at 2:04 AM, Tom Crocker tomcrockerm...@gmail.com wrote: live, 1995-10-21: The Palace, Hollywood, CA, USA: reprise: multi-source mix Some of this can be recorded in the recording-of AR. I assume by this you mean the date? but the first bit is a standard live recording disambiguation comment, as I understood it. Perhaps you're only meant to put the date and only add the venue if they played two gigs on the same night, both of which were released, but if that's the case it isn't obvious to me. I meant live and the date. And yes, venue/location is redundant unless the artist has played the same song at multiple venues on the same date. Venue information is still interesting, mind you, but not strictly necessary for disambiguation (usually :). This style may already be in the guidelines, I don't really know. I'm just curious as to the reasoning. The reprise bit I would usually expect to be in the title. Of course, you say the release does not disambiguate the titles, so perhaps length can serve that purpose. I agree, normally that would be in ETI already, but here it (or anything else) isn't. So, personally I'd prefer it if recordings with the same title and artist were explicitly disambiguated by the disambiguation text. Partly just to be entirely clear but also because the length can vary widely between two tracks with the same recording, particularly with live performances with the choice of which chunk of crowd noise to allocate where, but also with inserted chunks of silence to make 'hidden' tracks on albums. Often, this can be gleaned from other information such as track sequence. In the case where a release only includes one performance of a song in a set list that had the song twice, I don't know how much having reprise in the disambiguation comment really helps identify which performance you have. Length certainly could. That said, I don't object to recording this information - I'm just not certain how generally useful it is as a guideline. Again, I am most interested in learning why it's useful to store this information in the disambiguation comment (esp. the live and date part, which can be stored in an AR, and go a long way toward disambiguating the recording in a structured way). -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: STYLE-230 - Recording Title Guidelines
On Mon, Jul 29, 2013 at 1:15 PM, Nicolás Tamargo de Eguren reosare...@gmail.com wrote: On Mon, Jul 29, 2013 at 11:08 PM, David Gasaway d...@gasaway.org wrote: I meant live and the date. And yes, venue/location is redundant unless the artist has played the same song at multiple venues on the same date. Venue information is still interesting, mind you, but not strictly necessary for disambiguation (usually :). This style may already be in the guidelines, I don't really know. I'm just curious as to the reasoning. It is in the guidelines, and I can't find a problem with it My only problem (and I use that loosely) with any of it is that it's unstructured and redundant (if also stored in an AR). And that I have, apparently, not been following the guidelines. :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-227: More new packaging types
On Mon, Jul 29, 2013 at 4:07 PM, Ross Tyler rossety...@gmail.com wrote: CAA snap case: http://musicbrainz.org/release/2ff90f71-983d-4c32-8818-529e48aafc70/cover-art I have a number of those. But they do not seem to be the same as what Rachel is proposing. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-227: More new packaging types
On Mon, Jul 29, 2013 at 6:58 PM, Ross Tyler rossety...@gmail.com wrote: Yes, it is hard to tell but zoom in on the hi-res CAA picture and you'll see it's the same as yours Huh?! That and what Rachel linked don't look at all the same to me. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-227: More new packaging types
On Mon, Jul 29, 2013 at 6:21 PM, Rachel Dwight hibiscuskazen...@gmail.com wrote: Nah, it looks right. The Wikipedia article did say snap cases have been used for 12cm CDs and DVDs. They're not exclusive to Japanese 8cm singles (though that's where they were most used). Two Wikipedia articles have been posted in this thread. For two different types of cases, near as I can tell. Which one were you proposing to add? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV STYLE-227: More new packaging types
On Mon, Jul 29, 2013 at 8:43 PM, Rachel Dwight hibiscuskazen...@gmail.com wrote: I was referring to https://en.wikipedia.org/wiki/Snap_case Ah, cool. Then it seems to me that the image you linked in your original post, and the text given in the ticket, Most commonly used for Japanese 8cm CD singles. are mistaken. Agreed? I can start a new proposal for the SnapPack later if you like. I've never seen a SnapPack in person... :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-205: Remove indication in conductor guidelines to use chorus master for choral conductors
On Wed, Apr 10, 2013 at 11:43 AM, Tom Crocker tomcrockerm...@gmail.comwrote: I would change the link phrases for chorus master because I think they're a little clunky: Artist http://wiki.musicbrainz.org/Artist *was chorus master on* Releasehttp://wiki.musicbrainz.org/Release Release http://wiki.musicbrainz.org/Release *has chorus master *Artisthttp://wiki.musicbrainz.org/Artist Artist http://wiki.musicbrainz.org/Artist *was chorus master on* Recording http://wiki.musicbrainz.org/Recording Recording http://wiki.musicbrainz.org/Recording *has chorus master * Artist http://wiki.musicbrainz.org/Artist I'm sure the artist - release/recording phrase I've suggested would work. I think the others would work but would want to see a bunch of examples to be sure I was thinking of making a suggestion like this, too, but changed my mind because it's not really part of this RFC. However, if Nicolás is willing to take this on, I could also suggest: artist served as chorus master on release/recording. This phrasing wouldn't work well in the other direction, but the existing phrases or the above could be used instead. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Work-Work summary
On Tue, Mar 5, 2013 at 9:36 AM, Frederic Da Vitoria davito...@gmail.comwrote: Hello, I have started assembling a general guideline about when to use ther different Work-Work ARs: http://wiki.musicbrainz.org/User:DavitoF/How_To_Link_Works_Together Would it be helpful to link to the following wiki page? http://en.wikipedia.org/wiki/Transcription_%28music%29 Or maybe borrow something from the second paragraph: Transcription may also mean rewriting a piece of music, either solo or ensemble, for another instrument or other instruments than which it was originally intended. The Beethoven Symphonies by Franz Liszt are a good example. Transcription in this sense is sometimes called arrangement, although strictly speaking transcriptions are faithful adaptations, whereas arrangements change significant aspects of the original piece. For Revision, you have for new versions of the work by the same author (similar instrumentation). I take that to mean that if a composer transcribes his/her own own work to different instruments, we would use Transcription, not Revision (there are some good examples of this on the wikipedia page). Is that correct? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: CSG Works part I: Works definition
On Thu, Feb 28, 2013 at 11:15 AM, symphonick symphon...@gmail.com wrote: IMO you shouldn't link to an excerpt work from the full opera; you are not listening to a performance of an excerpt. At least that sounds somewhat logical... I've said on the list before that I'd be unhappy if I couldn't click on an aria work and see every known performance of the aria. Still, I see the logic in it. I'm starting to get over it, I guess. The RFC text is still a little unclear on this, though. Maybe the Excerpts section needs to say something like Excerpt works are only used for excerpt performances (e.g., compilations or recitals). Also you say to add Excerpt of [Work] in the annotation. Wouldn't it be better to put this in the disambiguation, so that it's visible when searching from a add relationship dialog? Better yet, maybe we can get an excerpt flag on works somewhere down the road. Or maybe an excerpt attribute on part-of ARs. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: CSG Works part I: Works definition
On Wed, Feb 27, 2013 at 2:13 AM, symphonick symphon...@gmail.com wrote: A scene is not a work. Also I can't see how it would be helpful for anyone; scenes will seldom match track splits anyway, so instead of creating a single partial performance AR to the act work, you'll have to create one fore every scene. I've only been passively following this thread/RFC but this comment got my attention. If I'm reading your RFC right, we would only make excerpt works for for popular arias and choruses. For an opera release, then, many recordings would have only a partial-recording-of AR to a Act work? I really don't want to have to make decisions about what qualifies for that status and what doesn't. Many times it's hard to tell just from track lists whether a track is an aria or a recitative (or both). Would you be okay with only a recording-of-aria AR on a recording that contains both recitative and aria? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Revival of RFC STYLE-138: Add director AR
In opera and musicals, you have a director that is deeply involved with production including the singing, acting, and staging (like a film or play director). During performance, the focus shifts to the actors and conductor, with almost no involvement form the director. Yet, the director still has a strong influence on the performance, and certainly should be credited. The director may be the same person as the conductor (especially for a studio recording with no staging), but may not. Does any of this help? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: CSG Works part I: Works definition
On Wed, Feb 27, 2013 at 12:44 PM, symphonick symphon...@gmail.com wrote: Yes, that was my thought too. But the idea with excerpt works was to use it for recitals. A real opera recording should then only be linked to the original works. But now I wonder how this will work in practice? And what about compilations? I'm open for suggestions on how to rewrite that part... I'm not sure what original works means in this context. If you mean that opera releases will have only partial-recording-of-act ARs even when excerpt works are available, that does indeed pose problems when compilation releases share recordings with full-opera releases. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Revival of RFC STYLE-138: Add director AR
On Wed, Feb 27, 2013 at 3:15 PM, SwissChris swissch...@gmail.com wrote: And it seems the director credit covers quite different things depending on the genre, the country, the language. The wiki page for director is only an inventory of various directorial charges, nothing nearly defining what a director here is supposed to be or to do. http://en.wikipedia.org/wiki/Director In french, you often find a Directeur artistique, (artistic director) which so far I translated as (executive) producer. I still can't see in how far a director does something different from a producer. Yes, I have seen producer and directeur artistique used as equivalents. Example: http://coverartarchive.org/beta/release/79261775-e834-4e68-bfbe-9098d67e705a/3379426766.jpg On the other hand, they can be different roles the same way that a film producer and film director are different roles. Without a clear, concise (and ideally sourced) definition, backed by at least three or four examples from different musical genres (and countries) I don't think this should be added. There is so much overlap and so many different meanings for both producer and director that I don't know if that's possible. If I had a choice of Producer and Director ARs, I could credit exactly as they appear on the release without caring what role those people actually played. That said, translation is definitely a problem. Maybe we shouldn't try to translate. How about we add a directeur artistique AR and the like? Enter whatever is on the release (including multiple ARs if the release provided a translation of its own). I'm not helping very much, am I? :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Revival of RFC STYLE-138: Add director AR
On Wed, Feb 27, 2013 at 5:03 PM, David Hilton quercus.aeter...@gmail.comwrote: I've generally figured a producer manages the more commercial (not artistic) aspects of a project (arranging stage locations, producing albums, etc.). That's tricky. Producer covers a wide range of artistic input. In a film, artistic duties are generally carried by the director, it's true. In popular music, the producer may practically write the song, or may simply facilitate the vision of the artist. In opera, the producer .. umm .. produces the production (sets, costumes, etc.). Though with a new production, that person usually also provides dramatic direction, and is casually called the director. As in artistic director. In a new staging, production by Whosit is preferred over produced by Whosit. For studio recordings, the conductor may provide the dramatic direction and be credited as producer. As in artistic director. Clear as mud? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
On Thu, Jan 24, 2013 at 10:22 AM, Alex Mauer ha...@hawkesnest.net wrote: Non-musical: Ballet Hmm?! I expected ballet to be under Larger Works. Unless you mean a work that was only dance, no music. If so, how would you file ballet music? A ballet suite could be filed under Suite I suppose, but I wouldn't be inclined to use that for a complete ballet. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
A few others that come to mind: Cadenza (for composed cadenzas, not improvised) Theme and Variations (for Larger Works) Musical Theatre (Larger Work) Fantasia Impromptu I also had a think on Chorale and Chorale Prelude, but I'm not knowledgeable enough to make a specific suggestion. Perhaps the former is covered by something listed under Vocal, and the latter is covered by Prelude? But when you have a work like Franck's Prélude, Choral et Fugue, the middle part would be... ? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
On Thu, Jan 24, 2013 at 1:17 PM, Alex Mauer ha...@hawkesnest.net wrote: Added under Instrumental. Not sure there’s any reason that it should only be composed cadenzas though. Any time we would have a work which is a cadenza, it can certainly exist even if improvised (I believe we handle this similarly for jazz already) Well, maybe I'm misunderstanding how we would use these cadenza works. If you had a performance that included a composed cadenza, then the recording would be a performance of the regular work and the cadenza. If the performance included improvised cadenza, then the recording would only link to the regular work. That's what I vaguely remember of some past discussions regarding cadenzas, but it doesn't really matter to me. Theme and Variations (for Larger Works) Added. A clarification on this one: A smaller work could certainly be a Theme and Variations. What I had in mind was something like the Goldberg Varations, where this would be the type of the superwork, and the individual parts might be something else. Musical Theatre (Larger Work) This one I’m not sure of. Isn’t it covered by “play”? Could be, but Play was under the Non-musical heading. Also, I wouldn’t say that a specific instance of musical theatre is “a musical theatre” — compare “a symphony” or “an overture” True. I was trying to avoid the term musical lest anyone confuse it for anything vaguely related to music, but maybe that was a bad idea. :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
On Thu, Jan 24, 2013 at 3:35 PM, Frederic Da Vitoria davito...@gmail.com wrote: According to wikipedia, choral started by being sung, but modern composers use it for instrumental pieces. So I guess it would fit in Vocal or instrumental. Is it something distinct from Anthem (choral hymn)? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
On Thu, Jan 24, 2013 at 3:58 PM, Frederic Da Vitoria davito...@gmail.com wrote: Silly, of course anthems are often played as instrumentals, but does there exist an anthem which wasn't composed originally for voices? The national anthem of Spain? :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
On Thu, Jan 24, 2013 at 4:04 PM, LordSputnik ben.s...@gmail.com wrote: http://en.wikipedia.org/wiki/Marcha_Real Beaten to the punch! -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Thu, Jun 7, 2012 at 2:09 PM, Andii Hughes gnu_and...@member.fsf.org wrote: It also means they no longer share a tracklist: No longer sharing a tracklist is not an issue in itself. In fact, it sounds a lot like copy-on-write to me. That is, conceptually, releases all have individual tracklists; shared tracklists are merely an optimized implementation of that concept (which probably shouldn't be visible to the end user). You are free to disagree with the concept, of course. But some of your arguments seem to be coming at it from the wrong angle. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Transparency and Duplication of Tracklists
On Fri, Jun 8, 2012 at 7:18 AM, Andii Hughes gnu_and...@member.fsf.org wrote: I don't see what you disagree with here. That's because I didn't actually disagree with you. :) I didn't say that the copy-on-write (COW) technique didn't work in some situations. This bug and discussion is about controlling its use, which is inconsistent between release editing (always COW) and disc ID changes (never COW). All I was trying to say is that you seem to disagree with the concept that all releases have independent tracklists. If you really do disagree with that, then first convince people it is wrong. Then we can talk about the COW (which is just an artifact of an optimization of the original concept anyway - a feature, if you will). That optimisation would be nice, but the main issue is the duplicated work done by the user rather than the wasted space server-side. Exactly. It's about *this*, not about shared track lists and COW. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
I thought the idea was to use a combination of Back+Spine for an inlay (for the back of the inlay, anyway, I had to choose Other for the front of a two-sided inlay). In fact that is specifically mentioned in the page linked below, Then select the type or types that apply to the image: see our list of types. You can select more than one type by pressing Ctrl while clicking, for example if an image includes the back of a CD with its spines. http://musicbrainz.org/doc/How_to_Add_Cover_Art -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
On Thu, Jun 7, 2012 at 11:15 AM, Maurits Meulenbelt maurits.meulenb...@gmail.com wrote: My proposal is for the front of a double-sided inlay. ;) I'll write a good description later. Ah, my bad. :) But if the intention is to add the new type for *only* the front/inside then using the term inlay is going to confuse people (as it did me), since the whole thing is the inlay by my understanding. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
On Thu, Jun 7, 2012 at 12:21 PM, Nikki aei...@gmail.com wrote: It seems some people use inlay to mean the entire thing while most people (from what I've seen) use it to mean specifically the inside part. With that in mind, maybe something like Inlay (inside tray) would be better? Technically, it's behind the media tray, not inside it. Then again, both sides are behind the tray. :) Inlay (visible through the tray)? Perhaps that's a little to verbose for the type name. Truth is, I would be happy with most anything but a bare Inlay, provided the cover art types page explains the meaning of words like inlay and tray. Bonus points for tossing in alternative names mentioned in the linked edit. Extra-bonus points if the Types page explicitly mentions Back+Spine. By my count, you have to follow three links to get from a Cover Art edit to that how-to page that only mentions this in passing. (Yes, the description for Spine says that it's usually part of the back cover scan, but I initially took this to mean that I should *only* select Back for such a scan.) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Tue, Jan 31, 2012 at 04:44, symphonick symphon...@gmail.com wrote: RFC-333 doesn't apply to classical. I'm sorry, but you lost me here. What is import release context? I know that RFC-333 does not apply to classical, and I think I made that clear long ago. The point I'm making is that the same issues that made RFC-333 necessary for popular music, should inform the choices we make for classical. A particular recording can be used on any number of releases. So release context is what gives the recording extra meaning in the context of the release. For popular, we have things like (live). For classical, the best example I can give is language. Say a recording is made and initially released in Russia. So, the recording title is entered in Russian. Now the same recording is released in the United States. Well, which titles do I use? Recording titles are useless for me, as they are not localizable. Track titles would be in English, since they put the recordings into the context of an English-language release. Make sense? The titles printed on the cover (within context, also from cover/booklet) In other words, you do not want full CSG titles, as we would build for the work titles. You want titles like those in the proposal. Unfortunately, I do not. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-348: Artist Credits for Recordings
On Tue, Jan 31, 2012 at 08:45, Frederic Da Vitoria davito...@gmail.com Wouldn't it put repetitive information in pages where we could wish a more focused display? Which pages are those? From what I've gathered from earlier discussion, the information is not repetitive, since people are proposing composer disambiguation to but the recording in context. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Tue, Jan 31, 2012 at 03:01, symphonick symphon...@gmail.com wrote: Yeah, sorry I was unclear. It should have said Recording/Artist credits., only the first paragraph dealt with track(list) artists. (see the RFC for Recording artist credits) Okay, sorry for spilling the track AC discussion over into the other thread, then. As a matter of fact, I didn't express myself well in the other thread anyway, so let me clarify below. To clarify the track artist discussion: right now I have 2 suggestions: 1. leave at default value (=Release Artist, featured composers performers suggested) 2. set to composer 1 is the easiest; the problem with it is if you actually want to use the data there's a good chance that it's incorrect 2 is old CSG-style For a concrete examples why (1) could a problem, see: [a] http://musicbrainz.org/release/720fa605-51b4-48f7-852f-ff1069b19402 [b] http://musicbrainz.org/release/b3969b7f-f006-412c-b72b-b849fc7e2732 [c1] http://musicbrainz.org/release/98a01ae6-aaf9-4678-a99a-4fd253a33c8b [c2] https://www.murfie.com/albums/20574 [a] Has no prominent release composer. [b] Has two prominent release composers - will tracks 1-3 have Vaughan Williams in the ACs, and track 4 have Elgar? [c] Tasmin Little is a release featured artist, but only involved in 4 tracks out of 9. A third option would be... Track ACs have a) the composer (which is always going to be credited in the back-cover track list), and b) which ever release ACs apply to the track. But still, I have concerns, which I explain next. Let me restate the points I was making yesterday (hopefully, more coherently). These are in response to the idea that I can make a choice between tagging ARTIST from track ACs or work ACs. 1) Even if Picard had this option, it's not a one-time either-or choice for me. I listen to both classical and popular music. Perpetually toggling a switch to get reasonable results is not appealing. 2) I use last.fm. And sometimes when I scrobble a track, last.fm overrides my choice of artist which a choice of its own. Obviously, their choice must be based on some other set of data -- MusicBrainz data, near as I can tell. So, regardless of my own choices, how third parties use MusicBrainz data has an impact on me, as well. 3) Third parties like last.fm cannot make a release-to-release choice between an option that works for popular and an option that works for classical. They can make only once choice. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Tue, Jan 31, 2012 at 09:48, symphonick symphon...@gmail.com wrote: Let me restate the points I was making yesterday (hopefully, more coherently). These are in response to the idea that I can make a choice between tagging ARTIST from track ACs or work ACs. You mean Track or Recording ACs, right? No, I was responding to a suggestion that if I want my track artist tags to have composer, then I should use the work. I guess what I misstated was work ACs should have been work composers. Sorry. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-348: Artist Credits for Recordings
On Tue, Jan 31, 2012 at 11:42, Frederic Da Vitoria davito...@gmail.com wrote: For example displaying all the recordings of a work. In that case, since you started from a work, you know the composer, of course. And on other pages you have the reverse problem, thus composer disambiguation? For me, it all comes down to artist credits, and IMO composition is contribution worthy of recording credit when it comes to classical. Even if you disagree, I don't see the point in using solutions like disambiguation comments when you can just go ahead and properly link the artist with an AC. Seems a reasonable compromise to me. After all, we've gone through so much effort to remove artist credits from other titles/comments. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Tue, Jan 31, 2012 at 10:15, symphonick symphon...@gmail.com wrote: That's essentially track AC = composer + my suggested recording ACs. Maybe Picard could join them if you want both? Okay, but I don't quite follow why track/recording ACs wouldn't have this data to begin with. Are you back to track AC = composer only? Or track AC = something else? Okay, but what's the sense of having them separate to begin with? 1) Even if Picard had this option, it's not a one-time either-or choice for me. I listen to both classical and popular music. Perpetually toggling a switch to get reasonable results is not appealing. I suppose tracklist ACs is the default? I don't understand. Are you saying that track ACs will work equally well for classical and popular? What would they have in them? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Tue, Jan 31, 2012 at 13:58, symphonick symphon...@gmail.com wrote: Okay, but what's the sense of having them separate to begin with? This question was actually *supposed* to be deleted before I hit Send. :) If you mean we should have composer + featured performers in both track recording ACs? It's duplication of data that's not (IMO) really needed. I think performers in recording ACs is important, so we can browse performances from works, now it's broken: http://musicbrainz.org/recording/00bc2f83-64e2-40db-b700-a9a52f9fd108 Fair enough, I see the issue with the recording list. The meaning of featured at the recording level is unclear, but I suppose we could make it work. Having composers in that list would mostly clutter up the view, if they're not really useful for anything. In that particular view, perhaps not. I don't see that as reason enough to exclude composers from recording ACs, however. For track artists, I think I'd personally favor composer only. It's the easiest to enter (second only to not entering anything at all), it looks clean in the tracklist works for tagging. For showing performer credits in the UI, ARs work much better, so I don't know if it helps anyone to have both composer performers there? Agreed. Are track ACs displayed anywhere but tracklists? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Fri, Jan 27, 2012 at 16:04, David Hilton quercus.aeter...@gmail.com Regardless, I don't consider this the ideal solution. Putting the redundant information into the work hierarchy and then appending the unique parts is much more appealing. Definitely, and I'd be happy to revisit this when we get there. I think it's still likely to produce odd results with opera (though exactly how opera recording/work linking is going to work is still undecided, I think). I feel like you focused on less important parts of my message; perhaps I was unclear, or you agree with the rest of what I said? No, I think you were clear. It's just that I've been down this road already in my mind, and concluded it's unlikely to work well. :) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: That I can agree with, some of them do not conform to old CSG (and some look too simplified for me too, tbh). But mostly I am asking: what would you, personally, see as good enough? Can you choose, from the list, those who are unacceptable to you, and say what is the minimum amount of normalisation you'd accept for each? (it's hard to compromise on vague grounds :) ). To be honest, it would be more or less the same as I expressed a few months ago in the work title thread. I have a feeling the core idea is getting lost in the discussion, however. My goal, in the end, is to have the same titles that I had before NGS. And in my mind, using track titles that are closer to whats on the release makes that impossible, or at least very difficult. So, yes, all the edits we did before for track titles, we would continue to do for track titles. I apologize if that's vague. First, I just want to make sure I've gotten the concept across. I don't necessarily have time to give a lot of detail aside from what input I've made in the past. Let me ask this. Suppose we implemented a system like that outlined by David Hilton. Do you believe that it could: a) produce consistent, high-quality titles, and b) retain relevant release context? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Sat, Jan 28, 2012 at 06:16, symphonick symphon...@gmail.com wrote: The general idea is to use the track title field to store the actual track title, normalized as any other title in mb (maybe a little bit more). Caps, delimiters etc. but not changing Adagio from Spring to: The four seasons: Spring: II. Adagio or something. This is what concerns me, and this is why I keep bringing up RFC-333. The important message of RFC-333 is that the Musicbrainz schema has no good place to store as-on-cover titles. If you try to use track titles to store this data, you lose import release context; track titles are the *only* place to put the recording in the context of the specific release. I suppose we could ask for a CSG language, if there are people who really really cannot be without old CSG-style track titles. What kind of titles would you like to see on your files when you tag a classical release? And where will these titles come from? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Mon, Jan 30, 2012 at 16:07, Lemire, Sebastien m...@benji99.ca wrote: If the recording titles are normalized and CSGified, why is it not possible to simply use those when tagging for those that want it (myself included) while those that want as on-cover could use the track titles. Well, as I said in my first post in this thread: a) They lack release context. b) Recording titles are not localizable (which I suppose you could include in (a) if you consider language a part of the release context). -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Mon, Jan 30, 2012 at 16:28, David Hilton quercus.aeter...@gmail.com What are you referring to by release context? I'm interpreting that as ARs, but tagging software should be able to attach any or all of the ARs for release, recording and work. Yes, well... I can think of no concrete classical-themed example off the top of my head. If I could, I'd have given it already. :) But in popular music, this would be referring to ETI, maybe some other things brought up in the RFC-333 discussion. http://musicbrainz.org/doc/Style/Titles/Extra_title_information -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Sat, Jan 28, 2012 at 07:55, symphonick symphon...@gmail.com wrote: I recall no one had any ideas of what to do with track artists. I'm going to suggest that we leave them at the default value (=release artist). Slightly reworded from the 2011 wiki: Artist Credits Recording Artist Credits should link to the performer, not the composer. Composer information should be included in a linked work (by way of the recording-work performance AR). I'm a little confused by what we're after in this thread. The title says recording credits and track artist, but your post seems to focus on track ACs. Then you seem to say that we should use the same ACs as the release. Then you go on to say performers, not composer (which I think you may have revised in a later post, I'm not real clear on that). In any case, can someone please explain the benefits of including performers in track/recording ACs? I have some general ideas, but I'd like to hear why people feel so strongly about this. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Recording credits track artists
On Sat, Jan 28, 2012 at 10:39, symphonick symphon...@gmail.com wrote: No, we discussed using featured composer AND performers in the releaseartist field (new pre-RFC will follow). Suppose the release has two featured composers. Are you suggesting that every track would have both composers? (If track ACs repeat release ACs). -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
On Mon, Jan 30, 2012 at 08:59, Alex Mauer ha...@hawkesnest.net wrote: If we are going to do this, I would say “;” for the major separation, “/” or “,” for the minor separation: I think we should have something a little more explicit. Such as using perf. for the join phrase before starting the performing credits. I think ARs already solve this problem, and *that* means we should give up on extra artist fields. Adding a second artist field will just duplicate the ARs and make the problem of artist fields even worse. Yes, but ACs are for storing credits. As in prominent cover/spine/back credits. ARs encompass a whole lot more that that. It's a whole different concept, IMO. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
On Mon, Jan 30, 2012 at 09:03, lorenz pressler l...@gmx.at wrote: Am 30.01.2012, 17:04 Uhr, schrieb Marco Curti mcu...@aliceposta.it: Maybe I've lost something, but I could not understand why we need composer at track/recording level, is not the one at work level the correct one? In my opinion composer(s) are related to works, performers to recordings and other credits (like producers, art designers,...) to releases or tracks in case of 'compilation' of recordings pre released in other releases. Tryng to have some form of 'normalized' composer or performer field at release (or track) level will lead for sure in truble, unless we agree to use them as a form of 'mnemonic' help to name the release (or track) itself, and in this case I think the better way is to use exactly the form producers printed on the cover. i agree. why should i bother adding composer at work lvl if i can do it at release lvl? Here is the practical problem I see with playing too much with track ACs. If my plays start scrobbling as Yo Yo Ma - Sonata for cello and piano, Op. 99 either because that's what's stored in ARTIST, or stored in MUSICBRAINZ_ARTISTID, or pulled in by last.fm through their data feed... Well, then I have a big issue with that. Before we make a change like this I want to know that this scenario *will not happen*. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-348: Artist Credits for Recordings
On Sun, Jan 29, 2012 at 08:55, symphonick symphon...@gmail.com wrote: http://wiki.musicbrainz.org/Proposal:CSG2012/Recording/Credits Thought this might be a good place to start the CSG RFCs, didn't hear anything negative about this in the discussion thread. (track artists will be in another RFC later). I guess I'm just dense today. Can someone please explain the justification for excluding the composer from the AC? While the composer may not have had a direct hand in the recording, they had a rather critical indirect hand in it. Usually the qualification for an AC is .. a prominent credit on the cover/spine/back. About the closest I can find in the style guides after a quick search is Featured artists, which says That is, they are given credit on the cover or track listing of a release by another artist in a manner which elevates their contribution above normal liner note credits. Which to me, says a composer would qualify. That said, recording ACs are really murky for me. Credits for the same recording can change from release to release. Is that what this discussion is about? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
On Mon, Jan 30, 2012 at 20:35, Lemire, Sebastien m...@benji99.ca wrote: This should be handled at the the tagging level. The attached work has a composer linked to it, Picard or whichever tagging software will simply need to be aware of it and give the user the option. That's a great theory and all, but there's so much software out there, and so many data partners, that you can't dismiss the issue out-of-hand, IMO. And it doesn't even consider that it would actually need to work differently for *classical* versus *everything else*. Because *nobody* will want their popular music to put the composer in the track artist and have that scrobbled. Even if Picard was the only tagger in the world, how would it know the difference? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: Nobody is asking to stop normalising titles - just to stop overdoing it. Right now, the idea is to always have, for example, a track title like Divertimento No. 2 for Flute, Oboe, Bassoon, 4 Horns Strings in D major, K. 131: I. Allegro, even if the release says Divertimento nº 2, K131: Allegro. The pre-RFC proposal disagrees with you. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Fri, Jan 27, 2012 at 02:00, David Hilton quercus.aeter...@gmail.com wrote: Sorry, I'm not clear on how part-performance and multi-work-performance stuff makes work titles unusable for track titles. Could you explain? Sure. If I have a track that spans multiple parts, then I want a track title that includes both parts. However, that recording will link to two works, one for each part. So, I have two work titles, how do I get from there to a single title with both parts? Similarly, if it's a partial performance, the work title would not properly reflect such. Theoretically, you could kludge it by slapping (partial) or (excerpt) if it's a partial performance AR, but static phrases like that might not always be appropriate. I would expect to instead use release/recording specific ETI. Again, using recording titles is problematic, so I'm back to track ETI for this information. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: On Fri, Jan 27, 2012 at 10:09 PM, David Gasaway d...@gasaway.org wrote: 2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: Nobody is asking to stop normalising titles - just to stop overdoing it. Right now, the idea is to always have, for example, a track title like Divertimento No. 2 for Flute, Oboe, Bassoon, 4 Horns Strings in D major, K. 131: I. Allegro, even if the release says Divertimento nº 2, K131: Allegro. The pre-RFC proposal disagrees with you. I said *right now*, as in before the pre-RFC. I don't understand. You said nobody is asking to stop normalising titles, yet the pre-RFC says exactly that. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: On Fri, Jan 27, 2012 at 9:12 AM, David Gasaway d...@gasaway.org The line for prominent credit gets a lot murker at the recording/track level, I think. I'd prefer to keep our composer-as-AC status quo (at least for now). If only to avoid a lot of duplication. As far as presentation, is there a reason why the UI currently reads work: performances: recording by AC, recording by AC? Shouldn't that be recordings: anyway, since it's derived from the recording AC, not a performance AR? FWIW, it *is* derived from the (recording) is a performance of (work) relationship. You're right. I didn't think that all the way through. The point is, there is still seems to be an incorrect assumption in there somewhere. An assumption that the AC on the recording represents a performance. The fact that the UI uses the combination of words performance: recording by AC leads people to read that the artists in the AC performed the recording. That's not the case. The better way to phrase it is to say they were credited with the recording. And I still think recordings: recording by AC would clear up a lot of that confusion. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
On Fri, Jan 27, 2012 at 02:10, Frederic Da Vitoria davito...@gmail.com wrote: It's not so much the wording as the uselessness of the information. When I am looking at a Beethoven quartet, I don't need to reminded that Beethoven composed composed that quartet on each performance! But I very much need the main performers. However, the information presented isn't that Beethoven composed the quartet (that information is in the composition AR), rather it's recording that Beethoven was credited with the recording. Granted that *happens* to be the same, but they are different concepts. As far as performers go, I'm of the opinion that is much more important at the release level (as it informs what artists have the releases in their discography). Note also that I said keep the composer-as-artist status quo at least for now. Meaning, I can certainly could be convinced otherwise, but would rather save that discussion for after this RFC. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
On Fri, Jan 27, 2012 at 12:40, Alex Mauer ha...@hawkesnest.net wrote: I don’t see how it would help — in fact, I see no difference there. No matter how you slice it, composer is not a useful thing to put there. For classical music, the composer generally has little or nothing to do with the recording, and everything to do with the work. Furthermore, usually the performer is credited as well as the composer, and they have a much more direct involvement with the recording. So it makes sense to put them on the recording AC. Again, I am reserving opinion at this particular time, in anticipation of further discussion post-RFC. There could be lots of problems with this change from editors on down to end users, and I would like them fully considered as a separate item. That's all I ask. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: It really depends on what you call normalising. Adding the name of the work to all track titles is normalising, and it's useful. The pre-RFC tells to keep doing it. Repeating the same stock title all the time so all the tracks in the DB for the same work have the same title is useless now that we can just relate the work to it to show they're all the same thing, so that's just overkill right now. Except that I explained the reasons why I still want full CSG on track titles, and why RFC-333 should apply to classical as well (meaning recording titles and track titles should match). You didn't address that at all. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Fri, Jan 27, 2012 at 15:10, David Hilton quercus.aeter...@gmail.com It wouldn't be difficult to have Picard recognize that a recording represents multiple works and remove the starting duplicate info: Work1: Subwork1 / Subwork2 You're making a lot of assumptions about what the subworks would be, and whether edits like this would be appropriate. With opera, in particular, things get really hairy. Work titles only have structure in that they will conform to an as-yet-WIP CSG and can and will change. Works, themselves, are used to represent a multitude of entities. Bottom line, I have no confidence the the output of such a process would not be total garbage. It was suggested a while back that where common divisions take place sub-sub works could be created; They *could*, but maybe not, maybe it will have both, maybe it will be case-by-case, that change changes from release to release. That's the whole point. By using works instead of tracks for tagging you *lose all release context*. It's the same argument made months ago in RFV-333. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
2012/1/27 Nicolás Tamargo de Eguren reosare...@gmail.com: Except that I explained the reasons why I still want full CSG on track titles, and why RFC-333 should apply to classical as well (meaning recording titles and track titles should match). You didn't address that at all. RFC-333 *never* said that recording titles and track titles should match - Lukas has repeated that several times. That's why my explanation included *both*. :) RFC-333 said that track titles get the same normalization (same as recording titles), but would include release context. Extrapolating that to classical, both would get CSG normalization. Because recording titles get CSG normalization, no? Even if the end result was to end CSG normalization for recording titles, I'm still right back where I started: I have no way, in the new scheme of things, to the get the same track titles that I know and love from the old system. It did say that for now, until changes were made if deemed interesting, we would use the same *guidelines* for recording titles and track titles (it also explicitly excluded classical, FWIW). Yes, it explicitly excluded classical so that it could be addressed in another discussion. Which is happening now. And now I'm making the argument that all the reasons for RFC-333 apply here. :) One of its goals was indeed not to blindly follow the cover, but I suspect symphonick is not trying to make anyone blindly follow the cover either: classical titles in this pre-RFC still retain a much stronger normalisation than any popular music titles do via the current titling guidelines. That's not my impression looking at the examples in the pre-RFC. That being said, what's full CSG for you? Is it using a standard track title, in the same form and language, for all appearances of a work regardless of liner language? No, in my view the form will not always be the same, thanks to release context, same as in popular music. Is it adding work titles at the beginning of the track, movement numbers, and colons to separate the full work title and the movement? (I tend to agree with that, but that's not that different from the pre-RFC). I've seen as many ideas of full CSG as classical editors, so it'd be useful to know what extent of CSG normalisation you consider basic. CSG as in old CSG. I know there's plenty of disagreement about what that does and does not include. But if you came across a classical release with track titles like those shown in the proposal, I'm fairly confident you would agree that those *do not* conform to old CSG. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG for track titles
On Thu, Jan 26, 2012 at 06:46, symphonick symphon...@gmail.com wrote: Work titles are independent of track names. Work titles should ideally be sourced from the (best possible) score. Eventually most works will exist in the db, so it will be just a question of linking (the recordings) to the appropriate works. (Not replying to symphonick in particular here...) I'm at a loss to understand why the same arguments that applied to RFV-333 for popular music don't apply here. I, as a user, want fully normalized titles in my language, with release-specific ETI. So here are all the potential problems I see for not applying CSG to track titles: 1) Track titles: If I tag from these I get un-normalized garbage. 2) Recording titles: I lose release-specific title variations. In the classical world, in particular, I'm thinking of language variations. Recording titles are not localizable, so there's no telling what language I get. Surely, we're not thinking of having a different recording for language it was released in. 3) Work titles: While they have can have localized aliases, they are not usable for track titles thanks to part-performance and multi-work-performance goodness. In other words, barring other changes, the only way to get what I have now would be to continue normalizing track titles per CSG as before. No? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-347: CSG update for NGS
On Thu, Jan 26, 2012 at 05:20, pabouk pab...@centrum.cz wrote: I am glad that you like the idea but I see much more use for the major artists at release level. They are not only for disambiguation. Please see above. Yes. I think it's important to remember that we're dealing with artist credits now. The release AC should have the artists prominently credited on the cover/spine. This also avoids how a release with two lousy composers currently has to be VA... unless there's a prominent performer... and a one composer release with a prominent performer only goes under the composer... :P We have AC's, let's use them already. The line for prominent credit gets a lot murker at the recording/track level, I think. I'd prefer to keep our composer-as-AC status quo (at least for now). If only to avoid a lot of duplication. As far as presentation, is there a reason why the UI currently reads work: performances: recording by AC, recording by AC? Shouldn't that be recordings: anyway, since it's derived from the recording AC, not a performance AR? Seems that would satisfy peoples concerns regarding nonsense performances by the composer. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC - CSG - Artist Credit
On Fri, Aug 19, 2011 at 16:51, lorenz pressler l...@gmx.at wrote: i already said this, but again: (imho) AC is not here to provide us with specific information (thats ARs task), it is merely a sort instrument. every track, release and recording will be listed under every artist present in its AC. therefor it must be allowed to store every possible artist the entity might be attributed to in the AC field. okay, not every, but we have to decide what are the most likely ones. and for classical this will be most commonly: composer, conductor, soloist and maybe orchestra. [...] as said above, AC just says: this guy plays a significant role for this release/track though i have no idea what, you might want to look at the liner notes (aka ARs) to find out more. its like pop releases. also here the composer is sometimes omitted, sometimes given, sometimes to soloist is credited (feat.) This. I recognize this is problematic for tagging. Possibly downright useless, as others have pointed out, and I have a feeling I'll be forced to rethink my tagging workflow because of it. But I find it preposterous that a release such as this... http://musicbrainz.org/release/c7740aa9-a99f-4665-9063-50e37ce5284e ... does not appear under Cecilia Bartoli's releases at all. It's a fine release that would be of interest to Mozart and Bartoli fans alike. I personally have Bartoli as the album artist; I assume others do actually want it under Mozart. So, let's compromise and put both in the AC. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Arrange on works
On Fri, Aug 19, 2011 at 22:34, Paul C. Bryan pbr...@anode.ca wrote: There are numerous examples of classical works that composers adapt from other composers. In practice, aren't these in the catalog of the adapting composer, given composition credit to the adapter (and possibly the original composer) and/or identified along the lines of Sonata for Harpsichord in C major after Reincken, BWV 966, Fantasie über Beethovens Ruinen von Athen, S. 122? I'd say yes, for your examples (but it would still be nice to link back to the original work somehow). But not necessarily for a famous transcription or orchestration (one that would have many recordings) of a work by another composer. I'd want another work, composition credit for the original composer, and arranger credit for whoever did the transcription/orchestration. Does that sound reasonable? If we need to re-word the work-work AR or some SGs to specifically exclude whatever other garbage people are using the AR for, let's do that. I would say that removing the AR, destroying data in the process, then adding back a new one is the worse solution. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: CSG for works, part II: Subtitles instrumentation
On Fri, Aug 12, 2011 at 01:51, Frederic Da Vitoria davito...@gmail.com wrote: I believe this is again a conflict between what is and what we want to have. Bach's preludes are for organ, that's a fact, and removing this information would be supposing they were meant to be played on any instrument which would be wrong. You don't want to see it because you know they are for organ. Sort of. Removing the instrumentation doesn't say that it could be played on any instrument, just as leaving instrumentation off a titled work doesn't say it can be played on any instrument. It just means it's not specified in the title. All the attributes of the work aren't in the title, and I don't suppose anyone would ever expect them to be. What I'm getting at is this: the instrumentation is not, broadly speaking, part of the title of the work, but there are cases where it's useful to have it there anyway, IMO. The reason I wouldn't want it for that particular example is because I find Prelude and fugue for organ in D minor, BWV 538 unnecessarily verbose, while getting in the way of the information I actually want. Now that I think of it, even if we don't implement the second solution, implementing a classical work input mask which separates the parts to later assemble them appropriately in the physical fields could be a good idea. I like your ideas, but what shall we do right now? I've suggested a number of times in past discussions to move the key signature after the cat#. I think it helps, but no one has ever shown must interest. Could you explain again what you believe this would solve? I guess it would be easiest to provide some links to old posts. I'm pretty sure you were around each time, though. :) http://lists.musicbrainz.org/pipermail/musicbrainz-users/2007-December/017109.html http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-January/005565.html http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007411.html -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: CSG for works, part II: Subtitles instrumentation
On Mon, Aug 8, 2011 at 14:30, symphonick symphon...@gmail.com wrote: Thinking it over again, and I agree it's not optimal. Think we should just have a list instead? Add instrumentation to sonatas, concertos, suites. Maybe Kontretanz in B is enough here. Something like that, yeah. I'm tempted to say any work where a single instrument plays a prominent part. That would also cover partitas, Klavierstücke, etc. On the other hand, would you really want to put for organ on Bach's preludes or for piano on Chopin's mazurkas? I do want Concerto for two oboes and Sonata for four hands, yet I don't want Quartet for two violins, viola and cello. I guess I don't really have a good answer. I suppose it's difficult to avoid. But there's the issue of where to put it, in a way it's like an extra cat no. The old version for the pianosonata: Sonate für Klavier Nr. 29 B-Dur op. 106 For a string quartet, Nr. after instrumentation means it will end up next to the cat. no : Quartett in G für zwei Violinen, Viola und Violoncello Nr. XX K. 80/73f Quartett Nr. XX in G or Quartett in G Nr. XX could theoretically be confused with a Quartet Nr. XX for other instruments. I've suggested a number of times in past discussions to move the key signature after the cat#. I think it helps, but no one has ever shown must interest. Still, even if we leave it where it was, wouldn't your example end up as the following? Quartett für zwei Violinen, Viola und Violoncello Nr. XX in G, K. 80/73f It has been suggested that we use aliases. They are specific for each language anyway. Good point. You're probably right. Keep thinking about that solution :-) Also classical releases often come with 3-4 different tracklists (languages), so we will need a guideline for chosing. Language of label? of work? recording location? I don't think work language is quite right. If a Tchaikovsky recording is made and only ever released in the US, what's the point in using Russian recording titles? Recording location may not necessarily have anything to do with release country; I have a BBC Music release (companion disc for the UK magazine) that contains material recorded all around Europe. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: CSG for works, part II: Subtitles instrumentation
On Wed, Aug 10, 2011 at 01:25, Frederic Da Vitoria davito...@gmail.com wrote: Actually, the only thing that was bothering me here was that the closest part to the original title would probably be Sonate für Klavier B-Dur with or without opus number, it depends. Then we (actually not only we, but almost everybody) insert a number right inside the original title and append a catalog number. I was trying to get to separating extra-original data from original title data, something like ETI. But I now realize this is not possible: some composers did number their works by category, some did not, some composers used Opus numbers, some did not and so on. There is no universal way to name a work which would keep original data and added data separate. I must accept that the original title (when the original title is available) will not be clearly separated from whatever we add, that the work titles are completely artificially assembled, and that separators are part of this assembly. In short, please forget my question :-) Can you think of anywhere else where we *could* put the original title? Or some reasonable way to ask that a field be added to the schema for this purpose? (By reasonable, I mean, something that would be clear and relatable to other types of music.) -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Add work types
On Fri, Aug 12, 2011 at 09:54, Nikki aei...@gmail.com wrote: And given that we deliberately don't have genre fields, instead only having folksonomy tags, I wonder if that is an argument for removing work types entirely... I still think there's a use in classical for a select list of work types, with an Other catch-all, for the purpose I already stated. As long as people don't expect it to be especially precise. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Add work types
On Wed, Aug 10, 2011 at 01:40, Rupert Swarbrick rswarbr...@gmail.com wrote: So, my question: Has anyone articulated a vision for what this field should become? What are the views of the people in this thread? And, finally, have I missed an important explanation which makes my whole email a waste of time? :-) I'm not real sure what the original purpose to work type was, but I believe there was a discussion to use work type to provide some minimum grouping/organization/filtering to the work lists of classical composers. As it stands now, the work list of a prolific composer like Bach is a total cluster. And will continue to be even after making all the appropriate merges. Supposing such features were implemented, what sorts of groups would folks expect to see for popular music? -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Tue, Aug 9, 2011 at 08:50, jesus2099 hta3s836gzac...@jetable.org wrote: Is there anything more to // the so called “normalisation” stance // than just personal taste ? I fear many more damage will come with this RFV but maybe it was just a wrong feeling. It is personal taste, in a way. MusicBrainz has never catered to that particular taste. I'm not saying we shouldn't try. But as folks have tried to explain, by using track titles for this purpose, we *loose the existing pre-NGS functionality*. The crowd of people giving this a +1 just want back what they already had. It would have been nice to make everyone happy in one fell NGS swoop, but reality bites. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: CSG for works, part II: Subtitles instrumentation
On Fri, Aug 5, 2011 at 07:34, symphonick symphon...@gmail.com wrote: ==Special cases== ===Untitled/Generic Works=== Instrumentation For some types of untitled works (sonatas, concertos +?), the instrumentation is a part of how you usually would identify the work. In these cases, instrumentation has to be added to the worktitle. If available, use explicitly printed instrumentation or what can be derived from the title page. *Kontretanz in B für zwei Oboen, zwei Hörner, zwei Violinen, Violoncello und Baß K. 123/73g (printed) So, you feel, in this case, that the instrumentation is a part of how you usually would identify the work? I feel I'm still missing something. *Sonate für Klavier B-Dur op. 106 (derived from Klaviersonaten) OT, but have you decided whether you'd like to have the Nr. 29? The lack of punctuation in many of these examples is troubling. But since you did have punctuations in the earlier thread, I'll just assume you were dropping parts irrelevant to this discussion. These few things aside, looks pretty good to me. We can surely find better wording, but I want to make it clear that you must have very strong reasons to change a title that has been verified against a printed score (of high quality). Fair enough. How do you feel about popular titles not given by the composer? So am I. it's OT, but I think recording titles must be standardized track titles (from earliest release), like in pop MB. so recordings will have (complete) French titles only if the first release had. Hmm. I don't know that earliest release really works for anyone. Even for popular music, I'm sure I've seen examples were an English artist had releases that were available first in Japan or some such. I doubt anyone would be pushing to have Japanese titles for the recordings in that case. I don't have a better solution off the top of my head, though. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Fri, Aug 5, 2011 at 20:13, Ryan Torchia anarchyr...@gmail.com wrote: I tried to point out specific flaws this message (though all the formatting got stripped out, so it's hard to follow, but sections are quoted directly from the proposal followed by numbered comments). Ah, a message that came four days into the RFV, following weeks of RFC, hundreds of posts, after almost everyone had burned out on arguing over this. I can see how it didn't get much attention. But hey, the floor is always open for new proposals. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
2011/8/6 Lukáš Lalinský lalin...@gmail.com: It's been more than a week since the RFC and to my surprise there has been only one negative feedback, which I don't think is justifiable, because it ignores the basic problems that motivated me to propose these changes, which I mentioned in the initial email. All MB editors I know, except for jesus2099, agree with these changes. So, considering the +1s I got on the ML, here is the RFV. I'll give this my +1. I do share Philip's concerns regarding documentation on the differences between track titles and recording titles. However, I would like to see this go through sooner rather than later. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Fri, Aug 5, 2011 at 05:34, Ryan Torchia anarchyr...@gmail.com wrote: Hmm. The only assumption I see in this proposal is a credit is a credit. Which is an assumption, an enormously damn bad one too, borderline offensive if you work in performing arts, which I'm guessing relatively few people here do, will occasionally run contrary to artist intent, and -- given that the basis of this proposal is that featured credits are different from other album credits -- not what's being assumed. The problem is you keep reading a meaning out of artist credits that just isn't there. Why would anyone be offended by the statement that the artist was credited? Because that's the only statement made by adding an artist credit for a featured artist. Seriously, how could you not see the value in that? Sorry, but I don't. But all that is a completely different topic than where to put the featured artist credits. Putting the artist in the track title solves none of those things. It's already accurate. I've never seen a single conflict over whether somebody was a primary or a guest. The existing guidelines and primary/secondary definitions weren't the reason for this change; it was all about linking the name. Except that you wanted, IIRC, to have a guideline that said *sometimes* featured artists went in the title, and *sometimes* they went in the AC. Figure out what you're doing wrong and correct it. You're the only one I see complaining about it. You figure it out and get back to the rest us with a solution. A collaboration means both are primaries. That's been a well-established standard here for awhile. I don't see it. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Fri, Aug 5, 2011 at 06:28, Ryan Torchia anarchyr...@gmail.com wrote: On Thu, Aug 4, 2011 at 8:43 PM, David Gasaway d...@gasaway.org wrote: Please give specific examples. There are currently 373 artist that have feat in their names, 458 if you use fuzzy feat*. I am able to search the database just fine, thank you. The problem is, I know nothing about these artists. Please cite specific examples you are familiar with and explain how they are problematic/incorrect and what we might do to fix it. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Wed, Aug 3, 2011 at 23:15, Ryan Torchia anarchyr...@gmail.com wrote: I think some of the assumptions upon which the guideline is based aren't consistently true -- not that they're false, but that they're not reliably true. Hmm. The only assumption I see in this proposal is a credit is a credit. I've asked for the plan to preserve current functionality, how to keep guests out of the Artists field and off Recording lists while ensuring collaborations are still there. That's the thing. I don't want to preserve the current functionality because I think it stinks. And I still don't see much value in a list that only shows recordings where the artist is primary. That's beside all the trouble it would take to make such a list accurate, given every other editor's definition of primary. That's what concerns me: a group of a dozen or so people woking in relative isolation under the assumption they're representative of the community at large. It's pretty hard to reach the community at large. If they're not motivated sufficiently to participate, what are we to do about it? Anyway, I just came across this page. You may find it interesting: http://wiki.musicbrainz.org/Getting_Rid_Of_Featuring_Artist_Style We've already had a guideline that requires users to make judgement calls whether a credit is primary or secondary. That was the statement I was replying to, and of course, the current proposal would still require it. It asked that they make a judgment call about whether it should be considered a collaboration, but not about who is primary or secondary. Please, if you have to strip my replies of all context to make some weak jab, don't. I did misinterpret your statement, and I apologize for that. There was no intent to twist your words in my zealous cropping. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Thu, Aug 4, 2011 at 04:28, Ryan Torchia anarchyr...@gmail.com wrote: So the cases where feat. is used in an actual equal collaboration, or where a band is named Band feat. Leader aren't allowed to use feat. because it's reserved to parse this specific kind of relationship? What are they supposed to use instead? Please give specific examples. Counterexamples in the SG might be worthwhile, if they really are notable and useful. But it sounds to me these are just exceptions that fall outside the guideline. So if they made tea and... cowrote and produced the track, and for whatever reason feat. is used on the album, that's the same as just making tea? As far as ACs are concerned? Yes. That's why we have ARs. -- -:-:- David K. Gasaway -:-:- Email: d...@gasaway.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
