[Playlist] Re: proprietary media types in a generic playlist
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
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
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
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.
> 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
More information about the Playlist