2014-09-19 11:07 GMT+02:00 KRSCuan <donc...@gmx.de>: > On 19.09.2014 10:17, Frederic Da Vitoria wrote: > > I've seen this in downloadable tracks from compilations (soemthing like > > "#### remaster). Not very good (there could be 2 remasters the same > > year) but it gives an indication. Maybe we should add a reliability > > flag, allowing to say: "these sound the same" or "these are the same > > according to credits". You gave an excellent suggestion that master data > > should stay out of the way for uninterested users, so that for users who > > are interested we can have a fairly complex UI. > Thing is, we used to have those separated by them being different > recordings. We then chose to throw that info away by merging different > masters/remasters, even in cases where they have different information > (I remember some Queen remasters having distinct ISRCs) and > fingerprints. Now we try to replicate the info we've just thrown away > before? Seems like a wasted effort. And I'd argue that we have more > important things that need fixing. > > I'm not saying the earlier decision regarding masters was necessarily > the best one, quite the contrary. But it's hard to row back now. And I > don't know whether it's really still worth it. In most cases the > information is simply not available, and most of our users probably > won't care. And if they don't care, a master entity won't see any use. >
I agree it will be hard. I agree it would probably have been easier if we hadn't thrown away the data first. I objected when this decision was taken. But now that we are going back, I'm ready to enter the data for masters when I'm aware of it, even if this isn't the optimal path to do it. I disagree that the fact some (most?) users don't care means it won't be any use. The data that is here is useful, even if it not complete. But the UI for Masters should be out of the way so that users who don't care are not bothered by it and are not tempted to enter bad data. > Is this the thing we want to represent, is it definable and do we > > often / ever have data about it on compilations? > > Do we want to attach mastering credits on a per-track basis? That > > seems a bit backwards. > > > > Why "backwards"? There are certainly lots of situations where masters > > will come from different sources. I am of course thinking of > > compilations, but also of releases such as this > > https://musicbrainz.org/release/86d5fc27-0b65-4750-95e2-fb42d6017c4e, > > the second disc could be a different master. > We just got rid of lots of mastering credits on recordings, which were > moved back to releases. If we try to attach these to tracks or a new > kind of entity, we are again rowing backwards. If rowing backwards is the only way to go in the right direction, then let's do it, instead of persisting in rowing in the wrong direction! -- 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
