new rev

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

new rev

Lucas Gonze-2
It's been 2 1/2 years since v1 and there is extensive experience with
the protocol in practice, so we're in a position to do a round of
improvements.  The errata list alone is detailed enough that we should
consider a new rev for the sake of fixing just those issues:

http://wiki.xiph.org/index.php/XSPF_v1_Notes_and_Errata

As an example of the types of modifications, Sebastian has suggested
offline that a new performer element to complement the creator element
would improve the accuracy of metadata.

One way to tackle this is is to do a formal IETF or W3C document.  To
see what would be involved in doing that with the IETF, Sebastian and I
have chatted a bit with folks there, and Ian and I have also talked
informally with a W3C person.

The image I have in my head is that we'd do the qualitative part of the
work as a set of tweaks to the existing v1 spec, then compose the
document itself per whatever formats were appropriate in context.  We'd
be better off than before in that we'd probably have more participation
from people skilled in spec work, so we'd be able to avoid bonehead
mistakes.

It seems to me that we'd want to keep things streamlined, which means
steering away from the complex agendas of major vendors.  To my mind
this is the trickiest part of the project.

Thoughts?


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

Re: new rev

Sebastian Pipping
Lucas Gonze wrote:
> As an example of the types of modifications, Sebastian has suggested
> offline that a new performer element to complement the creator element
> would improve the accuracy of metadata.

Let me explain this a little more:

The issue I see is that currently everyone is using
<creator> to store/read "the artist", no matter if
creator or performer. (I assume the latter in most cases.)

If the tag was called <artist>, the stored data would
be correct, just not very precise.  But as it's called
<creator> its content is no longer correct if holding
the performer.

How do you think or feel about this?



Sebastian


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

new rev

Chris Anderson-4
On Wed, Sep 3, 2008 at 12:44 AM, Sebastian Pipping
<[hidden email]> wrote:
>
> The issue I see is that currently everyone is using
> <creator> to store/read "the artist", no matter if
> creator or performer. (I assume the latter in most cases.)

You are right about this as far as I have seen.

>
> If the tag was called <artist>, the stored data would
> be correct, just not very precise.  But as it's called
> <creator> its content is no longer correct if holding
> the performer.

An <artist> tag would be more intuitive, to my naive self. In fact, in
Grabb.it's database schema, creator tags are saved in the artist
field. (Grabb.it keeps a composer field as well, we tend to only get
the information from ID3 tags and MusicBrainz.)

Let me put myself out there as about as careful an XSPF user as can be
hoped for. And then let me say that I have trouble with the creator /
performer distinction, myself. If we were talking about composer /
performer, that would be more clear.

I'm not advocating that we rename the creator tag, <composer> just
explaining a confusion which I'd be surprised if it isn't widespread.

--
Chris Anderson
http://jchris.mfdz.com



--
Chris Anderson
http://jchris.mfdz.com

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

Re: new rev

Sebastian Pipping
I think if we renamed <creator> we should try to rescue
the sharing of playlist.creator and track.creator.

Ignoring this for a moment we could also go backwards
<artist> in order to keep XSPF simple. It's non-trivial
already and also not meant as a meta data collection.
(I still think this is a use case and should be possible
but in my eyes that's something that does not belong
into "core XSPF".)



Sebastian

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

Re: new rev

Lucas Gonze-2
Sebastian Pipping wrote:
 > Ignoring this for a moment we could also go backwards
 > <artist> in order to keep XSPF simple. It's non-trivial
 > already and also not meant as a meta data collection.
 > (I still think this is a use case and should be possible
 > but in my eyes that's something that does not belong
 > into "core XSPF".)

I think there's a lot of demand for a music metadata format which could
do things like say who the violinist and arranger were, and if we could
help this along it would be a contribution.  Not that we'd be the only
ones -- there are also Musicbrainz, Music Ontology, and Music XML
gnawing away at this problem -- but it is an area we might be able to
help with.

> I think if we renamed <creator> we should try to rescue
> the sharing of playlist.creator and track.creator.

"creator" naming has some features that are handy if not commendable.

One, it avoids saying in what respect the person is the creator, so
there's no need for the xspf spec to define a thing which is pretty
murky in general use as well.  When people say "artist", what they mean
is "the biggest name in the vicinity of the creation of this recording."
  If Bob Dylan played 2 seconds of triangle in a performance of Joe
Blow's 9th symphony by the community center youth orchestra, most people
would set the "artist" field to Bob Dylan.

And the biggest name changes over time.  I have a CD of 1920s jazz vocal
recordings that Louis Armstrong was a sideman for.  At the time the
headliner was clearly not him, but now it clearly is him.  My point here
being that we need a way to not get dragged into having to make this
kind of distinction.

Two, it's not specific to music.  "artist" wouldn't make sense for a
news podcast or audio book, for example.  "performer" would be an
awkward fit for the person who reads the news, and "anchor" would be a
total mismatch for the person who plays the song.  "author" would make
sense for an audio book, but wouldn't be equivalent to the "composer" of
a symphony.  So this little "creator" ambiguity allowed us to stay clear
of the fairly large job of dealing with all of these details.



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

Re: new rev

Sebastian Pipping
Lucas Gonze wrote:
> And the biggest name changes over time.  I have a CD of 1920s jazz vocal
> recordings that Louis Armstrong was a sideman for.  At the time the
> headliner was clearly not him, but now it clearly is him.  My point here
> being that we need a way to not get dragged into having to make this
> kind of distinction.

I think changes of view in time are nothing we can handle by concept.
But maybe it's more a feeling, I'm not sure about it.


> Two, it's not specific to music.  "artist" wouldn't make sense for a
> news podcast or audio book, for example.  "performer" would be an
> awkward fit for the person who reads the news, and "anchor" would be a
> total mismatch for the person who plays the song.

I'm not a native speaker but as I understand the word "performance"
it could apply to a play or even someone speaking the news.



Sebastian

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

Re: new rev

Sebastian Pipping
Sebastian Pipping wrote:
> I'm not a native speaker but as I understand the word "performance"
> it could apply to a play or even someone speaking the news.

I should have said that maybe we would have to remember people
or to actually define <performer> as an entity doing a
performance to fix the problem that performer might not fit
at first impression. Just my two cents, I'm mentally in bed
already anyway :-)




Sebastian

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

Re: new rev

Lucas Gonze-2
Sebastian Pipping wrote:
> Sebastian Pipping wrote:
>> I'm not a native speaker but as I understand the word "performance"
>> it could apply to a play or even someone speaking the news.
>
> I should have said that maybe we would have to remember people
> or to actually define <performer> as an entity doing a
> performance to fix the problem that performer might not fit
> at first impression. Just my two cents, I'm mentally in bed
> already anyway :-)

Another option is to redefine "creator" as an issue of attribution.  EG
<attributionto>Beethoven</attributionto>
<attributionto>Louis Armstrong</attributionto>

etc


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

Re: new rev

Lucas Gonze-2
In reply to this post by Sebastian Pipping
Sebastian Pipping wrote:
> Sebastian Pipping wrote:
>> I'm not a native speaker but as I understand the word "performance"
>> it could apply to a play or even someone speaking the news.
>
> I should have said that maybe we would have to remember people
> or to actually define <performer> as an entity doing a
> performance to fix the problem that performer might not fit
> at first impression. Just my two cents, I'm mentally in bed
> already anyway :-)

Under the assumption that the errata page is where we're collecting todo
items, I have added on a note about the track creator issue there.



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

Re: new rev

Sebastian Pipping
Btw some people out there invalidly use <artist>
instead of <creator> in XSPF.


A live example can be seen here:
https://www.musictank.co.uk/playlist.xspf

Here is the same file through the eyes of a validator:
http://validator.xspf.org/?url=https%3A%2F%2Fwww.musictank.co.uk%2Fplaylist.xspf#bad_12



Sebastian

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

Re: new rev

Sebastian Pipping
In reply to this post by Lucas Gonze-2
Let me just dump a few thoughts about the status quo
of XSPF here.  Feedback is appreciated.


== In this mail ==
1. Location ranking
2. Location mime type
3. Tag spelling fixes
4. Broken attribution concept


== 1. Location ranking ==
For a track with several locations it's currently not
possible for an XSPF processor (e.g. audio player)
to tell which location will likely result in the
best human experience.  It's not possible because
(native) XSPF does not allow specifying a quality
ranking of a location explicitly and because there
is not defined implicit ranking.

How about defining an implicit ranking like this:

  Where several locations are given the quaility
  should decrease from first to last, so the highest
  quality version always comes first.  This way
  software only working with the first entry will
  not result in a reduced user experience.

  For multimedia files (e.g. combined video and
  audio) quality should be ranked with respect
  to the dominant component of that file.
  For instance for a clip of somebody reading
  the news, audio might be the dominant component
  while video might be the dominant component
  for a dancing competition recording.


== 2. Location mime type ==
Let's say you run a Linux distribution which for legal
reasons comes without support for MP3 decoding.  Some do,
I think Fedora is one of them, not sure.
If a track's location would carry mime type information
with it, an audio player taking care could ignore a
location pointing to an MP3 file as it cannot play it
anyway.


== 3. Tag spelling fixes ==
Today I noticed again how bad <trackNum> and <trackList>
fit into an otherwise consistently lowercase naming.
Especially <trackList> and <playlist> together bite hard.
If there ever is a successor to XSPF-1 I personally
want (backwards-compatible) support for <tracknum>
and <tracklist> tags.


== 4. Broken attribution concept ==
With the current concept of attribution support
a derivative playlist is created by moving
either the playlist's <identifier> or <location>
into <aatribution>, e.g.

   <playlist ...>
     ...
     <creator>Leonardo</creator>
     ...
     <identifier>v1_identifier</identifier>
     ...
   </playlist>

is extended to

   <playlist ...>
     ...
     <creator>Mona Lisa</creator>
     ...
     <identifier>v2_identifier</identifier>
     ...
     <attribution>
       <identifier>v1_identifier</identifier>
     </attribution>
     ...
   </playlist>

Notice that <creator> is holding the name of the author
of the latest version of the playlist file, same applies
to <license>.  To find out the creator or license of
any earlier version one has to find an original copy
of this very version's file and look it up from the inside.
In some or even many cases this might work, but what
if this original version has been moved or even deleted?
In that case neither license nor author can be determined.

That's not cool.  I'm aware attribution probably is one
of the least-used features of XSPF but as it seems
inherently broken I feel like we have to fix it on the
next occasion.  How do you feel about this?
Is there a way to fix this backwards-compatibly?



Sebastian

_______________________________________________
Playlist mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/playlist