Re: [mb-style] Master and Performance entities
2014-09-16 19:58 GMT+02:00 LordSputnik : > Frederic Da Vitoria wrote > > I now see that another way to handle the problem would be to > > systematically > > create a different Master for each track, and later merge those we decide > > to consider identical. I believe that's the way MB handled this kind of > > situation until now. In this case, no need for an "undefined" status, but > > the editors will have to merge lots of Masters instead of creating new > > ones. I am not sure this is a better solution. > > Well, perhaps we could allow either a master and a recording to be linked > to > a track, bypassing the need to do anything special for undefined masters? > > > lixobix wrote > > Why not both? Both have different uses. Although perhaps (1) should be > > approached in a broader way: as 'edition' or something, rather than > > master. > > This would allow for the grouping releases that share the same mastering, > > and also e.g. those that have the same track lists / bonus tracks. > > I'm not sure about adding Edition - this seems to overlap too much with > release groups, and also in most cases there'll be a 1:1 relationship > between Editions and Releases. > Yes, this would be a good solution too. -- 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] Master and Performance entities
Frederic Da Vitoria wrote > I now see that another way to handle the problem would be to > systematically > create a different Master for each track, and later merge those we decide > to consider identical. I believe that's the way MB handled this kind of > situation until now. In this case, no need for an "undefined" status, but > the editors will have to merge lots of Masters instead of creating new > ones. I am not sure this is a better solution. Well, perhaps we could allow either a master and a recording to be linked to a track, bypassing the need to do anything special for undefined masters? lixobix wrote > Why not both? Both have different uses. Although perhaps (1) should be > approached in a broader way: as 'edition' or something, rather than > master. > This would allow for the grouping releases that share the same mastering, > and also e.g. those that have the same track lists / bonus tracks. I'm not sure about adding Edition - this seems to overlap too much with release groups, and also in most cases there'll be a 1:1 relationship between Editions and Releases. lixobix wrote > What would be the difference between an event and a performance? Are you > suggesting that both should be entities? I mean that we could use the Event entity (already due to be added in October, afaik) instead of adding a separate Performance entity. -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Master-and-Performance-entities-tp4668141p4668200.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] Master and Performance entities
2014-09-16 16:39 GMT+02:00 lixobix : > Frederic Da Vitoria wrote > > 2014-09-14 14:00 GMT+02:00 LordSputnik < > > > ben.sput@ > > > >: > > > >> Master audio could be represented in one of two ways: > >> - 1. as an entity which groups releases with identical mastering. > >> - 2. as an entity which seamlessly fits between recordings and tracks, > >> and > >> allows the grouping of tracks with shared mastering. > >> > >> Ben / LordSputnik > >> > > > > I think we don't really have a choice: it will have to be #2 for the > > reason > > you gave. > > Why not both? Both have different uses. Although perhaps (1) should be > approached in a broader way: as 'edition' or something, rather than master. > This would allow for the grouping releases that share the same mastering, > and also e.g. those that have the same track lists / bonus tracks. > > http://musicbrainz.org/release/8549ce34-2349-42e0-bf28-1a773b35bcaa > http://musicbrainz.org/release/472fed21-00bc-3b35-842b-f8a44a8b9678 > > as opposed to > > http://musicbrainz.org/release/780823a5-a852-4958-bcb3-b291ceb66ea1 > > > Frederic Da Vitoria wrote > > One thought; many times (most of the times?) the master will be > impossible > > to chose. This should be part of whatever we build. I believe simply > > allowing users to create temporary "undefined" masters for such > situations > > would be dangerous. For recording from the sixties. there existed analog > > and digital masters. A user could later set the "undefined" master to > > digital because he saw "DDD" on his CD and thus store false data in MB > > (not > > all masters were digital). So IMO we should either allow for no master, > or > > create a special kind of master which could not be edited. > > I'm not sure what you mean by this. If there is no information about > mastering, then the master is the same as all other undefined releases. I see no problem with using an undefined master. > The problem is that the "undefined" master may not really exist in the real world. It could be (will often be) only a wrapper for all the masters MB users don't know about. Just after creating the Master Entity (if it is to become an Entity), the situation could even be catastrophic: all the tracks made out of all Recordings could be considered as issuing from undefined Masters until we start creating the real, documented Masters. The problem I see is that if we don't mark those undefined Masters as such, some users will start adding data to them instead of creating a new Master. Imagine for example that on one Release, a user finds the DDD logo, he would start editing the undefined Master to state that it is digital. Even if some Tracks from that Master are part of vinyl Releases (I know, some vinyl tracks are digitally mastered, but you see what I mean). If later another user found mention of a Mastering engineer on another release, he would link it to the same Master, even if the engineer actually worked on an analog master. Actually, two or three Masters should be created in my example, the original undefined (which should always remain unmodified) plus 1 or 2 more depending on whether the engineer worked on the Master from which the DDD track issued or not. I now see that another way to handle the problem would be to systematically create a different Master for each track, and later merge those we decide to consider identical. I believe that's the way MB handled this kind of situation until now. In this case, no need for an "undefined" status, but the editors will have to merge lots of Masters instead of creating new ones. I am not sure this is a better solution. > It's questionable whether > SPARS codes should be used at all as a reference for mastering info (I > think > not), as the mastering aspect of them refers merely to the nature of the > medium onto which the master is pressed, and bears no relation to the > processing of mixed recordings, which is what I believe we are concerned > with. There should only be a distinction between the mastering of different > media when there is clear evidence that they contain different (processed) > masters, as is often the case with modern CD / DD vs vinyl (brickwalling). > So perhaps all we need to do is to state in the guidelines that SPARS codes > are not authoritative for defining the type of mastering. > I agree. But this means that we must again insist on the fact that an MB Master is slightly different from a real world master. -- 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] Master and Performance entities
Frederic Da Vitoria wrote > 2014-09-14 14:00 GMT+02:00 LordSputnik < > ben.sput@ > >: > >> Master audio could be represented in one of two ways: >> - 1. as an entity which groups releases with identical mastering. >> - 2. as an entity which seamlessly fits between recordings and tracks, >> and >> allows the grouping of tracks with shared mastering. >> >> Ben / LordSputnik >> > > I think we don't really have a choice: it will have to be #2 for the > reason > you gave. Why not both? Both have different uses. Although perhaps (1) should be approached in a broader way: as 'edition' or something, rather than master. This would allow for the grouping releases that share the same mastering, and also e.g. those that have the same track lists / bonus tracks. http://musicbrainz.org/release/8549ce34-2349-42e0-bf28-1a773b35bcaa http://musicbrainz.org/release/472fed21-00bc-3b35-842b-f8a44a8b9678 as opposed to http://musicbrainz.org/release/780823a5-a852-4958-bcb3-b291ceb66ea1 Frederic Da Vitoria wrote > One thought; many times (most of the times?) the master will be impossible > to chose. This should be part of whatever we build. I believe simply > allowing users to create temporary "undefined" masters for such situations > would be dangerous. For recording from the sixties. there existed analog > and digital masters. A user could later set the "undefined" master to > digital because he saw "DDD" on his CD and thus store false data in MB > (not > all masters were digital). So IMO we should either allow for no master, or > create a special kind of master which could not be edited. I'm not sure what you mean by this. If there is no information about mastering, then the master is the same as all other undefined releases. I see no problem with using an undefined master. It's questionable whether SPARS codes should be used at all as a reference for mastering info (I think not), as the mastering aspect of them refers merely to the nature of the medium onto which the master is pressed, and bears no relation to the processing of mixed recordings, which is what I believe we are concerned with. There should only be a distinction between the mastering of different media when there is clear evidence that they contain different (processed) masters, as is often the case with modern CD / DD vs vinyl (brickwalling). So perhaps all we need to do is to state in the guidelines that SPARS codes are not authoritative for defining the type of mastering. LordSputnik wrote > I also think that we might be able to use the new Event entity for storing > Performances - we could introduce a new "recording session for" or > "recorded at" relationship to link Events to Recordings. What would be the difference between an event and a performance? Are you suggesting that both should be entities? -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Master-and-Performance-entities-tp4668141p4668195.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
