MP3、AAC 与 Opus：现代音频编解码器对比
为什么你选择的编解码器至关重要
大多数人选择音频格式就像选字体一样：看到熟悉的就用，然后就不管了。MP3 作为默认选项已经太久了，以至于人们很容易认为它就是唯一的“音频格式”。但你选择的编解码器会带来实实在在的影响。文件大小、低比特率下的音频保真度、设备兼容性，甚至流媒体成本，都会因为你选择的是 MP3、AAC 还是 Opus 而发生巨大变化。 举个实际的例子。一首四分钟的流行歌曲，用 128 kbps 的 MP3 格式编码，大小约为 3.7 MB。同样这首歌，用 128 kbps 的 AAC 格式编码，听起来会明显更清晰——效果堪比 160–192 kbps 的 MP3——同时占用同样的空间。如果用 96 kbps 的 Opus 格式编码，你得到的音质往往能超过前两者，而文件大小却只有 2.8 MB 左右。无论你是管理成千上万的音轨，运营一个播客网络，还是在不稳定的移动网络下传输音频，这些差异都会迅速累积起来。 本文将为你剖析这三种编解码器在实际应用中的差异。我们会探讨它们各自的优势所在，并为你提供转换时可以使用的具体设置。我们的目标不是要评选出唯一的赢家，因为根本就没有。而是希望让你掌握足够的知识，为你的项目做出明智的选择。
MP3：拒绝退役的编解码器
MP3 (MPEG-1 Audio Layer III) 于 1993 年标准化，到 90 年代末已经风靡全球。它的专利最终在 2017 年到期，使其可以完全免费使用。这种免费特性，加上三十年来在硬件和软件上的广泛支持，正是 MP3 至今仍是数字音频领域中一个无法绕开的部分的原因。 从技术上讲，MP3 依赖一种心理声学模型来丢掉人耳最不容易察觉的音频信息。这包括被更响亮的声音所掩盖的声音、约 16 kHz 以上的极高频，以及一些瞬态细节。在高比特率（256–320 kbps）下，对于大多数人在大多数设备上听起来，效果是完美的。但一旦降到 128 kbps，你就能听出问题了。只要你注意到鼓声的前回声，或是镲片上那种轻微的“漩涡”质感，你就再也无法忽略它了。 编码时，直接使用可变比特率 (VBR) 就行。在文件大小相同的情况下，它的音质几乎总是优于恒定比特率 (CBR)。LAME 编码器的 V0 预设（平均码率 220–260 kbps）对于严苛的听音来说是通透的。V2 预设（平均码率 170–210 kbps）则在音质和大小之间取得了绝佳的平衡，非常适合日常使用。唯一需要使用 CBR 的情况是某些老旧硬件有此要求，比如老式汽车音响或某些运动手环。在这种情况下，192 kbps 是个稳妥的选择。 那么 MP3 的短板在哪里呢？它的“联合立体声”模式在低比特率下会损害立体声声场效果，而且与现代编解码器相比，其音质在 128 kbps 以下会断崖式下跌。它还缺乏对无缝播放的原生支持，这对任何听现场专辑或 DJ mix 的人来说都是一个持续的困扰。
AAC：基本成功的指定继承者
作为 MP3 的正式继承者，AAC（高级音频编码）于 1997 年被标准化。如果不是苹果公司在 2003 年决定将其用于 iTunes 商店，它可能至今仍默默无闻。这一举动给了它所需的主流市场立足点。如今，AAC 是 Apple Music、YouTube 音频以及大多数数字广播的标准。 AAC 背后的工程师们在 MP3 的基础上做了一些聪明的升级。该编解码器最多支持 48 个音频通道（MP3 实际上仅限于立体声），使用了更高效的滤波器组，并在低比特率下能更智能地处理立体声信息。听感就是最好的证明：在像 Hydrogenaudio 这样的社区进行的盲听测试中，128 kbps 的 AAC 始终比同比特率的 MP3 听起来更好，更接近原始音源。 AAC 并非一成不变；它有多种配置。AAC-LC（低复杂度）是音乐和通用音频的主力，iTunes 和 YouTube 都在使用。对于非常低的比特率（32–64 kbps），HE-AAC（高效率）使用一种名为“频谱带复制”的巧妙技术来重建高频，非常适合流式传输语音或广播。HE-AAC v2 则通过“参数化立体声”更进一步，能在 24–32 kbps 这样令人印象深刻的低码率下挤出可用的语音质量。 对于你自己的音乐，256 kbps 的 AAC-LC（苹果的标准）在消费级设备上几乎无法与无损音源区分开来。对于播客，96–128 kbps 的单声道是一个很好的目标。但 AAC 的致命弱点在于授权问题。它仍受专利保护，这就是为什么一些开源的 Linux 发行版默认不包含它，以及为什么一些嵌入式系统的开发者为了避免法律麻烦干脆跳过它。
Opus：一项被世人低估的工程奇迹
Opus 是一个开放、免版税的编解码器，由 IETF 于 2012 年标准化 (RFC 6716)。它由 Xiph.Org 和 Mozilla 的开发者们共同开发，巧妙地结合了两种不同的技术：用于语音的 SILK（源自 Skype）和用于音乐的 CELT。其结果是一个强大的混合体。它可以从 6 kbps 的清晰窄带语音扩展到 510 kbps 的高保真立体声音乐，同时保持极低的算法延迟（可低至 2.5 毫秒）。 它的每比特质量令人惊叹。在正式的听音测试中，96 kbps 的 Opus 在音乐表现上稳定地持平或优于 128 kbps 的 AAC-LC。在 64 kbps 时，Opus 甚至能与 96 kbps 的 AAC 相媲美。这些可不是微不足道的学术差异。对于任何需要大规模支付带宽或存储费用的人来说，这意味着巨大的成本节省。 那为什么 Opus 没有无处不在呢？一个词：兼容性。在 iOS 上，没有第三方库就无法原生支持它，而 Android 在 5.0 版本之前也不支持。大多数专用音乐播放器——从便携式高保真播放器到汽车音响和智能电视——根本无法播放 Opus 文件。如果你要分发音频给未知的设备，把它作为默认格式风险很高。但对于服务器端处理、网页分发，或任何你控制播放环境的内部工作流来说呢？坦白讲，你就应该用 Opus。在低到中等比特率下，它是完成任务的最佳工具。
正面交锋：质量、比特率与文件大小
让我们抛开那些模糊的说法，来看看已发布的听音测试和编码器基准测试中的实打实的数据。以下数据使用了参考级编码器：用于 MP3 的 LAME 3.100，苹果的 AAC 编码器，以及用于 Opus 的 libopus，测试对象均为典型的立体声音乐。 在 64 kbps 立体声的极低码率下，MP3 充满了可闻的失真，比如金属质感的混响和模糊不清的打击乐。AAC-LC 仅能满足随意听听。而 Opus 在这里是无可争议的冠军，大多数听众认为它的音质和 96 kbps 的 MP3 一样好。 提升到 128 kbps 立体声，情况就变了。MP3 的表现变得不错，但还不够通透。对于大多数音乐来说，AAC-LC 已经非常接近通透了。然而，对于绝大多数听众和音乐素材来说，Opus 已经达到了事实上的通透。一旦你达到 192 kbps，这三者在典型的消费级设备上的差异就变得无关紧要了。 就文件大小而言，一个 60 分钟的音频文件：一个 128 kbps 的 MP3 大约是 55 MB。一个 128 kbps 的 AAC-LC 文件大小相同，但听起来更好。一个 96 kbps 的 Opus 文件，其感知质量与 128 kbps 的 AAC 文件相似，但大小只有约 41 MB。 对于语音，差距甚至更大。48 kbps 单声道的 HE-AAC 能产生可靠的播客级音质。而 Opus 仅用 32 kbps 单声道就能达到相当甚至更好的效果。对于一本 10 小时的有声读物来说，这意味着文件大小从 216 MB 降至 144 MB——在音质没有下降的情况下减少了 33%。 最后一条铁律：在有损格式之间转码是灾难的开始。将 MP3 转换为 AAC 或 Opus 无法恢复已被 MP3 编码器丢弃的信息。任何一个曾被要求把一个乱七八糟的 96 kbps MP3“变好听”的人都懂这种痛苦。记住，如果质量很重要，一定要从无损源文件，如 WAV、FLAC 或 AIFF 开始。
针对具体场景，该如何选择编解码器
正确的编解码器完全取决于你的分发目标，而不是哪个在抽象的实验室测试中得分最高。以下是如何选择。 当你向最终用户分发音乐供他们自己的音乐库使用时（比如 Bandcamp 下载、个人收藏、用于汽车的 U 盘），请使用 MP3。一个高质量的 VBR 文件（LAME V0）或 320 kbps 的 CBR 是你的最佳选择。当你无法控制播放设备时，通用兼容性的重要性超过了其他编解码器带来的边际质量提升。 对于播客和口述内容，96 kbps 的 AAC-LC 单声道是最佳选择。这是一个广泛兼容的选择，像 Apple Podcasts、Spotify 和 Pocket Casts 这样的主流平台都能完美处理。如果你的听众中苹果用户占多数，AAC 是原生选择，播放效果极佳。 如果你在网络或浏览器中流式传输音频，在任何低于 160 kbps 的比特率下，WebM 容器中的 Opus 都是明确的技术赢家。如果你的分析数据显示有相当一部分用户是老旧 iOS Safari 用户，请务必为他们提供 AAC 或 MP3 作为备用选项。 当涉及到音频归档时，答案很简单：永远不要使用有损格式。将你的母带文件存储为 FLAC 或 WAV 文件，然后在需要时编码为你的交付格式。你可以使用 CocoConvert 进行 FLAC 到 MP3、FLAC 到 AAC 以及 FLAC 到 Opus 的转换，从你的无损母带生成这些交付文件。 对于语音通信和实时音频，答案是 Opus。没有之一。其低延迟和在语音比特率（6–32 kbps）下的惊人效率，正是从 Discord 到 WhatsApp 等所有主流 VoIP 应用都使用它的原因。MP3 和 AAC 根本不是为此而生的。 在视频游戏音频资源领域，AAC 在 Unity 和 Unreal Engine 工作流中都是常见选择。Opus 也在迎头赶上，Unity 2019.3 及更高版本已提供原生支持。MP3 也能用，但在现代游戏引擎中，它与 AAC 相比没有任何实际优势。
使用 CocoConvert 进行格式转换
准备好转换了吗？CocoConvert 支持 MP3、AAC（在 M4A 容器中）和 Opus（在 OGG 或 WebM 中），并提供完全可配置的比特率设置。 将 FLAC 文件转换为 AAC 非常简单。上传你的源文件，选择 M4A 作为输出，然后选择你的比特率。对于音乐，256 kbps 的 AAC-LC 是一个很好的默认值。对于语音，96 kbps 的单声道可以在不明显损失语音质量的情况下将文件大小减半。CocoConvert 使用标准的 AAC-LC 配置，对于低于 80 kbps 的比特率，还可选择 HE-AAC。 对于 Opus，你可以选择 OGG Opus 或 WebM Opus 作为输出。我们建议音乐使用 96 kbps 的比特率，语音使用 32–48 kbps。我们的编码由参考实现 libopus 处理，确保质量与你使用命令行工具得到的结果完全相同。 而对于经典的 MP3，选择格式后，你可以在 VBR 和 CBR 之间选择。我们强烈推荐使用 V2 质量级别的 VBR（平均约 190 kbps），而不是固定的 192 kbps CBR。你可以在获得相当质量的同时，得到一个平均更小的文件。 我们开诚布公地谈谈一些限制。CocoConvert 目前不支持多声道环绕声编码。批量转换是 Pro 账户的功能；免费用户一次只能转换一个文件。对于非常大的文件（超过 500 MB），缓慢的连接可能会导致上传超时，因此先将音频分割成段是一个很好的解决方法。CocoConvert 也不执行音频标准化或响度目标（LUFS）处理。如果你需要这些功能，你需要在转换前后使用像 FFmpeg 或 Auphonic 这样的工具来处理你的音频。 我们界面中的格式推荐器会为了最大兼容性默认推荐 MP3，但设置面板给了你完全的控制权。没有唯一的正确答案，但本文中的数据和使用场景应该能帮助你为你的工作流程做出正确的决定。