[Playlist] Re: proprietary media types in a generic playlist format

Matthias Friedrich matt at mafr.de
Mon Mar 1 22:20:35 UTC 2004

On Monday, 2004-03-01, ian c rogers wrote:
>    I definitely agree that a portable playlist format should support this
>    functionality.
>    I'm thinking of playlists as serialization.  A playlist is just a
>    snapshot of player state.  Everything that the player knows about that
>    moment can be recorded and exported to the playlist.  When handed to
>    another player, that player does its best to recreate the state with
>    the resources it has available and the information from the playlist
>    which it understands.  The advantage we have here is that it's not
>    necessary that this recreation be perfect to provide a worthwhile
>    experience; playlists can be suggestions.

I really like the "serialization of player state" approach. Combined
with the canonical identifiers and some of Rob's and Lucas' ideas it
leads us to something like this:

<?xml version="1.0"?>


  <license>Public Domain</license>

  <cover_art resource="http://www.wherever.invalid" />

  <!-- cover art could also be included as CDATA -->

<entries order="sequential">
    <creator>Tori Amos</created>
    <!-- more data -->


    <creator resource="http://allmusic.com/whatever"/>
    <title>Near Wild Heaven</title>

  <!-- pulls in all available songs by this band -->
    <creator>The White Stripes</creator>



The player should describe each song as precise as possible. If
canonical identifiers are available, they should be used. Additionally,
some metadata is put into the file. In the worst of all cases a file:
URI is used.

If it isn't possible to resolve the IDs, the metadata can be used to try
a fuzzy match.

The last entry shows an interesting feature: Supplying only partial
metadata to match a number of tracks.

Sure, the syntax is crappy. Feel free to correct or improve it.


More information about the Playlist mailing list