RFC: Add date fields usage to the Performance AR guidelines

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

RFC: Add date fields usage to the Performance AR guidelines

ChurruKa
This is a trivial RFC for changing the guidelines of the Recording<->Work performance AR so it encourages people to add the performance dates of live recordings when that information is available: http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates 

I would like to hear your thoughts about it (especially about the "end date": using the same date as the start date seemed obvious to me, but maybe other people would like to keep it blank, "guess" if the performance started a little before midnight and ended at 0:01, etc).

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

Re: RFC: Add date fields usage to the Performance AR guidelines

Frederic Da Vitoria
2011/7/10 ChurruKa <[hidden email]>
This is a trivial RFC for changing the guidelines of the Recording<->Work performance AR so it encourages people to add the performance dates of live recordings when that information is available: http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates 

I would like to hear your thoughts about it (especially about the "end date": using the same date as the start date seemed obvious to me, but maybe other people would like to keep it blank, "guess" if the performance started a little before midnight and ended at 0:01, etc).

I disagree about the end date rule: I can easily imagine a release which states that the tracks were recorded between two dates but does not indicate which track was recorded when. Also, it is quite possible that a track is actually a mix of two separate live recordings from the same series of concerts.

--
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: RFC: Add date fields usage to the Performance AR guidelines

Aurélien Mino-2
In reply to this post by ChurruKa
On 07/10/2011 04:46 PM, ChurruKa wrote:

> This is a trivial RFC for changing the guidelines of the
> Recording<->Work performance AR so it encourages people to add the
> performance dates of live recordings when that information is
> available:
> http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates
>
> I would like to hear your thoughts about it (especially about the "end
> date": using the same date as the start date seemed obvious to me, but
> maybe other people would like to keep it blank, "guess" if the
> performance started a little before midnight and ended at 0:01, etc).
>

I don't understand what you're trying to achieve:

"start date":
For live performances with a known date this indicates the start date of
the performance.

This is true for any performance, not only live ones.

- Aurélien

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

Re: RFC: Add date fields usage to the Performance AR guidelines

Nicolás Tamargo de Eguren
On Mon, Jul 11, 2011 at 9:22 AM, Aurélien Mino <[hidden email]> wrote:

> On 07/10/2011 04:46 PM, ChurruKa wrote:
>> This is a trivial RFC for changing the guidelines of the
>> Recording<->Work performance AR so it encourages people to add the
>> performance dates of live recordings when that information is
>> available:
>> http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates
>>
>> I would like to hear your thoughts about it (especially about the "end
>> date": using the same date as the start date seemed obvious to me, but
>> maybe other people would like to keep it blank, "guess" if the
>> performance started a little before midnight and ended at 0:01, etc).
>>
>
> I don't understand what you're trying to achieve:
>
> "start date":
> For live performances with a known date this indicates the start date of
> the performance.
>
> This is true for any performance, not only live ones.

Is there any guideline for how to use dates in "performance of",
though? I imagine his point was that while it's quite common for
studio recordings to be recorded in pieces over time, live
performances tend to be recorded all together in one day, so the dates
would be more useful there.

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



--
Nicolás Tamargo de Eguren

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

Re: RFC: Add date fields usage to the Performance AR guidelines

ChurruKa
In reply to this post by ChurruKa
@murdos yes, "this is true" for all recordings, but is easier to know performance dates for live tracks. I also this is useful, given a recording artist/ac and the performance date it should be easy to get information about the convert where it was performed. I'll talk about the case I'm most familiar with: a website (last.fm etc) could parse the date+artist(s) from the ACs and show info about the event (their event page for the event, flickr images via their eventID using "lastfm:event=XXXX" machine tags, link to setlist.fm to get the full setlist for the performance, etc). Other uses could be showing a list of events when a particular work has been played and recorded (via work->recording ARs), etc

There should be more useful usages, these are just the ones I can think about at the moment.

Ideally the start/end date fields could be filled for any recording, but I think the only cases when we can be sure about the dates is on live ones (for studio recordings the dates would be only a guess, and I don't think they would be as useful as on the live ones....)

2011/7/10 ChurruKa <[hidden email]>
This is a trivial RFC for changing the guidelines of the Recording<->Work performance AR so it encourages people to add the performance dates of live recordings when that information is available: http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates 

I would like to hear your thoughts about it (especially about the "end date": using the same date as the start date seemed obvious to me, but maybe other people would like to keep it blank, "guess" if the performance started a little before midnight and ended at 0:01, etc).


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

Re: RFC: Add date fields usage to the Performance AR guidelines

Alex Mauer
On 07/11/2011 03:33 PM, ChurruKa wrote:
> Ideally the start/end date fields could be filled for any recording, but I
> think the only cases when we can be sure about the dates is on live ones
> (for studio recordings the dates would be only a guess, and I don't think
> they would be as useful as on the live ones....)

Actually, it’s pretty feasible for a fair amount of the studio
recordings out there too, with appropriate research.

e.g. this book[1] has a lot of information about recording dates.  There
are also books focusing on particular record labels.

http://books.google.com/books?id=MyfObhq6b-oC&lpg=PP1&pg=PP1#v=onepage&q&f=false



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

Re: RFC: Add date fields usage to the Performance AR guidelines

ChurruKa
Should I edit the proposal to remove the live part of "for live performances" from http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates and let use the performance dates for any recordings when the performance (AKA recording) dates are konwn? If so, I think we should either:

- "Allow" only *full* dates when valid proof is available.
- "Allow" partial dates, for example, if a band entered the studio, say, on January 2010 and released the album on April 2010 enter ARs as "<Recording> is a performance of <Work> from YYYY-MM to YYYY-MM". I personally dislike this option (IMO it would be better to "allow" partial dates on the Release/RG level only).

As on my original proposal, I think we should keep the start_date=end_date for live recordings.

I'll check back tomorrow for more comments about this, and I'll probably edit the proposal wiki page to reflect any changes risen from the discussion here.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

Alex Mauer
On 07/11/2011 05:01 PM, ChurruKa wrote:
> Should I edit the proposal to remove the live part of "for live performances"
> from
> http://wiki.musicbrainz.org/Proposal:Live_Performance_Relationship_Dates and
> let use the performance dates for any recordings when the performance (AKA
> recording) dates are konwn? If so, I think we should either:

I think so.

> - "Allow" only *full* dates when valid proof is available.
> - "Allow" partial dates, for example, if a band entered the studio, say, on
> January 2010 and released the album on April 2010 enter ARs as "<Recording>
> is a performance of <Work> from YYYY-MM to YYYY-MM". I personally dislike
> this option (IMO it would be better to "allow" partial dates on the
> Release/RG level only).

One possibility would be to require that the start date and end date be
the same.  So if you know it was "in 1923" or "May 2007" you can put
that, even if you don't know the precise dates.

Also relevant is the previous thread[1] regarding composition dates.

To really do it right/completely, I think we would need multiple sets of
start/end dates. But the above should work for the majority of cases.

1. http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/10307


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

Re: RFC: Add date fields usage to the Performance AR guidelines

ChurruKa
In reply to this post by ChurruKa
I've edited the RFC to remove the "for live performances" part, and changed the start/end date descriptions to a more generic "this indicates the start/end date of the performance".

I've moved the old guide about live performances to bottom "Guidelines" section, and rewrote it on a more non-strict way (i.e., start/end dates are "usually" the same and is OK to just use the start date of a live event as the performance date of all of its recordings.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

jacobbrett
ChurruKa wrote
I've edited the RFC to remove the "for live performances" part, and changed the start/end date descriptions to a more generic "this indicates the start/end date of the performance".

I've moved the old guide about live performances to bottom "Guidelines" section, and rewrote it on a more non-strict way (i.e., start/end dates are "usually" the same and is OK to just use the start date of a live event as the performance date of all of its recordings.
I think "For live recordings the end date is usually the same as the start date. For most live albums from a single concert starting close to midnight and ending early in the morning is OK to just use the start date of the event on all concert recordings." should be appended with ", though precise dates are preferred.", or have such guide expressed in an equivalent manner.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

Nicolás Tamargo de Eguren
On Fri, Jul 15, 2011 at 12:51 PM, jacobbrett <[hidden email]> wrote:

>
> ChurruKa wrote:
>>
>> I've edited the RFC to remove the "for live performances" part, and
>> changed the start/end date descriptions to a more generic "this indicates
>> the start/end date of the performance".
>>
>> I've moved the old guide about live performances to bottom "Guidelines"
>> section, and rewrote it on a more non-strict way (i.e., start/end dates
>> are "usually" the same and is OK to just use the start date of a live
>> event as the performance date of all of its recordings.
>>
> I think "For live recordings the end date is usually the same as the start
> date. For most live albums from a single concert starting close to midnight
> and ending early in the morning is OK to just use the start date of the
> event on all concert recordings." should be appended with ", though precise
> dates are preferred.", or have such guide expressed in an equivalent manner.
Would you really prefer to put a song performed before midnight as day
X and after midnight as day X+1? Sounds ridiculously confusing to me,
people will assume it's a different concert the following day.
> --
> View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Add-date-fields-usage-to-the-Performance-AR-guidelines-tp3657704p3669540.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
>



--
Nicolás Tamargo de Eguren

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

Re: RFC: Add date fields usage to the Performance AR guidelines

jacobbrett
Nicolás Tamargo de Eguren wrote
On Fri, Jul 15, 2011 at 12:51 PM, jacobbrett <[hidden email]> wrote:
>
> ChurruKa wrote:
>>
>> I've edited the RFC to remove the "for live performances" part, and
>> changed the start/end date descriptions to a more generic "this indicates
>> the start/end date of the performance".
>>
>> I've moved the old guide about live performances to bottom "Guidelines"
>> section, and rewrote it on a more non-strict way (i.e., start/end dates
>> are "usually" the same and is OK to just use the start date of a live
>> event as the performance date of all of its recordings.
>>
> I think "For live recordings the end date is usually the same as the start
> date. For most live albums from a single concert starting close to midnight
> and ending early in the morning is OK to just use the start date of the
> event on all concert recordings." should be appended with ", though precise
> dates are preferred.", or have such guide expressed in an equivalent manner.
Would you really prefer to put a song performed before midnight as day
X and after midnight as day X+1? Sounds ridiculously confusing to me,
people will assume it's a different concert the following day.
> --
> View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Add-date-fields-usage-to-the-Performance-AR-guidelines-tp3657704p3669540.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
>



--
Nicolás Tamargo de Eguren

_______________________________________________
MusicBrainz-style mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Indeed, because that is what's technically correct. I presume that the recordings would be linked via a release, or at worst, annotations.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

Stephen
In reply to this post by Nicolás Tamargo de Eguren

On Jul 15, 2011, at 5:54 AM, Nicolás Tamargo de Eguren wrote:
> Would you really prefer to put a song performed before midnight as day
> X and after midnight as day X+1? Sounds ridiculously confusing to me,
> people will assume it's a different concert the following day.

That seems very confusing to me as well.


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

Re: RFC: Add date fields usage to the Performance AR guidelines

Frederic Da Vitoria
2011/7/15 Stephen <[hidden email]>

On Jul 15, 2011, at 5:54 AM, Nicolás Tamargo de Eguren wrote:
> Would you really prefer to put a song performed before midnight as day
> X and after midnight as day X+1? Sounds ridiculously confusing to me,
> people will assume it's a different concert the following day.

That seems very confusing to me as well.

I agree. I am glad we don't record hours, because this would be very difficult to solve :-)

--
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: RFC: Add date fields usage to the Performance AR guidelines

ChurruKa
In reply to this post by jacobbrett
I see using the same date for all recordings is not 100% correct, but I think using the "exact" date would be overkill.

Assuming the typical song from a pop/rock band lasts no more than 10 minutes, live albums can be edited, for example, to cut long pauses when the band is not playing, and that is nearly impossible to know the exact hour when the concert started/the band started playing the first track (without counting time zone issues), I think knowing the exact track when we pass from concert_start_day to concert_start_day+1 would be nearly impossible and a source of disagreemens. I think the best way is as expressed on the current proposal.

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

Frederic Da Vitoria
2011/7/19, ChurruKa <[hidden email]>:

> I see using the same date for all recordings is not 100% correct, but I
> think
> using the "exact" date would be overkill.
>
> Assuming the typical song from a pop/rock band lasts no more than 10
> minutes, live albums can be edited, for example, to cut long pauses when the
> band is not playing, and that is nearly impossible to know the exact hour
> when the concert started/the band started playing the first track (without
> counting time zone issues), I think knowing the exact track when we pass
> from concert_start_day to concert_start_day+1 would be nearly impossible and
> a source of disagreemens. I think the best way is as expressed on the
> current proposal.

I am not concerned with long concerts. What I can easily imagine is a
live release where the only information would be something like "all
tracks recorded between 2010-07-03 and 2010-07-12". This is not a
problem of "exact" date, but rather of recording a poorly defined
date.

--
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: RFC: Add date fields usage to the Performance AR guidelines

jacobbrett
In reply to this post by ChurruKa
ChurruKa wrote
I see using the same date for all recordings is not 100% correct, but I think using the "exact" date would be overkill.

Assuming the typical song from a pop/rock band lasts no more than 10 minutes, live albums can be edited, for example, to cut long pauses when the band is not playing, and that is nearly impossible to know the exact hour when the concert started/the band started playing the first track (without counting time zone issues), I think knowing the exact track when we pass from concert_start_day to concert_start_day+1 would be nearly impossible and a source of disagreemens. I think the best way is as expressed on the current proposal.
I think it's quite reasonable to often not know when the clock ticks over on a live recording, though I think it should be mentioned as an optional, preferred enhancement to the quality of the MB data, if the editor is sure of the accuracy of their source data.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Add date fields usage to the Performance AR guidelines

Nicolás Tamargo de Eguren
On Thu, Jul 21, 2011 at 3:12 PM, jacobbrett <[hidden email]> wrote:

>
> ChurruKa wrote:
>>
>> I see using the same date for all recordings is not 100% correct, but I
>> think using the "exact" date would be overkill.
>>
>> Assuming the typical song from a pop/rock band lasts no more than 10
>> minutes, live albums can be edited, for example, to cut long pauses when
>> the band is not playing, and that is nearly impossible to know the exact
>> hour when the concert started/the band started playing the first track
>> (without counting time zone issues), I think knowing the exact track when
>> we pass from concert_start_day to concert_start_day+1 would be nearly
>> impossible and a source of disagreemens. I think the best way is as
>> expressed on the current proposal.
>>
> I think it's quite reasonable to often not know when the clock ticks over on
> a live recording, though I think it should be mentioned as an optional,
> preferred enhancement to the quality of the MB data, if the editor is sure
> of the accuracy of their source data.

I don't see it as an improvement, unless we have also hh:mm, which is
ridiculously overkill. If not, half a show being set to day X, half to
day X+1 and one song to both is just mind-boggingly confusing and
totally unworth of the small data "quality" difference.

> --
> View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Add-date-fields-usage-to-the-Performance-AR-guidelines-tp3657704p3683524.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
>



--
Nicolás Tamargo de Eguren

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

Re: RFC: Add date fields usage to the Performance AR guidelines

swisschris


2011/7/21 Nicolás Tamargo de Eguren <[hidden email]>
On Thu, Jul 21, 2011 at 3:12 PM, jacobbrett <[hidden email]> wrote:
>
> ChurruKa wrote:
>>
>> I see using the same date for all recordings is not 100% correct, but I
>> think using the "exact" date would be overkill.
>>
>> Assuming the typical song from a pop/rock band lasts no more than 10
>> minutes, live albums can be edited, for example, to cut long pauses when
>> the band is not playing, and that is nearly impossible to know the exact
>> hour when the concert started/the band started playing the first track
>> (without counting time zone issues), I think knowing the exact track when
>> we pass from concert_start_day to concert_start_day+1 would be nearly
>> impossible and a source of disagreemens. I think the best way is as
>> expressed on the current proposal.
>>
> I think it's quite reasonable to often not know when the clock ticks over on
> a live recording, though I think it should be mentioned as an optional,
> preferred enhancement to the quality of the MB data, if the editor is sure
> of the accuracy of their source data.

I don't see it as an improvement, unless we have also hh:mm, which is
ridiculously overkill. If not, half a show being set to day X, half to
day X+1 and one song to both is just mind-boggingly confusing and
totally unworth of the small data "quality" difference.

+1 

> --
> View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-Add-date-fields-usage-to-the-Performance-AR-guidelines-tp3657704p3683524.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
>



--
Nicolás Tamargo de Eguren

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


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