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

Brown, Dave dabrown at yahoo-inc.com
Tue Mar 2 22:12:00 UTC 2004


I think by definition <Metadata> in the playlist is supplemental, whereas
the IDs can be used to get "official" metadata from whatever source you
choose.

-Dave


-----Original Message-----
From: Robert Kaye [mailto:rob at eorbit.net] 
Sent: Tuesday, March 02, 2004 2:07 PM
To: Lucas Gonze
Cc: playlist at musicbrainz.org
Subject: Re: [Playlist] Re: proprietary media types in a generic playlist
format



On Monday, March 1, 2004, at 04:24  PM, Lucas Gonze wrote:
> Where does a content resolver fit into, for example, Winamp?  It can
> have its own resolver for filenames and URLs, but use a plugin when 
> the identifying info requires a more specialized bit of code.  The 
> resolver might know how to find downloads on the iTunes music store, 
> do a magnet lookup, or convert a URL into the path of a file in the 
> browser cache.

I see the resolver being used in two different ways:

* Invoked from a browser/mail app -- the downloaded/mailed playlist 
gets fed to the resolver, it gets resolved and then passed on the 
primary media player or
* the primary media player receives a playlist and then calls upon the 
resolver to resolve  the tracks.

To make this work best it would be nice if all of the incompatible 
music download stores could all be hooked into this system. For 
instance, if a playlist calls for tracks that can only be found in 
three separate music services, how could the resolver, the three media 
services and the primary media player coordinate the playback of all 
these tracks??

So, how can the resolver know about local media repositories? I'd hate 
to extend the features of the resolver to be the media library itself 
-- that seems too far out of the scope. But how do we get all the 
players to behave nicely and play in the same sandbox?

Ultimately this system will fail if it cannot be used with the user's 
favorite player -- the new system should be integrate-able into 
existing players with little effort.

> This is analogous to the way that MS compilers (used to?  I don't know
> if this is obsolete.) convert thunks into addresses within a DLL.  
> There's a reference to a song in a playlist, and the content resolver 
> converts it into something that an MP3 player can work with.  What I 
> like about this is that it lets us put all kinds of bizarre identifier 
> info in there without breaking existing players.

Yup.

> What I don't like is that playlists will get gunked up with all kinds
> of bizarre identifier info.  If somebody makes a playlist that has a 
> couple specific songs, then passes it on to their friend, and their 
> friend's MP3 player adds a SHA1 and a URL and some ID3 tags then the 
> thing will pretty quickly become bloated and messy.  The state info 
> that Ian was talking about is handy but mutable, it shouldn't be mixed 
> in with the fact that this playlist contains songs A and B.  So how to 
> keep a clean division between the two sets of data?

We could define different sections in the XML file. For instance the 
identifier list and its order would be 'authoritative' and the metadata 
section would be 'supplemental'. How does that sound?


> --

--ruaok              Somewhere in Texas a village is missing its idiot.

Robert Kaye     --     rob at eorbit.net     --    http://mayhem-chaos.net

_______________________________________________
Playlist mailing list
Playlist at lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/playlist




More information about the Playlist mailing list