audio - 在javascript中将.wav文件转换为.ogg

Question

我正在尝试从浏览器捕获用户的音频输入。我已经用 WAV 完成了，但是文件真的很大。我的一个 friend 告诉我，OGG 文件要小得多。
有谁知道如何将WAV转换为OGG？
我也有原始数据缓冲区，我真的不需要转换。但我只需要OGG编码器。

这是来自 Matt Diamond's RecorderJS 的 WAV 编码器:

function encodeWAV(samples){
  var buffer = new ArrayBuffer(44 + samples.length * 2);
  var view = new DataView(buffer);

  /* RIFF identifier */
  writeString(view, 0, 'RIFF');
  /* file length */
  view.setUint32(4, 32 + samples.length * 2, true);
  /* RIFF type */
  writeString(view, 8, 'WAVE');
  /* format chunk identifier */
  writeString(view, 12, 'fmt ');
  /* format chunk length */
  view.setUint32(16, 16, true);
  /* sample format (raw) */
  view.setUint16(20, 1, true);
  /* channel count */
  view.setUint16(22, 2, true);
  /* sample rate */
  view.setUint32(24, sampleRate, true);
  /* byte rate (sample rate * block align) */
  view.setUint32(28, sampleRate * 4, true);
  /* block align (channel count * bytes per sample) */
  view.setUint16(32, 4, true);
  /* bits per sample */
  view.setUint16(34, 16, true);
  /* data chunk identifier */
  writeString(view, 36, 'data');
  /* data chunk length */
  view.setUint32(40, samples.length * 2, true);

  floatTo16BitPCM(view, 44, samples);

  return view;
}

有OGG的吗？

Answer 1

对于那些对这篇文章投反对票的人:如果不花时间提供一些关于为什么这个问题在某种程度上“不好”的见解，就对问题投反对票真的没有成效。我认为这个问题是有道理的，发帖人显然花了一些时间试图自己解决这个问题。 Web Audio spec实际上是为了允许这种功能，但还没有接近实现这个目的:

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.

这是关于当前 w3c audio spec draft 的声明，这说明了以下几点:

在 JavaScript 中处理音频时，要获得可靠、无故障的音频，同时实现相当低的延迟是极具挑战性的，尤其是在处理器负载较重的情况下。

JavaScript 比经过严格优化的 C++ 代码慢得多，并且无法利用 SSE 优化和多线程，这对于在当今处理器上获得良好性能至关重要。与 JavaScript 相比，优化的 native 代码处理 FFT 的速度大约快 20 倍。对于大量音频源的卷积和 3D 空间化等重载音频处理来说，它的效率不够高。

setInterval() 和 XHR 处理将从音频处理中窃取时间。在一个相当复杂的游戏中，游戏物理和图形需要一些 JavaScript 资源。这带来了挑战，因为音频渲染是截止日期驱动的(以避免故障并获得足够低的延迟)。
JavaScript 不在实时处理线程中运行，因此可以被系统上运行的许多其他线程抢占。

垃圾收集(以及 Mac OS X 上的自动释放池)可能会导致 JavaScript 线程出现不可预知的延迟。

多个 JavaScript 上下文可以在主线程上运行，从而从执行处理的上下文中窃取时间。

页面渲染等其他代码(JavaScript 除外)在主线程上运行。

可以使用锁并在 JavaScript 线程上分配内存。这可能会导致额外的线程抢占。

对于当今这一代移动设备而言，这些问题更加困难，这些移动设备的处理器性能相对较差，并且存在功耗/电池生命周期问题。

ECMAScript (js) 在很多事情上都非常快，并且一直在变得更快，具体取决于解释代码的引擎。但是，对于像音频处理这样密集的事情，您最好使用经过编译以优化特定于任务的资源的低级工具。我目前正在使用 ffmpeg on the server一边完成类似的事情。

我知道必须通过 Internet 连接发送 wav 文件以获取更紧凑的 .ogg 文件确实效率低下，但这是网络音频 api 的当前状态。要进行任何客户端处理，用户必须明确授予对本地文件系统的访问权限以及文件的执行权限以进行转换。希望有人能尽快解决这个明显的问题。祝你好运。

编辑:您也可以使用 Google 的 native-client如果您不介意将用户限制为 Chrome。这似乎是一种非常有前途的技术，可以加载到沙箱中并实现几乎与 native 执行代码一样好的速度。我假设在某些时候其他浏览器中会有类似的实现。