Audio encoders/decoders

Hello all!

A thought came in to my mind just now: canvas API provides means to convert
images from png to jpg, or just save the results created by programmatic
drawing, why don't <audio> and <video> have these capabilities? I mean,
implementing this behavior is not a big deal and thus could be standardized
pretty quickly. After all, the browsers *already* have the codecs
implemented in one way or another, why shouldn't they be made available via
APIs as well?

Imagine this:

var myAudio = new Audio('whatever.wav');
// Would return a string for the wav file converted to ogg, in binary form,
like it would have been read from a file.
myAudio.toData('audio/ogg');

myAudio = new Audio('something.ogg');
// The same, except vice versa, thus allowing us to go through the raw data
hidden underneath the binary nonsense.
myAudio.toData('audio/wav');

// This would be just a stupid thing to do, unless the content was
generated, but who knows if someone would find use for this. Same could also
be achieved by doing btoa() conversion to the .toData() output.
myAudio.toDataUrl('audio/mp3');

// Also, pretty much useless, if performance is not regarded, we could just
create new Audio(header + btoa());
myAudio = Audio.fromData(data, 'audio/ogg');

Very simple, yes? Not hard to implement, like I said, the encoders /
decoders are already there. Useful? Very. For example, let's say we wanted
to record data that's generated by our Audio demos/apps, then we wanted it
to be stored on the users computer via say, File API? We very much would
like it to be compressed, but not as much as the end user does.

So it would be something like:
string toData(string <datatype>)

If this sounds reasonably, why even leave it at that?
We can add more arguments:
compression level
bitrate
sample rate
etc.

Then also let's have another look at the Audio.fromData(<data>, <codec>).
To make that more powerful, as data, it could accept
1. A string containing the binary data, of course.
2. An AudioBuffer created by the Web Audio API,
3. An Array, or a typed Array.
4. A data URL, but this would be stupid because that's already implemented
via new Audio(<dataurl>)
Which actually gives us reason to just put it in the existing constructor (
new Audio(<data>, optional <codec>) ).

And voilà, there we have a simple but powerful API that allows our browsers
to become full-fledged audio conversion tools (to say the least).

Rather vague, but what do you think?

Best Regards,
Jussi Kalliokoski