Archive | May 2010

Dissecating ASF/ASX format

Radio Tray development is coming along fine. A lot of new features have been added, as long as some bug fixes. And it’s precisely about one specific bug fix that I’m gonna rant…err….I mean talk about. The infamous ASF format.
As you all probably know, when we do an HTTP request, the server sends a response and in that response there’s the content-type property. This property is the MIME type that identifies the following data in the response body. Radio Tray would inspect that content-type to see if it can decode the stream data. This is mostly important for the playlist formats. These are text files whose entries point to the real streams of music. So, it’s from this MIME type that Radio Tray knows which format of playlist is receiving and thus, proceed to decode it.
Now, let’s check out the "video/x-ms-asf" MIME type. This is the  MIME type returned when we have an ASF stream, the music data itself. However, for a music server, it’s allways useful to return a playlist. And so they created the ASF Playlist, which is basically a key-value text file where each entry represents a stream URL. But instead of defining a different MIME type for this playlist, they decided to use the same! So now we have a text file and a byte stream identified by the same content-type. Of course I had to figure out a way to distinguish between the two, because the content-type was not sufficient anymore.
Somewhere along the way, someone decided that the ASF playlist wasn’t good enough and decided to make a new playlist format to serve ASF streams. This time, in the form of a XML file. It was named ASX playlist. That is fine, except for one detail: they decided to use the same MIME type again! So now the "video/x-ms-asf" represents a binary stream and two completely different playlist formats.

Unfortunately, the complexity of the ASF/ASX playlists don’t end here. They decided that it wasn’t enough for a playlist entry to indentify just a media stream. So, that URL can also be another playlist. From the playlist syntax there’s no way to tell, they’re just URLs. One has to contact the URL and inspect the response. Now, the fun part begins. When I was testing this, this specific radio pointed to a playlist with just one entry. This entry ended up being another playlist. So, Radio Tray downloads the new playlist and inspects that one. Again, it had one entry. Something like "http://someurl?MSWMExt=.asf". I thought that would finally be the media stream. However, to my surprise, that URL just returned the same playlist file again. Let me repeat that: when downloading the playlist, which contains "http://someurl?MSWMExt=.asf", that URL just returns the same file. Does it mean it goes into an infinite loop ? you bet.

So how can we access the media stream ?
The rule is: when we have an http URL that ends with "?MSWMExt=.asf", substitute "http" with "mms". I just have one question: why ? Why would anyone think of such a bizarre scheme ?

Maybe I’m missing something, but it feels strange and excessive. Where has simplicity gone ?

Well, I just had to let it out 🙂 But at least it was fun to dissecate this playlist format. As for the upcoming 0.6 version of Radio Tray, it’s almost there. Just a few small things missing.

Happy Listening!