Master and Performance entities

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Master and Performance entities

LordSputnik
Just over a year ago now, we redefined the MusicBrainz recording entity. Previously, it had mainly been seen as one of two different things, depending on which editor you asked - either a "mix" or a "master".

This resulted in a lot of subjective decision making when merging or splitting recordings, with arguments over whether the practically identical recordings contained "unique audio". A lot of the time, decisions had to be made based on listening to the track (not always possible) or looking at AcoustID data (not always accurate).

So, recording was redefined to represent "distinct audio" prior to final mastering (http://wiki.musicbrainz.org/recording). In most cases (for songs, anyway), this corresponds to the "mix".

This means that we're left with a gap in the MusicBrainz model, since there is no entity to represent audio at the "master" level. Back when recordings were redefined, it was agreed that masters should be implemented in some form in the future, so I've made this thread to get some ideas on what form they should take.

Additionally, it would be nice to hear thoughts on a Performance entity, which was also discussed last year.

My own thoughts:
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.

#1 seems the least complicated way of doing things, but #2 would allow for cases where mastered audio from different sources has been copied to some other release (eg. some compilations)

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.

Anyway, let me know your thoughts, and we can try to come up with some sort of plan!

Ben / LordSputnik
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-14 14:00 GMT+02:00 LordSputnik <[hidden email]>:
Just over a year ago now, we redefined the MusicBrainz recording entity.
Previously, it had mainly been seen as one of two different things,
depending on which editor you asked - either a "mix" or a "master".

This resulted in a lot of subjective decision making when merging or
splitting recordings, with arguments over whether the practically identical
recordings contained "unique audio". A lot of the time, decisions had to be
made based on listening to the track (not always possible) or looking at
AcoustID data (not always accurate).

So, recording was redefined to represent "distinct audio" prior to final
mastering (http://wiki.musicbrainz.org/recording). In most cases (for songs,
anyway), this corresponds to the "mix".

This means that we're left with a gap in the MusicBrainz model, since there
is no entity to represent audio at the "master" level. Back when recordings
were redefined, it was agreed that masters should be implemented in some
form in the future, so I've made this thread to get some ideas on what form
they should take.

Additionally, it would be nice to hear thoughts on a Performance entity,
which was also discussed last year.

My own thoughts:
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.

#1 seems the least complicated way of doing things, but #2 would allow for
cases where mastered audio from different sources has been copied to some
other release (eg. some compilations)

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.

Anyway, let me know your thoughts, and we can try to come up with some sort
of plan!

Ben / LordSputnik

I think we don't really have a choice: it will have to be #2 for the reason you gave. 

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.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

lixobix
Frederic Da Vitoria wrote
2014-09-14 14:00 GMT+02:00 LordSputnik <[hidden email]>:

> 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?
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-16 16:39 GMT+02:00 lixobix <[hidden email]>:
Frederic Da Vitoria wrote
> 2014-09-14 14:00 GMT+02:00 LordSputnik &lt;

> ben.sput@

> &gt;:
>
>> 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
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

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.

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.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-16 19:58 GMT+02:00 LordSputnik <[hidden email]>:
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
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

lixobix
In reply to this post by Frederic Da Vitoria
Frederic Da Vitoria wrote
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.
This is no more of a problem that with other current entities in MB, for a couple of reasons:

1) There are plenty of releases in the database that have an unspecified format, lack a release event, etc. You seem to suggest that there is a risk with masters that empty fields may be filled with incompatible data, which is true, but is there any difference between that risk and that with the above such releases? I think not. Users generally do (or voters can encourage them to) check against all the data for an entity before filling blank fields. So a user would hopefully not enter a release event for a release that did not have a corresponding cat no. The same principal applies here: I don't see why users would decide to fill in blank fields with data incompatible with existing data. If there is an inconsistency they would, as with other entities, create a new one.

(and yes, that may be a high standard to hold users too, but you get the point!)

2) I foresee masters being generated like works rather than like recordings, i.e. created specifically rather than by default. There could be an option to do so in the release editor, but the default would be to not create a master. Of course, if a user did decide to create a master in the release editor, the existing ones would pop up, as they do for recordings, to discourage duplication. In that case, I don't see why users would be adding incorrect data to existing masters, nor would there be a ridiculous number of new, undefined masters generated.

Frederic Da Vitoria wrote
2014-09-16 16:39 GMT+02:00 lixobix <[hidden email]>:
> 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.
I agree that we need to define at this point what we want to document in MB as a 'master'. The reality of the mastering process is that there is not necessarily a single master produced between the final mix and what is pressed onto the medium. For example the 2011 vinyl release of DSOTM has been through two mastering processes: a digital remastering, then vinyl mastering from that digital remaster. So it is important to decide whether we want to document that master as different to the 2011 DSOTM CD, which uses the same digital master, but without the vinyl mastering stage. As all vinyl releases contain this extra stage, would we want to create separate masters for each vinyl lacquer cut? Or just when the release has been remastered?

http://www.discogs.com/release/3128042
http://www.discogs.com/release/3472649

LordSputnik wrote
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?
The only way I see masters working practically is to have triangular relationships between recording, master, and track. Otherwise, if we adopt a hierarchical system (i.e. recording > master > track), we're back to the problem of tracks being linked to the wrong master by default, or new masters being created by default each time new tracks are added and not linked to an existing master. A hierarchical structure would be ideal, but it would be problematic for users if they were forced to select a master or create a new one, if they have little mastering information. On the other hand, creating a new master each time a release is added could lead to serious duplication. A triangular relationship would mean adding releases stays the same as present if desired, as tracks would still be linked to recordings. Yet both recordings and tracks could be linked to masters, so those users actually interested in mastering information could deal with it on the side, as it were, much like works.

LordSputnik wrote
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.
I see it as being at a level between RG and release, which would obviously be a complex change. Perhaps it could be added only when needed, rather than by default, to avoid 1:1 relationships. On the other hand, this is often the case with RGs, and that's not a problem, although I can appreciate that it occurs less for RGs than it would for editions. This should probably be a different discussion anyway, but I'm not sure how else you could group releases by mastering other than creating an entity similar to series.

LordSputnik wrote
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.
Ok, well I don't know how event is going to work. Are there any documents? Perhaps we should wait on that one.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

tommycrock
In reply to this post by LordSputnik


On 14 Sep 2014 13:01, "LordSputnik" <[hidden email]> wrote:
> ...
> This means that we're left with a gap in the MusicBrainz model, since there
> is no entity to represent audio at the "master" level. Back when recordings
> were redefined, it was agreed that masters should be implemented in some
> form in the future, so I've made this thread to get some ideas on what form
> they should take.
>
> Additionally, it would be nice to hear thoughts on a Performance entity,
> which was also discussed last year.
>
> My own thoughts:
> 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.
>
> #1 seems the least complicated way of doing things, but #2 would allow for
> cases where mastered audio from different sources has been copied to some
> other release (eg. some compilations)
>

I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album. 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.
If we could possibly link tracks to either recordings or masters could we make medium-like entities and link through them, either wholly or partially? That way they'd be properly tied together. Or should we be looking to n-ary relationships to fill this gap (not that they currently exist obviously).
More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

> 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.
>

I'd assumed we would be using entities to store performances whether live or in studio, though I'm not sure that can solve problems about "duplicate" data - but can tie locations to sessions more satisfactorily


_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-19 1:24 GMT+02:00 Tom Crocker <[hidden email]>:

On 14 Sep 2014 13:01, "LordSputnik" <[hidden email]> wrote:
> ...
> This means that we're left with a gap in the MusicBrainz model, since there
> is no entity to represent audio at the "master" level. Back when recordings
> were redefined, it was agreed that masters should be implemented in some
> form in the future, so I've made this thread to get some ideas on what form
> they should take.
>
> Additionally, it would be nice to hear thoughts on a Performance entity,
> which was also discussed last year.
>
> My own thoughts:
> 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.
>
> #1 seems the least complicated way of doing things, but #2 would allow for
> cases where mastered audio from different sources has been copied to some
> other release (eg. some compilations)
>

I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album.

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.
 

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. 
 

More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data.
 

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

KRSCuan
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.

>     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.

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

tommycrock
In reply to this post by Frederic Da Vitoria

I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album.

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.

Useful to know
 
Maybe we should add a reliability flag, allowing to say: "these sound the same" or "these are the same according to credits".

(Much) more broadly I'd love it if we could introduce a 'source' similar to wikidata, since nothing is certain and is based on stronger or weaker claims...
 
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.
 

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. 

There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...)  on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release.
 

More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data.


But, I also think KRSCuan might be right.  We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time.


_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

LordSputnik
In reply to this post by KRSCuan
KRSCuan wrote
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.
ISRCs should remain on the recording level, no matter what. They're simply too badly regulated and subjectively assigned for us to reliably attach them to anything else.

AcoustIDs generally can't distinguish between different masters anyway, so the recording is the correct place for those.

The other information you refer to should not have been lost. The recording guidelines make provisions for storing mastering information in all cases (release-level for mastering of while releases, release annotation for separately mastered tracks), until we decide on a better system.

If it's the case that different mastering per-track is very rare, and people have no real need for an alternative, then I have no problem keeping the current system, where the release is also essentially the master entity.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
In reply to this post by KRSCuan
2014-09-19 11:07 GMT+02:00 KRSCuan <[hidden email]>:
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
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
In reply to this post by tommycrock
2014-09-19 11:18 GMT+02:00 Tom Crocker <[hidden email]>:

I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album.

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.

Useful to know
 
Maybe we should add a reliability flag, allowing to say: "these sound the same" or "these are the same according to credits".

(Much) more broadly I'd love it if we could introduce a 'source' similar to wikidata, since nothing is certain and is based on stronger or weaker claims...

Ah, yes, I have been hoping for something like this for a long time.

 

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. 

There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...)  on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release.

My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter.
 

More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data.

But, I also think KRSCuan might be right.  We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time.

I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
In reply to this post by LordSputnik
2014-09-19 11:32 GMT+02:00 LordSputnik <[hidden email]>:
KRSCuan wrote
> 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.

ISRCs should remain on the recording level, no matter what. They're simply
too badly regulated and subjectively assigned for us to reliably attach them
to anything else.

AcoustIDs generally can't distinguish between different masters anyway, so
the recording is the correct place for those.

The other information you refer to should not have been lost. The recording
guidelines make provisions for storing mastering information in all cases
(release-level for mastering of while releases, release annotation for
separately mastered tracks), until we decide on a better system.

If it's the case that different mastering per-track is very rare, and people
have no real need for an alternative, then I have no problem keeping the
current system, where the release is also essentially the master entity.

There is one situation where I would really like per-track mastering information data: I sometimes buy tracks from when I was young. Of course I'd like to get the best possible sound, but I still want to recognize the tracks. Some digital remasters are so different that I barely recognize the song (I was particularly thinking of a remaster of Jethro Tull's Locomotive Breath). If MB had Mastering information, I'd have avoided listening to many samples from many compilations to find a correct track. And even if MB hadn't had this data for this recording when I decided to buy it, I could have entered the results of my tests in MB.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

lixobix
Frederic Da Vitoria wrote
2014-09-19 11:32 GMT+02:00 LordSputnik <[hidden email]>:

> KRSCuan wrote
> > 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.
>
> ISRCs should remain on the recording level, no matter what. They're simply
> too badly regulated and subjectively assigned for us to reliably attach
> them
> to anything else.
>
> AcoustIDs generally can't distinguish between different masters anyway, so
> the recording is the correct place for those.
>
> The other information you refer to should not have been lost. The recording
> guidelines make provisions for storing mastering information in all cases
> (release-level for mastering of while releases, release annotation for
> separately mastered tracks), until we decide on a better system.
>
> If it's the case that different mastering per-track is very rare, and
> people
> have no real need for an alternative, then I have no problem keeping the
> current system, where the release is also essentially the master entity.


There is one situation where I would really like per-track mastering
information data: I sometimes buy tracks from when I was young. Of course
I'd like to get the best possible sound, but I still want to recognize the
tracks. Some digital remasters are so different that I barely recognize the
song (I was particularly thinking of a remaster of Jethro Tull's Locomotive
Breath). If MB had Mastering information, I'd have avoided listening to
many samples from many compilations to find a correct track. And even if MB
hadn't had this data for this recording when I decided to buy it, I could
have entered the results of my tests in MB.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
What I'm looking for from the entity is similar, a way to easily see that recordings a, b, and c on release x were mastered n number of times, and those masters were released as tracks on releases y and z.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

symphonick
In reply to this post by Frederic Da Vitoria


2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria <[hidden email]>:
2014-09-19 11:18 GMT+02:00 Tom Crocker <[hidden email]>:

I think it depends what we want to represent and store. My understanding of a master pretty much fits our existing mediums. I also know you can recognise broader remastered albums and notice the same processed version of a song has been used on various compilations, though I've never come across a credit to back that up beyond reissues of the same album.

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.

Useful to know
 
Maybe we should add a reliability flag, allowing to say: "these sound the same" or "these are the same according to credits".

(Much) more broadly I'd love it if we could introduce a 'source' similar to wikidata, since nothing is certain and is based on stronger or weaker claims...

Ah, yes, I have been hoping for something like this for a long time.

 

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. 

There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...)  on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release.

My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter.
 

Percieved sound differences are in practice unusable as proof, unless we are dealing with intended differences; like 1973 version vs. 2010 remaster. But in those cases you would have liner notes or similar anyway.
 

More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data.

But, I also think KRSCuan might be right.  We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time.

I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR.

--
Frederic Da Vitoria
(davitof)


Regarding specific tracks; maybe a (release - release) AR which would show the master engineer @ track level when (if) you know the exact release a specific compilation track was sourced from?

Otherwise some sort of headings inside the release group for specific masters maybe could work? Like:

Release ...
Official
Foo   CD
Foo   Vinyl
*1997 remaster
Foo   CD
*2010 remaster
Foo   CD


& probably leave deafult = unspecified = original. My suggestion would be to have no more detail than this.

/symphonick

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-23 23:31 GMT+02:00 symphonick <[hidden email]>:

2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria <[hidden email]>:

2014-09-19 11:18 GMT+02:00 Tom Crocker <[hidden email]>:

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. 

There are lots of potential sources for tracks on compilations (old vinyl, tapes, masters...) but what do we want to be able to represent? What level of complexity and what fit with reality? Do we care about the vinyl master vs. the CD master? It might be the best solution to enter a mastering credit (mastered by ... on ...)  on a per track basis but if masters are much more like an ordered set of (our type of) recordings it might be best to represent them as such, and see if there's a way within that we can handle complexities like compilations. If that was at a medium level it would work with your suggested release.

My preference would be for sound differences. If the CD sounds exactly like the vinyl (this is not plausible but it should be possible), then I'd expect only one Master in MB. But if the sounds differ, then I expect 2 separate Masters, even if both are on the same medium. Of course, data should be also taken into account. If a mastering engineer recreates exactly the same sound as another master, there should be 2 Masters in MB because there would be 2 Mastering Engineer ARs to enter.
 

Percieved sound differences are in practice unusable as proof, unless we are dealing with intended differences; like 1973 version vs. 2010 remaster. But in those cases you would have liner notes or similar anyway.

Yes, if we are speaking of albums. But in compilations, liner notes are often missing, so that we have to rely on our ears to decide.



More than anything, if we do add something let's make sure it is simple to use and transparent to anyone who doesn't care.

Yes, very important! Users who don't understand what a master is (and furthermore, what MB calls a Master) should not be tempted to enter data.

But, I also think KRSCuan might be right.  We have tons of stuff to fix and millions of releases to add, so I'm not sure adding another potential layer of data that most people won't care about is the best use of our time.

I am not sure either, and I agree there could be more urgent things to develop (like the reliability data you wrote about above). OTOH, the volume of missing releases should not prevent us from improving existing data. Just like the fact that we will certainly never know the names of all the engineers who recorded existing tracks should not induce us to throw away the Recording Engineer AR.



Regarding specific tracks; maybe a (release - release) AR which would show the master engineer @ track level when (if) you know the exact release a specific compilation track was sourced from?

Otherwise some sort of headings inside the release group for specific masters maybe could work? Like:

Release ...
Official
Foo   CD
Foo   Vinyl
*1997 remaster
Foo   CD
*2010 remaster
Foo   CD


& probably leave deafult = unspecified = original. My suggestion would be to have no more detail than this.

There must be something I am missing here: Our developers have created a quite efficient release tracks editor which enables us to enter ARs for all the tracks at the same time with almost no more work than entering a release level AR. So why not enable something similar for masters (if / when then are implemented)?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

lixobix
Frederic Da Vitoria wrote
There must be something I am missing here: Our developers have created a
quite efficient release tracks editor which enables us to enter ARs for all
the tracks at the same time with almost no more work than entering a
release level AR. So why not enable something similar for masters (if /
when then are implemented)?
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
I think the issue is that whilst there is a strong argument that master should link recordings and tracks, there is also a strong desire to display the information at release level, so that one can easily see that releases a,b, and c use x masters of the recordings, whilst releases d, e, and f use y masters.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-24 13:54 GMT+02:00 lixobix <[hidden email]>:
Frederic Da Vitoria wrote
> There must be something I am missing here: Our developers have created a
> quite efficient release tracks editor which enables us to enter ARs for
> all
> the tracks at the same time with almost no more work than entering a
> release level AR. So why not enable something similar for masters (if /
> when then are implemented)?

> MusicBrainz-style@.musicbrainz

> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

I think the issue is that whilst there is a strong argument that master
should link recordings and tracks, there is also a strong desire to display
the information at release level, so that one can easily see that releases
a,b, and c use x masters of the recordings, whilst releases d, e, and f use
y masters.

Ah, I see. Couldn't the release-level master info be computed dynamically from track-level? I mean, of course it technically could, but would it cost too much in terms of overhead?

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
12