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