[Playlist] Getting additional fields added to XSPF?

[Lucas Gonze]

There is also DDEX, which has detailed metadata but does not do playlists.
It might be practical to namespace it in.

Nick, are you aware of applications for this metadata?

-Lucas

On Tue, Feb 25, 2020 at 2:55 AM Nicholas Humfrey <njh at aelius.com> wrote:

> Hi!
>
>
> Section 3.2 of the XSPF specification states:
>
> "The function of a playlist is not to communicate metadata about the
> composer, song title, etc. Metadata is hard and there are many providers
> already. We decided that we couldn't compete, and that there was no need
> for us to try. Moreover, good metadata does not travel well — every user
> has to recreate it. Metadata should come from external sources and
> namespaces like MusicBrainz or Gracenote; this what the XSPF link and
> meta elements are for."
>
> However after stating that, the XSPF does support quite a few different
> fields, communicating quite a lot of different types of information.
>
>
> One area that it doesn't cover is contributors. I suspect the the
> 'creator' field was deliberately vague, so that it can be used flexibly
> for Composer, Performer, Spoken Word etc... but it would be really
> useful, if it was possible to describe contributors better.
>
> Is there any appetite for extending XSPF?
>
>
>
> Alternatively, can anyone suggest a music metadata standard, for
> exchanging metadata as a file, that is better suited to this task?
>
> The ones I am aware of are:
> - the Music Ontology
> - DDeX
>
>
> Is there anything else I have missed?  MusicBrainz provides a mechanism
> for querying for music metadata, but it does not specify an exchange
> format.
>
>
>
> nick.
> _______________________________________________
> Playlist mailing list
> Playlist at xiph.org
> http://lists.xiph.org/mailman/listinfo/playlist
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/playlist/attachments/20200225/b497eda4/attachment.html>