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

Kevin Marks kmarks at mac.com
Tue Mar 2 02:38:59 UTC 2004

On Feb 28, 2004, at 11:19 AM, Lucas Gonze wrote:
>> It is a hard problem. The QT component solution is a good one, but 
>> they have neglected it recently.
> What's the QT component solution, Kevin?  It's new to me and it sounds 
> relevant.

This may go against Steve G's warning on pre-existing solutions, but I 
think it is relevant and worth going into some detail.

QuickTime's movie format is in effect a playlist format. A movie 
consists of multiple tracks of  arbitrary type, with a temporal 
relationship defined though a movie timescale and track timescales.

Each track has a series of data references to media, time to offset 
mappings, and Sample Descriptions.

To play it back, QT looks up each track type to see if it has a Media 
Handler Component of that type (eg 'vide' for video and 'soun' for 

It opens suitable Data Handler components for each Dataref, and uses 
the time to offset tables to tell the datahandlers which bits it needs 

Then it instantiates Sound or Video (or whatever) decompressor 
components for each Sample Description type is defined (eg 'jpeg' or 
'png ' or whatever).

Each class of component has a common defined API which consists of a 
single entrypoint with selectors passed in; the meaning of the 
selectors is dependent on the Component class, but it is uniform for a 
give class (eg video decompressor or data handler).

This double abstraction is very powerful, as you can add a new 
datahandler (eg http, freenet) and play movies over it, and add new 
decompressor types independently. As it works by reference, you can 
import non-QT files by reference only, which is how QT can play DV and 
mp3 files.

When QT encounters an unknown format, it checks with an Apple-hosted 
database to see if there is a component it could download to play this. 
Apple had a programme to support hosting and automatic download of 3rd 
party components this way.

I don't propose this as a format here, but the component idea of 
defining an API set and having alternatives is a useful one to absorb.

>> This is why I am proposing a playlist format at a meta level that 
>> indicates songs canonically, so you can resolve them through any 
>> playback format available.
> Ok, so the thing you're imagining is that songs are identified by 
> acoustic fingerprint, and the player is responsible for converting an 
> acoustic fingerprint to a playable resource like an MP3 file.  Do I 
> have that right?  It seems to me that you're envisioning a new set of 
> functionality that's too far reaching to be within this project.

The problem is having a canonical reference to a 'song'. MB provides 
this, and does not require an acoustic fingerprint to provide one, 
though it can be useful confirmation. (As an aside, the current MB UIDs 
seem remarkably large; I assume there is a design reason for this, but 
I would be surprised if there are more than a trillion songs, and one 
can readily get 5 bits of data in a character with just lowercase 
letters and numbers, so one could express a trillion distinct entities 
in 8 characters).

As others have said, the more additional metadata involved, the surer 
you can be of a match.

Knowing not only that an Amazon ASIN + track number or a CDDB id or an 
iTunes URL correspond to the same song is only part of the problem; 
also knowing that the version of the song on a compilation album is the 
same as that on the original LP is worth knowing.

> Really, it's a lot like a proprietary media type.  Let's say there's 
> an app that can take an MB ID and return a file or list of files.  
> That app would be very happy to have MB IDs embedded in playlists.  At 
> the same time, MP3 players that don't have access to the app need to 
> be able to keep doing what they do if they can't resolve a URI.
>> MB could perhaps collate publicly available versions of the song with 
>> mime types to indicate format.
> Being able to get the mime type seems like the main requirement.  In 
> some cases, e.g. if it's RTSP or HTTP, you can do that over the net, 
> in others  the mime type has to be made available as metadata, 
> probably in a catalog section of the playlist.

No, the playlist does not know the mime type. The mime type needed 
depends on the player. The mime types available depend on the 
resolvers. One might need a format converter to transform between them 
if there isn't a match, but that is a second order problem.

A first iteration could deal purely with MP3 files and still provide 
the very useful service of identifying which ones are the same and thus 
suitable alternatives.

More information about the Playlist mailing list