[Playlist] wiki updates

Steve Gedikian steve at nullsoft.com
Tue Mar 2 01:23:29 UTC 2004

ian c rogers wrote:

> > NamingSongs: given that names vary for good reasons, how can
> > identifiers in playlists be stated in a way that different client 
> agents
> > on different hosts can resolve them?
> I think the way this is going to happen, realistically, is through 
> identifiers in the Metadata.  There need not be an uber-identifier.  
> If the format allows for arbitrary identifiers, playlists can be 
> created that have multiple identifiers such as MusicBrainz, AMG, Muze, 
> or other proprietary IDs.  My sense is that this sort of freedom will 
> actually promote a solution such as MusicBrainz, since an open 
> directory gives the most interoperability.  But if some vendor wants 
> to key off of AMG or some proprietary ID, that's their prerogative.  
> Today those vendors are using proprietary playlist formats, too.  If 
> they used the portable format and not the portable ID that would still 
> be a step in the right direction.

So I agree with the concept of having a uber id system that's open. One 
potential problem that I see is that meta data providers like AMG, 
Gracenote, Muze, are all in the business of selling their data and 
having you leverage their propietary IDs as a means of using their data. 
It's in their best interest to make it not easy for customers to be able 
to switch from one data provider to another. That said, I'm curious to 
see how we're going to get those data mappings between the propietary 
and open systems mapped. I would guess that for it to really work well, 
we'd need to make it dead simple for companies like AMG to suck down the 
open IDs and map it internally to their data mapping and sell that as 
part of the package. The trick will be to get enough customers to demand 
such integration to make it worth those companies time.

Not to complicate things but how will this database be built? For 
example, are the IDs based on an digital fingerprint of a given asset? 
Do supporting applications write this ID into the asset so that other 
applications can easily leverage it without refingerprinting every time? 
How will other meta data providers map an open ID with their closed ID 
system? Will users be providing this new ID DB with meta data? If so, 
how will we ensure that we don't have users/companies entering data from 
propietary systems into the open system, thus leading to copyright 
infringment? This quickly becomes very hairy. Also, we'll need to get 
some IP lawyers to investigate whether there is enough wiggle room in 
the existing patents to allow us to create this open system without 
infringing on any patents.

> > PrivacyAndSecurity: given that paths reveal information that
> > might be compromising, and that playlists might be shared, how
> > can private information be kept separate?
> My assumption is that this should be up to the player implementation 
> to decide if it's going to write path name out to the file.  We can 
> discourage it, but if they want/need that metadata we shouldn't 
> prevent them from writing it.  There is very little truly sensitive 
> information in a playlist and we're not exposing any more than any 
> playlist already exposes.  In fact, by encouraging the use of IDs 
> we're encouraging solutions which don't rely on file URIs so this will 
> likely become less of an issue over time.

If you had to ask me, I would be fine with referencing only IDs within 
playlists and allow each application to resolve the IDs against local 
and remote DBs. Not sure how much that complicates things but I see that 
being a more elegant solution long term.

> > MultipleSourcesOfSongMetadata: the same song may have different
> > metadata from ID3, CDDB, MusicBrainz. How can these be aligned
> > and reconciled?
> I think it's well beyond the scope of this playlist spec to try to 
> reconcile these.  It's up to the player and the user to define what 
> the metadata is.  The source of the metadata is really irrelevant.  
> We're just looking to save the state as known at some moment in time.

Again, going back to what I was saying before. Meta data and meta data 
providers must be thought about in the context of this conversation. Any 
of these solutions will require their involvement on some level and we 
want to make sure that whatever we come up with doesn't ruin their 

> > NetworkFriendlyNames: given that someone may receive a playlist
> > containing URIs of songs she doesn't have locally, how can we help
> > users to fetch songs from the internet? CanonicalURIs would probably
> > factor in.
> Again I think clues to how to find network resources may come in 
> several ways in the metadata.  There is no One Way (tm) and I don't 
> think we should try to invent one.  If the playlist supports arbitrary 
> metadata, players could find network media from something as simple as 
> the URI or MusicBrainz ID, or something as fuzzy as a combo of artist, 
> album, title, and track length.  Our job is to give as much info as is 
> known at the time of save, and the job of the rendering player is to 
> find as many tracks as possible with the given information.
> > ProprietaryFileFormats: given that songs are often in proprietary
> > formats, and that a generic playlist format will allow third party
> > players to handle the playlist, how can songs in proprietary formats
> > be handled? Knowing mime types of song files is relevant.
> Proprietary formats should be punished.  :)  This is going to be a 
> huge problem, particularly in the video world.  Trying to get various 
> kinds of video to play, particularly streaming video, with any one 
> player is an impossibility.  And the problem goes much further than 
> file formats, you really need to worry about both format support and 
> the availability of decoders -- it's impossible to know the 
> capabilities of the player which will be rendering the playlist.  My 
> suggestion is that a playlist entry may contain good information about 
> what format the file is in, and again it'll be up to the renderer as 
> to what the right thing to do with that file is.
> ian
> Lucas Gonze wrote:
>> http://playlist.musicbrainz.org/playlist/moin.cgi/FactoringTheProblem
>> http://playlist.musicbrainz.org/playlist/moin.cgi/StrawmanSolutions
>> _______________________________________________
>> Playlist mailing list
>> Playlist at lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/playlist
> _______________________________________________
> Playlist mailing list
> Playlist at lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/playlist

More information about the Playlist mailing list