Tracking the tools that decentralize the media. tools process ideas resources eventsav

unmediated

 

August 10, 2006

Jay Fienberg emailed these interesting comments on the MP3HTML file format I made up a couple weeks ago:

I've been thinking about your MP3 embedded in HTML experiment, and I keep meaning to write you about it. Mostly, I keep wanting to write and say "no", and then think "why not?", and get stuck--so, I guess it's an interesting experiment, and it got me thinking :-)

BTW, Why not just embed HTML and other stuff in MP3s?

Part of my bias against this kind of embedded approach is that, generally, I like the idea of decoupling data / information from files. The nice example, I think, is being able to put a URL in my browser and get back lots of files that represent a "web page"--the browser decides to load lots of images and supporting files to give me a page that is not just what's in the HTML. (And, generally, I think the browser / hypertext interaction can be pushed further, with the browser doing more / different things with various forms of links--all without me, the end-user. having to worry about what is or isn't in one file or another.)

Along these lines, I could imagine an HTML based media format, e.g., application/xhtml+mp3, that doesn't necessarily embed the media data inside the HTML, but media players would read this type and expect different / specific elements representing binary media files that they then would do something with / download / play.

In terms of the potential to exploit this using existing browsers with Javascript, I think it's maybe comparable with the embedded MP3 approach--the Javascript can download external mp3s via HttpRequest.

Anyway, I think there's something to what you've done--maybe embedding vs external is just a matter of options, the way it is generally. In other words, if we have a way to declare something a "media HTML" resource that should be played by a media player, in principle HTML allows binary data to be either embedded or linked, and either should work.

I actually think that is the bigger deal: suggesting that there might be a viable "media HTML" format that's not too much weirder than HTML itself.

An answer to one specific point:

Why not just embed HTML and other stuff in MP3s?

Because you wouldn't be able to get at the HTML and other stuff without knowledge specific to MP3. If nothing else, we should be able to get out of the problem where every user agent must understand every media format.

There is a secondary problem which isn't directly related to format design: to get anything done, we need a strategy for avoiding the need for client-side software.

One last thing -- I love the coinage Media HTML. It's the kind of name which evokes the thing being named without any explicit setup or explanation.