Re: [mb-style] RFC: recordings: remove remaster from the 'should not be merged' list
lorenz pressler wrote: http://musicbrainz.org/doc/Style/Recording ### 3. What should and shouldn't be merged together? # change: shouldn't merge different edits, mixes, remixes or remasters of a performance. # into: shouldn't merge different edits, mixes or remixes of a performance. # add: should normally merge remasters unless theres an clear audible difference between them. * # add: 3.2 remasters most remaster jobs just consist of some minor adjustment in volume and cutting silence. In these cases merging is valid and remastering credit should be added to the release only (not the recordings itself). If there is a real difference they should not be merged and it is mandatory to add a short disamiguation comment to the remastered recordings, detailed info can be added to the annotations. ### maybe someone can add a nice example? i only recall someone mentioned some beatles remasters and the rhcp/californication release. or should it be the other way round: don't merge unless you hear no difference? imho most remasters are just a marketing hoax to sell old recordings again. real remasters worth of their own recordings are sparse (at least in my collection). regards, -- lorenz pressler PGP 0x92E9551A Here are two examples for remastered albums containing recordings that should definitely not be merged: The Sisters of Mercy - First and Last and Always http://musicbrainz.org/release-group/8dba5572-6b3d-3e31-ab32-51d1f3ed1f69 This one is quite complex with different mixes used as sources for the remasters. Details are given in http://en.wikipedia.org/wiki/First_and_Last_and_Always#Different_editions_of_the_album A more straightforward one is Front 242 - Geography http://musicbrainz.org/release-group/7526b5ca-a954-3a2d-bf67-2e9bb44ab338 http://en.wikipedia.org/wiki/Geography_%28album%29 Note that all contained recordings have disambiguation comments to (hopefully) prevent merging. BTW, does anyone have a good idea how to fix the mess of PUIDs and AcoustIDs for these tracks and prevent them from becoming messed up again? A problem that most probably will come up with the proposed change of the guideline is that editors and/or voters either have the original or the remaster at hand. And even if you happen to have both versions it will still be disputable whether or not there is a clear audible difference. Keeping originals and remasters separate has the advantage of being a much clearer guideline with a lot less room for discussion. OTOH, for compilations it is usually not clear whether they contain original or remastered tracks. Things would be a lot easier if there was only one recording for both versions. Christian (MD) -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-recordings-remove-remaster-from-the-should-not-be-merged-list-tp3990663p4015404.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-rato: Add DJ-mix to the RG type list
Andii Hughes wrote: What's the status with this? I don't recall seeing an RFV. When I asked Nicolás about it, he said he wanted to wait until we get types and attributes. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-rato: Add DJ-mix to the RG type list
On Tue, Nov 8, 2011 at 11:45 AM, Nikki aei...@gmail.com wrote: Andii Hughes wrote: What's the status with this? I don't recall seeing an RFV. When I asked Nicolás about it, he said he wanted to wait until we get types and attributes. Yeah. I would like to wait a bit because introducing DJ-mix like this would mean a lot of releases would suddenly be in the wrong category, while introducing it as an attribute would make much more sense. If I don't see any progress towards this in a few months, I will probably bring this up again though, but I am hoping we can see some progress here. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ 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/8, MeinDummy meindu...@nurfuerspam.de: A problem that most probably will come up with the proposed change of the guideline is that editors and/or voters either have the original or the remaster at hand. And even if you happen to have both versions it will still be disputable whether or not there is a clear audible difference. Keeping originals and remasters separate has the advantage of being a much clearer guideline with a lot less room for discussion. OTOH, for compilations it is usually not clear whether they contain original or remastered tracks. Things would be a lot easier if there was only one recording for both versions. Maybe we are missing a level here. We sometimes need a recording level, almost in/as the common sense (sorry, I feel I am not formulating this clearly), which would be useful for your compilations example, but at other times we need a master level to keep audibly distinct remasters separate. -- 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 Tue, Nov 8, 2011 at 12:19 PM, Frederic Da Vitoria davito...@gmail.comwrote:
2011/11/8, MeinDummy meindu...@nurfuerspam.de:
A problem that most probably will come up with the proposed change of the
guideline is that editors and/or voters either have the original or the
remaster at hand.
And even if you happen to have both versions it will still be disputable
whether or not there is a clear audible difference.
Keeping originals and remasters separate has the advantage of being a
much
clearer guideline with a lot less room for discussion.
OTOH, for compilations it is usually not clear whether they contain
original
or remastered tracks. Things would be a lot easier if there was only one
recording for both versions.
Maybe we are missing a level here. We sometimes need a recording
level, almost in/as the common sense (sorry, I feel I am not
formulating this clearly), which would be useful for your compilations
example, but at other times we need a master level to keep audibly
distinct remasters separate.
It's not the first time an idea like this is brought up, and if this was a
place were only people with a {computer/library} science degree entered
information, I'd say go for it (and also add an arrangement level). But I
think it would be way too confusing for casual users (I know people already
find the current amount of levels hard).
--
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
--
Nicolás Tamargo de Eguren
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-rato: Add DJ-mix to the RG type list
2011/11/8 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Nov 8, 2011 at 11:45 AM, Nikki aei...@gmail.com wrote: Andii Hughes wrote: What's the status with this? I don't recall seeing an RFV. When I asked Nicolás about it, he said he wanted to wait until we get types and attributes. Yeah. I would like to wait a bit because introducing DJ-mix like this would mean a lot of releases would suddenly be in the wrong category, while introducing it as an attribute would make much more sense. If I don't see any progress towards this in a few months, I will probably bring this up again though, but I am hoping we can see some progress here. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style Is that something likely in the near future? And without another big schema redesign? I already think this is long overdue and I'm not sure how a lot of releases would suddenly be in the wrong category. They'd only get there by edits and, to my mind, a lot of releases already are in the wrong category i.e. a lot of DJ mixes are mixed up with compilations and it will be a big job to separate them. -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Reduce the requisites for Live Performance Relationship Type
Nicolás Tamargo de Eguren wrote: On Fri, Oct 28, 2011 at 9:58 PM, Nikki lt;aeizyx@gt; wrote: jacobbrett wrote: * Radio, TV, and internet-streamed performances are considered to be 'live'. * This relationship type should not be used to link from compilations of live performances, nor should it be linked to box sets. * The song order of the live release does not have to match the song order of the studio release. * At least 80% of the tracks from the studio release must be present on the live release. * At least 80% of tracks on the live release must be present on the studio release. * For either of the above two guidelines, the 80% requirement may be lowered if sufficient reason exists, subject to agreement by voters. I think it may be worth keeping the above guidelines, though the 80% rules are a bit superflous. What about something like The original and live releases should contain mostly the same songs? (instead of the last three bullet points) Hmm, I would even just say The live release should contain most of the songs in the original (without blocking the option that it also has a good amount of songs from other albums if it is still advertised and sold as a live version of *that* one album). Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@.musicbrainz http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style Hey, I think both are good suggestions...I suppose I'd go with the wording that's most applicable to real releases... May anybody provide examples (I don't know how to find the entities of those 24 relationships)? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Reduce-the-requisites-for-Live-Performance-Relationship-Type-tp3926041p4015672.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-rato: Add DJ-mix to the RG type list
On Tue, Nov 8, 2011 at 1:00 PM, Andii Hughes gnu_and...@member.fsf.orgwrote: 2011/11/8 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Nov 8, 2011 at 11:45 AM, Nikki aei...@gmail.com wrote: Andii Hughes wrote: What's the status with this? I don't recall seeing an RFV. When I asked Nicolás about it, he said he wanted to wait until we get types and attributes. Yeah. I would like to wait a bit because introducing DJ-mix like this would mean a lot of releases would suddenly be in the wrong category, while introducing it as an attribute would make much more sense. If I don't see any progress towards this in a few months, I will probably bring this up again though, but I am hoping we can see some progress here. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style Is that something likely in the near future? And without another big schema redesign? I already think this is long overdue and I'm not sure how a lot of releases would suddenly be in the wrong category. They'd only get there by edits and, to my mind, a lot of releases already are in the wrong category i.e. a lot of DJ mixes are mixed up with compilations and it will be a big job to separate them. What I mean is: currently Dj-mixes are in the category they're expected to be (compilations). But by adding DJ-mix, they'd suddenly all be in the wrong place (compilations) until manually fixed. And this needs a schema change, but we will have two schema change releases per year, so that doesn't imply that it has to wait years like NGS did. I think I'll wait until the next schema change release (estimated for mid-January). If this is not added in that one, I will RFV it and do it manually (as I agree it's quite annoying now). -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ 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/8, Nicolás Tamargo de Eguren reosare...@gmail.com:
On Tue, Nov 8, 2011 at 12:19 PM, Frederic Da Vitoria
davito...@gmail.comwrote:
2011/11/8, MeinDummy meindu...@nurfuerspam.de:
A problem that most probably will come up with the proposed change of
the
guideline is that editors and/or voters either have the original or the
remaster at hand.
And even if you happen to have both versions it will still be disputable
whether or not there is a clear audible difference.
Keeping originals and remasters separate has the advantage of being a
much
clearer guideline with a lot less room for discussion.
OTOH, for compilations it is usually not clear whether they contain
original
or remastered tracks. Things would be a lot easier if there was only one
recording for both versions.
Maybe we are missing a level here. We sometimes need a recording
level, almost in/as the common sense (sorry, I feel I am not
formulating this clearly), which would be useful for your compilations
example, but at other times we need a master level to keep audibly
distinct remasters separate.
It's not the first time an idea like this is brought up, and if this was a
place were only people with a {computer/library} science degree entered
information, I'd say go for it (and also add an arrangement level). But I
think it would be way too confusing for casual users (I know people already
find the current amount of levels hard).
Yes, you are right, there are already too many levels. Reality is complex :-)
--
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-rato: Add DJ-mix to the RG type list
2011/11/8 Nicolás Tamargo de Eguren reosare...@gmail.com: What I mean is: currently Dj-mixes are in the category they're expected to be (compilations). But by adding DJ-mix, they'd suddenly all be in the wrong place (compilations) until manually fixed. Sure. But how would a schema change affect this? Doing this either as a new type or an attribute of an existing type, it's still going to need lots of manual edits to add the new data. And this needs a schema change, but we will have two schema change releases per year, so that doesn't imply that it has to wait years like NGS did. I think I'll wait until the next schema change release (estimated for mid-January). If this is not added in that one, I will RFV it and do it manually (as I agree it's quite annoying now). Well is there a bug or something for this? What makes you think it might happen with the next schema change? -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Andii :-) ___ 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
I've also had problems with remastered tracks.
I understand that some would like to keep them separate, but as Christian
said above, it's often very difficult to find out which remastered version
of a track you might have on a certain album or especially compilation. I
think in a lot of cases, for smaller artists, I'm afraid the information
might be impossible to get.
It almost seems to me that this information should be stored at track level
rather than recording level. Perhaps with a special attribute in the tracks
in the tracklist or more simply as part of the style.
Sebastien
On Tue, Nov 8, 2011 at 6:54 AM, Frederic Da Vitoria davito...@gmail.comwrote:
2011/11/8, Nicolás Tamargo de Eguren reosare...@gmail.com:
On Tue, Nov 8, 2011 at 12:19 PM, Frederic Da Vitoria
davito...@gmail.comwrote:
2011/11/8, MeinDummy meindu...@nurfuerspam.de:
A problem that most probably will come up with the proposed change of
the
guideline is that editors and/or voters either have the original or
the
remaster at hand.
And even if you happen to have both versions it will still be
disputable
whether or not there is a clear audible difference.
Keeping originals and remasters separate has the advantage of being a
much
clearer guideline with a lot less room for discussion.
OTOH, for compilations it is usually not clear whether they contain
original
or remastered tracks. Things would be a lot easier if there was only
one
recording for both versions.
Maybe we are missing a level here. We sometimes need a recording
level, almost in/as the common sense (sorry, I feel I am not
formulating this clearly), which would be useful for your compilations
example, but at other times we need a master level to keep audibly
distinct remasters separate.
It's not the first time an idea like this is brought up, and if this was
a
place were only people with a {computer/library} science degree entered
information, I'd say go for it (and also add an arrangement level). But I
think it would be way too confusing for casual users (I know people
already
find the current amount of levels hard).
Yes, you are right, there are already too many levels. Reality is complex
:-)
--
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
___
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 4 November 2011 16:14, lorenz pressler l...@gmx.at wrote: http://musicbrainz.org/doc/Style/Recording ### 3. What should and shouldn't be merged together? # change: shouldn't merge different edits, mixes, remixes or remasters of a performance. # into: shouldn't merge different edits, mixes or remixes of a performance. # add: should normally merge remasters unless theres an clear audible difference between them. * # add: 3.2 remasters most remaster jobs just consist of some minor adjustment in volume and cutting silence. In these cases merging is valid and remastering credit should be added to the release only (not the recordings itself). If there is a real difference they should not be merged and it is mandatory to add a short disamiguation comment to the remastered recordings, detailed info can be added to the annotations. ### maybe someone can add a nice example? i only recall someone mentioned some beatles remasters and the rhcp/californication release. or should it be the other way round: don't merge unless you hear no difference? imho most remasters are just a marketing hoax to sell old recordings again. real remasters worth of their own recordings are sparse (at least in my collection). regards, -- lorenz pressler PGP 0x92E9551A ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -1. No, this is too vague. Requiring differing recordings depending on the user's ability to perceive audible differences depends not only on the user being able to discern such differences (which varies from person to person), but also on them having access to said recording. In all the cases I'm aware of, remasters are separate either because they are on a known remaster or have different ISRCs, and that's good enough for me to suggest these are different recordings. One advantage is the ISRC can be used to see the proliferation of remastered versions across different releases (e.g. the new Queen remasters appear both on remastered studio albums and new 'Deep Cuts' compilations). I don't see any good reason to destroy remastering data. Why would we want to do this? -- Andii :-) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-339: Work/Relationship Inheritance in Works Trees
Hi Jim, some comments about the revised RFC-339. I must admit that I have trouble understanding some parts of your proposal as well. In particular the Relationship Inheritance Rules part. I understand the various inheritance possibilities but I must say I fail to see how these rules have to do with Musicbrainz. Are they implemented at the moment? Should they be implemented? If so, between which entities in MB? Also, you write in several parts except for the Parts Relationship Type (Work-Work) but I was under the impression that the whole point of this RFC was in fact for inheritance between child and parent works. So I'm confused... That said, I'm 100% in favor of the concept as I understood it (and still do globally, I think) that we should have inheritance rules between entities (in this case work-work) so that can minimize data entry, reduce useless duplicate ARs (thus reducing errors), etc... This RFC just seems to explain what inheritance but that I don't see any practical applications in MB. (Will they come in a future RFCs?) I think what would be useful is quick and concise explanation of the purpose of this RFC as well as they goal that you wish to get to should it pass. What will it fix. Sebastien On Mon, Nov 7, 2011 at 7:48 PM, Jim DeLaHunt from.nab...@jdlh.com wrote: At 1:04 AM -0800 11/7/11, symphonick [via MusicBrainz mailing lists] wrote: IMHO it would be better if the page began with your proposal examples, and you could get into details further down. Judging from your responses to my other mail, I obviously don't understand exactly what you're suggesting here. Symphonick and swisschris: Thank you for your feedback. I'm getting the impression that the way I wrote the proposal text isn't communicating clearly. It's hard for me to improve this, because the text is clear to *me*. But I'll try. If the page begins like this, is it a big improvement? = Work/Relationship Inheritance in Works Trees When one Work entity (Parent) is linked to another Work (Child) with the Parts Relationship Type (Child is part of Parent), then each Work entity inherits the Relationships on the other Work entity. The inheritance rules are: 1. *Indivisibility*. Any relationship to a Work entity applies to the all of the composition (or part of a composition) to which the Work refers, and to any portion of it. This applicability is called full coverage. 2. *All of Child inherits from Parent*. Any relationship to the Parent Work means that the same relationship applies also to the entire portion of the musical composition to which the Child Work refers (i.e., with full coverage). 3. *Some of Parent inherits from Child*. Any relationship to the Child means that the same relationship applies to some non-zero portion, and maybe or maybe not all, of Parent. This applicability is called partial coverage. 4. *Siblings don't inherit*. Given another Work entity, Child 2, which also has a Parts Relationship Type saying Child 2 is a part of Parent, then any relationship to Child does not imply any meaning about that relationship and Child 2. Inheritance passes between parent and child, but not from one child to another of the same parent. 5. *Inheritance is transitive*. Given yet another Work entity, Grandchild, which has a Parts Relationship Type saying Grandchild is a part of Child, then any relationship which Child inherits from Parent, Grandchild in turn inherits from Child (its parent). Any relationship which Child inherits from Grandchild (its own child), Parent in turn inherits from Child. 6. *Inheritance status matters*. Anything which displays or interprets Relationships should present the distinction between inherited and direct Relationships, between inheritance from distant and immediately-linked relatives, and between full and partial coverage, in a way that's appropriate. = Examples ...[more text goes here]... = Definitions ...[more text goes here]... = Discussion ...[more text goes here]... -- --Jim DeLaHunt, [hidden email]http://user/SendEmail.jtp?type=nodenode=6972719i=0 http://blog.jdlh.com/ (http://jdlh.com/) multilingual websites consultant 157-2906 West Broadway, Vancouver BC V6K 2G8, Canada Canada mobile +1-604-376-8953 -- View this message in context: Re: RFC-339: Work/Relationship Inheritance in Works Treeshttp://musicbrainz-mailing-lists.2986109.n2.nabble.com/RFC-339-Work-Relationship-Inheritance-in-Works-Trees-tp6952822p6972719.html Sent from the Style discussions mailing list archivehttp://musicbrainz-mailing-lists.2986109.n2.nabble.com/Style-discussions-f3020564.htmlat Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___
