Master and Performance entities

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

Re: Master and Performance entities

symphonick


2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria <[hidden email]>:
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)

 
Now you got me worried; it's already quite hard to find the exact recording you want when there are lots of similar recordings to choose from. How would the master-info be shown in the search boxes?

/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-24 23:50 GMT+02:00 symphonick <[hidden email]>:
2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria <[hidden email]>:
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)?
 
Now you got me worried; it's already quite hard to find the exact recording you want when there are lots of similar recordings to choose from. How would the master-info be shown in the search boxes? 

You are right, I don't see a good answer to this question. Sometimes ARs would give the clue (mastering engineer, of course), but we won't always have this data, and sometimes the mastering engineer could be misleading. And of course a good data structure without an UI is useless.

I still think that it would be nice to be able one day to go to Track level, and the design for Release level should IMO be made in such a way that we will be able to switch to Release level without losing data.

As long as we limit ourselves to Release level masters, I think that users should not enter masters for track compilations (except for re-masters of compilations).

--
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-24 23:50 GMT+02:00 symphonick <[hidden email]>:

> 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria <[hidden email]>:
>
>> 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)?
>>
>
> Now you got me worried; it's already quite hard to find the exact
> recording you want when there are lots of similar recordings to choose
> from. How would the master-info be shown in the search boxes?
>

You are right, I don't see a good answer to this question. Sometimes ARs
would give the clue (mastering engineer, of course), but we won't always
have this data, and sometimes the mastering engineer could be misleading.
And of course a good data structure without an UI is useless.

I still think that it would be nice to be able one day to go to Track
level, and the design for Release level should IMO be made in such a way
that we will be able to switch to Release level without losing data.

As long as we limit ourselves to Release level masters, I think that users
should not enter masters for track compilations (except for re-masters of
compilations).

--
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
Back to the fundamental question: should the master entity link to releases, or to recordings and / or tracks? I'm uncertain as to what your position is at present.
Reply | Threaded
Open this post in threaded view
|

Re: Master and Performance entities

Frederic Da Vitoria
2014-09-25 12:45 GMT+02:00 lixobix <[hidden email]>:
Frederic Da Vitoria wrote
> 2014-09-24 23:50 GMT+02:00 symphonick &lt;

> symphonick@

> &gt;:
>
>> 2014-09-24 7:54 GMT+02:00 Frederic Da Vitoria &lt;

> davitofrg@

> &gt;:
>>
>>> 2014-09-23 23:31 GMT+02:00 symphonick &lt;

> symphonick@

> &gt;:
>>>
>>>> 2014-09-19 11:34 GMT+02:00 Frederic Da Vitoria &lt;

> davitofrg@

> &gt;:
>>>>
>>>>> 2014-09-19 11:18 GMT+02:00 Tom Crocker &lt;

> tomcrockermail@

> &gt;:
>>>>>
>>>>>> 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)?
>>>
>>
>> Now you got me worried; it's already quite hard to find the exact
>> recording you want when there are lots of similar recordings to choose
>> from. How would the master-info be shown in the search boxes?
>>
>
> You are right, I don't see a good answer to this question. Sometimes ARs
> would give the clue (mastering engineer, of course), but we won't always
> have this data, and sometimes the mastering engineer could be misleading.
> And of course a good data structure without an UI is useless.
>
> I still think that it would be nice to be able one day to go to Track
> level, and the design for Release level should IMO be made in such a way
> that we will be able to switch to Release level without losing data.
>
> As long as we limit ourselves to Release level masters, I think that users
> should not enter masters for track compilations (except for re-masters of
> compilations).

Back to the fundamental question: should the master entity link to releases,
or to recordings and / or tracks? I'm uncertain as to what your position is
at present.

I'd prefer track level, but I can't imagine how some points of the UI would work. How do we disambiguate masters at record level? How do we populate pick lists for track masters so that their contents are are meaningful? Once we are able to answer those questions, I'll happily turn back to track level masters. Until then, I must reluctantly content myself with release level masters.

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

tommycrock


On 25 September 2014 12:18, Frederic Da Vitoria <[hidden email]> wrote:

2014-09-25 12:45 GMT+02:00 lixobix <[hidden email]>:
Back to the fundamental question: should the master entity link to releases,
or to recordings and / or tracks? I'm uncertain as to what your position is
at present.

I'd prefer track level, but I can't imagine how some points of the UI would work. How do we disambiguate masters at record level? How do we populate pick lists for track masters so that their contents are are meaningful? Once we are able to answer those questions, I'll happily turn back to track level masters. Until then, I must reluctantly content myself with release level masters.

Because mastering is a lot to do with the set of recordings (sequence, gaps, relative qualities between tracks) and that set should have one name and one credit, I'd prefer something that can achieve that, if possible. If it can also handle compilations of different tracks from different masters, great.

I'm not sure if there's a way this could be done that doesn't risk data integrity, and/or made user-friendly but here's the possible bones of a solution. A master is an ordered set of recordings (IDs only, data can come from the recordings). The master could be named and have a few ARs, maybe other properties. Tracks in releases link to recordings as now. They can optionally also be linked to a master that is associated with the recording they are linked to (or the master-recording). In UI terms this could be chosen per medium or per track. Masters could also be created from existing tracklists.

_______________________________________________
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
tommycrock wrote
On 25 September 2014 12:18, Frederic Da Vitoria <[hidden email]> wrote:

>
> 2014-09-25 12:45 GMT+02:00 lixobix <[hidden email]>:
>
>> Back to the fundamental question: should the master entity link to
>> releases,
>> or to recordings and / or tracks? I'm uncertain as to what your position
>> is
>> at present.
>>
>
> I'd prefer track level, but I can't imagine how some points of the UI
> would work. How do we disambiguate masters at record level? How do we
> populate pick lists for track masters so that their contents are are
> meaningful? Once we are able to answer those questions, I'll happily turn
> back to track level masters. Until then, I must reluctantly content myself
> with release level masters.
>

Because mastering is a lot to do with the set of recordings (sequence,
gaps, relative qualities between tracks) and that set should have one name
and one credit, I'd prefer something that can achieve that, if possible. If
it can also handle compilations of different tracks from different masters,
great.

I'm not sure if there's a way this could be done that doesn't risk data
integrity, and/or made user-friendly but here's the possible bones of a
solution. A master is an ordered set of recordings (IDs only, data can come
from the recordings). The master could be named and have a few ARs, maybe
other properties. Tracks in releases link to recordings as now. They can
optionally also be linked to a master that is associated with the recording
they are linked to (or the master-recording). In UI terms this could be
chosen per medium or per track. Masters could also be created from existing
tracklists.

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
That's the kind of approach I was thinking of.
12