[mb-style] RFV: Add orchestrator and instrumentation at recording level
This proposal is to add orchestrator and instrumentation at recording level. The RFV should expire on the 20th. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-341 CSG Recording parts Relations
2011/11/17, Lemire, Sebastien m...@benji99.ca: I propose here an RFC to create a hierarchy in recordings similar as we have in the works tables. It expires in 7 days on Novemer 24th 2011. Because I haven't thought the consequences through for non-classical music, this RFC only applies with CSG. The proposal can be found here: http://wiki.musicbrainz.org/Proposal:Recording_Parts_Relationship NOTE: This is the first time I created a wiki page (I shamelessly copied from the similar http://wiki.musicbrainz.org/Parts_Relationship_Type). Please feel 100% to make modifications to it or let me know what I need to modify, change or add. *A few extra notes as to why I'm making this proposal.* In classical music, and Opera, very often, an entire work is performed and recorded (with it's sub-works or movements). This performance is then split into tracks on a CD. Having a recording-leve hierarchy would allow us, as with our works, to concentrate ARs at a higher level than the recordings present on CDs. This should be discussed in further RFCs but we could for example store the conductor and orchestra at a higher level as it applies to all movements/parts. This along, with an inheritance system as proposed in RFC-339 would simplify editing of classical recordings. *Makes adding/editing ARs easier, faster and more streamlined:* For example, at the moment, if a classical performance has 12 parts and 3 performers (say a pianist, conductor and orchestra), the ARs need to be added to every part (36 ARs). Approval and implementation of this RFC would give us the possibility to only have 3 ARs to enter or correct.The sub-parts/movements could get the ARs through inheritance. *Improvements to the UI and data presentation:* Having a hierarchy has the potential (as with works) to make dramatic improvements in how the data is displayed and presented to the user: - Sub recordings could be hidden from the recordings and relationships pages making for a much cleaner and useful .pages for heavily recorded artists such as Herbert von Karajanhttp://musicbrainz.org/artist/d2ced2f1-6b58-47cf-ae87-5943e2ab6d99 - Classical releases could show only the parent-recordings making for a much more concise list of works present on a release. This would be more in line with how allmusic.com presents classical releases. *Makes editing recording titles easier:* The same concept as proposed by me in MBS-3374http://tickets.musicbrainz.org/browse/MBS-3374 could apply very well to recording titles allowing us to separate the parent-recording title (Say Symphony No. 5 in C minor, Op. 67) from the movements and allowing us to edit them separately. *Regarding partial recordings on releases* There are often CDs which have partial recordings (for example most of the tracks on this release which I'm currently editing: Les Grands Classiques d'Edgar : Encore Plushttp://musicbrainz.org/release/f8b78017-9b9a-48fa-8e9b-90310400a84b). The fact is that most of these recorded parts were actually recorded along with the remaining parts and released on other albums. Such recordings will simply be merged with other recordings If they haven't and were indeed recorded alone, then a decision will need to be made in a future RFC. Personally, we should keep the same tree structure with perhaps an attribute at the supra-recording level that indicates that this performance is incomplete. *NOTE*: With RFC-341, I'm only proposing the relationship to link recordings in a hierarchy similar to works. A lot of the advantages I listed above are future benefits but they will and should be passed in separate RFCs after this one has passed. I'd remove the date attributes as they seem meaningless to me. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
2011/11/18, Alex Mauer ha...@hawkesnest.net: On 11/17/2011 06:11 PM, Oliver Charles wrote: For my own merging guidelines, I will merge recordings that came out at roughly the same time (say the vinyl version and the week later CD release, with drum bass albums) because I can be confident that these are mastered the same; save a high pass filter here and there that I don't hear. I think we need to be more clear about what a MB-recording is, then. Is it: 1. A recording event (this was recorded on such-and-such day or days)? 2. a mix event (this was mixed by so-and-so on this day)? 3. a mastering event (CD/phonograph/cassette(?) releases cannot share recordings!)? 4. something else? Until we’re clear on this one, I don’t think this discussion is going to really help anything (people will carry on doing what they do) For my part, I’ve been handling it primarily as 1, with a little bit of 2 thrown in where there’s a noticeable difference, and avoiding merging any instances of 3 if someone has taken the effort to add the mastering info to the disambiguation comment. I consider Recording to be a *significant* master. The wiki says unique audio data. In this sense IMO, vinyl, k7, original digital transfer and victim of loudness wars are all distinguishable, so they should stay separate. I would not separate two masters with only a slight difference in tone balance, but if some users want to separate them, I would comply. The name Recording is unfortunate because it tends to be understood in it's common meaning, and there is currently no place in MB for the common sense of the word. But as someone has pointed out, - some users would definitely not want to erase the master concept (currently implemented by Recordings) - the user interface was already made more complex by the addition of the Recording level, adding a true Recording level would obviously make things worse. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-341 CSG Recording parts Relations
Lemire, Sebastien-2 wrote: I propose here an RFC to create a hierarchy in recordings similar as we have in the works tables. It expires in 7 days on Novemer 24th 2011. Because I haven't thought the consequences through for non-classical music, this RFC only applies with CSG. The proposal can be found here: http://wiki.musicbrainz.org/Proposal:Recording_Parts_Relationship NOTE: This is the first time I created a wiki page (I shamelessly copied from the similar http://wiki.musicbrainz.org/Parts_Relationship_Type). Please feel 100% to make modifications to it or let me know what I need to modify, change or add. [snip] *Makes adding/editing ARs easier, faster and more streamlined:* For example, at the moment, if a classical performance has 12 parts and 3 performers (say a pianist, conductor and orchestra), the ARs need to be added to every part (36 ARs). Approval and implementation of this RFC would give us the possibility to only have 3 ARs to enter or correct.The sub-parts/movements could get the ARs through inheritance. I think RFC-339 must be decided before citing this as a pro. Lemire, Sebastien-2 wrote: [snip] *Regarding partial recordings on releases* There are often CDs which have partial recordings (for example most of the tracks on this release which I'm currently editing: Les Grands Classiques d'Edgar : Encore Pluslt;http://musicbrainz.org/release/f8b78017-9b9a-48fa-8e9b-90310400a84bgt;). The fact is that most of these recorded parts were actually recorded along with the remaining parts and released on other albums. Such recordings will simply be merged with other recordings I disagree. There are obviously two distinct recordings, one of which is intentionally edited--it is not useful for users to have these two recordings muddled. Lemire, Sebastien-2 wrote: If they haven't and were indeed recorded alone, then a decision will need to be made in a future RFC. Personally, we should keep the same tree structure with perhaps an attribute at the supra-recording level that indicates that this performance is incomplete. *NOTE*: With RFC-341, I'm only proposing the relationship to link recordings in a hierarchy similar to works. A lot of the advantages I listed above are future benefits but they will and should be passed in separate RFCs after this one has passed. Then, I have no opinion on this RFC at this time. Lemire, Sebastien-2 wrote: Sebastien ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-341-CSG-Recording-parts-Relations-tp4081503p4082888.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Making edit note for Add release mandatory
Johannes Weißl jar...@molb.org writes: Hello Oliver, On Fri, Nov 18, 2011 at 12:25:36AM +, Oliver Charles wrote: I have worried about this problem too (people entering garbage to pass validation), but I think we can reduce the risk of that with a clear message that is both informative, but friendly. If we change it from just edit note is required to Please explain where you are entering this data from. For example, if you have purchased the release on iTunes please mention that. If you are entering data from a website, please provide a link to the website so other editors can verify your changes Something along these lines will hopefully bring out good edit notes, because people understand why the field is required. Of course, whether or not people actually read the message is something else ;) The message would be perfect. But the edit note would still be required? I don't worry at all about garbage being entered to circumvent the validation, it wouldn't make the situation any worse! Even garbage is better than nothing, because it will tell apart the I care, but I don't know how important an edit note is from the I completely don't care people. It would be great if this could make it into the next release! I mean, it is mandatory for Add standalone recording already... If you want things to make it into the next releases you need to create a ticket for them :) - Ollie ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
Frederic Da Vitoria davito...@gmail.com writes: 2011/11/18, Alex Mauer ha...@hawkesnest.net: On 11/17/2011 06:11 PM, Oliver Charles wrote: For my own merging guidelines, I will merge recordings that came out at roughly the same time (say the vinyl version and the week later CD release, with drum bass albums) because I can be confident that these are mastered the same; save a high pass filter here and there that I don't hear. I think we need to be more clear about what a MB-recording is, then. Is = it: 1. A recording event (this was recorded on such-and-such day or days)? 2. a mix event (this was mixed by so-and-so on this day)? 3. a mastering event (CD/phonograph/cassette(?) releases cannot share recordings!)? 4. something else? Until we=E2=80=99re clear on this one, I don=E2=80=99t think this discus= sion is going to really help anything (people will carry on doing what they do) For my part, I=E2=80=99ve been handling it primarily as 1, with a little= bit of 2 thrown in where there=E2=80=99s a noticeable difference, and avoiding = merging any instances of 3 if someone has taken the effort to add the mastering info to the disambiguation comment. I consider Recording to be a *significant* master. The wiki says unique audio data. In this sense IMO, vinyl, k7, original digital transfer and victim of loudness wars are all distinguishable, so they should stay separate. I would not separate two masters with only a slight difference in tone balance, but if some users want to separate them, I would comply. Yes, exactly this. I recently gave a presentation on the MusicBrainz schema, and I defined a recording as pretty much exactly this. See the slide at http://ocharles.org.uk/ngs-presentation/ngs-presentation.html#slide-43 I said: Generally defined to be a distinct audio signal, though determining exactly how distinct is left to our community. I think this echos what Frederic has said. - Ollie ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
2011/11/18, Oliver Charles oliver.g.charles.w...@gmail.com: Frederic Da Vitoria davito...@gmail.com writes: 2011/11/18, Alex Mauer ha...@hawkesnest.net: On 11/17/2011 06:11 PM, Oliver Charles wrote: For my own merging guidelines, I will merge recordings that came out at roughly the same time (say the vinyl version and the week later CD release, with drum bass albums) because I can be confident that these are mastered the same; save a high pass filter here and there that I don't hear. I think we need to be more clear about what a MB-recording is, then. Is = it: 1. A recording event (this was recorded on such-and-such day or days)? 2. a mix event (this was mixed by so-and-so on this day)? 3. a mastering event (CD/phonograph/cassette(?) releases cannot share recordings!)? 4. something else? Until we=E2=80=99re clear on this one, I don=E2=80=99t think this discus= sion is going to really help anything (people will carry on doing what they do) For my part, I=E2=80=99ve been handling it primarily as 1, with a little= bit of 2 thrown in where there=E2=80=99s a noticeable difference, and avoiding = merging any instances of 3 if someone has taken the effort to add the mastering info to the disambiguation comment. I consider Recording to be a *significant* master. The wiki says unique audio data. In this sense IMO, vinyl, k7, original digital transfer and victim of loudness wars are all distinguishable, so they should stay separate. I would not separate two masters with only a slight difference in tone balance, but if some users want to separate them, I would comply. Yes, exactly this. I recently gave a presentation on the MusicBrainz schema, and I defined a recording as pretty much exactly this. See the slide at http://ocharles.org.uk/ngs-presentation/ngs-presentation.html#slide-43 I said: Generally defined to be a distinct audio signal, though determining exactly how distinct is left to our community. I think this echos what Frederic has said. I am wondering if I shouldn't RFC changing the word record to master in the documentation and the interface (it wouldn't have to be done in the code as long as we don't have a table which maps to recordings). This would avoid a lot of errors. -- Frederic Da Vitoria (davitof) Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
On 11/18/2011 04:55 AM, Frederic Da Vitoria wrote: I consider Recording to be a *significant* master. The wiki says unique audio data. In this sense IMO, vinyl, k7, original digital transfer and victim of loudness wars are all distinguishable, so they should stay separate. I would not separate two masters with only a slight difference in tone balance, but if some users want to separate them, I would comply. I agree with this in principle, but I think this method is far too subjective. Audiophiles with perfect listening configurations and golden ears can argue about this stuff. Any digital release that isn’t bit-for-bit equal to any other release is *distinguishable*, as is essentially every playback of an analog medium (there is probably *some* chance that two will match, but it’s unlikely). That doesn’t mean it’s a useful difference to store. The name Recording is unfortunate because it tends to be understood in it's common meaning, and there is currently no place in MB for the common sense of the word. But as someone has pointed out, - some users would definitely not want to erase the master concept (currently implemented by Recordings) - the user interface was already made more complex by the addition of the Recording level, adding a true Recording level would obviously make things worse. I see it the other way ’round: adding a true Master level would make things worse. The system we have seems geared and implemented towards storing *recording* information rather than mastering information: * There is no way to apply ARs all at once to the multitude of MB-recordings that would be required if MB-recordings were to refer to only mastering events. * There is no system for having an “unknown master” recording, so that releases which are sourced from a master which is not known can be dumped there until someone figures out which master was used (not that anyone ever would, so it doesn’t matter) * MB-Recordings have an “is a performance of” AR to MB-Works, which if MB-recordings were mastering events would lead to the impression when looking at a work page that most artists performed their music up to dozens of times a day when recording (and while in some cases they did, that’s not the common case and a remaster is not a different performance) * Digital releases almost always share MB-recordings with analog releases. If MB-recordings were mastering events, this should never happen. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [Bulk] Re: Complete recordings as a type of release groups
On 11/17/2011 06:22 AM, Valery wrote: - Elvis Presley: The Original Elvis Presley Collection - 50 (!!!) CD box Is it similar to a retrospective for label? No, I suppose it's not. It looks like I didn't read your post very carefully. What piqued my interest was the idea of elevating certain collections above the normal compilation category, since this category can become (as you point out) meaningless noise. In the short term I'd encourage you to add something in the artist's annotation. We're all curators as well as editors, and the collections you mention clearly deserve special note. Sorry for going off on a tangent, Alex / caller#6 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Idea: remove track durations from analog releases
On 18 November 2011 18:54, Alex Mauer ha...@hawkesnest.net wrote: Discussion on IRC[1] brought up the idea that perhaps it would be useful to remove the possibility of setting track durations from releases which don’t have clearly-defined track boundaries or durations (I believe this is mostly analog releases, but there may be some exceptions in either direction). The situation is: * phonograph records (in particular) have no clearly-defined duration (especially since the last groove locks and loops forever * They also have no clearly-defined separation between individual tracks (the gaps visible on a phonograph with multiple tracks are only visual, and have their own duration (typically at least 1.8 seconds) * Track durations printed on covers or center labels are frequently several seconds off, and frequently have typos (number transposition is common) My proposed solution to this is to remove the possibility of having *track* durations on releases where this applies. Instead, the displayed durations would be those of the *recordings*, which will usually be taken from and shared with a digital version, so can be pulled from a discID or file. This might also have some impact on the release editor: * Editing track durations would either be impossible (similar to how it’s impossible to edit track durations on a release that has a discID), or * Editing track durations on such releases would change the recording durations, but only if the recordings are only used on releases which have no solid source of durations (such as discIDs or possibly in the future, acoustIDs), or * track durations should only be editable when adding releases, not when editing an existing release. Existing releases would have to be changed by editing the recording durations. I entered a ticket about this[2] and was directed to bring it to the style list. So what do you folks think? My immediate feeling is that this would cause more problems than it would solve. The primary advantage of having analog recording track times is for recording merging purposes. Without track times you risk accidentally merging recordings which one would otherwise recognize as different. It's not unheard of for vinyl to have different edits or even productions of cd recordings, Boris [1] in particular are fond of doing this. Apart from the fact that analog mediums often have inaccurate/incorrect times, what do you see as the problem that this would fix? If it's only to be precise then strictly speaking we should do away with analog tracks altogether, and instead just have sides. [1]: http://musicbrainz.org/artist/57652bf8-cfe8-42e7-b9a7-5572a7080d8d -- Per / Wizzcat ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Idea: remove track durations from analog releases
On 11/18/2011 02:31 PM, Per Øyvind Øygard wrote: My immediate feeling is that this would cause more problems than it would solve. The primary advantage of having analog recording track times is for recording merging purposes. Without track times you risk accidentally merging recordings which one would otherwise recognize as different. It's not unheard of for vinyl to have different edits or even productions of cd recordings, Boris [1] in particular are fond of doing this. Shouldn’t be a problem, this idea would only remove the track durations. Recording durations, acoustIDs, and especially disambiguation comments should be able to take care of the rest. I couldn’t find any specific recordings like you describe for Boris, but I’m aware of that situation in general. Apart from the fact that analog mediums often have inaccurate/incorrect times, what do you see as the problem that this would fix? The main problem I’m shooting to fix is having to update durations in several places. Ideally you’d only have to update the recording’s duration, and have that change flow out from there. As it is, in order to change a duration you have to change it on the recording and then again on every release where that recording appears. discIDs do the job for CDs, and acoustIDs should some day do the job for digital media files. But for analog media (and possibly some digital, I’m not sure of the details for DAT and DCC tapes) this information simply does not exist. If it's only to be precise then strictly speaking we should do away with analog tracks altogether, and instead just have sides. Sides have similar limitations to tracks, although at least you have fewer opportunities for error: early phonograph records are frequently played at the wrong speed; phonograph record end lock-grooves repeat forever; piano rolls don’t always have speed information available; tapes have leaders, etc. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
On 11/18/2011 02:54 PM, Frederic Da Vitoria wrote: Quite valid remarks. I still think that Recordings were meant for something closer to masters, but maybe we are changing direction here and maybe it is better. I would regret that we would lose what is IMO very musically relevant information, but maybe you are right and maybe it would be too difficult to maintain it. Well, as I said in a previous post I will avoid merging recordings where someone has gone through the effort to put the master info into the disambiguation comment. But this is relatively rare, so for most artists there is very little information there in the first place to be maintained. And the recording/release associations are highly suspect even before getting into the different remasters. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-341 CSG Recording parts Relations
A few comments to jacobbrett *Makes adding/editing ARs easier, faster and more streamlined:* For example, at the moment, if a classical performance has 12 parts and 3 performers (say a pianist, conductor and orchestra), the ARs need to be added to every part (36 ARs). Approval and implementation of this RFC would give us the possibility to only have 3 ARs to enter or correct.The sub-parts/movements could get the ARs through inheritance. I think RFC-339 must be decided before citing this as a pro. Whether or not RFC-339 passes, it's inevitable that some form of inheritance will be implemented in Musicbrainz and when that time comes, structural changes such as what's proposed here will benefit from it. *Regarding partial recordings on releases* There are often CDs which have partial recordings (for example most of the tracks on this release which I'm currently editing: Les Grands Classiques d'Edgar : Encore Plushttp://musicbrainz.org/release/f8b78017-9b9a-48fa-8e9b-90310400a84b ). The fact is that most of these recorded parts were actually recorded along with the remaining parts and released on other albums. Such recordings will simply be merged with other recordings I disagree. There are obviously two distinct recordings, one of which is intentionally edited--it is not useful for users to have these two recordings muddled. I think you misunderstood me, there are often instances where an entire track is re-released on another release. It's usually because the release just wants to include the most important or famous movements from bigger classical works. There is no editing involved. These recordings should definitely be merged since it's the same performance, same recording, same performers, etc... *NOTE*: With RFC-341, I'm only proposing the relationship to link recordings in a hierarchy similar to works. A lot of the advantages I listed above are future benefits but they will and should be passed in separate RFCs after this one has passed. Then, I have no opinion on this RFC at this time. I don't understand what I said in my last paragraph or two to make you say you have no opinion. Did you wish I include more in this RFC? Please let me know how I can improve my proposal so that I can get approval. Sebastien On Fri, Nov 18, 2011 at 6:22 AM, jacobbrett jacobbr...@hotmail.com wrote: Lemire, Sebastien-2 wrote: I propose here an RFC to create a hierarchy in recordings similar as we have in the works tables. It expires in 7 days on Novemer 24th 2011. Because I haven't thought the consequences through for non-classical music, this RFC only applies with CSG. The proposal can be found here: http://wiki.musicbrainz.org/Proposal:Recording_Parts_Relationship NOTE: This is the first time I created a wiki page (I shamelessly copied from the similar http://wiki.musicbrainz.org/Parts_Relationship_Type). Please feel 100% to make modifications to it or let me know what I need to modify, change or add. [snip] *Makes adding/editing ARs easier, faster and more streamlined:* For example, at the moment, if a classical performance has 12 parts and 3 performers (say a pianist, conductor and orchestra), the ARs need to be added to every part (36 ARs). Approval and implementation of this RFC would give us the possibility to only have 3 ARs to enter or correct.The sub-parts/movements could get the ARs through inheritance. I think RFC-339 must be decided before citing this as a pro. Lemire, Sebastien-2 wrote: [snip] *Regarding partial recordings on releases* There are often CDs which have partial recordings (for example most of the tracks on this release which I'm currently editing: Les Grands Classiques d'Edgar : Encore Plushttp://musicbrainz.org/release/f8b78017-9b9a-48fa-8e9b-90310400a84b ). The fact is that most of these recorded parts were actually recorded along with the remaining parts and released on other albums. Such recordings will simply be merged with other recordings I disagree. There are obviously two distinct recordings, one of which is intentionally edited--it is not useful for users to have these two recordings muddled. Lemire, Sebastien-2 wrote: If they haven't and were indeed recorded alone, then a decision will need to be made in a future RFC. Personally, we should keep the same tree structure with perhaps an attribute at the supra-recording level that indicates that this performance is incomplete. *NOTE*: With RFC-341, I'm only proposing the relationship to link recordings in a hierarchy similar to works. A lot of the advantages I listed above are future benefits but they will and should be passed in separate RFCs after this one has passed. Then, I have no opinion on this RFC at this time. Lemire, Sebastien-2 wrote: Sebastien ___ MusicBrainz-style mailing list
Re: [mb-style] RFC-341 CSG Recording parts Relations
Lemire, Sebastien-2 wrote: A few comments to jacobbrett *Makes adding/editing ARs easier, faster and more streamlined:* For example, at the moment, if a classical performance has 12 parts and 3 performers (say a pianist, conductor and orchestra), the ARs need to be added to every part (36 ARs). Approval and implementation of this RFC would give us the possibility to only have 3 ARs to enter or correct.The sub-parts/movements could get the ARs through inheritance. I think RFC-339 must be decided before citing this as a pro. Whether or not RFC-339 passes, it's inevitable that some form of inheritance will be implemented in Musicbrainz and when that time comes, structural changes such as what's proposed here will benefit from it. *Regarding partial recordings on releases* There are often CDs which have partial recordings (for example most of the tracks on this release which I'm currently editing: Les Grands Classiques d'Edgar : Encore Pluslt;http://musicbrainz.org/release/f8b78017-9b9a-48fa-8e9b-90310400a84b gt; ). The fact is that most of these recorded parts were actually recorded along with the remaining parts and released on other albums. Such recordings will simply be merged with other recordings I disagree. There are obviously two distinct recordings, one of which is intentionally edited--it is not useful for users to have these two recordings muddled. I think you misunderstood me, there are often instances where an entire track is re-released on another release. It's usually because the release just wants to include the most important or famous movements from bigger classical works. There is no editing involved. These recordings should definitely be merged since it's the same performance, same recording, same performers, etc... Ah, I understand now. Thanks for the clarification. Lemire, Sebastien-2 wrote: *NOTE*: With RFC-341, I'm only proposing the relationship to link recordings in a hierarchy similar to works. A lot of the advantages I listed above are future benefits but they will and should be passed in separate RFCs after this one has passed. Then, I have no opinion on this RFC at this time. I don't understand what I said in my last paragraph or two to make you say you have no opinion. Did you wish I include more in this RFC? Please let me know how I can improve my proposal so that I can get approval. Sebastien I haven't yet considered the RFC and its consequences as a whole (nor work parts); I was just knit-picking small points of your post--your above comment that they should be considered separate RFCs gave me no reason to veto this RFC. Hopefully, I'll get back to you soon with some relevant constructive criticism. :) -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-341-CSG-Recording-parts-Relations-tp4081503p4085453.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Multiple Scripts to the script list
Nicolás Tamargo de Eguren wrote: We already have a Multiple Languages option, but we lack Multiple Scripts, which applies to several of the same places where we use multiple languages (it's not too strange to have Japanese scripts, Cyrillic or Arabic in the same release as Latin). So this is just asking for us to add that to the script list. For an example of a clear Multiple Scripts release, see http://musicbrainz.org/release/575f1987-e61c-49cb-8c95-92b6b42b6700 +1 I wish we had a style guideline for how to fill out the Release Language and Release Script fields, because I would like to see a caution added there about Multiple Scripts: If a Release has titles in a language which features multiple scripts, then use that language's script instead of Multiple Scripts. This matters particularly for Japanese, where the four scripts Han ideographs, hiragana, katakana, and Latin letters are routinely used together. But we don't really appear to have a style guideline for the Release Language and Release Script fields. http://wiki.musicbrainz.org/How_to_Use_the_Release_Editor mentions the fields in passing. There is a red link to a non-existant page http://wiki.musicbrainz.org/?title=How_To_Add_Script_And_Language . But no real good place to write this down, at the moment. So I'll make a note here, and hope it doesn't get completely lost. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Multiple-Scripts-to-the-script-list-tp6993791p7010566.html Sent from the Style discussions mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-340: Improve CC-license links
jw wrote: Hello, this is a proposal to improve the situation for releases that are available under a Creative Commons (CC) or other free license. 1. Introduce a new License Relationship Type, which links a release to an official URL of the license (e.g. http://creativecommons.org/licenses/by-sa/1.0/). This has the benefit that exact versions of the license can be specified. 2. Obsolete the Creative Commons Licensed Download [1]. This can be done by either placing a note obsolete, do not use anymore, or by disabling new additions of this AR. Existing relationships should be converted by hand, or by a bot if possible (nikki wrote a script). 3. A drop-down list of some often used licenses (= license URLs) should be added to the Free Download [3] and Paid Download [4] Relationship Type. If a license is selected there, this results in two separate edits: - one for the pure download URL - one for the license URL This was suggested to make the process not more difficult as it was before. +1 -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-340-Improve-CC-license-links-tp6998925p7010571.html Sent from the Style discussions mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-337: Add 'solo' performer relationship attribute
Alex Mauer wrote: On 11/12/2011 03:44 AM, Jim DeLaHunt wrote: What is the definition of a solo? How can determine (without looking at credits) whether a performance counts as a solo or not? ... I'm not ready to +1 your proposal until it's clear enough for editors to agree whether a performance counts as a solo, in the case where there is no solo credit. I’m inclined to leave this undefined, i.e. up to the judgement of the editors/voters interested in the recordings in question, to determine ...whether the solo attribute works for that genre, and whether that particular instance qualifies as a solo itself. If there are disagreements, they could certainly brought to the list once we have a better idea how people tend to use this attribute. What do you think of that idea? I'm sorry, but I think it would be a mistake to a make a proposal that adds an attribute but fails to define how editors should use that attribute. (To be specific: saying the solo attribute applies if there is a solo citation is clear enough, but saying that the attribute applies if an artist performed a solo part, without definition, is not acceptable.) I agree it's hard to write such a definition. If you, the proposer, finds solo hard to define, then it will be much worse for everyone else using the database. What is the chance that two editors will agree on whether a specific performance counts as a solo? What is the chance that a database user tomorrow will understand what a contributor today means by solo? If a definition is hard, improve the proposal or withdraw it. Don't throw the problem into the laps of future editors. That, at least, is my opinion. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-337-Add-solo-performer-relationship-attribute-tp6905622p7010587.html Sent from the Style discussions mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Multiple Scripts to the script list
I wish we had a style guideline for how to fill out the Release Language and Release Script fields, because I would like to see a caution added there about Multiple Scripts: Completely agree, I've been editing Japanese releases for years without knowing the purpose of those fields or how they should be filled out. Japanese with the different scripts (I've been known to enter Japanese/Japanese even all the titles are written in English since the songs themselves are sung in Japanese), but also french releases with a few English titles thrown in, or perhaps one song sung in English, etc... Sebastien On Fri, Nov 18, 2011 at 10:03 PM, Jim DeLaHunt from.nab...@jdlh.com wrote: Nicolás Tamargo de Eguren wrote: We already have a Multiple Languages option, but we lack Multiple Scripts, which applies to several of the same places where we use multiple languages (it's not too strange to have Japanese scripts, Cyrillic or Arabic in the same release as Latin). So this is just asking for us to add that to the script list. For an example of a clear Multiple Scripts release, see http://musicbrainz.org/release/575f1987-e61c-49cb-8c95-92b6b42b6700 +1 I wish we had a style guideline for how to fill out the Release Language and Release Script fields, because I would like to see a caution added there about Multiple Scripts: If a Release has titles in a language which features multiple scripts, then use that language's script instead of Multiple Scripts. This matters particularly for Japanese, where the four scripts Han ideographs, hiragana, katakana, and Latin letters are routinely used together. But we don't really appear to have a style guideline for the Release Language and Release Script fields. http://wiki.musicbrainz.org/How_to_Use_the_Release_Editor mentions the fields in passing. There is a red link to a non-existant page http://wiki.musicbrainz.org/?title=How_To_Add_Script_And_Language . But no real good place to write this down, at the moment. So I'll make a note here, and hope it doesn't get completely lost. -- View this message in context: http://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-Add-Multiple-Scripts-to-the-script-list-tp6993791p7010566.html Sent from the Style discussions mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
