decoding entire audio files

[aykevl]

This is sort-of a question (possibly a bug).

I'm developing a small web application to do ABX testing in the browser. It works with the Web Audio API as that is going to be the future (the Firefox api is deprecated). It needs to decode the entire audio file in memory, as it is currently implemented. I wanted to add FLAC support (as FLAC isn't very well supported in browsers, AFAIK only Chrome OS has support for the format).
The test.html (in flac.js) worked. I added a 'data' event handler to the asset (player.asset). When playing the audio file (via player.play()), the data callback fired for every bit of data (which I do not want, I want the entire arraybuffer), but when calling player.asset.start(), two chunks of data were given to the data callback, but nothing more happened.

Is it actually possible to decode the whole file in one arraybuffer (possibly in a Web Worker)? The documentation (https://github.com/ofmlabs/aurora.js/wiki/Asset-Class-Reference#wiki-data-event) seems to suggest the 'data' callback is called when the whole file is decoded.

[devongovett]

No, the data event is emitted a number of times as data becomes available from the decoding pipeline. There isn't currently a very good way of decoding the whole file without writing a small function yourself. I plan to add this to the Asset class soonish.

First of all, make sure you're using the namespace branch from Github. It's much more up to date, and there's really no reason I haven't merged it in yet. Here's a small function that can decode the whole file into a BufferList that you can merge at the end into a single buffer if you really need to:

var list = new AV.BufferList;
asset.on('data', function(chunk) {
  list.append(new AV.Buffer(new Uint8Array(chunk.buffer)));
});

asset.on('end', function() {
  // merge bufferlist into a single buffer if you need to...
  var buf = new Uint8Array(list.availableBytes);
  var cur = list.first;
  var offset = 0;

  while (cur) {
    buf.set(cur.data, offset);
    offset += cur.length;
    cur = cur.next;
  }

  // buf now contains all of the buffers. do what you want with it here...
});

(function decode() {
  while (asset.decoder.decode());
  asset.once('data', decode);
})();

The code above is totally untested so something like it will probably work. :)

Like I said, this should obviously be a lot better, so I'm leaving the issue open to remind me to make it so. Good luck!

[mmontag]

Hi Ayke, I'm curious about your ABX testing app, since I'm currently
working on something similar (github.com/mmontag/audio-listening-test).
Is it something you are able to share?

Matt

On Fri, Feb 22, 2013 at 3:10 PM, Ayke van Laethem
notifications@github.comwrote:

This is sort-of a question (possibly a bug).

I'm developing a small web application to do ABX testing in the browser.
It works with the Web Audio API as that is going to be the future (the
Firefox api is deprecated). It needs to decode the entire audio file in
memory, as it is currently implemented. I wanted to add FLAC support (as
FLAC isn't very well supported in browsers, AFAIK only Chrome OS has
support for the format).
The test.html (in flac.js) worked. I added a 'data' event handler to the
asset (player.asset). When playing the audio file (via player.play()), the
data callback fired for every bit of data (which I do not want, I want the
entire arraybuffer), but when calling player.asset.start(), two chunks of
data were given to the data callback, but nothing more happened.

Is it actually possible to decode the whole file in one arraybuffer
(possibly in a Web Worker)? The documentation (
https://github.com/ofmlabs/aurora.js/wiki/Asset-Class-Reference#wiki-data-event)
seems to suggest the 'data' callback is called when the whole file is
decoded.

—
Reply to this email directly or view it on GitHubhttps://github.com/ofmlabs/aurora.js/issues/20.

[aykevl]

The testing app is here: http://webabx.nfshost.com/. It is implemented in pure JavaScript (no server side processing whatsoever, I don't even host any audio files because they're quite bandwidth and storage heave).

It might be possible to make some sort of API that can redirect, or something via an iframe or something. If you're interested, I can mail you (as this isn't really the place to talk about it). And, I haven't said it there, but I plan to license the code under the BSD license, so maybe you can just copy the code once it's licensed (with proper attribution, of course). It still has some bugs, though.

I am thinking of refactoring the whole thing to make it modular and to not load the whole file in memory (in PCM data, which is quite a lot). It uses at least a few hundreds MBs on my computer for a moderate song (actually, two songs, as two are played at the same time), so that's not very optimal. The reason I use this system is because I can start them at exactly the same time easily.

I think instead of loading the whole buffer in memory I'll refactor it in such a way that partial buffers are used (making the whole thing a lot more efficient). FLAC support isn't high priority for me (WAV already works), but would be nice to have so maybe once the refactoring is done I'll look into it again.

I asked this in the first place to ask a question (as I couldn't find another place). As that question is answered, maybe it's better to close this bug?

[devongovett]

No, I'll leave it open as a reminder to myself. I still want to add this feature. Thanks!