Web 音频编解码器指南

即使是适度质量的高保真立体声,也可能占用大量磁盘空间。对于 Web 开发者来说,更大的担忧是传输音频所需的网络带宽,无论是用于流媒体还是下载以在游戏中使用。音频数据的编码和解码处理由音频 编解码器COder/DECoder,编码器/解码器)负责。在本文中,我们将探讨 Web 上用于压缩和解压缩音频的音频编解码器、它们的功能和用例,并提供为您的内容选择音频编解码器的指导。

此外,WebRTC 实现通常使用这些编解码器的一个子集来编码和解码媒体,并且可能还支持其他编解码器,以实现视频和音频会议的最佳跨平台支持,并更好地与传统电信解决方案集成。有关详细信息,请参阅WebRTC 使用的编解码器

有关数字音频工作原理的基本概念信息,请参阅文章数字音频概念

常见编解码器

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

编解码器名称(短) 完整编解码器名称 容器支持
AAC 高级音频编码 MP4ADTS3GP
ALAC Apple 无损音频编解码器 MP4QuickTime (MOV)
AMR 自适应多速率 3GP
FLAC 自由无损音频编解码器 MP4OggFLAC
G.711 语音频率脉冲编码调制 (PCM) RTP / WebRTC
G.722 64 kbps 内的 7 kHz 音频编码(用于电话/VoIP RTP / WebRTC
MP3 MPEG-1 音频层 III MP4ADTSMPEG3GP

当 MPEG-1 音频层 III 编解码器数据存储在 MPEG 文件中,且文件中没有视频轨道时,该文件通常被称为 MP3 文件,尽管它仍然是 MPEG 格式文件。

Opus Opus WebMMP4Ogg
Vorbis Vorbis WebMOgg

影响编码音频的因素

影响音频编解码器编码器输出的编码音频的因素大致分为两类:关于源音频格式和内容的详细信息,以及编码过程中编解码器及其配置。

对于影响编码音频的每个因素,几乎总有一条规则是成立的:由于数字音频的保真度取决于将其转换为数据流时所采样的粒度和精度,因此用于表示音频数字版本的数据越多,采样声音与源材料的匹配程度就越高。

源音频格式对编码音频输出的影响

由于编码音频本质上使用较少的位来表示每个样本,因此源音频格式对编码音频大小的影响可能比预期的要小。但是,许多因素仍然会影响编码音频的质量和大小。下表列出了一些关键的源音频文件格式因素及其对编码音频的影响。

源音频格式和内容对编码音频质量和大小的影响
特性 对质量的影响 对大小的影响
声道数 声道数只影响方向感,不影响质量。 每个声道可能会显著增加编码音频的大小,具体取决于内容和编码器设置。
噪音 / 嘶嘶声 不需要的背景噪音或嘶嘶声倾向于直接(通过遮盖前景音频的细节)和间接(通过使音频波形更复杂,因此难以在保持精度的同时减小大小)降低音频质量。 嘶嘶声、静电声或背景噪音增加了音频的复杂性,这通常会降低可能的压缩量。
采样率 每秒可用的样本越多,最终编码音频的保真度可能就越高。 增加采样率会增加编码音频文件的大小。
样本大小 样本越大,每个样本可以包含的细节就越多,从而更准确地表示每个样本。 取决于编解码器;编解码器通常具有内部样本格式,该格式可能与原始样本大小相同,也可能不同。但是,更多的源细节可能会使编码文件更大;它永远不会使其更小。

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

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

编解码器配置对编码音频输出的影响

音频编解码器通常采用巧妙设计且高度复杂的数学算法,将源音频数据压缩以占用更少的内存或网络带宽。除了选择要使用的编码器类型之外,您还可以通过调整参数来调整编码器,这些参数选择特定的算法、调整这些算法并指定在编码时应用多少次。

音频编码器配置对质量和大小的影响
特性 对质量的影响 对大小的影响
无损压缩 无保真度损失 压缩率不太可能超过 40-50%
有损压缩 总是会损失一些保真度;压缩率越高,损失越大 压缩率可达 80-95%
比特率 比特率越高,质量可能越高 比特率越高,编码文件可能越大
音频频率带宽 如果移除的频带中有任何音频,可能会出现明显的保真度损失 移除频带意味着需要编码的数据更少,从而使编码文件更小
立体声编码 简单的立体声和中侧立体声编码不影响质量;但是,强度立体声编码会引入细节损失。 联合立体声可以在一定程度上减小编码音频的大小

可用参数(以及可能值的范围)因编解码器而异,甚至同一编解码器的不同编码工具之间也不同,因此请阅读您使用的编码软件附带的文档以了解更多信息。

影响编码音频大小的特性

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

无损与有损编解码器

音频压缩有两种基本类别。无损压缩算法在不损害声音质量或保真度的情况下减小音频大小。使用FLACALAC等无损编解码器解压缩音频后,结果在各个方面都与原始声音完全相同,精确到每个比特。

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

由于有损编解码器与无损编解码器的工作方式存在差异,特别是无损编解码器必须在压缩方面更加保守,有损编解码器几乎总是比无损编解码器产生更小的压缩音频。

一般来说,选择无损音频的最常见原因是您需要存档质量的存储,或者因为音频样本将被重新混合和重新压缩,并且您希望避免由于重新压缩而在音频中放大伪影。对于音频的实时流媒体,通常需要有损编解码器,以确保数据流能够跟上音频播放速率,无论网络性能如何。

最大声道数

提供给音响系统中每个扬声器的音频由流中的一个音频通道提供。单声道是单个通道。立体声是两个。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(高级音频编码)

高级音频编码AAC)编解码器是 MPEG-4(H.264)标准的一部分;具体来说,是MPEG-4 Part 3MPEG-2 Part 7的一部分。AAC 旨在提供比 MP3 更高的压缩率和更高的音频保真度,已成为一种流行的选择,并且是许多类型媒体中的音频标准格式,包括蓝光光盘和 HDTV,也是从包括 iTunes 在内的在线供应商购买歌曲所使用的格式。

AAC 有许多配置文件,用于定义针对特定用例的音频压缩方法,包括从高质量环绕声到仅用于语音的低保真音频。

作为一种受专利限制的格式,AAC 的支持情况不太可预测。例如,Firefox 仅在操作系统或外部库提供支持时才支持 AAC。

支持的比特率 任意,最高 512 kbps
支持可变比特率 (VBR)
支持的样本格式 32 位整数
支持的采样率 8 kHz - 96 kHz
立体声推荐的最低比特率 48 kHz 采样率下 96 kbps
压缩 有损
最大音频通道数 48(加 16 个低频增强通道)
音频频率带宽 0 Hz - 96 kHz(标准音频通道)
0 Hz - 120 Hz(LFE 通道)
延迟 20 毫秒至 405 毫秒
浏览器兼容性

由于专利问题,Firefox 不直接支持 AAC。相反,Firefox 依赖于平台对 AAC 的原生支持。此功能在不同的 Firefox 版本中在每个平台上引入

Chrome 仅在 MP4 容器中支持 AAC,并且仅支持 AAC 的主配置文件。此外,AAC 在 Chromium 构建中不可用。

容器支持 MP4、ADTS、3GP
RTP / WebRTC 兼容
许可 用于流媒体或分发 AAC 编码内容:无需许可证;编解码器开发者需要通过VIA Licensing获得专利许可证

ALAC (Apple 无损音频编解码器)

Apple 无损音频编解码器ALACApple Lossless)是由 Apple 开发的一种无损编解码器。最初是一个封闭格式,Apple 后来在 Apache 许可证下将其开源。

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

但是请记住,无损编解码器需要更多的带宽和存储容量,在非常具体的用例之外可能不是一个好的选择。

支持的比特率 基于样本格式和采样率,以及压缩级别
支持可变比特率 (VBR)
支持的样本格式 16 位、20 位、24 位和 32 位整数
支持的采样率 1 Hz 至 384,000 Hz
立体声推荐的最低比特率 不适用
压缩 无损;高达 45-60%
最大音频通道数 8(最高 7.1 环绕声)
音频频率带宽 ?
延迟 ?
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
ALAC 支持
容器支持 MP4
RTP / WebRTC 兼容
许可 开放许可证 (Apache License 2.0);GitHub 上提供源代码

AMR(自适应多速率)

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

存储在文件中的 AMR 音频类型可以是 .amr,但也可以封装在 .3gp 文件中。

作为一种语音专用编解码器,AMR 对于任何其他内容(包括仅包含歌唱声音的音频)基本无用。此外,由于 AMR 旨在最大程度地减少容量要求,因此它仅捕获人类语音完整音频频率带宽中绝对必要的部分,以理解所说内容,因此质量会相应降低。如果您需要在对网络和/或存储容量影响最小的情况下录制音频,AMR 是一个不错的选择。但是,如果您需要高保真度的人类语音再现——甚至是低质量的音乐再现——您需要选择另一种格式。

支持的比特率 半速率 (HR) 和全速率 (FR): 1.8 kbps、4.75 kbps、5.15 kbps、5.9 kbps、6.7 kbps、7.4 kbps、7.95 kbps
仅全速率 (FR): 10.2 kbps 和 12.2 kbps
支持可变比特率 (VBR)
支持的样本格式 13 位整数
支持的采样率 8 kHz
立体声推荐的最低比特率 不适用
压缩 有损
最大音频通道数 1
音频频率带宽 200 Hz 至 3,400 Hz
延迟 25 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
AMR 支持 ? ?

虽然 Chrome 浏览器不支持 AMR,但 ChromeOS 支持 AMR-NB(窄带)和 AMR-WB(宽带)。

容器支持 AMR, 3GPP
RTP / WebRTC 兼容
许可 非免费;需要许可证费和年费。详情请参阅VoiceAge 许可

FLAC(自由无损音频编解码器)

FLAC自由无损音频编解码器)是由 Xiph.org 基金会发布的无损音频编解码器。它提供良好的压缩率,且不损失音频保真度;也就是说,解压缩后的音频与原始音频完全相同。由于压缩算法是专门为音频设计的,因此它比使用通用压缩算法获得更好的结果。

FLAC 是对音质要求很高的小型音频效果文件以及音乐存档的绝佳选择。

支持的比特率
支持可变比特率 (VBR)
支持的样本格式 4 位到 24 位整数
支持的采样率 1 Hz 到 65,535 Hz(以 1 Hz 为增量)或 10 Hz 到 655,350 Hz(以 10 Hz 为增量)
立体声推荐的最低比特率
压缩 无损;高达 40-50% 的尺寸缩减
最大音频通道数 8
音频频率带宽 全频谱
延迟 4.3 毫秒至 92 毫秒,典型平均值为 46.4 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
FLAC 支持 51(桌面版)
58(移动版)
11
容器支持 MP4、Ogg、FLAC
RTP / WebRTC 兼容
许可 完全开放且无任何许可要求

G.711(语音频率脉冲编码调制)

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

G.711 不是高保真编解码器,而是经过优化以支持广泛的语音电平(从耳语到喊叫),同时保持高可理解性和低计算复杂性。G.711 使用对数压扩算法,在 8 位样本中提供 14 位的动态范围。它使用 8000 样本/秒的采样率,对应于 64000 bps 的比特率。

G.711 有两种变体,它们表示算法的精确数学方程:µ-law(通常用于北美和日本)和A-law(通常用于世界其他地区)。两种法则之间没有实质性的质量差异,并且可以互相转码音频。然而,在任何重放应用程序或文件格式中指定使用哪种法则都很重要。如果错误地使用 µ-law 算法解压缩 A-law 音频,则会重放得很差,反之亦然。

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

支持的比特率 64 kbps
支持可变比特率 (VBR)
支持的样本格式 编码音频每个样本 8 位
支持的采样率 8 kHz
立体声推荐的最低比特率 128 kbps
压缩 对数压扩(µ-law 或 A-law)
最大音频通道数 2
音频频率带宽 300 Hz – 3400 Hz
延迟 0.125 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
G.711 支持 23 15 22 43 11

G.711 仅支持 WebRTC 连接。

容器支持 3GP、WAV
RTP / WebRTC 兼容
许可 所有适用专利均已过期,因此 G.711 可自由使用,不受限制

G.722(64 kbps (7 kHz) 音频编码)

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

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

G.722 主要用于 WebRTC 连接,因为它是 WebRTC 规范强制要求的音频编解码器之一。

支持的比特率 G.722:48 kbps、56 kbps 和 64 kbps;然而,实际上总是使用 64 kbps
G.722 附件 B 超宽带:64 kbps、80 kbps 和 96 kbps
G.722 附件 D 立体声宽带:64 kbps 和 80 kbps
G.722 附件 D 立体声超宽带:80 kbps、96 kbps、112 kbps 和 128 kbps
支持可变比特率 (VBR)
支持的样本格式 14 位整数
支持的采样率 16 kHz(ADPCM 规定允许 8 kHz、11.025 kHz、22.05 kHz、44.1 kHz,但 G.722 使用 16 kHz)
立体声推荐的最低比特率 44.1 kHz 采样率下 128 kbps
压缩 有损
最大音频通道数 2
音频频率带宽 50 Hz - 7 kHz
延迟 4 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
G.722 支持

仅限 WebRTC。

容器支持 3GP、AMR-WB
RTP / WebRTC 兼容
许可 所有适用专利均已过期;G.722 可自由使用,不受限制

MP3 (MPEG-1 音频层 III)

在 MPEG/MPEG-2 标准指定的音频格式中,MPEG-1 音频层 III(也称为 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 文件的大部分许可问题。这使得它们成为许多项目的不错选择。

支持的比特率 MPEG-1 模式: 32 kbps、40 kbps、48 kbps、56 kbps、64 kbps、80 kbps、96 kbps、112 kbps、128 kbps、160 kbps、192 kbps、224 kbps、256 kbps、320 kbps
MPEG-2 模式: 8 kbps、16 kbps、24 kbps、32 kbps、40 kbps、48 kbps、56 kbps、64 kbps、80 kbps、96 kbps、112 kbps、128 kbps、144 kbps、160 kbps
支持可变比特率 (VBR)
支持的样本格式 16 位整数
支持的采样率 MPEG-1 模式: 32000 Hz、44100 Hz、48000 Hz
MPEG-2 模式: 16000 Hz、22050 Hz、24000 Hz(MPEG-1 支持模式频率的一半)
立体声推荐的最低比特率 48 kHz 采样率下 128 kbps
压缩 有损
最大音频通道数 MPEG-1 模式 2 [2.0]
MPEG-2 模式: 5(加 1 个可选低频增强通道)[5.1]
音频频率带宽 可变,取决于比特率和心理声学分析
延迟 至少 100 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
MP3 支持 3.1
容器支持 MPEG-1, MPEG-2, MP4, ADTS, 3GP
RTP / WebRTC 兼容
许可 欧盟自 2012 年起免专利;美国自 2017 年 4 月 16 日起免专利;现在可自由使用

由于专利原因,Firefox 在版本 71 之前不直接支持 MP3;相反,它使用平台原生库来支持 MP3。此功能在不同的 Firefox 版本中在每个平台上引入

Firefox 中通过外部库在平台上的 MP3 支持
平台 首个支持 MP3 的 Firefox 版本
带 MP3 支持
Windows(Vista 及更高版本) 22
Android 20
Linux(取决于 GStreamer 26
macOS 35

Opus

Opus 音频格式由 Xiph.org 基金会创建,是一种完全开放的音频格式;它已由 IETF 标准化为 RFC 6716。它是一种优秀的通用音频编解码器,可以高效地处理语音等低复杂性音频以及音乐和其他高复杂性声音。

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

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

支持的比特率 6 kbps - 510 kbps
支持可变比特率 (VBR)
支持的样本格式 16 位整数和 32 位浮点数(-1.0 到 1.0)
支持的采样率
配置文件 有效采样率
窄带 (NB) 8 kHz
中频带 (MB) 12 kHz
宽带 (WB) 16 kHz
超宽带 (SWB) 24 kHz
全频带 (FB) 48 kHz

指定的采样率是有效采样率。Opus 使用基于音频带宽而不是采样率的算法。有关详细信息,请参阅RFC 6716,第 2 节。此外,Opus 规范中有一个可选部分(Opus Custom)确实允许非标准采样率,但不鼓励使用此功能。

立体声推荐的最低比特率 48 kHz 采样率下 96 kbps
压缩 有损
最大音频通道数 255(最多 1 个 LFE 通道)
音频频率带宽
配置文件 音频带宽
窄带 (NB) 4 kHz
中频带 (MB) 6 kHz
宽带 (WB) 8 kHz
超宽带 (SWB) 12 kHz
全频带 (FB) 20 kHz

尽管奈奎斯特-香农采样定理表明音频带宽可达采样率的一半,但 Opus 不允许编码超出最大 20 kHz 的音频频带,因为人耳无论如何都无法感知 20 kHz 以上的任何内容。这节省了编码音频中的一些空间。

延迟 5 毫秒至 66.5 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
Opus 支持 33 14 15 20 11

此信息指代 HTML <audio><video> 元素中对 Opus 的支持,而非 WebRTC。

Safari 仅在 macOS High Sierra (10.13) 或 iOS 11 上,并且仅当封装在 CAF 文件中时,才支持 <audio> 元素中的 Opus。

容器支持 Ogg、WebM、MPEG-TS、MP4
RTP / WebRTC 兼容
许可 完全开放且无任何许可要求

Vorbis

Vorbis 是 Xiph.org 基金会推出的一种开放格式,支持多种声道组合,包括单声道、立体声、多声道、四声道、5.1 环绕声、全景声或最多 255 个独立音频声道。根据编码时使用的质量设置,最终比特率可在 45 kbps 到 500 kbps 之间变化。Vorbis 本身使用可变比特率编码;在压缩过程中,比特率可以根据需要从一个样本到下一个样本变化。

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

支持的比特率 45 kbps - 500 kbps
支持可变比特率 (VBR)
支持的样本格式 16 位整数
支持的采样率 8 kHz - 192 kHz
立体声推荐的最低比特率 48 kHz 下 192 kbps;这通常通过将质量级别设置为 6 到 8 来实现。
压缩 有损
最大音频通道数 255
音频频率带宽
延迟 至少 100 毫秒
浏览器兼容性
特性 Chrome Edge Firefox Opera Safari
Vorbis 支持 4 17 3.5 11.5

此信息指代 HTML <audio><video> 元素中对 Vorbis 的支持,而非 WebRTC。

容器支持 Ogg、WebM
RTP / WebRTC 兼容
许可 完全开放且无任何许可要求

选择音频编解码器

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

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

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

  • 编码后的音频是否会被重新混合或重新压缩?如果是,请避免有损压缩,因为重新压缩音频会加剧其损失;或者至少尽可能少地使用压缩。
  • 如果音频需要转换为特定的文件类型,请记住这一点,因为媒体容器通常支持可用编解码器的一个特定子集。
  • 编解码器将处理哪种音频内容?某些编解码器专门设计用于仅限语音的内容(它们利用了人类语音所需的降低的频率范围)。其他编解码器可能在编码特定音乐类型时算法上表现更差。
  • 每个编解码器有哪些比特率和其他可配置属性,可能使其成为好的(或差的)选择?
  • 对于您的需求,延迟在多大程度上重要?如果您需要非常精确的计时声音,延迟越低越好。
  • 您需要实现多大的压缩率?

让我们考虑一些常见的场景来感受一下决策过程。

示例:流媒体音乐

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

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

通常在流媒体音乐时,延迟并不特别重要。可能的例外情况包括循环音乐,您需要音乐能够不间断地反复播放,或者您需要在歌曲之间没有间隙的情况下连续播放。这对于古典音乐、戏剧配乐以及游戏过程中的背景音乐尤为重要。

对于一般音乐播放,最有可能的三个候选是 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 可能是您的最佳选择。当然,如果您可以提供多种格式(例如,通过在 <audio><video> 元素中使用 <source> 元素),您可以避免许多或所有这些例外情况。

示例:下载音乐

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

对于实际的音乐下载服务,您可以根据用户选择的偏好,提供 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 毫秒。

注意: 有关 WebRTC 及其可使用的编解码器的更多信息,请参阅WebRTC 使用的编解码器

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

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

示例:专业混音的音频片段

压缩将被混音或重新混音的音频时,您通常希望保真度损失为零或接近零,这表明可能需要使用无损编解码器。然而,由于无损编码的压缩级别自然远低于有损编码,您可能会发现,如果您的源音频足够大,您可能仍然不得不选择有损编码器,尤其是在您无法控制媒体下载速率的 Web 环境中。

假设无损压缩是这里的最佳选择(通常如此,只要音频文件很小),那么从编解码器角度来看,三个最有力的候选是 FLACApple 无损 (ALAC)MPEG-4 ALS。我们选择哪个取决于浏览器支持以及哪些媒体容器格式支持它们。

为了本示例的目的,我们假设所有浏览器都具有与 Firefox 相同的编解码器和容器支持(尽管这远非事实)。在做出决策时,请考虑对编解码器的实际支持范围。

  • Firefox 支持 FLAC 在其原生容器以及 Ogg 和 MPEG-4 (MP4) 文件中。
  • 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 或类似工具进行安装。

另见