Metadata is information about song resources, encompassing artist, song title, song length, bit rate, and so on. Sequence information is the order of songs in a collection. Every playlist format, even the simplest, covers both. Most if not all metadata is derived from the media object itself, either by extracting the contents of ID3 tags or by measuring features like song length. Derived metadata is secondary to the media object -- there is no need or reason to trust that derived metadata received over a network is valid, and there is little need to transmit it along with media objects, since recipients should re-derive it during import of a new resource. Another kind of metadata is advisory rather than derived. Advisory metadata encompasses things like comments on the quality of a file, free text descriptions of a file, and associations between an image resource and a song resource. Recipients of a song resource may find advisory metadata helpful but must not assume that it is canonical. Sequence data expresses a specific order or combination of resources. While metadata is never canonical, sequence data always is; or rather, its integrity is built in in the same way as the integrity of a media resource is intrinsic to the resource. Metadata will change for every transmission of a file, for example to rewrite the filesystem path to a cached resource, but sequence data won't. This is the first reason why metadata and sequence data should be kept separately: because we can expect that one will be constantly changing, while the other won't. The second reason is that media resources will be reused in separate sequences. For example one playlist will have a song be first, another will have it be second. If metadata is kept with the sequence information, there will be multiple copies, and the copies will inevitably get out of synch. Non-normalized data leads to heartbreak.
In the iTunes library format, the "Tracks" section contains metadata, while the "Playlists" section contains lists of references to items in the "Tracks" section.
The root.channel.items element holds sequence data, while metadata is kept separately in root.item elements. Further metadata about resources referenced within a root.item element could easily be kept separately, using additional root.work elements.
A market that rewards providers creates a virtuous circle. We want to help those who make music available make money. There are two types of vendor extensions -- data inserted by vendors and data inserted on behalf of vendors.
Kazaa's Kapsule
playlist format defines
a <identifier>urn:topsearch:8c603512f1f5f0b9f93afc844d17a27021b8d257f5c4e95f4269ba0b3b4b25941ba87b90</identifier>
element, which presumably allows them to charge for placement. This
is an incentive to Kazaa to make their software available.
On less controversial ground, it is common practice among authors
of URL playlists
to make it easy for listeners to get to the web source of an MP3.
Typically this means that a click during a song will open a browser
window to the web site hosting the song. An example (using an
undocumented feature of SMIL under Real) is:
<par>
<audio src="http://mirrors.creativecommons.org/copyremix/Fourstones_-_Superego_Exchange_(
suicide_remix).mp3"/>
<img src="http://creativecommons.org/images/features/copyremix.gif?url=http://creativecom
mons.org/extras/copyremix&target=_browser" fill="freeze"/>
</par>
The effect of the above SMIL is that a user who clicks on the image
will go to the MP3 host site.
First, I have invented a pseudo-module for sponsor information:
<media:ref l:type="audio/mpeg"
media:src="http://gonze.com/playlists/wtf.mp3"
sponsor:sponsor="http://www.amazon.com/exec/obidos/tg/detail/-/B00008S2VG/102-7404280-7423310?v=glance"
/>
Second, RSS 1.0's support for XML namespaces allows allows vendor-supplied extensions like Kazaa's <identifier> tag.
Client side remixing means enabling clients to transform remote audio resources. One example is being able to link to a particular point in a streamed audio file. Another is combining a voice-over from one URI with instrumental music from another URI. Another is looping a drumbeat from a short audio clip.
The following SMIL combines a church sermon from one URL with a
series of instrumental tracks from other URLs.
<par>
<!-- sermon -->
<audio src="http://www.insearchoftruth.org/audio/pride_and_envy.mp3" end="1920s"/>
<!-- instrumental backing -->
<seq>
<audio src="http://www.digitalcutuplounge.com/audio_video/Aphex_Twin-Drukqs_[Digital_Cutup_Loun
ge_remix].mp3" />
<audio src="http://www.digitalcutuplounge.com/audio_video/Digital_Cutup_Lounge-Dream_Of_Gabriel
_Valley.mp3" />
<audio src="http://www.digitalcutuplounge.com/audio_video/Digital_Cutup_Lounge-Indian_Accordion
_In_Dub.mp3" />
<audio src="http://www.digitalcutuplounge.com/audio_video/Digital_Cutup_Lounge-Viral_Distributi
on_(Taikoo_live).mp3" />
<audio src="http://www.digitalcutuplounge.com/audio_video/Digital_Cutup_Lounge-Hypokondriak_[li
ve_edit].mp3" />
</seq>
</par>
Because RSS+Time imports the SMIL synchronization specification as an XML namespace, including the <par> and <seq> tags, it conceivably can do all of the above. It happens that some features of SMIL 1.0 are supported in Internet Explorer already, as HTML+Time, so RSS+Time renderers based on IE can keep implementation to a reasonable minimum.
We want things to look good. There needs to be some analog to album art for downloaded music. A good playlist format should support attractive and customizable visuals.
The iTunes audio player allows images to be embedded in audio files. While this is not a great idea technically, it shows the desire to have artwork. Authors of URL playlists have found that playlists with images are downloaded more than playlists without images. Clearly, users prefer to have visuals.
We can use long-established RSS 1.0 features to associate an image with an item.
A URL playlist format is nothing but an extension of hypertext to encompass audio data. It must fit smoothly with the web, using established standards and tools wherever possible.
Most playlist formats already support URLs of items in addition to filesystem paths. These include M3U, ASX, KPL (using Magnet URIs), SMIL, and so on.
RSS 1.0 is RDF. Its native environment is the web, and support for web standards is superb.
A number of playlist formats exist to flag proprietary data formats.
RAM exists to make sure that RealAudio streams are handled by the RealAudio player -- otherwise it is too similar to M3U to be considered to have a separate existence. Similarly, the ASX family of formats exists to make sure that Micosoft media formats are handled by Microsoft's renderers and the Magma format exists to allow Magnet URIs to be handled by Magnet-aware clients.
RSS+Time uses the RSS 1.0 "link" module to set the mime type of a
remote resource, which allows clients to launch a helper application
registered with the operating system in the same way that browsers
and email clients do.
<rdf:RDF
xmlns:l="http://purl.org/rss/1.0/modules/link/"
xmlns="http://purl.org/rss/1.0/"
>
...
<media:ref l:type="audio/mpeg"
media:src="http://gonze.com/playlists/wtf.mp3"
/>