Results of the Recordings IRC meetings

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

Results of the Recordings IRC meetings

Nicolás Tamargo de Eguren-2
One of the unresolved loose ends from NGS is the definition of a recording (or rather, the fact that recordings were ill-defined entities floating in a level between master and mix, with different people thinking of them as different things). During two long IRC meetings in the past weeks, we reached the following decisions on how to advance on this issue:

Recordings are to be understood as existing at the mix level, not the master level. Recordings which represent the same mix should thus be merged, regardless of how they are mastered. If what's labeled as a "remaster" is different enough to be seen as a new mix, it should stay separate - what counts as different enough should be decided by editors on a case by case basis. Obviously this will mean the current recording guidelines will need to change somewhat to adapt to recordings actually having a clear meaning.

A mix is generally a combination of several independently-recorded tracks into unified audio, although from a MusicBrainz point of view other major edits will also call for new recordings. (We could probably use a better definition, so if someone wants to suggest a great definition of a mix and can get people to agree, that'd be sweet!).

Mastering relationships should be added at the release level. The ones which are now at the recording level should be moved up to the release level. If the same relationship doesn't apply to all tracks on the release, the information should be added to the release annotation, as specifically as possible.

A new master-level entity will probably be added at some point in the future as part of an advanced interface, which will mean its use will be optional - people who aren't interested in dealing with this level won't have to. If and when this happens, annotated master relationships can be moved into these masters.

While the general direction of recording=mix seems clear and unlikely to change, it'd be great to have suggestions on how to better define what a mix/recording is in MB (apart from "a recording is a mix and a mix is a mix"), how to deal with ISRCs, and comments on other possible problems we might not have thought of yet.

It would also be good to hear from Lukas on how this would affect acoustID.

A third meeting to talk about any issues that come up here and try to get this discussion to its conclusion will take place in a couple weeks - once the date is confirmed I'll post it to the list.

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

Re: Results of the Recordings IRC meetings

jacobbrett
I’ll repost what I wrote on the dev list (as I was absent):

jacobbrett wrote
http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097

20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS stuff -- I think that 10 years of data is rather more important than the bit since NGS release tbh” [1]

I’m super‐late to the party, though what is the problem (besides dev. time and increased database complexity) of implementing Master entities, if we default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the API/UI by default. I still back my prototype: https://wiki.musicbrainz.org/User:Jacobbrett/Recordings

This is directed towards nikki, etc.’s proposal: One argument I have against relying on master relationships at release level is that a mastered track may appear identical on two releases (more likely bit‐identical on digital releases, especially), yet the masterer is not known for either of the two releases. Even if the masterer was known for those tracks on those two releases and the masterer was the same person, how can we represent whether the tracks are identical masters? At least, with Master entities, we can say definitely that those tracks on those two releases are the same master (after analysing the waveforms somehow).

Due to the above, if it is decided to implement Master entities, I’d prefer to redefine the definition of existing entities (Recordings) with the implementation of the former—I’m not convinced automatically moving masterer relationships to Release level is a good idea in all cases (or necessarily at all).

[1] http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731
Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

--
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: Results of the Recordings IRC meetings

onasis

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

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

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

Onasis

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

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

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

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

If I understand correctly what you are saying, you suggest to kepp Master X. But where would be stored Remaster X and Edit X? If we don't store them somewhere, we will have to duplicate all specific ARs for Remaster X on Release C and D and all specific ARs for Edit X on Releases E and F. How do you solve this?

--
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: Results of the Recordings IRC meetings

onasis
2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

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

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

If I understand correctly what you are saying, you suggest to kepp Master X. But where would be stored Remaster X and Edit X? If we don't store them somewhere, we will have to duplicate all specific ARs for Remaster X on Release C and D and all specific ARs for Edit X on Releases E and F. How do you solve this?


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


Scheme would be:

1. General Recording (stores general information like performers, engineers etc & date of these ARs)
    1.1. Version of Recording that appears on some Release. When you add this version you can enter additional information like Remaster or Edit. (stores information like Remastering engineer, Editor & date of these ARs).

Versions information will be stored on General Recordings sub-folder for respective version.
So, when you add Release you should choose (from drop-down list) which Recordings appears on it (Original Master, Edit X, Remaster X, "Unknown Version" or add "New Version").

I would suggest to keep merged all "Unknown Version" since there is no data to keep them split. In this case "Unknown Version" won't be able to contain "Main Lenght" since it will be variable on each of the Releases.

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

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
2013/1/25 Edgars Ducens <[hidden email]>
2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

If I understand correctly what you are saying, you suggest to kepp Master X. But where would be stored Remaster X and Edit X? If we don't store them somewhere, we will have to duplicate all specific ARs for Remaster X on Release C and D and all specific ARs for Edit X on Releases E and F. How do you solve this?


Scheme would be:

1. General Recording (stores general information like performers, engineers etc & date of these ARs)
    1.1. Version of Recording that appears on some Release. When you add this version you can enter additional information like Remaster or Edit. (stores information like Remastering engineer, Editor & date of these ARs).

Versions information will be stored on General Recordings sub-folder for respective version.
So, when you add Release you should choose (from drop-down list) which Recordings appears on it (Original Master, Edit X, Remaster X, "Unknown Version" or add "New Version").

I would suggest to keep merged all "Unknown Version" since there is no data to keep them split. In this case "Unknown Version" won't be able to contain "Main Lenght" since it will be variable on each of the Releases.

You are forgetting the mix level. How do you identify an "original master"? Currently very few tracks are made from one recording only. Most are collages of several individual recordings. Whole parts seamlessly appear or disappear in different versions of the same track while the sound is preserved. Maybe sometimes tracks with same duration have just a few instruments more or less and most listeners don't notice. This happens obviously in all kinds of music. I guess even live tracks are sometimes reconstructed from various takes. 50 years ago, when we bought records, we often got almost non-edited copies of the original recording session. Now, we very seldom buy copies of the original recordings as the artists performed them. In a way, we should probably ban the word "recording" entirely, the audio we get are fakes designed to sound like originals. Only sound engineers manipulate true recordings these days.

--
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: Results of the Recordings IRC meetings

onasis


2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>
2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

If I understand correctly what you are saying, you suggest to kepp Master X. But where would be stored Remaster X and Edit X? If we don't store them somewhere, we will have to duplicate all specific ARs for Remaster X on Release C and D and all specific ARs for Edit X on Releases E and F. How do you solve this?


Scheme would be:

1. General Recording (stores general information like performers, engineers etc & date of these ARs)
    1.1. Version of Recording that appears on some Release. When you add this version you can enter additional information like Remaster or Edit. (stores information like Remastering engineer, Editor & date of these ARs).

Versions information will be stored on General Recordings sub-folder for respective version.
So, when you add Release you should choose (from drop-down list) which Recordings appears on it (Original Master, Edit X, Remaster X, "Unknown Version" or add "New Version").

I would suggest to keep merged all "Unknown Version" since there is no data to keep them split. In this case "Unknown Version" won't be able to contain "Main Lenght" since it will be variable on each of the Releases.

You are forgetting the mix level. How do you identify an "original master"? Currently very few tracks are made from one recording only. Most are collages of several individual recordings. Whole parts seamlessly appear or disappear in different versions of the same track while the sound is preserved. Maybe sometimes tracks with same duration have just a few instruments more or less and most listeners don't notice. This happens obviously in all kinds of music. I guess even live tracks are sometimes reconstructed from various takes. 50 years ago, when we bought records, we often got almost non-edited copies of the original recording session. Now, we very seldom buy copies of the original recordings as the artists performed them. In a way, we should probably ban the word "recording" entirely, the audio we get are fakes designed to sound like originals. Only sound engineers manipulate true recordings these days.


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

Lets call thing this way:
Recording - Unit that makes Release (Album, Single, EP etc)
Track - Unit that makes Recording (Vocal Track X, Guitar Track X etc)

You are complicating things. Ok call it "Imaginary Original Master" or we don't even need such. Still we can merge all "equal" Recordings under one General Recording unless they are credited as "Alternate Mix", "Alternate Edit", "Alternate Version" or something like that. There are much more benefits in merging than keeping them on their own, unless you want to disable merging at all, becuse we can't merge any single Recording according to your view that any of them are unique till we can't prove othervise (and to do that we need access to Engineering studio and all information about any edit that is done with this Recording).
If the Recording have been put through such "gross" edits like cut down by few instruments or vocal parts, mostly it is credited on Release. You should agree such editings are job that engineers would like to be credited for since they like to get some profit of them. World class engineers aren't just anonym clerks.

All these "Minor" Mixes (unles they are credited Alternate or any other way as we can consider "Major") also could be stored under "General Recording". All such edits can be stored under every new Version of this Recording users discover.

As "General Recording" I would prefer first "Album Version" or first "Single / EP Version". But even this isn't necessary. We just need something like "Work level" for Recordings to be collected under. Instead of writting stuff there would be all the performing/recording/producing etc stuff.

Anyway such scheme would be much more better than this is now with NSG ans slippy Guidelines, where we can merge and split recordings as we like. And as you can see mostly all of "Unknown Version" with similar lenght are merged just because of lenght. That's rality.

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

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>
2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 Edgars Ducens <[hidden email]>

2013/1/25 Frederic Da Vitoria <[hidden email]>
2013/1/25 jacobbrett <[hidden email]>
I’ll repost  what I wrote on the dev list
<http://musicbrainz.1054305.n4.nabble.com/Recordings-Masters-mb-dev-discussion-2012-01-23-td4647103.html>
(as I was absent):

jacobbrett wrote
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-29-21-549097
>
> 20:49:40 ianmcorvidae: “that merge guideline does ignore all the pre-NGS
> stuff -- I think that 10 years of data is rather more important than the
> bit since NGS release tbh” [1]
>
> I’m super‐late to the party, though what is the problem (besides dev. time
> and increased database complexity) of implementing Master entities, if we
> default to “catch‐alls”? Also, I’m assuming Masters are not exposed in the
> API/UI by default. I still back my prototype:
> https://wiki.musicbrainz.org/User:Jacobbrett/Recordings
>
> This is directed towards nikki, etc.’s proposal: One argument I have
> against relying on master relationships at release level is that a
> mastered track may appear identical on two releases (more likely
> bit‐identical on digital releases, especially), yet the masterer is not
> known for either of the two releases. Even if the masterer was known for
> those tracks on those two releases and the masterer was the same person,
> how can we represent whether the tracks are identical masters? At least,
> with Master entities, we can say definitely that those tracks on those two
> releases are the same master (after analysing the waveforms somehow).
>
> Due to the above, if it is decided to implement Master entities, I’d
> prefer to redefine the definition of existing entities (Recordings) with
> the implementation of the former—I’m not convinced automatically moving
> masterer relationships to Release level is a good idea in all cases (or
> necessarily at all).
>
> [1]
> http://chatlogs.musicbrainz.org/musicbrainz-devel/2013/2013-01/2013-01-23.html#T20-49-40-727731

I understand what you are saying, but I don't think the current situation is better. Actually, I believe the current situation is worse because the word "Recording" suggests to some editors to merge Recordings which are completely different masters/transfers (sometimes separated by 20 years). So what do you suggest?

Hi!

I suggest quite different scheme. I would prefer merging all the recordings if they are from the same source origin (original master). This means that we should merge all versions (remasters, analog, digital etc edits) of this recording in one recording but keep them separate by introduction filters. In such case all the information about individual version of Recording will be linked only to release on which this recording appears and we will be able to filter on which release recording with such parameters appears:
For example
Master X appears on Release A, Release B, etc.
Remaster X appears on Release C, Release D
Edit X appears on Release E, Release F......
But the general information of Recording, like who performed on it, recorded, did general mastering, mixing etc. stays linked to Recording and most important benefit would be that all this general information will be linked to all the versions of this Recording and we don't need to add each performer to every version manually.

There is no need to keep bunch of recording because of different remasters & edits that are made in past, it makes them hard
to look through.

P.S. such filters can be usefull also for Artists, Releases, Works etc.

If I understand correctly what you are saying, you suggest to kepp Master X. But where would be stored Remaster X and Edit X? If we don't store them somewhere, we will have to duplicate all specific ARs for Remaster X on Release C and D and all specific ARs for Edit X on Releases E and F. How do you solve this?


Scheme would be:

1. General Recording (stores general information like performers, engineers etc & date of these ARs)
    1.1. Version of Recording that appears on some Release. When you add this version you can enter additional information like Remaster or Edit. (stores information like Remastering engineer, Editor & date of these ARs).

Versions information will be stored on General Recordings sub-folder for respective version.
So, when you add Release you should choose (from drop-down list) which Recordings appears on it (Original Master, Edit X, Remaster X, "Unknown Version" or add "New Version").

I would suggest to keep merged all "Unknown Version" since there is no data to keep them split. In this case "Unknown Version" won't be able to contain "Main Lenght" since it will be variable on each of the Releases.

You are forgetting the mix level. How do you identify an "original master"? Currently very few tracks are made from one recording only. Most are collages of several individual recordings. Whole parts seamlessly appear or disappear in different versions of the same track while the sound is preserved. Maybe sometimes tracks with same duration have just a few instruments more or less and most listeners don't notice. This happens obviously in all kinds of music. I guess even live tracks are sometimes reconstructed from various takes. 50 years ago, when we bought records, we often got almost non-edited copies of the original recording session. Now, we very seldom buy copies of the original recordings as the artists performed them. In a way, we should probably ban the word "recording" entirely, the audio we get are fakes designed to sound like originals. Only sound engineers manipulate true recordings these days.

Lets call thing this way:
Recording - Unit that makes Release (Album, Single, EP etc)
Track - Unit that makes Recording (Vocal Track X, Guitar Track X etc)

You are complicating things. Ok call it "Imaginary Original Master" or we don't even need such. Still we can merge all "equal" Recordings under one General Recording unless they are credited as "Alternate Mix", "Alternate Edit", "Alternate Version" or something like that. There are much more benefits in merging than keeping them on their own, unless you want to disable merging at all, becuse we can't merge any single Recording according to your view that any of them are unique till we can't prove othervise (and to do that we need access to Engineering studio and all information about any edit that is done with this Recording).
If the Recording have been put through such "gross" edits like cut down by few instruments or vocal parts, mostly it is credited on Release. You should agree such editings are job that engineers would like to be credited for since they like to get some profit of them. World class engineers aren't just anonym clerks.

I don't think I am complicating things. I am only taking the complex reality into account. How releases are made is not going to become more manageable only because MB doesn't want to take it's complexity into account ;-)

I agree that engineers would probably like to be credited. But they are not always. Can you find the name of any vinyl-to-CD transfer before 1990? Those transfers were probably made by engineers, but their names are mostly lost. And that's a pity because old transfers are often better than "digital remasters" IMO.


All these "Minor" Mixes (unles they are credited Alternate or any other way as we can consider "Major") also could be stored under "General Recording". All such edits can be stored under every new Version of this Recording users discover. 

As "General Recording" I would prefer first "Album Version" or first "Single / EP Version". But even this isn't necessary. We just need something like "Work level" for Recordings to be collected under. Instead of writting stuff there would be all the performing/recording/producing etc stuff.

Yes, I agree that an abstract, catchall level would be very useful. But the "mix" level suggested here could give us this. I believe "'mix" is a better word than "recording". Recording was a bad choice of words and part of the current situation comes from that bad choice. Some users took "Recording" at face value and edited accordingly. I even think replacing Recording with Mix in the documentation might be a good idea.

 
Anyway such scheme would be much more better than this is now with NSG ans slippy Guidelines, where we can merge and split recordings as we like. And as you can see mostly all of "Unknown Version" with similar lenght are merged just because of lenght. That's rality.

I know :-(

--
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: Results of the Recordings IRC meetings

Lukáš Lalinský
In reply to this post by Nicolás Tamargo de Eguren-2
On Fri, Jan 25, 2013 at 1:14 AM, Nicolás Tamargo de Eguren
<[hidden email]> wrote:
> It would also be good to hear from Lukas on how this would affect acoustID.

I don't have much to say about this. I'm sure there will be an obvious
solution once there is a plan now to migrate the existing MB data.
Most likely it's that AcoustIDs will be at the equivalent of the
current level or lower (closed to releases), unless somebody will have
a better idea once it's clear what's going to change.

A better question is what will happen with the current recording MBIDs?

Lukas

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

Re: Results of the Recordings IRC meetings

LordSputnik
Just so you know, there are no schema changes planned for recordings. The only thing changing in the schema due to this at the moment will be tracks getting track ids at some point soon.

So recording mbids will stay valid, since recordings will still be around - we're just redefining the existing recordings entity in the style guidelines as a mix.

This will mean though that a lot more merging will go on between recordings, partly because they're properly defined now, and secondly because there's no longer a requirement for "unique audio", just "same mix".

This has the unfortunate side effect that when people merge a group of recordings together, all of the attached AcoustIDs will get linked to the resulting merged recording, which may not be what you want to happen there.

I'd personally hope that AcoustIDs could be linked to track IDs - where a recording only appears on one release, this should be fairly easy to do. Then if there's a need we can also display AcoustIDs at the mix level, by checking the AcoustID links for tracks using that mix.
Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

LordSputnik
In reply to this post by onasis
It seems what you're basically describing is that we should add a "Performance" entity above a "Master" entity.

I originally thought this too, but then came across this problem:

"How would you deal with cases where not all of the performer relationships on a general recording apply to sub-recordings?"

That's why we're using Mixes, not Performances. By using mixes, we do have to add identical relationships to several entities in some cases, but we have the ability to include different sets of relationships on different mixes.


Also note that we were trying to keep schema changes to a minimum when solving the problem. :)
Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

onasis
In reply to this post by LordSputnik

2013/1/25 LordSputnik <[hidden email]>
Just so you know, there are no schema changes planned for recordings. The
only thing changing in the schema due to this at the moment will be tracks
getting track ids at some point soon.

So recording mbids will stay valid, since recordings will still be around -
we're just redefining the existing recordings entity in the style guidelines
as a mix.

This will mean though that a lot more merging will go on between recordings,
partly because they're properly defined now, and secondly because there's no
longer a requirement for "unique audio", just "same mix".

This has the unfortunate side effect that when people merge a group of
recordings together, all of the attached AcoustIDs will get linked to the
resulting merged recording, which may not be what you want to happen there.

I'd personally hope that AcoustIDs could be linked to track IDs - where a
recording only appears on one release, this should be fairly easy to do.
Then if there's a need we can also display AcoustIDs at the mix level, by
checking the AcoustID links for tracks using that mix.




--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/Results-of-the-Recordings-IRC-meetings-tp4647181p4647270.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.

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


This will mean though that a lot more merging will go on between recordings,
partly because they're properly defined now, and secondly because there's no
longer a requirement for "unique audio", just "same mix".

So, according to new guidelines all Remasters, Digital, Analog etc. Edits will be merged?
Then what about ARs that are unique for these Edits, like remastering, digitizing etc. engineers, editors, producers? Will they be linked to one "Mix" as all other Artists? What abour dates when these Edits were done?


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

Re: Results of the Recordings IRC meetings

LordSputnik
Yes that's right. Analog/Digital was never distinguished anyway in the guidelines - too much work. Remasters should only be split if they change the audio enough for it to be considered a new mix.

As reo said in the original email, all of those ARs will be either moved to the correct release(s), or added as annotations to those releases where there are variations among the tracks.



Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

Lukáš Lalinský
In reply to this post by LordSputnik
On Fri, Jan 25, 2013 at 6:09 PM, LordSputnik <[hidden email]> wrote:

> Just so you know, there are no schema changes planned for recordings. The
> only thing changing in the schema due to this at the moment will be tracks
> getting track ids at some point soon.
>
> So recording mbids will stay valid, since recordings will still be around -
> we're just redefining the existing recordings entity in the style guidelines
> as a mix.
>
> This will mean though that a lot more merging will go on between recordings,
> partly because they're properly defined now, and secondly because there's no
> longer a requirement for "unique audio", just "same mix".
>
> This has the unfortunate side effect that when people merge a group of
> recordings together, all of the attached AcoustIDs will get linked to the
> resulting merged recording, which may not be what you want to happen there.
>
> I'd personally hope that AcoustIDs could be linked to track IDs - where a
> recording only appears on one release, this should be fairly easy to do.
> Then if there's a need we can also display AcoustIDs at the mix level, by
> checking the AcoustID links for tracks using that mix.

Well, I hope this change would have track MBIDs as a prerequisite. I
don't see how we can change the definition without having a lower
level entity that can be used by 3rd party databases.

As I said, AcoustIDs should be at the current level ("unique audio")
or lower ("tracks"). So if we are changing the definition of
recordings to make it more broad, they will be moved to tracks, but
for that we need track IDs first.

Lukas

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

Re: Results of the Recordings IRC meetings

onasis
In reply to this post by LordSputnik


2013/1/25 LordSputnik <[hidden email]>
Yes that's right. Analog/Digital was never distinguished anyway in the
guidelines - too much work. Remasters should only be split if they change
the audio enough for it to be considered a new mix.

As reo said in the original email, all of those ARs will be either moved to
the correct release(s), or added as annotations to those releases where
there are variations among the tracks.

If I understand correctly, these ARs will be transfered from "Recording/Mix" level to Release level (that means no matter if he engineered whole Release or only few "Recordings/Mixes") or deleted (moved back to stone age - annotations).

P.S. where can I see new "Mix" definition?



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

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
In reply to this post by LordSputnik
2013/1/25 LordSputnik <[hidden email]>
Yes that's right. Analog/Digital was never distinguished anyway in the
guidelines - too much work. Remasters should only be split if they change
the audio enough for it to be considered a new mix.

As reo said in the original email, all of those ARs will be either moved to
the correct release(s), or added as annotations to those releases where
there are variations among the tracks.

How should we handle all those "Digitally remastered" releases with named remastering engineers? Some of them are more than 10 years old and are getting re-issued themselves. Are we to enter one AR for each new reissue?

--
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: Results of the Recordings IRC meetings

LordSputnik
Sorry, I'm not sure I understand how your question relates to the discussion? Maybe rephrase it..?

As far as I know remastering engineers would go on releases, and the release would be disambiguated as a remaster, just as it is currently.
Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

LordSputnik
In reply to this post by onasis
If, using your example, the engineer didn't engineer all the tracks on the release, that'd go in annotations too.

I agree using annotations isn't the ideal solution, but the problem is developer time needed to get a more sophisticated system.

Also, we haven't got a clear definition on Mix yet, I think we're open to suggestions on that though. We'll probably need another meeting to discuss that.

Currently have these suggestions:
* "A mix is the result of editing an audio recording"
* "A mix is an edited performance of a work"
* "A mix is structurally unique audio" (where structural refers to things like whether certain tracks are audible (eg. vocals), the number of channels in the final audio, the number of verses and choruses there are)
Reply | Threaded
Open this post in threaded view
|

Re: Results of the Recordings IRC meetings

Frederic Da Vitoria
In reply to this post by LordSputnik
2013/1/25 LordSputnik <[hidden email]>
Sorry, I'm not sure I understand how your question relates to the discussion?
Maybe rephrase it..?

As far as I know remastering engineers would go on releases, and the release
would be disambiguated as a remaster, just as it is currently.

It seems your mail client removed all the message your were answering to, so that I am not quite sure your question is addressed to me, but I'll assume so.

About 10 years ago, majors started issuing "digitally enhanced" re-Releases (I mean albums). Those re-issues mention the names of the engineers who made those new masters. So we are supposed to enter those engineers into MB. Those digitally-enhanced re-releases are re-issued, either as economic releases or as special releases with bonus tracks. So that for those albums (I am thinking of albums from Supertramp, the Who, Yes, Pink Floyd...) all releases currently available are "digitally enhanced". So this means that all those re-issues should mention the remastering engineers. Are we supposed to enter those ARs for each new release? Or even worse enter them as comments on each new re-release?

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