JavaScript mp3 decoder allows Firefox to play mp3 without flash

http://jsmad.org/play/176848 | N.E.R.D & Daft Punk - Hypnotize U (Nero Remix)

http://jsmad.org/play/266408 | Nero - Me & You

http://jsmad.org/play/201732 | Cassius - I <3 U So (Skream Remix)

http://jsmad.org/play/265379 | The Streets - Blinded By The Lights (Nero Remix)

http://jsmad.org/play/237774 | Ellie Goulding - Lights (Bassnectar Remix)

There's some awesome music on Official.fm :) I'm so thankful I get paid to develop stuff like jsmad over there.

(edit: typo)

Browsers have a much harder time dealing with binary XHRs, huge typed arrays, huge strings, and a real fucking lot of arithmetic operations.

I think the most difficult part was the debugging. Jens Nockert, Matthias Georgi & I finally used node.js and carefully diff'd the output from minimad.c (the canonical libmad example) and jsmad.

However, it quickly became obvious that comparing exact values wasn't going to cut it. Listening was also almost useless (try to debug when all you have is SCRRRCHHHHHH vs CRRRRRRKKKKKK). So we plotted graphs. With gnuplot. It was a matrix-like experience but quickly allowed us to see what was wrong.

Profiling the code via Firebug made us realize that most of the time (~28%) was spent in the synthetizer (synth.js). The I/O code is particularly expensive too, it's a mix of Uint8Arrays and javascript Strings, depending on whether you're using the local file version (filestream.js) or the http streaming version (ajaxstream.js)

One of the funniest part was when I had to code 36-bit precision integer routines in Javascript such as shifting, OR-ing, AND-ing.. I had to separate the numbers in a low word and a high word and then work with floats (which have a 54-bit mantissa in JS).

Really quite an experience!

We did most of the work during and after Music Hackday Berlin (and it was continued at MHD Barcelona) and just staying awake was quite difficult, but porting much of the low-level bitfiddling and pointer-stuff to javascript was hard because of language differences, but also converting a fixed-point library to the floating-point that is available in javascript was a bit of trouble.

If the audiolib.js dev is here or anyone else has a clue, it'd be very welcome.

nb, you say: "libmad has commercial license. As for jsmad, we're in a sort of grey legal area." I presume you mean that you would have problems with a commercial licence? Your work is clearly a derivative work of libmad, so it has to be GPLv2 licensed: any commercial license would have to be by agreement with the libmad developers I think.

Regardless: very cool stuff!

On Chrome 13 if you enter a new ID track and hit enter it will keep playing the old song even if you start playing the new one or it will have that crkkkk repeating sound. :) Firefox 4 seems to have no problem but you have to sometimes hit refresh and then play to get the new track playing.

One cool feature would be to make a random ID track generator so you won't have to search/enter the codes for yourself.

Hope this feedback helps somehow.

Did I say how cool all this is?

In the demo, we're replicating some of its functionality in https://github.com/nddrylliog/jsmad/blob/master/src/player.j... instead, although in a less robust way.

That's great news though! Bear with us as we try to handle the traffic :) And reload from time to time until it works.

Edit: all static assets are now served by nginx, and the default track is cached on our server instead of being proxied by node.js all the way. Wish we had CORS at official.fm!

The page linked is just a demo for Music Hackday Barcelona, was not intended to get _this_ much publicity.

Here's a quick overview:

bytestream is our general I/O abstract class - there's much room for improvement because it works with Strings. substream allows to have a 'view' of a slice of a bytestream.

filestream and ajaxstream are two implementations of bytestream, doing local File I/O (with the upcoming W3C File API) and XMLHttpRequest streaming. On Firefox 4.0+, ajaxstream takes advantage of mozBinaryResponse and uses Uint8Array(s) to 1) compute the amount of data read, and 2) implement getU8 (which is used a lot).

bit.js is a straight port of libmad's bit manipulation routines. Bit-level I/O is a must-have in an MP3 decoder because you have numbers stored on 7 bytes, 19 bytes, and other weird stuff like this (especially in the huffman decoding part).

huffman.js, imdct_s.js, rq_table.js are all tables used somewhere else in the process.

layer3.js is really the central part. it implements huffman decoding, the various IMDCT transforms, reordering, requantizing... all sorts of magic tricks I didn't fully grasp even while porting. Comparing the output was really our best weapon. The libmad guys are really the reference guys for this kind of question. We had to strip out all their fixed-point stuff because it's really of no use in Javascript, since JS only has floating point numbers - even if we can make them behave almost as integers, it's still as costly as FP arithmetic so we just went floating point all the way - hence, jsmad doesn't have 24-bit output like libmad has. libmad is wayyyy better at everything :)

synth.js is the second central part - it synthesizes the sound waves from the decoded MPEG Layer-III data. It's the most expensive part of the project, since it's just thousand meaningless arithmetic operations, something JavaScript doesn't excel at.

mad.js contains mostly constants (errors), a few utility functions

decoder.js isn't used anywhere, it's my attempt to port decoder.c from libmad, but it's unfinished.

player.js is our ill-fated attempt to play the decoded MP3 correctly - it's really naive (no seeking, stutter in some cases, no buffering of decoded frames, etc.)

The legacy way is dealing with binary data as an ASCII String - effectively a string of bytes. This works but it's hella slow - probably because browsers didn't think we'd be using 67MB strings :)

The new way is with Typed Arrays: using an Uint8Array is pretty awesome, see the [Mozilla Developer Docs](https://developer.mozilla.org/en/JavaScript_typed_arrays).

Mozilla Firefox since version 4.0 allows to do XMLHttpRequests (xhr) to be retrieved directly as an ArrayBuffer, which you can then create an Uint8Array view on. Since Gecko 6.0 (Firefox 6.0), mozResponseByteArray is deprecated and they've implemented the new standard way: see https://developer.mozilla.org/En/XMLHttpRequest/Using_XMLHtt... for more details.

As for reading local files, the [W3C File API Draft](http://dev.w3.org/2006/webapi/FileAPI/) is implemented in Firefox 4.0 and Chrome 11+ as far as I can tell, and it also allows us to retrieve a binary string.

As far as I can tell, jsmad is not going to replace the HTML5 audio tag on mobile devices. However, it does constitute a nice legal workaround for MP3 in desktop browsers such as Firefox.

It gives access to the full decoded audio data, the code doing the playback (player.js) is actually just a tiny little part of jsmad! The HTML5 audio tag seems to also give access to the decoded data, but I haven't messed with it enough to know what's the level of control.

What would be really interesting though, would be something like streaming audio applications - completely flash-free, something that would be (imho) hard to achieve using the HTML5 <audio> tag.

My opinion is that it's wrong to try to add everything as browser built-ins. If the Javascript are powerful enough, why not use it to decode PDF/MP3/whatever? I'm guessing we won't see a video decoder for a few months more, but who knows? Things are moving fast.

So to answer your original question: it goes much deeper. For an audio button it would probably be overkill, but then again, why not?

I don't care if the year of the Linux desktop never comes - you just don't pull the plug one something like that. Adobe is becoming incredibly irrelevant to the consumer, while still strong to the content producer market - which I want to know nothing about anyway. So, all the best :)