converting .wav file to .ogg in javascript

Question

I\'m trying to capture user\'s audio input from the browser. I have done it with WAV but the files are really big. A friend of mine told me that OGG files are much smaller. Does

Answer 1

Ok, this might not be a direct answer as it does not say how to convert .wav into .ogg. Then again, why bother with the conversion, when you can the .ogg file directly. This depends on MediaRecorder API, but browsers which support WebAudio usually have this too( Firefox 25+ and Chrome 47+)

github.io Demo

Github Code Source

Answer 2

This question has been driving me crazy because I haven't seen anyone come up with a really clean solution, so I came up with my own library:

https://github.com/sb2702/audioRecord.js

Basic usage

audioRecord.requestDevice(function(recorder){
  // Request user permission for microphone access

      recorder.record(); // Start recording

      recorder.stop();  /Stop recording

      recorder.exportOGG(function(oggBlob){
        //Here's your OGG file
      });

      recorder.exportMP3(function(mp3Blob){
               //Here's your mp3 file
      });

      recorder.exportWAV(function(wavBlob){
            //Here's your WAV file
      });

});

Using the continuous mp3 encoding option, it's entirely reasonable to capture and encode audio input entirely in the browser, cross-browser, without a server or native code.

DEMO: http://sb2702.github.io/audioRecord.js/

It's still rough around the edges, but I'll try to clean / fix it up.

Answer 3

NEW: Derivative work of Matt Diamond's recorderjs recording to Ogg-Opus

To encode to Ogg-Opus a file in whole in a browser without special extensions, one may use an Emscripten port of opus-tools/opusenc (demo). It comes with decoding support for WAV, AIFF and a couple of other formats and a re-sampler built in.

An Ogg-Vorbis encoder is also available.

Since the questioner is primarily out for audio compression, they might be also interested in mp3 encoding using lame.

Answer 4

To those who down-voted this post: It's really not productive to down-vote questions without taking the time to offer some kind of insight into why the question is somehow 'bad'. I think this question has merit, and the poster clearly has spent some time trying to solve the issue on their own. The Web Audio spec is actually intended to allow exactly this kind of functionality, but is just not close to fulfilling that purpose yet:

This specification describes a high-level JavaScript API for processing and synthesizing audio in web applications. The primary paradigm is of an audio routing graph, where a number of AudioNode objects are connected together to define the overall audio rendering. The actual processing will primarily take place in the underlying implementation (typically optimized Assembly / C / C++ code), but direct JavaScript processing and synthesis is also supported.

Here's a statement on the current w3c audio spec draft, which makes the following points:

• While processing audio in JavaScript, it is extremely challenging to get reliable, glitch-free audio while achieving a reasonably low-latency, especially under heavy processor load.
• JavaScript is very much slower than heavily optimized C++ code and is not able to take advantage of SSE optimizations and multi-threading which is critical for getting good performance on today's processors. Optimized native code can be on the order of twenty times faster for processing FFTs as compared with JavaScript. It is not efficient enough for heavy-duty processing of audio such as convolution and 3D spatialization of large numbers of audio sources.
• setInterval() and XHR handling will steal time from the audio processing. In a reasonably complex game, some JavaScript resources will be needed for game physics and graphics. This creates challenges because audio rendering is deadline driven (to avoid glitches and get low enough latency). JavaScript does not run in a real-time processing thread and thus can be pre-empted by many other threads running on the system.
• Garbage Collection (and autorelease pools on Mac OS X) can cause unpredictable delay on a JavaScript thread.
• Multiple JavaScript contexts can be running on the main thread, stealing time from the context doing the processing.
• Other code (other than JavaScript) such as page rendering runs on the main thread.
• Locks can be taken and memory is allocated on the JavaScript thread. This can cause additional thread preemption.
• The problems are even more difficult with today's generation of mobile devices which have processors with relatively poor performance and power consumption / battery-life issues.

ECMAScript (js) is really fast for a lot of things, and is getting faster all the time depending on what engine is interpreting the code. For something as intensive as audio processing however, you would be much better off using a low-level tool that's compiled to optimize resources specific to the task. I'm currently using ffmpeg on the server side to accomplish something similar.

I know that it is really inefficient to have to send a wav file across an internet connection just to obtain a more compact .ogg file, but that's the current state of things with the web audio api. To do any client-side processing the user would have to explicitly give access to the local file system and execution privileges for the file to make the conversion. Hopefully someone will address this glaring problem soon. Good luck.

Edit: You could also use Google's native-client if you don't mind limiting your users to Chrome. It seems like very promising technology that loads in a sandbox and achieves speeds nearly as good natively executed code. I'm assuming that there will be similar implementations in other browsers at some point.