Re: [mb-style] [silence]/[data track] recordings in NGS
2011/3/23 Nicolás Tamargo de Eguren reosare...@gmail.com: On Wed, Mar 23, 2011 at 1:29 PM, Maurits Meulenbelt maurits.meulenb...@gmail.com wrote: Don't all silent tracks on a release have an artistic purpose? Otherwise I don't think they would be on the release. I'd keep them separate. -- Inviato dal mio cellulare Android con K-9 Mail. Not all of them. We have the [silence] tracks that are just there to separate normal tracks and bonus tracks, and that are just 2-second long computer silence. Those are the ones I'd consider merging as one recording… any others I'd keep separate. Can you give an exaple of any of these 'others'? Jan (zout) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Bandleader Position Relationship Type
BrianFreud decided to revert all edits on this proposal[1] because this proposal has an active champion, and was assumed without my permission. That's not the way to go. Jan (zout) [1] http://wiki.musicbrainz.org/Proposal:Bandleader_Position_Relationship_Type_Proposal On 11 March 2011 23:37, Alex Mauer ha...@hawkesnest.net wrote: On 03/11/2011 02:32 PM, Aurélien Mino wrote: Music Director Position Relationship Type is mentioned in the Guidelines section, but it's neither an official AR type, nor an active proposal. This mention should be removed if this AR ought to become official. Good catch, thanks. There are no examples. Please add a few ones for each AR type. I added some examples. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Extra Title Information vs Recording comment
Hi, A ticket has been filed regarding extra fields for ETI: http://tickets.musicbrainz.org/browse/MBS-1608 Jan (zout) On 13 January 2011 21:25, ChurruKa churr...@hangar18.cc wrote: (The feature req. I sent was about subtitles, but I think the principle is the same) 2011/1/13 ChurruKa churr...@hangar18.cc: On Wed, 12 Jan 2011 23:22:54, Frederic Da Vitoria davito...@gmail.com wrote: I still think that physically separating ETI from the actual title would be a good idea. I understand that the comment field would not be the correct way to do it, but I believe that cramming different types of data into one field is a bad way to do things. IMO we should keep the titles as they currently are (with the extra title info.) and maybe later ALSO split them on two different fields, so users/websites/etc accessing the data can choose to handle it the way they want. Some months ago I posted a feature request about this at http://jira.musicbrainz.org/browse/MBS-832 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Mailing list/forum dissonance
On 12 February 2011 01:25, Johannes Weißl jar...@molb.org wrote: what about the Google Groups interface? I participate in a mailing list there, and from the mail headers it seems that most people just post using their web browser, although for me it's a perfectly normal mailing list. Downside is of course, it isn't open-source and you need a google account. I did a quick search and found GroupServer [1], maybe it helps... I always wondered why there were forums and mailing lists, a unification would be great! [1] http://groupserver.org/ I also found Midgard[2] and m2f (Mail2Forum)[3]. Might be what 'both sides' can live with. Regards, Jan van Thiel [2] http://www.midgard-project.org/discussion/developer-forum/forum-to-mailing_list_integration/ [3] http://mail2forum.com/ ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bass vs. Bass Guitar: generic bass?
On 10 February 2011 06:36, Nikki aei...@gmail.com wrote: Nikki wrote: How about moving the current bass to other and giving it a description saying that it's a generic instrument and people should use bass guitar or double bass if they know which one it refers to? (although unfortunately the description won't actually be shown until someone fixes [1]) There didn't seem to be any reasons why I shouldn't, so I've done this now. (It can always be undone...) Is it somehow possible to get a search query that returns all ARs that use this bass? Or a report that lists the releases and/or tracks that use them? Regards, Jan van Thiel ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Better name for guess case?
On 25 February 2011 21:41, Nikki aei...@gmail.com wrote: As you're probably aware, guess case does more than just guessing the case. :) (it also changes things like Pt, extra title info, etc). It came up on IRC and we were wondering if anyone can think of a better name we can use. One thing we do like about the current name is guess though, it is only a guess, so something which doesn't make it sound too much like it will definitely be right would be nice. So, any ideas? :) What about Guess Style Format? Or would that be too long? Regards, Jan van Thiel ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Go - The Very Best of Moby
Hi, Recently, my edit http://musicbrainz.org/show/edit/?editid=12875332 was voted down. It was to rename Go: The Very Best of Moby to Go - The Very Best of Moby. It is against http://musicbrainz.org/doc/Subtitle_Style , but the - is everywhere on the artwork and in my opinion should therefore be allowed. Same rationale has been used on http://musicbrainz.org/release/ade21fff-dba2-438f-8e31-5325c4afb05f.html . What do you think? Regards, Jan van Thiel (zout) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (4th try): add attribute 'translated' to LyricistRelationshipType
On 28 February 2010 17:19, Brian Schweitzer brian.brianschweit...@gmail.com wrote: On Sun, Feb 28, 2010 at 8:33 AM, Jan van Thiel z...@musicbrainz.org wrote: On 27 February 2010 17:02, Brian Schweitzer brian.brianschweit...@gmail.com wrote: On Sat, Feb 27, 2010 at 8:39 AM, Jan van Thiel z...@musicbrainz.org wrote: This is a fourth RFC, rephrased compared to the third RFC. On the JIRA bug tracker this RFC is located at [4]. -- I'd like to see attribute 'translated' added to the Lyricist Relationship Type[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that somehow follow the original lyrics (e.g. carry the overall meaning of the work into the other language). The 'translated' attribute does not apply on cases where the meaning of the lyrics is unrelated (i.e. only the music is related/covered). I know this is where this got bogged down the last time, and this is definitely better, but follow the original lyrics (e.g. carry the overall meaning of the work into the other language). still seems like it's stretching; it specifies something, but the something it's defining is so vague that I can see lots of potential misreadings and loopholes. Would something like this (to replace the entire above paragraph) maybe work better? While a literal translation is not required for this attribute, the translated lyrics should still be distinctly and detectably derived from the original lyrics. and leave any further value judgments for the voters to decide? I guess this is better. Finally a native English speaker gives it a go ;) Parody translations should be linked with Parody Relationship Attribute[2] of the Cover Relationship Type[3], not with this attribute. What if the original song were a serious song with lyrics in German, and the new song were an English parody of the German song? To give this some purely hypothetical context, consider a parody version of the German football team's (hypothetical) fight song, released by the fan of a team from South Africa, taunting the German team during the World Cup. Would that use both parody and translated, or would the last bit above exclude *any* parodies, translated or not? It should exclude *all* parodies, whether they are translated or not. Parodies in general have new lyrics, right? I guess that's where I'd see the judgment of the voters coming into play. It's not a translation from any other language, but wouldn't you consider We will, we will, mock you! (just one at random; http://www.com-www.com/weirdal/submissions/parody-049.html ) to be essentially the same lyrics, but satirized? I just get the sense that there's cases where both attributes could be true, so making the two attributes explicitly mutually exclusive seems like its being over-restrictive. Is your aim to block these perhaps rare almost the same, even in translation, parody lyrics cases, or to avoid something like http://www.com-www.com/weirdal/submissions/parody-049.html having an English-English satirization of the lyrics misinterpreted as translation? The last case. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (4th try): add attribute 'translated' to LyricistRelationshipType
On 27 February 2010 17:02, Brian Schweitzer brian.brianschweit...@gmail.com wrote: On Sat, Feb 27, 2010 at 8:39 AM, Jan van Thiel z...@musicbrainz.org wrote: This is a fourth RFC, rephrased compared to the third RFC. On the JIRA bug tracker this RFC is located at [4]. -- I'd like to see attribute 'translated' added to the Lyricist Relationship Type[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that somehow follow the original lyrics (e.g. carry the overall meaning of the work into the other language). The 'translated' attribute does not apply on cases where the meaning of the lyrics is unrelated (i.e. only the music is related/covered). I know this is where this got bogged down the last time, and this is definitely better, but follow the original lyrics (e.g. carry the overall meaning of the work into the other language). still seems like it's stretching; it specifies something, but the something it's defining is so vague that I can see lots of potential misreadings and loopholes. Would something like this (to replace the entire above paragraph) maybe work better? While a literal translation is not required for this attribute, the translated lyrics should still be distinctly and detectably derived from the original lyrics. and leave any further value judgments for the voters to decide? I guess this is better. Finally a native English speaker gives it a go ;) Parody translations should be linked with Parody Relationship Attribute[2] of the Cover Relationship Type[3], not with this attribute. What if the original song were a serious song with lyrics in German, and the new song were an English parody of the German song? To give this some purely hypothetical context, consider a parody version of the German football team's (hypothetical) fight song, released by the fan of a team from South Africa, taunting the German team during the World Cup. Would that use both parody and translated, or would the last bit above exclude *any* parodies, translated or not? It should exclude *all* parodies, whether they are translated or not. Parodies in general have new lyrics, right? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC (4th try): add attribute 'translated' to LyricistRelationshipType
Hi, This is a fourth RFC, rephrased compared to the third RFC. On the JIRA bug tracker this RFC is located at [4]. -- I'd like to see attribute 'translated' added to the Lyricist Relationship Type[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that somehow follow the original lyrics (e.g. carry the overall meaning of the work into the other language). The 'translated' attribute does not apply on cases where the meaning of the lyrics is unrelated (i.e. only the music is related/covered). Parody translations should be linked with Parody Relationship Attribute[2] of the Cover Relationship Type[3], not with this attribute. -- Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html http://musicbrainz.org/track/f66f275a-9c7c-4fb6-9d36-9f0e489d01f7.html -- Thoughts, ideas? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/Lyricist_Relationship_Type [2] http://wiki.musicbrainz.org/Parody_Relationship_Attribute [3] http://wiki.musicbrainz.org/Cover_Relationship_Type [4] http://jira.musicbrainz.org/browse/MBS-466 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: add DCC (Digital Compact Cassette) as media format
No-one replied to this, so it has been accepted! Jan 2009/8/4 Jan van Thiel z...@musicbrainz.org Hi, I'd like to see DCC (Digital Compact Cassette)[1] being added as media format. We already have MiniDisc, which is similar. The name in the format list can be DCC. The RFC was posted on April 25th and no-one objected: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-April/007871.html Jan [1] http://en.wikipedia.org/wiki/Digital_Compact_Cassette ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: Soundtrack's track title style
2009/8/11 Gioele gio...@svario.it: right now there are no clear guidelines on how to deal with compilations that combine tracks from more than one soundtrack. The current trend is to name these tracks using the Movie name: Track name template. I like this template and I'd like to put forward a RFC to codify this behaviour into a guideline. Any comments? Do you have some real-life examples where this template might be used? Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: add DCC (Digital Compact Cassette) as media format
Hi, I'd like to see DCC (Digital Compact Cassette)[1] being added as media format. We already have MiniDisc, which is similar. The name in the format list can be DCC. The RFC was posted on April 25th and no-one objected: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-April/007871.html Jan [1] http://en.wikipedia.org/wiki/Digital_Compact_Cassette ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: PartNumberStyle (second attempt)
I meant real-life examples of things like This Is a Trackname, Parts 1, 4 5. That is, parts that are not just ranges. Jan 2009/7/21 Brian Schweitzer brian.brianschweit...@gmail.com: Just with respect to Part as a part word, there are around 100,000 cases in the database of multiple part numbers being indicated within a track title. I don't have the dump handy anymore (I was using it while working on ironing out newGuessCase bugs), but I can say that there is basically no consistancy at all; everything from Parts 1, 2, 3 to Part 1 and Part 2 + Part 3 to Pts.1,2,3, and worse, is in there. Honestly, given the current mess, I could provide any examples, but anyone else could likely also provide counter-examples using just about any formulation desired. (Keep in mind that the current GuessCase script only fixes singular Part, so every time anyone's entered a track with more than one part in the title, it's just been kept as is, no fixing.) Brian On Mon, Jul 20, 2009 at 4:31 PM, Jan van Thiel z...@musicbrainz.org wrote: I want to see real-life MB examples of all cases presented in the draft. Jan 2009/7/20 Chris B ch...@whenironsattack.com: i still think that dropping the various spacing rules and just having either X-Y or X to Y is better. it's consistent, looks more natural, and these language issues with to IMO aren't a deal breaker because of all the other various localisations issues we have with this style, and indeed all across musicbrainz. simple guidelines like this are just going back and forth and getting even more complicated. the guideline has doubled in size from the old http://musicbrainz.org/doc/Part_Number_Style, which was if anything too long to start with. blah. 2009/7/17 Brian Schweitzer brian.brianschweit...@gmail.com: http://wiki.musicbrainz.org/Part_Number_Style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: PartNumberStyle (second attempt)
I want to see real-life MB examples of all cases presented in the draft. Jan 2009/7/20 Chris B ch...@whenironsattack.com: i still think that dropping the various spacing rules and just having either X-Y or X to Y is better. it's consistent, looks more natural, and these language issues with to IMO aren't a deal breaker because of all the other various localisations issues we have with this style, and indeed all across musicbrainz. simple guidelines like this are just going back and forth and getting even more complicated. the guideline has doubled in size from the old http://musicbrainz.org/doc/Part_Number_Style, which was if anything too long to start with. blah. 2009/7/17 Brian Schweitzer brian.brianschweit...@gmail.com: http://wiki.musicbrainz.org/Part_Number_Style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] DiscogsRelationshipType and pending Discogs releases
2009/7/16 meindu...@nurfuerspam.de: I'd like to re-open the discussion here whether this sentence shall be removed from the guideline or not. +1 for removal. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Cataloguer Relationship Type
2009/5/2 Aurélien Mino a.m...@free.fr: Does that means that a non-artist person can be added in the database just for this relationship? We already have photography etc.? Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: add DCC (Digital Compact Cassette) as media format
Hi, I'd like to see DCC (Digital Compact Cassette)[1] being added as media format. We already have MiniDisc, which is similar. The name in the format list can be DCC. Jan [1] http://en.wikipedia.org/wiki/Digital_Compact_Cassette ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add DCC (Digital Compact Cassette) as media format
2009/4/25 Brian Schweitzer brian.brianschweit...@gmail.com: I am all for adding support for more, and more detailed, formats. However, I suggest that, as with the already-accepted Blu-ray, HD-DVD, and DVD-Audio formats, this, and the rest of http://wiki.musicbrainz.org/ReleaseTypeRestructuringDiscussion , may perhaps be best implemented when the server has subformat support, rather than our simply expanding the list of formats into a mix of actual media types as well as specific types of media. Jan, I'd support this RFC. However, assuming this passed, would you be willing to accept a delay in actual implementation, so that DCC could be implemented as a subformat? (MiniDisc as well likely will have to be moved to be a subformat when that type of support for subformats is implemented.) Sure, sounds good. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
2009/4/24 Kuno Woudt k...@frob.nl: On Thu, Apr 23, 2009 at 07:38:17PM -0400, Brian Schweitzer wrote: Please, stop the condesension. Example != guideline. There is no need, nor reason, to revert. The example, as I have pointed out many times now, is just as correct, per the current guideline's text, with spaces as without. Considering the amount of traffic on this subject (I haven't read most of it, sorry), whatever change you've made apparently isn't as trivial as you assumed it to be. This in itself already qualifies your change for the RFC process. Thanks. Good point. I also think that examples *are* part of the guideline, especially when they show cases that aren't explicitly written out in the rest of the guideline. About this specific problem with spaces/no spaces. There seems to be just one person who has a problem with Main Title, Parts 1-3. Guess there is no need to change the guideline. An RFC of course can always be written. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
I meant examples of tracks where no spaces give an ambiguous result. Jan 2009/4/21 Brian Schweitzer brian.brianschweit...@gmail.com: Just some example searches: http://musicbrainz.org/search/textsearch.html?query=%22Parts+1+-+3%22type=tracklimit=25handlearguments=1 http://musicbrainz.org/search/textsearch.html?query=%22Parts+one+-+three%22type=tracklimit=25handlearguments=1 There's some in there. But mostly, any of these, either style, there's fewer that follow any particular style pattern than those not following any pattern, regardless of the guidelines. Brian On Tue, Apr 21, 2009 at 7:52 AM, Jan van Thiel janvanth...@gmail.com wrote: And can you show where any of these examples should contain spaces in the part numbering to get more clarity? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
2009/4/21 Brian Schweitzer brian.brianschweit...@gmail.com: Just trying any number greater than 12, at random, I see several perfectly valid Part 20 results right now: http://musicbrainz.org/search/textsearch.html?query=%22Part+20%22type=tracklimit=25handlearguments=1 As for 1a and 1-1, they're not interchangable, as the guideline says that we respect whatever the original numbering scheme was, so I don't know that I follow your point there. I most frequently see 1-1 in legal or lecture materials, where it is quite possible to see 1-1a, being the first example for the first section of the first chapter. We are dealing with track titles, not legal or lecture material. The point here is, it can be shown that the no spaces version breaks, where the spaces version doesn't. Even if some of the cases where the no spaces version breaks are uncommon, there's *no* instances where the spaced out version breaks. True. But first show some real MusicBrainz examples of these weird cases without talking about hypothetical problems. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
And can you show where any of these examples should contain spaces in the part numbering to get more clarity? 2009/4/21 Brian Schweitzer brian.brianschweit...@gmail.com: On Tue, Apr 21, 2009 at 3:10 AM, Jan van Thiel janvanth...@gmail.com wrote: 2009/4/21 Brian Schweitzer brian.brianschweit...@gmail.com: Just trying any number greater than 12, at random, I see several perfectly valid Part 20 results right now: http://musicbrainz.org/search/textsearch.html?query=%22Part+20%22type=tracklimit=25handlearguments=1 As for 1a and 1-1, they're not interchangable, as the guideline says that we respect whatever the original numbering scheme was, so I don't know that I follow your point there. I most frequently see 1-1 in legal or lecture materials, where it is quite possible to see 1-1a, being the first example for the first section of the first chapter. We are dealing with track titles, not legal or lecture material. The point here is, it can be shown that the no spaces version breaks, where the spaces version doesn't. Even if some of the cases where the no spaces version breaks are uncommon, there's *no* instances where the spaced out version breaks. True. But first show some real MusicBrainz examples of these weird cases without talking about hypothetical problems. I'm not sure I follow your first point; legal and lecture materials come in audio form on CDs, just like anything else we deal with. But, some examples: 1-1, 1-2, using what appears to be ArtistIntent for no 'Part' title: http://musicbrainz.org/album/6823dac6-92c9-435f-91dd-48fdc830516f.html Using Dialog as the section title: (Dialogue 1-1, etc) http://musicbrainz.org/album/38598c38-38a0-4f2c-833e-d9769ec4b8d2.html Using Unit as the section title, ala lecture material: (Unit 1-1, etc): http://musicbrainz.org/release/b3f652ec-f2c6-463f-992a-5258ca8fec61.html 1-1, 1-2, etc as chapter titling, using various translations of the word Chapter as section word: http://musicbrainz.org/release/98c22b7c-e7e7-440a-b189-05ed46e86c00.html http://musicbrainz.org/release/877ca245-40c9-422f-8421-7f51f625504c.html 1-1, etc as level title, using Level as the section word: http://musicbrainz.org/release/698a655a-1233-43ff-8a7f-cf2e259e9384.html Part I-III: http://musicbrainz.org/release/8f5066f9-b7e9-4f3e-940d-5b8fe0a2c5b0.html Just a few examples. Keep in mind, PartNumberStyle is written to be quite expansive, due to it covering any numbering scheme in use, and allowing any alternate word with simiiar intent to Part to be substituted... Brian ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
2009/4/18 Bogdan Butnaru bogd...@gmail.com: By the way, this disambiguates numbering schemes with sub-parts, e.g. “Parts 1-3–3-7”, or “Parts twenty-two–seventy-nine”. On the other hand, I see no reason why we wouldn't simply have as a rule “spell things out whenever the dash would be confusing”, e.g. “Parts twenty-two to seventy-nine”. I'd like to see some real life examples of subparts in part numbering to see whether this discussion is even relevant to MB. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PartNumberStyle - Foo, Parts 1-3 vs Foo, Parts 1 - 3
2009/4/16 Aaron Cooper coope...@gmail.com: My vote is for a)... no extra spaces. +1 Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC (3rd try): add attribute 'translated' to LyricistRelationshipType
Hi, I propose something, people object, it is amended to add 'significantly altered', people object to the 'significantly altered' part. I don't know what should be done now. Drop this proposal? Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Revise SortNameStyle to establish single delimiter for multiple artists
2009/4/14 Paul C. Bryan em...@pbryan.net: Proposal: Change item #5 in the SortNameSytle to read as follows: If an ArtistName consists of two or more collaborating artists, each individual name is sorted separately according to the rules below. The separator (e.g. and, with, vs., y, et, comma, etc.) is always replaced with an ampersand . +1 Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC (3rd try): add attribute 'translated' to LyricistRelationshipType
Hi, This is a third RFC, somewhat altered. It specifically excludes 'based on'/'adaption' lyrics and is rephrased from the second RFC. -- I'd like to see attribute 'translated' added to the LyricistRelationshipType[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that are really translations (e.g. follow the original lyrics). The 'translated' attribute does not apply on cases where the meaning of the lyrics is significantly altered. The meaning of 'significantly' must be left to the appreciation of the editor and voters. Parody translations should be linked with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3], not with this attribute. -- Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Is this satisfactory? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/LyricistRelationshipType [2] http://wiki.musicbrainz.org/ParodyRelationshipAttribute [3] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/3/27 Frederic Da Vitoria davito...@gmail.com: 2009/3/27 Jan van Thiel janvanth...@gmail.com 2009/3/27 Frederic Da Vitoria davito...@gmail.com: 2009/3/27 Jan van Thiel janvanth...@gmail.com Parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]) and lyrics that are based on lyrics in another language that have altered location, meaning, new elements, elements dropped, etc. (This probably should be rephrased) Maybe it's me (I have been quite inefficient in reading MB documentation recently ;-) ) but I don't understand the last part from and lyrics... at all. I understand what you are speaking about, but not what you suggest should be done or not done with it. I think it was me ;) I meant to exclude the cases you (amongst others) were talking about, i.e. songs that are covers in a different language but with the meaning changed substantially. Ok. As SwissChris said, a translation always alters the original meaning. Some alterations could actually improve the transmission ot the original meaning. For example, imagine a Japanese song set in Tokyo. To a Japanese listener, nothing exotic here. If this song was translated to English and the translator kept the Tokyo setting, this would trigger a feeling of exotism in an occidental listener which would distract him from the song's true meaning. So I believe changing the setting to a big occidental city would be correct and I would still consider this as a translation. I could easily imagine similar examples for new elements and elements dropped. So I suggest something more open: The translated attribute does not apply on cases where the meaning is significantly altered. The meaning of significantly must be left to the appreciation of the editor and voters. This seems like better description. Thanks! Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/3/27 SwissChris swissch...@gmail.com: What I could imagine to work would be a check box (like for the cover relationship), which for the lyricistAR allows to pick – original (= wrote the lyrics of the original version) – translated (= wrote the lyrics of the translated/adapted version in the language of the actual track or release) We now have the 'wrote the lyrics for' AR which would indicate original as above. The new attribute 'translated' which this RFC is for would indicate translated as above. Isn't this covered in the RFC? This whould be purely descriptive (some guy wrote lyrics to this tune in language A; some other guy wrote different lyrics in language B), and independent from the content of the song or from how important the alterations were: from a very close translation (like e.g. Next/Au suivant) to a completely new story told (like in the case of My way/Comme d'habitude). Well, completely different lyrics are not a translation, are they? It's just new lyrics (accidentally in a different language). Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/1/13 Frederic Da Vitoria davito...@gmail.com: 2009/1/13 Jan van Thiel janvanth...@gmail.com 2009/1/13 Frederic Da Vitoria davito...@gmail.com: 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Jan van Thiel janvanth...@gmail.com Hi, I'd like to see attribute 'translated' added to the LyricistRelationshipType[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that are really translations (e.g. follow the original lyrics), not for parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html This RFC goes hand-in-hand with RFC posted in http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007379.html . Thoughts? This http://forums.musicbrainz.org/viewtopic.php?pid=6306#p6306 seems to be neither translation nor parody. (only hearsay, I don't know anything about German or Swedish ;-) ) So while we're at it, we might as well add the transposed attribute. transposed or adapted, I don't know which is better. My mind is really slow, today, I saw Brian's RFC on the ML but did not react to them :-( Which of Brian's RFCs are you referring to? I should refrain from posting when I am in this state. Brian's RFC was about CoverRelationshipType, which is different since as Brian pointed out, it does not currently speak about parody. Anyway, I don't think these examples are not 'regular' translations. See also my forum post. Ok, what about this http://musicbrainz.org/track/e01ecf45-a5cd-41d1-a29b-fc72dcbcbf94.html and this http://musicbrainz.org/track/899e0e10-0b4a-4c50-8b3b-feb6dab6b182.html This is not a translation, the lyrics are clearly inspired by the original (it is still about a woman who remembers the boy she used to play with), the mood is the same (nostalgic), but the lyrics are different, there are new elements in the French version (a hint of another woman) and other elements have disappeared from it... This is clearly not a mere translation, this is an adaptation (to a language, a culture, a performer...) I'll post a new RFC to also deal with this case (well, actually excluding this specifically). Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/3/27 Frederic Da Vitoria davito...@gmail.com: 2009/3/27 Jan van Thiel janvanth...@gmail.com Parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]) and lyrics that are based on lyrics in another language that have altered location, meaning, new elements, elements dropped, etc. (This probably should be rephrased) Maybe it's me (I have been quite inefficient in reading MB documentation recently ;-) ) but I don't understand the last part from and lyrics... at all. I understand what you are speaking about, but not what you suggest should be done or not done with it. I think it was me ;) I meant to exclude the cases you (amongst others) were talking about, i.e. songs that are covers in a different language but with the meaning changed substantially. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Feat. on non-english releases
2009/3/2 Kuno Woudt k...@frob.nl: On Mon, Mar 02, 2009 at 04:30:09PM +0100, Jan van Thiel wrote: We can only get rid of feat. in titles if there is an AR artist X features on release/track Y. Otherwise the information that an artist is explicitly credited as featuring artist will be lost, because from 'performs on' ARs you can't deduce that. So, does that mean you add '(feat. somebody)' to track titles on certain releases even though it isn't used in the tracklisting on the backcover? No, of course not! I don't see how you infer that from my reply. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Feat. on non-english releases
2009/3/2 Kuno Woudt k...@frob.nl: On Mon, Mar 02, 2009 at 11:54:51AM +0100, Maurits Meulenbelt wrote: In my opinion the feat. is a leftover form the bad old days when there were no AR's. Personally I only enter them when they're mentioned this way on the case, and if I do, I follow the case (except that I change featuring to feat. for consistency). So I'd follow regional variants if they're used by the artist (artist intent). I'd rather get rid of them altogether though, they're quite redundant.* Same here, and I expect that is the approach used by most editors (ofcourse I'm just guessing, i could be wrong :). The FeaturingArtistStyle guideline as it exists now probably predates the AR feature and should be updated/clarified to be in line with current practice. We can only get rid of feat. in titles if there is an AR artist X features on release/track Y. Otherwise the information that an artist is explicitly credited as featuring artist will be lost, because from 'performs on' ARs you can't deduce that. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/1/13 Frederic Da Vitoria davito...@gmail.com: 2009/1/13 Jan van Thiel janvanth...@gmail.com 2009/1/13 Frederic Da Vitoria davito...@gmail.com: 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Jan van Thiel janvanth...@gmail.com Hi, I'd like to see attribute 'translated' added to the LyricistRelationshipType[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that are really translations (e.g. follow the original lyrics), not for parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html This RFC goes hand-in-hand with RFC posted in http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007379.html . Thoughts? This http://forums.musicbrainz.org/viewtopic.php?pid=6306#p6306 seems to be neither translation nor parody. (only hearsay, I don't know anything about German or Swedish ;-) ) So while we're at it, we might as well add the transposed attribute. transposed or adapted, I don't know which is better. My mind is really slow, today, I saw Brian's RFC on the ML but did not react to them :-( Which of Brian's RFCs are you referring to? I should refrain from posting when I am in this state. Brian's RFC was about CoverRelationshipType, which is different since as Brian pointed out, it does not currently speak about parody. You mean my (zout) proposal? Anyway, I don't think these examples are not 'regular' translations. See also my forum post. Ok, what about this http://musicbrainz.org/track/e01ecf45-a5cd-41d1-a29b-fc72dcbcbf94.html and this http://musicbrainz.org/track/899e0e10-0b4a-4c50-8b3b-feb6dab6b182.html This is not a translation, the lyrics are clearly inspired by the original (it is still about a woman who remembers the boy she used to play with), the mood is the same (nostalgic), but the lyrics are different, there are new elements in the French version (a hint of another woman) and other elements have disappeared from it... This is clearly not a mere translation, this is an adaptation (to a language, a culture, a performer...) OK, this sounds like something different than a 'simple' translation. But how where do we draw the line? What is a simple translation and what is adapted/transposed? Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/1/14 Frederic Da Vitoria davito...@gmail.com: 2009/1/14 Jan van Thiel janvanth...@gmail.com OK, this sounds like something different than a 'simple' translation. But how where do we draw the line? What is a simple translation and what is adapted/transposed? As usual, there is no clear limit. Common sense and vote are out only tools. OK, agreed. What would be a good line to describe the AR? Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to CoverRelationshipType
Please regard the attachment, my bad. 2009/1/13 Jan van Thiel janvanth...@gmail.com: Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to CoverRelationshipType
*dis*regard ;) 2009/1/13 Jan van Thiel janvanth...@gmail.com: Please regard the attachment, my bad. 2009/1/13 Jan van Thiel janvanth...@gmail.com: Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to CoverRelationshipType
And to raise the spam level even more: original message wasn't sent because the attachment I accidentally attached was too big. Original message: -- Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType -- 2009/1/13 Jan van Thiel janvanth...@gmail.com: *dis*regard ;) 2009/1/13 Jan van Thiel janvanth...@gmail.com: Please regard the attachment, my bad. 2009/1/13 Jan van Thiel janvanth...@gmail.com: Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to CoverRelationshipType
Yes, seems like a good idea to add this alongside the attribute for the cover relationship. Jan 2009/1/13 Brian Schweitzer brian.brianschweit...@gmail.com: Sorry for the double response, but nikki had a better idea than mine, and asked me to pass it along. Rather than a whole new artist-track AR, add a translated attribute to the existing artist-track lyrics AR. Brian On Tue, Jan 13, 2009 at 6:43 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Would you also then add an artist-track AR for artist translated the lyrics of track? Brian On Tue, Jan 13, 2009 at 6:13 AM, Jan van Thiel janvanth...@gmail.com wrote: And to raise the spam level even more: original message wasn't sent because the attachment I accidentally attached was too big. Original message: -- Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType -- 2009/1/13 Jan van Thiel janvanth...@gmail.com: *dis*regard ;) 2009/1/13 Jan van Thiel janvanth...@gmail.com: Please regard the attachment, my bad. 2009/1/13 Jan van Thiel janvanth...@gmail.com: Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
Hi, I'd like to see attribute 'translated' added to the LyricistRelationshipType[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that are really translations (e.g. follow the original lyrics), not for parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html This RFC goes hand-in-hand with RFC posted in http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007379.html . Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/LyricistRelationshipType [2] http://wiki.musicbrainz.org/ParodyRelationshipAttribute [3] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to CoverRelationshipType
RFC for this mailed in http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007392.html . 2009/1/13 Brian Schweitzer brian.brianschweit...@gmail.com: Sorry for the double response, but nikki had a better idea than mine, and asked me to pass it along. Rather than a whole new artist-track AR, add a translated attribute to the existing artist-track lyrics AR. Brian On Tue, Jan 13, 2009 at 6:43 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Would you also then add an artist-track AR for artist translated the lyrics of track? Brian On Tue, Jan 13, 2009 at 6:13 AM, Jan van Thiel janvanth...@gmail.com wrote: And to raise the spam level even more: original message wasn't sent because the attachment I accidentally attached was too big. Original message: -- Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType -- 2009/1/13 Jan van Thiel janvanth...@gmail.com: *dis*regard ;) 2009/1/13 Jan van Thiel janvanth...@gmail.com: Please regard the attachment, my bad. 2009/1/13 Jan van Thiel janvanth...@gmail.com: Hi, I'd like to see attribute 'translated' added to the CoverRelationshipType[1]. The phrase for this attribute could read This attribute indicates a cover with the lyrics in a different language than the original. Note that this only says something about the language of the lyrics. It does not say anything about it being (also) a parody (other attribute) or having totally different lyrics (i.e. only covering the music, not the lyrics). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html Thoughts? Regards, Jan (zout) [1] http://wiki.musicbrainz.org/CoverRelationshipType ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: add attribute 'translated' to LyricistRelationshipType
2009/1/13 Frederic Da Vitoria davito...@gmail.com: 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Frederic Da Vitoria davito...@gmail.com 2009/1/13 Jan van Thiel janvanth...@gmail.com Hi, I'd like to see attribute 'translated' added to the LyricistRelationshipType[1]. The phrase for this attribute could read This attribute describes if the lyrics are a translation of the same work in another language. This should only be used for lyrics that are really translations (e.g. follow the original lyrics), not for parody translations (which should be link with ParodyRelationshipAttribute[2] of the CoverRelationshipType[3]). Example for releases: http://musicbrainz.org/release/88593941-0819-40bc-b527-824f3283f31c.html Example for tracks: http://musicbrainz.org/track/c4c3bc16-220e-4185-a71f-5a8c4823bd6b.html This RFC goes hand-in-hand with RFC posted in http://lists.musicbrainz.org/pipermail/musicbrainz-style/2009-January/007379.html . Thoughts? This http://forums.musicbrainz.org/viewtopic.php?pid=6306#p6306 seems to be neither translation nor parody. (only hearsay, I don't know anything about German or Swedish ;-) ) So while we're at it, we might as well add the transposed attribute. transposed or adapted, I don't know which is better. My mind is really slow, today, I saw Brian's RFC on the ML but did not react to them :-( Which of Brian's RFCs are you referring to? Anyway, I don't think these examples are not 'regular' translations. See also my forum post. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Creating a non-code AR to grou p releases into “cultural identifiers” for fu ture importing.
Why is this needed at all? 'Earliest release of' and 'Remaster of' ARs can be taken advantage of right now if you write some software. This new AR will be attached to exactly the same releases as these two ARs. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Creating a non-code AR to grou p releases into “cultural identifiers” for fu ture importing.
Yes, I usually pick the (more common) CD as 'the first'. For multiple disc releases, we could link disc 1 to disc 1 of 'the first' and use the new 'is part of a series' AR to link the other discs to their respective sets. Jan (zout) 2008/10/9 Philip Jägenstedt [EMAIL PROTECTED]: Just pick either of them as the first, whichever seems the most canonical. The only reason the current ARs is phrased as it is is to avoid link clusters, there's no need to add new ARs because the wording happens to be slightly wrong in these corner cases. Philip On Thu, Oct 9, 2008 at 9:29 PM, Aaron Cooper [EMAIL PROTECTED] wrote: On 9-Oct-08, at 3:11 PM, Jan van Thiel wrote: Why is this needed at all? 'Earliest release of' and 'Remaster of' ARs can be taken advantage of right now if you write some software. This new AR will be attached to exactly the same releases as these two ARs. Jan (zout) But right now we don't/can't link two versions of the same album that were released on the same day. Not to mention a CD version (1 mb release) and a vinyl version (5 MB releases). -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] artist A presents artist B
2008/10/8 Jim DeLaHunt [EMAIL PROTECTED]: On Thu, 18 Sep 2008, Toni Panadès wrote: LSS it's a group where the main artist is Dennis White (AKA Static Revenger), and in some places (and on the cover of the album) appears as Static Revenger presents Love Song Surprise What you think? I need to put an alias for this artist, or I need to change the name of the artist? Steve Wyles wrote: I'm certain this has been covered in previous discussions, either on the mailing list or the IRC channel. My understanding is: The current artist Love Song Surprise should stay exactly as named. It is probably worth adding Static Revenger presents Love Song Surprise as an alias under Love Song Surprise So, would any of you like to point to which style guideline ought to contain this guidance, and how the guidance ought to be worded? Please make a proposal. Then we can clarify the style guidelines to make this clear for the next contributor. A new page listed under 'Additional Readings' on http://wiki.musicbrainz.org/Artist ? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Part of series relationship
Can you give some examples of track series? Jan (zout) 2008/9/24 Chris B [EMAIL PROTECTED]: it might already be your intention, could we use this AR to link both releases and tracks? some track 'series' are spread across different releases, so it would be useful to link those i think (and to a lesser extent the usual ones on the same release). (but yeah the proposal sounds good!) 2008/9/24 Johannes Dewender [EMAIL PROTECTED]: Hello, similary to the set AR I would like to see a series AR. Series have quite similar properties. I posted this on mb-users and got no comments, other than a misunderstanding on what a series is: http://lists.musicbrainz.org/pipermail/musicbrainz-users/2008-September/018393.html A series: The Return of Rock, Volume 1 The Return of Rock, Volume 2 .. Technically, we could use the exact same AR for a set and a series. However, the wording for the set AR does not permit such a usage and it would help the semantics later when there is an extra AR for series. It would also be possible to have a checkbox for series or a radiobox for set and series. Differences: Obviously, the word set should get changed to series then. The optional/bonus option doesn't make sense for a series. Sets consists of usually 2 or maybe 3 discs, series can consist of a lot more. This might make a difference, when we want to list all of them fast, see problems. Wording: release A is part of a series, the next disc in the series is release B release B is part of a series, the previous disc in the series is A Additional rules: In cases of multi-disc releases that are part of the series: Only the first disc in a set should get linked to the first disc of the next release in the series. Problems: One might be interested to list all the items of a set and likewise all the releases in a series. It might not be cheap to list all 20 releases, because we need 20 queries, unless I am missing a feature that can do this as fast as selecting all rows with a certain property. It might not be uncommon, that we will have gaps in the data, meaning we have a bunch of releases in order and then there is this one release that is not in the DB, so we can't link it to the next bunch, creating two different series in terms of our logic. -- JonnyJD ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Part of series relationship
2008/9/25 Chris B [EMAIL PROTECTED]: 2008/9/25 Jan van Thiel [EMAIL PROTECTED]: Can you give some examples of track series? Jan (zout) sure - on the same release: http://musicbrainz.org/release/eddc2843-d3dd-48ba-b1c9-2ad509570aaa.html across different releases (track 4 and 2 respectively): http://musicbrainz.org/release/25854b63-25fd-4375-b18a-1007176c676d.html http://musicbrainz.org/release/42a30618-90cf-415d-95e0-35454531659d.html Thanks, then you meant what I thought you probably meant. What about these sort of tracks: tracks 5 and 11 on both http://musicbrainz.org/release/a4451421-df15-447c-a7d9-fd6ce2deb6b3.html and http://musicbrainz.org/release/c1d700a8-4b66-42cb-ad8c-d5ec9c0fc2df.html ? Release is the same, one with 12 tracks, other with a bonus track. How to link these? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] album version, original mix, etc.
2008/8/18 Tim [EMAIL PROTECTED]: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names, effectively describing any differences in sound (ie unique tracks) with unique, specific track name information. (Note I am not using the term TrackName; by track name I mean everything after the artist name.) I also believe the converse: that unique track names should be paired with unique tracks across all releases. There should be no doubt as to what sound (unique track) one is referring to given a track name. To summarize: every unique track should be paired with one and only one unique track name. Each name has one sound and each sound has one name. [...] MusicBrainz is a discography site with all info on music and some on artists. We capture info on what is printed on sleeves, unless that info is proved to be wrong (e.g. typos). This info can be used for tagging. Picard has the powerful TaggerScript which lets you format any tag basically the way you want. There's no need to change almost all track titles to accommodate your tagging needs. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [mb-users] MediaWiki (was: Looking for a new [Documentation|Style] leader)
2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: part of the previous discussion was migrating the wiki to either MoinMoin 1.6 or MediaWiki. A MediaWiki instance is now set up on http://mediawiki.musicbrainz.org/ with the latest version of our current wiki (no history). Can you please play with it, try to use some of the features that were discussed as improvements over MoinMoin and see if it's worth migrating? Can you repost these improvement features? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [mb-users] MediaWiki (was: Looking for a new [Documentation|Style] leader)
2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: Dňa Ut, 2008-08-05 o 14:54 +0200, Jan van Thiel napísal: 2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: part of the previous discussion was migrating the wiki to either MoinMoin 1.6 or MediaWiki. A MediaWiki instance is now set up on http://mediawiki.musicbrainz.org/ with the latest version of our current wiki (no history). Can you please play with it, try to use some of the features that were discussed as improvements over MoinMoin and see if it's worth migrating? Can you repost these improvement features? Looking at the previous mails, these were mentioned: * Real categories * Working full-text search * Talk pages * Templates * Namespaces Thanks. Would talk pages be used for discussion, or something else? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] multi-disc releases / box sets.
2008/6/26 Kuno Woudt [EMAIL PROTECTED]: I would like to have an AR to group multiple discs of a single releases. This would be intended as a temporary solution until we get proper release and boxset support with NGS. Considering this, not all that much time should be wasted on it. In it's simplest form, I would suggest an AR like this: album B is part of a release with album A What is the advantage over adding this as an annotation to each of the discs involved? Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: ReleaseTitle
On Oct 30, 2007 9:36 AM, Frederic Da Vitoria [EMAIL PROTECTED] wrote: 2007/10/30, Kuno Woudt [EMAIL PROTECTED]: On Sat, Oct 27, 2007 at 04:08:41PM +0200, Jan van Thiel wrote: I started the wiki page for ReleaseTitle almost 2 years ago. Guess it's time to make it official ;) I wasn't active on the mailinglist when that was made, it seems most or all of it is in being used already, right? I'm not entirely certain about the order of (feat.) and (disc #), but can't think of any examples right now to which the style would apply. (so i wouldn't veto an RFV to make this ReleaseTitle as it currently exists official). I guess I would prefer the guideline to be little less strict, and leave the order as on the cover in such cases. Actually, this raises an interesting question: if different elements from this list are actually printed on the release cover with no obvious separation (all on the same line, same font used...) and if the printed order differs from ReleaseTitle, should we follow ReleaseTitle or do we stick to what is printed? ArtistIntent is always more important than any guideline, of course, Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] At which level do we enter AR's
On 11/3/07, Brian Schweitzer [EMAIL PROTECTED] wrote: If I'm adding an AR to a track, it specifically applies to that track. If I'm adding an AR to a release, theoretically it applies to every track, but I will put money on the fact that this isn't actually true for each and every single release-level track-describing AR currently in the database. Of course, the site's UI can make sure it's impossible to add e.g. composer ARs to the release level. It's now possible to add ARs to all tracks on a release with almost no more work than adding ARs on the release level. So, if a future website version will give a different meaning to track vs. release ARs, I suggest we force the different ARs being added on the correct level with a UI change. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: ReleaseTitle
Hi, I started the wiki page for ReleaseTitle almost 2 years ago. Guess it's time to make it official ;) I hereby request http://wiki.musicbrainz.org/ReleaseTitle to contain the official definition of a release titles and the order of its parts. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Albums compiled by artists
On 3/5/07, Rod Begbie [EMAIL PROTECTED] wrote: There are a few series of compilation discs available where an artist or group compiles songs they like or were influenced by. Examples include: [...] Currently, these discs are sometimes filed under the compiling artist, and sometimes under Various Artists. Also, sometimes the Compiled by or DJ-Mixed by ARs are set, and sometimes they aren't. I'd like to propose a StyleGuideline to clean this up a bit. My initial feeling is that the discs should be filed under Various Artists with the appropriate AR back to the artist. I agree that these have to be cleaned up. But I don't think a guideline is necessary. Common sense should do the trick ;) And for me that is: if the ReleaseArtist is clearly stated on the release (which is for most/all of these releases), it should be set. Of course, also a DJ-Mixed by/Compiled by AR should be created. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Request for Clarification: positioning of disc numbers
On 10/19/06, Don Redman [EMAIL PROTECTED] wrote: On Wed, 18 Oct 2006 13:10:24 +0200, David Gibson wrote: As far as I can tell, the current style guideline information doesn't have any examples covering the intersection of DiscNumberStyle and ClassicalStyleGuide. Which order should the information mandated by each go, that is should it be: Big Works (Timbuktu Philharmomic feat. conductor Fred Nertz) (disc 1) or Big Works (disc 1) (Timbuktu Philharmomic feat. conductor Fred Nertz) I know for sure that there is a guideline on which we have already discussed this problem. The result was that this stuff should be ordered by generality. The information that applies to most elements comes first. Therefore if the Timbuktu Philharmomics appear on all discs, it is Big Works (Timbuktu Philharmomic feat. conductor Fred Nertz) (disc 1) whereas if they appear on disc 1 only (and another orchestra on disc 2), then it is Big Works (disc 1) (Timbuktu Philharmomic feat. conductor Fred Nertz) Unfortunately I cannot find this on the wiki anymore. I have searched all guidelines that could be relevant, but have not found it. I would expect it in ExtraTitleInformationStyle. Does anyone of the elders remember the page and discussion I am talking about? Yes, http://wiki.musicbrainz.org/ReleaseTitle . Although I might be a bit late with my reply ;) Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x(disc 2), vs x x (bonus disc) / version info for special releases)
On 9/20/06, Don Redman [EMAIL PROTECTED] wrote: To me it looks like there is a difference in what people understand under album. In the past, MusicBrainz has had a very formal definition of an album. It is my impression that Chris and Aaron are bringing in a definition which is much more meaningful. Restructuring of release attributes has been in the making since quite some time but nothing has come out of it, yet. There is an issue and it is overdue. So it does not really help if Lauri or me say: Well that's how albums are defined, period. I also believe that a very simple reason for the past practice (assigning the same type to the bonus disc) was that then it shows up just next to the main album. With the ammendement this relationship would get lost. I do not have the impression that Chris or Aaron have opened up to concerns of this kind. I am very uneasy with redefining what an album is, and my impression is that this is a consequence of your arguments. The reason for this discussion is the fact that people use different definitions of 'album'. I know that the current definition is: An album, perhaps better defined as a Long Play (LP) release, generally consists of previously unreleased material. This includes album re-issues, with or without bonus tracks. Current practice (well, at least for me and Chris) is not to use this definition this strict. E.g. releases with 'rarities' and live tracks could be considered albums, but I usually put them under Other'. Also, releases with 'alternate versions', 'studio outtakes', demo tapes combined with other stuff, etc. Regardless of the fact that they are 'regular' releases or bonus discs. I personally think ReleaseType``s have to be redefined, but am not sure whether that's a good idea at the moment. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Rejigging release attributes (was Re: RFC: BonusDisc ammendment...)
On 9/20/06, Lauri Watts [EMAIL PROTECTED] wrote: Imagine the possibilities. You could totally have a live spoken word ep, performance poetry perhaps. Or an audiobook compilation album (say, excerpts from a series, or a collection of HG Wells short stories for instance, that have been previously released separately). Or a remix compilation ep, collecting remixes that were released as b-sides. Or a perfectly ordinary album. See http://wiki.musicbrainz.org/ReleaseTypeRestructuringProposal and http://wiki.musicbrainz.org/ReleaseTypeRestructuringDiscussion ;) Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] English capitalization
On 9/2/06, Mangled [EMAIL PROTECTED] wrote: 2006/9/2, Bogdan Butnaru [EMAIL PROTECTED]: Since we're already discussing English capitalization, can we please also discuss these two other special cases: 1) Script-o-Rama, Ping-o-Matic: I always see these with the 'O' capitalized, but it seems to me it's just a contraction+inversion of of (it plays the role of conjunction, anyway, right?) I've also seen Sack o' Woe (in this case, it's more clear that it's just a contracted of). http://musicbrainz.org/search/textsearch.html?query=sack+o+woetype=tracklimit=handlearguments=1 I now (and I think mudcrow thought the same) prefer o as it seems more logical, while it's mostly uppercase in the db right now... 2) a-Running (or a'Running, not sure): I've seen this in some jazz records mostly. I'm not sure what to call it, I think it's an epenthesis (reverse elision), but it does seem to have a gramatical role (I think it gives a slight 'continuous mode' nuance to the verb, but it may be because of the sencence structure). We have at least: A-Tisket, A-Tasket http://musicbrainz.org/search/textsearch.html?query=A-Tisket%2C+A-Taskettype=tracklimit=handlearguments=1 Just A-Sittin' and A-Rockin' http://musicbrainz.org/search/textsearch.html?query=Just+A-Sittin%27+and+A-Rockin%27type=tracklimit=handlearguments=1 Though you shouldn't deduce anything from the way it is caped now (as I harmonized them), this was discussed in edit notes and irc, and concluded it should be uppercase. Still, I'm absolutely clueless about the reasoning behind. I think I remember the discussion involved Nyght and mudcrow at least, but I'm not sure. Some other examples: The Times They Are A-Changin' A Hard Rain's A-Gonna Fall Hear My Train A-Comin' I use capital A in these cases. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Torrents as Releases (Was: Billboard's topwhatever)
On 8/1/06, Aaron Cooper [EMAIL PROTECTED] wrote: What is important is that the Billboard lists would exist without torrents and there is a possibility that someone would want to tag against this information. Sure. But a Billboard list, with or without torrents, is *not* a release. MusicBrainz is all about releases, not lists. That's why we don't add setlists for live shows, but only tracklists for live (bootleg) releases. And to stay with the Billboard case: I feel this is a pirate release, not a bootleg. It's a compilation of previously released tracks, which is, if I am correct, a pirate release. And I don't think we should add these. Whether they're released as torrents or CDs. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] new official guideline: SplitReleaseTitleStyle
Hi, After 10 days no veto was issued on SplitReleaseTitleStyle. Therefore, I've made it official[1][2]. [1] http://wiki.musicbrainz.org/SplitReleaseTitleStyle [2] http://wiki.musicbrainz.org/RecentStyleChanges -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Dealing with translations and transliterations
On 7/18/06, Lauri Watts [EMAIL PROTECTED] wrote:
I suggest an additional attribute of {the titles of}, and make it
available at track level too, and it could cover both cases.
I don't think this is a good idea; your proposal covers two completely
different things, which happen to be called 'translation'. If you want
an AR to link '99 Red Balloons' to ''99 Luftballons' this probably is
best somehow placed in the 'cover of' AR branch.
I suggest you start another thread on this, as this only RFV only
deals with the transl(iter)ation of titles, not lyrics.
--
Jan van Thiel (zout)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: SplitReleaseTitleStyle
On 7/12/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: But I just remembered I've seen once a case you might want to add to the Details section: I've encountered at least one split where each half (both are on the same disc, thus the split status) had a name (presumably given by its respective artist). This should probably appear as First half title / Second part title. I've added this to the guideline at http://wiki.musicbrainz.org/SplitReleaseTitleStyle . -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Artist Type: Project
On 7/5/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: in that case, maybe we should consider about introducing Project, and rename the Group type to Band as well, to get rid of the ambiguous part of the Group type. Is that a valid deduction? Please no renaming! Collaborations are listed as Group at the moment, they're not bands. I think this discussion has proven that we cannot only add Project, Band, perhaps Ensemble. We now have the distinction between 1 person (Person) and more than 1 person (Group). Using Project, Collaboration, Band, Ensemble, ..., is a different way to describe how people can work together on making music. This is a new approach to the Artist Type. We can go there, but we need to make sure we cover all cases before implementing this. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: split artist release title
On 7/4/06, Thomas Tholén [EMAIL PROTECTED] wrote: I don't really have an opinion on split or not, I'd just like to pont out that this case is quite far from equivalent with V/A releases. In all cases I can think of V/A releases already have a name, and this is about constructing a (MB purpose) name for something that doesn't already have one. True. I should've said something like Various Artists Compilation. Maybe a better argument: if only the artist names are mentioned on the cover, it seems strange to me to add something like 'Split' to the title. Citerar Jan van Thiel [EMAIL PROTECTED]: On 7/4/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: /me thinks it would be great if you could revisit http://wiki.musicbrainz.org/ReleaseTypeRestructuringProposal and bring it into a state where we can just develop this feature in the most straightforward manner. I think it needs some additional work, from that point on the discussions about the current release attributes will be irrelevant. I agree. And I'd like to have this proposal implemented regardless whether we have a release attribute 'Split' or not. I think 'Split' shouldn't be part of the title, the same as we don't add 'Various Artists' or something equal to VA releases. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: split artist release title
On 7/4/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 03 Jul 2006 20:07:41 +0200, Jan van Thiel wrote: I've created http://wiki.musicbrainz.org/SplitReleaseTitleStyle and like to have comments. Thanks! I think that page should state very clearly that the artist should be Various Artists. This is kind of implied but not very clear. Agreed, I've added that info. -- Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: IMDbRelationshipStyle
Hi, I hereby request IMDbRelationshipStyle[1] to be made official. The content of this guideline is already widely applied. If you strongly oppose it, please post a veto. [1]: http://wiki.musicbrainz.org/IMDbRelationshipStyle -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: IMDbRelationshipStyle
On 6/20/06, Lukáš Lalinský [EMAIL PROTECTED] wrote: Why link only to the earliest release? The listed rationale is Reducing duplicated content/effort. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: IMDbRelationshipStyle
On 6/20/06, Lukáš Lalinský [EMAIL PROTECTED] wrote: On 6/20/06, Jan van Thiel [EMAIL PROTECTED] wrote: On 6/20/06, Lukáš Lalinský [EMAIL PROTECTED] wrote: Why link only to the earliest release? The listed rationale is Reducing duplicated content/effort. Yep, I read that. But why? :) From database point of view, adding a new instance of existing URL is very cheap. From usability point of view the link it means two clicks instead of one. And the AR type phrase says release is a soundtrack for the movie with an IMDb page at url, which apply to both original releases and re-releases. To be honest; I didn't write that page, I just thought it was mature enough to be made official ;) Can I conclude you issued a veto? -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Hi, First of all: I think it's a very bad idea to remove information just because people want their music collections ordered nicely. If you have problems with ' (album version)' in a track title, Why not just remove it in your tags? On 6/18/06, Schika [EMAIL PROTECTED] wrote: 1. Title (XY remix) 2. Title (original mix) 3. Title (album mix) 4. Title 5. Title (AV radio edit) All versions have different track durations and sounds different, but the essential question is: what is the original version? track 2, 3 or 4 ? If I would get the album to compare each version, and find out that track 3 is exactly the same as on this single, then should I strip track 3 title to Title. But now what's the title of track 4 and who decides how this unlabeld other version should be named? Not to mention the confusion if track 2 would be on the artist album. Secondly: who decides what is a 'version' name like Tiesto's Oldschool Rework edit and what is not (in this case, what you think is, album version). The problem is same songs are listed under different names, e.g. as album edit or something similar. edit, mix and version are often used for the same thing. Surely we're not going to rename all of these to the same name? We use the name used on the cover for these. ARs can be used to indicate they're the same. Maybe we also have to remove ' (12) ' from track titles, if that's where the song was released on originally. Or perhaps remove (original version), because that might be the same as the album version (e.g. if the album was released first). Or maybe long version on a single indicates it's the same as the album version, because it's a 10 minute long track and the single edit with 3.15 minutes is better suited for radio play. Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] new official guideline: SortNameStyle
Hi, The SortNameStyle has been made official. This guideline can be found at http://wiki.musicbrainz.org/SortNameStyle . -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Beth [EMAIL PROTECTED] wrote: I didn't say only by the number of edits. That states contributions, there are many ways to contribute. Zout happens to contribute with edits, has been on the style council has done a lot for MB, I think that is a fair reason zout's thoughts should have a bit more weight. Thanks for the support, but I think everyone deserves an opinion. I don't think my opinion should count for more, because we try to get consensus, not count votes and let the majority have their way. Speaking of consensus: we will never get it on this issue. Therefore, I'd like Robert as 'style overlord' to make a decision so that we won't have to discuss the same issue every month. I've made a small summary, I hope I haven't forgotten any arguments. If so, please reply and add them in one of the lists below. The Idea: Keeping 'album version' in track titles as opposed to the present situation. Against --- - people like having the same track name for the same tracks on different releases. this, however, is already the case for e.g. live tracks on album releases and the same tracks on live releases. - mostly used for tagging purposes, and people contribute to MB primarily for tagging purposes, so these contributors should have more to say on this issue. For --- - we loose version information when it's removed - in line with 'state what is on the cover' - when it's removed, a release can have two tracks with the same name, making the track listing ambiguous. - SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/18/06, Thomas Tholén [EMAIL PROTECTED] wrote: What she said. Really. I can't phrase it any better than what Nikki did, but those are words straight out of my heart as well. It's so totally arbitrary that it sickens me, and we're losing information over it all the time which will be if not impossible, take lots and lots and lots of work to get back. Can't we just nuke the stupid (album version) rule once and for all? Please? What they said. Please! -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Decision and clarification of imdb format
On 6/13/06, derGraph [EMAIL PROTECTED] wrote: teleGUISE wrote: This should be pretty simple and straight forward can we get this decided upon. Style Council ? Decided? Is there something to decide? IMDb says Yes, link to us as much as you want, but please use this link schema. I don't think that we have anything to decide there. Agreed. teleGUISE, I think it's safe to say you can change these wiki pages accordingly. It seems the server software already uses this convention. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
On 5/27/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: It seems we have encountered another issue with unwritten rules in a relationship type. Imho, it is strange that links to existing, and valid amazon pages which list information about a release (even if it might have been created by a seller, not amazon itself) not be allowed to link to. Theres the implication that customer images do not show in the musicbrainz release page, but its still there once one clicks on the amazon link. So, i'd like to request comments (or vetoes) to a possible removal of the paragraph from the amazon relationship page which disallows to add links to this kind of custom ASINs. I agree with this. I also think we need to have an actual link to the page, not a 1x1 pixel link. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] omitting major?
On 5/25/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: Some people (not only MB users) omit major, and specify only minor. The CSG recommends writing major/minor in lower case, but it doesn't say if major can be omitted. Personally, I'd prefer always specifying it (because there is also the convention where upper case means major and lower case means minor and those who don't know this might misinterpret c and change it to C). What are your opinions? I'd say: let's keep it. -- Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
On 5/16/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Chris Bransden wrote: however i must say i hate the mutilation of track titles for hidden tracks - song / [untitled] looks horrific IMO. they should be just left as they are - [untitled] should only be used when the entirity of the track is untitled (ie, use [untitled] rather than no title at all) So do I. You can never clearly say if a piece still belongs to the current song or if it's something new. This is not bullet proof enough in my eyes. But we have been voted down on this. :( Glad you realise this ;) (I was in the other camp at that time, and still am) To stay on topic: I agree with you both that it's not a good idea to let hidden tracks also be entered as non-album tracks. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
On 5/16/06, derGraph [EMAIL PROTECTED] wrote: Anyway, I'd support your proposal. I just want to clarify something closely related: If the hidden track is not unnamed, i.e. it appears on another release with a title, then that title is to be used, without any brackets etc. I.e., if Some Long Song is followed by a long silence and then by Funny Little Song, the correct track title would be Some Long Song / Funny Little Song. Correct? Yes, that's how it is in the guidelines at the moment. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ideas on improving Style Council decissions
On 4/26/06, Simon Reinhardt [EMAIL PROTECTED] wrote: The only thing we need is that someone *really* cares about a problem and controls discussions. And well, if noone like that is found for an issue then the style secretary can ask someone to do the work or try to do it themselves as a last resort. And we need the secretary for overviewing the general process. The person best suited to deal with an open style issue is, of course, the person proposing a change! If (s)he doesn't even have the interest in remembering to ask for a RFC/RFV/whatever, who will? I don;t think we need yet another way to deal with style issues. I can hardly keep up with the way to have an issue discussed as it is. And I don't consider myself a newbie with respect to style guideline proposals. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ideas on improving Style Council decissions
On 4/26/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Some explanation for the image you attached? I do not understand it. :) I don't get it either. I think the width of the grey band indicates the number of emails per time unit sent on the subject. But images are usually only a way to enhance comprehension of a process; they're only usefull if all transitions are clearly defined. We seem to have a process defined at the moment; let's keep it at that. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bootleg locations
On 4/23/06, Cristov Russell [EMAIL PROTECTED] wrote: I think 'The' should be included, to indicate it's plural and because I like it better. Ummm the 's' makes it plural not The. :-) True :) Anyway, I've decided I really don't care what we decide to use, as long as it's consistent. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bootleg locations
On 4/22/06, Nikki [EMAIL PROTECTED] wrote: I was curious about the distribution of countries for bootlegs [1] and I noticed that the untitled bootleg style [2] doesn't really consist of much and live bootleg style [3] still doesn't expand the location very much. A general style appears to have emerged in some places and I'd like to get it written down instead of it being one of those unwritten rules. In other areas, we're using two or more different ways of representing the same data, and given that untitled bootlegs have titles we've created, we should be a bit more consistent. :) I agree with all or am neutral, except this one: Should we use The Netherlands or just Netherlands? Wikipedia [9], the CIA World Factbook [A] and ISO [B] call it just Netherlands but The Netherlands appears to be more common amongst our titles [6]. Holland also gets some use but this is really misuse [7]. Holland is definitely wrong. I usually use 'The Netherlands' and probably am responsible for renaming most titles ;) I think 'The' should be included, to indicate it's plural and because I like it better. zout (from the Netherlands) -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Contextual information in track title
On 4/10/06, Don Redman [EMAIL PROTECTED] wrote: On Sat, 08 Apr 2006 15:27:32 +0200, Frederic Da Vitoria wrote: About mod 4578355, The original title was: Canitque de Jean Racine From the Film Babe, clearly wrong since From the Film Babe is not really part of the title. After asking advice in the IRC, Nyght added a mod to change it to Canitque de Jean Racine (from Babe). I would have rather used Canitque de Jean Racine (from film Babe), because what Babe actually is (film, tv series, opera, whatever) is not clear in the proposed mod. Is there a good reason to prefer one solution or the other? (oh, and I didn't the misspelling in this message, because this in not the issue, here) Um, sorry if I disagree with everyone here, but IMO this is ExtraTitleInformation which does not belong into the TrackTitle and should be left to the AlbumAnnotation (except if it were used to differentiate between two tracks of the same title on the same album). DonRedman Yes, I agree with Don. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Evil overlord speaks on DVDs (was: WTF DVD?)
On 4/8/06, Frederic Da Vitoria [EMAIL PROTECTED] wrote: I was asking because Robert wrote: Once we get a few (more) into the database, we will see how people have been adding them and only then start creating official guidelines for how DVDs will be entered, but in order to do this, we must be able to retrieve the dvds entered! I think it's not that hard for a person with database access to run a query the lists albums that have the word 'dvd' in their annotations. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] LiveTrackStyle
On 4/3/06, Michelle . [EMAIL PROTECTED] wrote: Only a little comment: Shouldn't example 6 have the word live in it? No, see the paragraph before the examples. Hurray! I've been waiting for this one forever. :) Guess I'll have to go throw all the acoustics into separate parentheses now. :) -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] BoxSetNameStyle
On 3/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] Enter every release as a different entry in the database [...] I fully agree with Stefan here. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] add instrument request: vacuum cleaner
On 3/2/06, Simon Reinhardt [EMAIL PROTECTED] wrote: More votes on this, please! I haven't replied to this thread so far, because I thought it was a trivial question. Guess not. My input: if an instrument exists and someone can show a MB example where he/she can add it and intends to add it, it must me added. Period. Whether javascript is needed or not. That's somebody else's problem, so to say. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] DVD in album titles
On 2/14/06, Simon Reinhardt [EMAIL PROTECTED] wrote: DVDs again, this time about the album titles, not the release status. If you look at http://musicbrainz.org/newsearch.html?limit=0table=albumsearch=dvd we have quite a mess there. I'm not calling for an official style guideline since I think this is more a provisional thing until we have media type attributes, but it would be nice to have something like a common agreement. And I don't think we can ignore DVDs since we have a lot of them in the database already. [...] Simple question: what of all that do you think we need? My personal opinion: Title (DVD) makes sense and I can see a need to combine it with DiscNumberStyle and BonusDiscStyle. Why not add this information to the album annotation? We leave out 'CD' and 'vinyl' too, don't we? Another question is: what DVDs do we allow to be added? Audio DVD for certain, but what about video DVD rips and the like? -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] State of the Style Secretary
OT:
On 2/8/06, Björn Krombholz [EMAIL PROTECTED] wrote:
Another
analogy to the programming: The task is to print the numbers from 1 to
10. Let people discuss the best solution, you would get proposals
like:
a) print 1 2 3 4 5 6 7 8 9 10
[argument: it's the fastest way to do it!]
b) for ( i = 0 to 10) { print i }
[argument: it's more flexible!]
c) i=0; do { print i; i = i + 1 } until ( i 10 )
...
Well, a is the only correct solution :) Or there are not correct
solutions if you define 'from 1 to 10' in another way ;)
--
Jan van Thiel
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On 1/31/06, Björn Krombholz [EMAIL PROTECTED] wrote: Actually, I do hope that we target a limited audience and keep the data within a well defined (which is currently not the case) scope. Personally I think we already exceeded the scope with audio books and similar stuff. All this, while we are far away from tapping the full potential of collecting _music_ related data. We should try to stick to music and once we could say that this main area of MusicBrainz is nearly complete, we can think about further expansion. Though ATM we have more than enough to do with the completion of the data that is most interesting. Yes, I agree. We need a document decscribing what should and should not be added to the database, covering artists, albums, non-album tracks and ARs. What is a homebrew? When to add a non-album track? Is a TV-show rip OK? Do we add not-yet-completed albums, to which tracks have to be added later? What DVD content should be added, what not? Do we add non-musical artists? Etc. These questions, and probably a lot more, have to be addressed? GoodWikiName anyone? ;) -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On 1/30/06, Steve Wyles [EMAIL PROTECTED] wrote: For instance, we can only show both parents of an artist if both of them would be in the database for another reason. An example here is: http://musicbrainz.org/showartist.html?artistid=40437 which shows both parents and http://musicbrainz.org/showrel.html?type=artistid=8152 which only shows one, because his mother is Cynthia Powell, John Lennon's first wife. But despite Cynthia Powell being married to a famous artist and the mother of another, she isn't currently deemed worthy of an entry in the database. True. The only important information here (Julian Lennon is John Lennon's son) can be entered in the database without adding Cynthia Powell. An example where I think it is OK to add a non-musician is http://musicbrainz.org/showartist.html?artistid=245372 . This is the son of Carmine Coppola, and the father of Nicolas Cage, who both are in the database. Without this person, there is no way to link the two. But in general, I think adding non-musicians is not the way to go. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5 Border cases: Album artist an split release
On 1/17/06, Björn Krombholz [EMAIL PROTECTED] wrote: On 1/16/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Do you think it is ok to create collaboration artists for split releases if it is written like that on the covers? The different artists may not even have been involved in creating the release but I think we can consider an album a work just like a song, so I'd personally make no difference here. 1. IMO, it's ok to create the collaboration artists. For the first case, there are 2 releases in some kind of a series, so one could argue that there must have been something like working together aka collaboration. I hate it. An artist in the db is an person/group/entity that *worked together* on something. Creating 'Dire Straits Mark Knopfler' is therefore incorrect, because the solo artist Mark Knopfler did not collaborate with Dire Straits. The fact that you'd at the same time get a 'collaborated on' and 'is/was member of' relationship points out the problem with this. Same holds for Deborah Harry and Blondie: http://musicbrainz.org/showalbum.html?albumid=353236 . These releases can be seen as a regular split album, which all have AlbumArtist=VariousArtists. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: [mb-users] Remix question
On 1/16/06, Björn Krombholz [EMAIL PROTECTED] wrote: IMO this has nothing to do with RemixStyle, but is a much more general rule in MusicBrainz. But you are right, this information can be found nowhere in the wiki or the styleguides. I like the way zout is explaining these basic structures and terms in pages like Track, Album, TrackTitle, AlbumTitle, etc. PrimaryArtist only explains AlbumArtist, so maybe it would be nice to follow the concept for the title documentation, and add general pages for AlbumArtist (== PrimaryArtist now) and TrackArtist, both linked at the top of the Artist page. Thanks. But as we're a *community*, please help out with creating/improving/updating these pages! -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: AlbumTitle proposal [WAS: Re: Title styles revised (was: [mb-style] redundant ExtraTitleInformation)]
On 1/16/06, Chris Bransden [EMAIL PROTECTED] wrote: ahhh, yr right! forgot about that. still unclear about what happens when you tag, say, a DJ mix album - do the tracks all get credited to the DJ mixer, rather than the original artists? if so, is the original artists credits put into the tag at all? It's treated as a 'regular' VA artist album, with albumartistname and albumartistsortname as variables to be used to tag music. But we're getting off-topic here ;) -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Release Countries
On 1/16/06, Matthew Exon [EMAIL PROTECTED] wrote: Don Redman wrote: A pretty simple enhancement could allow contributors to select some special release areas during the input process, and could translate that into the corresponding states. You klick on EU and it enters a release record for each EU state. You klick on Benelux and it enters three release records. Of course changing the data or a EU-wide release would be a PITA. I don't like this because it's redundant data, and a huge pain for the many, many releases that cover several countries. Especially in Europe. If an album is released in even just six or seven of the EU nations, think how much effort you'll have to go to to fix an incorrect date. Not to mention the fact that the set of countries varies/gets bigger over time... So we'd have to define different 'versions' of the EU. -- Jan van Thiel ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Updating FeeturingArtistStyle
On 1/10/06, Tarragon M. Allen [EMAIL PROTECTED] wrote: However, in film credits for story, screenplay, etc., indicates a closer collaboration than and; in screenplays, for example, two authors joined with collaborated on the script, while two authors joined with and wrote the script at different times and may not have consulted each other at all. From http://en.wikipedia.org/wiki/Ampersand. So, based on that, does it make more sense to use the ampersand rather than the word and when indicating an equal collaboration? Maybe we can use the ampersand version when different versions are used on different records? And use any other version as long as that is being used consistent on all records? Same system as VolumeNumberStyle uses. Jan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
