Web 音频编解码指南

下面的列表指出了 Web 上最常用的编解码器以及支持它们的容器（文件类型）。如果您只需要知道可以使用哪些编解码器，那么这就是适合您的内容。当然，各个浏览器可能选择支持或不支持所有这些编解码器，并且它们对哪些容器类型可以使用这些编解码器的支持也可能有所不同。此外，浏览器可以选择支持此列表中未包含的其他编解码器。

影响音频编解码器编码器输出的编码音频的因素一般分为两类：有关源音频格式和内容的详细信息，以及编码过程中的编解码器及其配置。

对于每个影响编码音频的因素，都有一条几乎总是正确的简单规则：因为数字音频的保真度是由用于将其转换为数据流的采样样本的粒度和精度决定的，所以用于表示音频数字版本的数据越多，采样声音与源材料的匹配程度就越高。

由于编码音频本质上使用更少的位来表示每个样本，因此源音频格式实际上可能对编码音频大小的影响不如人们预期的那样大。但是，许多因素仍然会影响编码音频的质量和大小。下表列出了许多关键的源音频文件格式因素及其对编码音频的影响。

当然，这些影响可以通过编码音频时做出的决定来改变。例如，如果编码器配置为降低采样率，则采样率对输出文件的影响将相应降低。

有关音频数据的这些和其他功能的更多信息，请参阅音频数据格式和结构。

音频编解码器通常采用巧妙设计且高度复杂的数学算法来获取源音频数据并对其进行压缩，以便在内存或网络带宽中占用更少的空间。除了选择要使用的编码器类型外，您还可以有机会使用参数调整编码器，这些参数可以选择特定的算法、调整这些算法并指定在编码时应用多少次传递。

可用的参数（以及可能值的范围）因编解码器而异，甚至在同一编解码器的不同编码实用程序之间也存在差异，因此请阅读您使用的编码软件附带的文档以了解更多信息。

几个因素会影响编码音频的大小。其中一些是源音频形式的问题；另一些则与编码音频时做出的决策有关。

无损编解码器与有损编解码器

音频压缩主要分为两类。**无损**压缩算法在不影响声音质量或保真度的情况下减小音频的大小。解码使用无损编解码器（如FLAC或ALAC）压缩的音频后，结果在各个方面都与原始声音相同，精确到每个位。

有损编解码器则利用了人耳并非完美的音频解释器，以及人脑可以从不完美或嘈杂的音频中提取重要信息的事实。它们去除掉很少使用的音频频率，容忍解码输出的精度损失，并使用其他方法来损失音频内容、质量和保真度，从而生成更小的编码媒体。解码后，输出在不同程度上仍然可以理解。使用的特定编解码器（以及选择的压缩配置）决定了人耳听到的输出与原始未压缩音频信号的接近程度。

由于有损编解码器的工作方式与无损编解码器不同，尤其是无损编解码器必须对其压缩更加保守，因此有损编解码器几乎总是产生比无损编解码器小得多的压缩音频。

一般来说，选择无损音频的最常见原因是需要档案级存储，或者音频样本将被重新混音和重新压缩，并且希望避免由于重新压缩导致音频中出现伪影的放大。对于音频的实时流传输，通常需要有损编解码器，以确保数据流能够跟上音频播放速率，而不管网络性能如何。

提供给声音系统中每个扬声器的音频由流中的一个音频声道提供。单声道声音是一个声道。立体声是两个声道。5.1环绕声有五个音频声道，加上一个低频增强（LFE）声道。

LFE声道专门设计用于存储低频音频数据，并且通常用于提供例如低音炮的音频数据。当您看到以X.Y形式（例如2.1或5.1）编写的音频声道数时，小数点后的数字Y是LFE声道的数量。例如，MP3支持一个LFE声道，而AAC最多支持16个。

除了为声音系统中的特定扬声器提供音频外，某些编解码器还可以允许使用音频声道提供替代音频，例如不同语言的语音或视障人士的描述性音频。

编解码器的音频频率带宽指示可以使用该编解码器表示的音频频率范围。一些编解码器专门通过消除落在给定频率范围之外的音频来工作。采样率与编解码器表示的波形的最大声音频率之间存在相关性。在理论上，编解码器可以表示的最大频率是采样率除以二；此频率称为奈奎斯特频率。实际上，最大值略低，但非常接近。

当编解码器设计或配置为表示人类语音而不是广泛的声音时，音频频率带宽尤其明显。人类语音通常位于300 Hz到18 kHz的音频频率范围内。但是，绝大多数人类发声存在于300 Hz到8 kHz的范围内，并且您可以在500 Hz到3 kHz的频率范围内捕获足够的人类发声，仍然可以理解。

因此，特定于语音的编解码器通常首先丢弃落在设定范围之外的声音。该范围是音频频率带宽。例如，G.722 去除了 50 Hz 到 7 kHz 音频频率带宽之外的声音。这从一开始就减少了需要编码的数据量。

下面我们将简要介绍每个编解码器，了解其基本功能和主要用例。

高级音频编码（AAC）编解码器定义为MPEG-4（H.264）标准的一部分；具体来说，作为MPEG-4第3部分和MPEG-2第7部分的一部分。AAC旨在能够以比MP3更高的音频保真度提供更多压缩，已成为一种流行的选择，并且是许多类型媒体（包括蓝光光盘和高清电视）中音频的标准格式，以及从iTunes等在线供应商购买歌曲时使用的格式。

AAC有许多配置文件，定义了针对特定用例压缩音频的方法，包括从高品质环绕声到仅用于语音的低保真音频等各种情况。

作为一种受专利保护的格式，AAC的支持在某种程度上是不确定的。例如，Firefox仅在操作系统或外部库提供支持的情况下才支持AAC。

苹果无损音频编解码器（ALAC或Apple Lossless）是由苹果开发的一种无损编解码器。在最初是一个封闭格式之后，苹果将其在Apache许可下开放。

ALAC的跨平台和浏览器支持并不强大，这使其成为不太理想的通用选择。但是，如果您的目标主要是macOS和iOS用户，则可能值得考虑，因为操作系统已集成对ALAC的支持。否则，如果您必须使用无损编解码器，则FLAC可能是更好的选择。

但是，请记住，无损编解码器需要大量的带宽和存储容量，并且可能不是非常具体的用例之外的理想选择。

自适应多速率音频编解码器针对有效编码人类语音进行了优化。它于1999年作为用于GSM和UMTS蜂窝电话的3GPP音频标准的一部分被标准化，并使用多速率窄带算法以大约7.4 kbps的电话级质量级别对音频频率进行编码。除了用于实时电话外，AMR音频还可以用于语音邮件和其他短音频录音。

存储在文件中的AMR音频可以键入.amr，但也可以封装在.3gp文件中。

作为一种特定于语音的编解码器，AMR对于任何其他内容（包括仅包含人声的音频）基本上都是无用的。此外，由于AMR旨在最大限度地降低容量要求，因此它仅捕获理解所说内容绝对必要的完整人类语音音频频率带宽的一部分，因此质量相应降低。如果您需要以最小的网络和/或存储容量影响来录制音频的功能，则AMR可以是一个不错的选择。但是，如果您需要高保真地再现人类语音（甚至低质量的音乐再现），则需要选择其他格式。

FLAC（免费无损音频编解码器）是由Xiph.org基金会发布的一种无损音频编解码器。它提供良好的压缩率，并且不会损失音频保真度；也就是说，解压缩的音频与原始音频相同。由于压缩算法专门针对音频设计，因此它比使用通用压缩算法获得的结果更好。

FLAC非常适合需要原始质量和音调准确性的较小的音频效果文件，以及音乐的存档。

国际电信联盟（ITU）发布的G.711规范于1972年发布，用于定义电话应用的标准音频编码。它支持覆盖300到3400 Hz频率的语音级音频。它广泛用于电话通信和语音邮件，并且是可以通过公共电话网络传输的最高质量的音频编码。

G.711不是高保真编解码器，而是针对支持各种语音级别（从耳语到喊叫）并在保持高清晰度和低计算复杂度的同时进行了优化。G.711使用对数压缩扩展算法，在8位样本中提供14位的动态范围。它使用8000样本/秒的采样率，对应于64000 bps的比特率。

G.711 有两种变体，它们指示了算法的精确数学公式：µ律（通常用于北美和日本）和A律（世界其他地区常用）。这两种律之间在质量上没有实质性差异，并且可以轻松地将音频从一种转换为另一种。然而，在任何回放应用程序或文件格式中指定使用哪种律都很重要。如果错误地使用µ律算法解压缩A律音频，则回放效果会很差，反之亦然。

所有WebRTC解决方案都必须支持此编解码器，因为它简单易于实现，并且广泛用于所有现代计算平台，并具有广泛的兼容性。

G.722 编解码器由国际电信联盟 (ITU) 发布，专为语音压缩而设计。其音频编码带宽限制在 50 Hz 至 7,000 Hz 范围内，涵盖了典型人类发声的大部分频率范围。这使得它不适合处理任何可能超出人类语音范围的音频，例如音乐。

G.722 音频使用自适应差分脉冲编码调制 (ADPCM) 进行编码，其中每个样本并非由其绝对值表示，而是由一个值表示新样本与前一个样本的差异。

G.722 主要用于 WebRTC 连接，因为它是由 WebRTC 规范规定的音频编解码器之一。

在 MPEG/MPEG-2 标准指定的音频格式中，MPEG-1 音频第 3 层——也称为MP3——是迄今为止使用最广泛、最知名的格式。MP3 编解码器由MPEG-1 第 3 部分和MPEG-2 第 3 部分定义，并于 1991 年推出（并于 1992 年最终确定）。

当 MP3 格式音频存储在 MPEG 容器内时，生成的的文件也被称为“MP3 文件”或“MP3”。具有普遍存在的 .mp3 扩展名的文件存储在可能是世界上分布最广泛的音频文件格式中，这在很大程度上推动了 20 世纪 90 年代末和 21 世纪初的数字音频革命。

MPEG-1 MP3 音频支持比 MPEG-2 文件中的 MP3 音频更高的比特率和更高的采样率。MPEG-1 格式的 MP3 通常最适合音乐或其他复杂音频，而 MPEG-2 模式 MP3 音频可用于语音和其他更简单的音频。

MP3 背后的专利已过期，消除了在项目中使用 MP3 文件的大多数或全部许可问题。这使得它们成为许多项目的良好选择。

出于专利原因，Firefox 在 71 版之前没有直接支持 MP3；而是使用平台本机库来支持 MP3。此功能是在每个平台的不同 Firefox 版本中引入的。

Opus 音频格式由 Xiph.org 基金会创建，是一个完全开放的音频格式；它已由IETF 标准化为RFC 6716。它是一种用途广泛的通用音频编解码器，可以有效地处理语音等低复杂度音频以及音乐和其他高复杂度音频。

Opus 支持多种压缩算法，甚至可以在同一个音频文件中使用多种算法，因为编码器可以为每一帧音频选择比特率、音频带宽、算法和其他压缩设置细节。

Opus 是一款适用于 Web 应用程序的全面音频编解码器，可用于您想到的任何音频任务。

Vorbis 是 Xiph.org 基金会的一个开放格式，它支持各种声道组合，包括单声道、立体声、复音、四声道、5.1 环绕声、全景声或最多 255 个独立的音频声道。根据编码过程中使用的质量设置，生成的比特率可以从大约 45 kbps 到 500 kbps 不等。Vorbis 本身使用可变比特率编码；比特率可以根据压缩过程中的需要从一个样本变化到下一个样本。

通常，在类似质量水平下，Vorbis 在大小和比特率方面比 MP3 更有效率。这以及其免费和开放的许可证使其成为许多类型音频数据的良好选择，只要其高延迟不是问题。

通常，无论您使用什么编解码器，它通常都能完成工作，即使它不是理想的选择，只要您选择的编解码器不是专门为完全不同的源音频设计的。例如，选择仅用于语音的编解码器并尝试将其用于音乐将无法获得可用的结果。

但是，某些编解码器可能会限制兼容性，而其他编解码器可能比其他编解码器更适合您的需求。在这里，我们将提供指导，以帮助您为您的用例选择合适的编解码器。

在选择用于音频的编解码器时，您应该首先考虑以下问题

• 编码后的音频是否会被重新混音或重新压缩？如果是，请避免使用有损压缩，因为这会因重新压缩音频而加剧；或者至少尽可能少地使用压缩。
• 如果音频需要进入特定文件类型，请牢记这一点，因为媒体容器通常支持可用编解码器的特定子集。
• 编解码器将处理哪种音频内容？某些编解码器专门为仅用于语音的内容而设计（它们利用了人类语音所需的频率范围缩减）。其他编解码器在编码特定类型的音乐时，算法上可能表现较差。
• 每个编解码器具有哪些比特率和其他可配置属性，这些属性可能使其成为良好（或糟糕）的选择？
• 延迟在您的需求中在多大程度上（如果有的话）很重要？如果您需要非常精确定时的音频，则延迟越低越好。
• 您需要实现多少压缩？

让我们考虑一些常见场景，以了解决策过程。

对于流媒体音乐，您需要选择一个编解码器，最大程度地减少带宽使用，同时尽可能少地通过压缩将伪像引入音频。这是必要的，因为音乐下载的速度不能大于网络上可用的带宽量，并且理想情况下应该为网络速度波动和其他应用程序使用网络留出空间。

除非有对无损压缩的特定需求，或者网络带宽保证足够高以支持它，否则有损压缩方案是一个不错的选择。您选择哪一个取决于浏览器兼容性和您可能需要编解码器支持的任何特殊功能的可用性。

通常，在流媒体音乐时，延迟并不特别重要。可能的例外包括循环音乐，您需要音乐能够连续播放，或者当您需要能够连续播放歌曲且歌曲之间没有间隙时。这对于古典音乐、戏剧配乐以及游戏中的背景音乐尤其重要。

对于一般的音乐播放，三个最可能的候选者是 MP3、AAC 和 Vorbis。

• MP4 容器中的 AAC 格式为所有主流浏览器所支持，这使其成为一个极佳的选择。
• Vorbis 几乎总是用于 Ogg 文件，但 Ogg 容器并非所有浏览器都支持。即使是支持 Vorbis 的 Microsoft Edge，目前也不支持 Ogg 容器。
• MP3（MPEG-1 音频层 III）为所有主流浏览器所支持。这些文件是包含音频层 III 轨道的 MPEG-1 文件。

如果您需要在音乐播放过程中将延迟降到最低，则应重点考虑 Opus，它在通用编解码器中拥有最低的延迟范围（5 毫秒至 66.5 毫秒，而其他编解码器的延迟至少为 100 毫秒）。

基于此，如果您只能支持一种音频格式，那么 AAC 可能是最佳选择。当然，如果您能够提供多种格式（例如，在您的 <source> 元素中使用 <audio> 和 <video> 元素），则可以避免许多或所有这些例外情况。

用户下载的音乐可以压缩到比流媒体音乐更大的总文件大小，因为（与流媒体不同）下载速度是否低于媒体的播放速度并不重要。这意味着您可以考虑使用更高比特率的有损压缩，这会导致文件更大，但保真度损失更小。或者，您可以选择无损格式。选择主要取决于您的应用程序需求和用户偏好的结合。

对于实际的音乐下载服务，您可以根据用户选择的偏好，提供 128 Kbps MP3 文件、256 kbps AAC 文件（在 MP4 容器中）或 FLAC 文件供用户下载歌曲。如果您需要选择一种格式，请选择一种根据您的需求和正在下载的音频内容类型有意义的格式。

当然，一般来说，MP3 是最常用的音乐格式；如果可能，请选择至少 192 kbps 的比特率。另一方面，iTunes 商店以 256 kbps AAC 格式分发音乐。

人类语音的特定特征允许特定于语音的编解码器比大多数通用编解码器更大幅度地压缩音频。这是因为，虽然人类可以听到大约 20 Hz 至 20,000 Hz 的频率范围，人类语音的频率范围约为 300 Hz 至 18,000 Hz，但为了理解所说内容而需要的大部分语音声音都位于大约 500 Hz 至 3,000 Hz 的频率范围内。这意味着仅用于语音的编解码器可以丢弃所有其他频率。

然而，特定于语音的编解码器本质上都是有损的，任何在语音捕获范围之外的频带中包含重要信息的声音都将完全丢失。这使得这些编解码器完全不适合除口语以外的任何用途。即使是仅包含语音但包含唱歌而不是说话的音频，在这些格式中也可能无法达到可接受的质量。

语音录制和播放通常需要低延迟，以便与视频轨道同步，或者为了避免串扰或其他问题。幸运的是，导致语音编解码器在存储空间方面如此高效的特性也使它们往往具有非常低的延迟。如果您正在使用 WebRTC，例如 G.722 的延迟为 4 毫秒（而 MP3 的延迟超过 100 毫秒），AMR 的延迟约为 25 毫秒。

网络上通常用于仅语音编码的编解码器是 G.722 和 AMR。AMR 是一种窄带编解码器，仅编码 200 Hz 至 3,400 Hz 之间的频率，比特率通常约为 7.4 kbps，而 G.722 是一种宽带编解码器，将音频带宽扩展到 50 Hz 至 7,000 Hz，比特率更高，通常为 64 kbps。

如果您有足够的网络带宽可以使用，并且合理地确定您的用户也拥有足够的带宽，那么 G.722 是更好的选择。为了在受限环境中最大限度地提高存储和网络效率，请选择 AMR。

在压缩将要进行混音或重新混音的音频时，您通常希望保真度损失为零或接近零，这表明可能需要使用无损编解码器。但是，由于无损编码的压缩级别自然比有损编码低得多，因此您可能会发现，如果您的源音频足够大，您可能无论如何都必须选择有损编码器，尤其是在无法控制媒体下载速度的网络环境中。

假设无损压缩是这里最好的选择（通常情况下确实如此，只要音频文件足够小），从编解码器的角度来看，三个最强的候选者是 FLAC、Apple Lossless (ALA 和 MPEG-4 ALS。我们选择哪一个将取决于浏览器支持和哪些媒体容器格式支持它们。

出于本示例的目的，我们假设所有浏览器都具有与 Firefox 相同的编解码器和容器支持（尽管这远非事实）。在做出决定时，请考虑编解码器的实际支持范围。

• Firefox 支持 FLAC 本机容器中的 FLAC，以及 Ogg 和 MPEG-4 (MP4) 文件中的 FLAC。
• Firefox 仅通过其特定于平台的 QuickTime 支持支持 Apple Lossless。
• Firefox 不支持 MP4 ALS。

在这种情况下，FLAC 看起来最可能是最佳编解码器；ALAC 几乎没有直接的浏览器支持。

有许多工具可用于编码音频。最简单的工具是那些用于提取 CD 或提取音频文件并快速自动将其转换为 MP3 或 AAC 格式以存储在库中的工具，例如 iTunes。但在开发将音频用作应用程序组件（例如游戏）的 Web 应用程序时，您将需要更多地控制编码过程，以及围绕编码音频时使用的格式的更多选项。

一些流行的选项

FFmpeg

FFmpeg 可谓是最知名和最广受认可的开源编解码器软件包，它支持大多数最流行的音频格式，并提供用于编码、解码和执行音频和视频格式转换的命令行工具和库。macOS、Linux 和 Windows 均提供二进制文件。

Handbrake

一个非常流行的 FFmpeg 开源前端，它添加了一个图形用户界面，使控制 FFmpeg 在编码音频和/或视频时提供的各种选项变得更加容易。macOS、Linux 和 Windows 均提供二进制文件。

Audacity

一个开源音频编辑器，支持从许多不同的格式加载音频、编辑、过滤和调整音频，并以原始格式或新格式保存回音频。macOS、Linux 和 Windows 均提供。

LAME

一个高质量的开源 MP3 编码器，支持 CBR、ABR 和 VBR 编码以及各种其他选项。仅由 LAME 项目以源代码形式分发，但可以使用 Homebrew 或类似工具安装。

• 媒体容器格式
• <audio> 和 <video> 元素
• WebRTC API
• Web 视频编解码指南
• WebRTC 使用的编解码器