如果你在 2026 年 6 月 29 日之前问任何一个音视频工程师”FFmpeg 的 AAC 编码器怎么样”，答案大概都是同一套：能用，但别指望它有多好。想要质量？用 libfdk_aac——前提是你愿意自己编译，因为 Fraunhofer 的许可证和 GPL 水火不容。或者，如果你用 macOS，直接调 Core Audio 的编码器；用 Windows 的话，挂个 qaac 壳也行。
这是一个持续了近十年的尴尬局面。FFmpeg 的原生 AAC 编码器在 2016 年就摘掉了”实验性”标签，官方文档也赫然写着”质量与 libfdk_aac 相当或更好”。但如果你去 hydrogenaudio 论坛——那个聚集了全球最较真的音频发烧友和编解码工程师的地方——看任何一次双盲听感测试，libfdk_aac 和 Apple 编码器总是高出一截。
2026 年 6 月 30 日，这个局面被一位开发者的一篇帖子终结了。
一篇帖子引发的震动
hydrogenaudio 的 AAC 技术板块，用户 lynne 发了一篇标题简洁的帖子：「FFmpeg 9.1’s new AAC encoder」。
正文第一段就毫不客气：
我最近彻底重写了 FFmpeg 的 AAC 编码器。从码率控制、RDO 到所有编码工具（PNS、TNS、I/S 和 M/S），全部重新设计。按照客观指标（Google 新出的 Zimtohrli、ViSQOL，以及我自己的耳朵），它显然是目前最好的 AAC 编码器，超过 qaac 和 fdk-aac。
然后贴了一张对比表。六列——旧版 FFmpeg fast 模式、旧版 twoloop 模式、新版（nmr）、fdk-aac、Apple、libopus——五行，分别对应 64/96/128/160/256 kbps。每个格子里是两个数字：Zimtohrli（越低越好）和 ViSQOL（越高越好）。
在 128 kbps——最常见的 AAC 编码码率——新版得分是 0.00072 / 4.47。fdk-aac 是 0.00143 / 4.27，Apple 是 0.00081 / 4.44。libopus 作为参考基准，是 0.00020 / 4.68。
也就是说，一个从头写起的编码器，在双指标上压制了 Fraunhofer 和 Apple 多年打磨的产物，并且正在逼近 Opus——后者的设计理念本就比 AAC 先进一代。
帖子在 Hacker News 上迅速发酵，372 分、113 条评论。一位用户 ant6n 的评论精准概括了这个时刻的氛围：
这就是老互联网的味道：有人写出了可能是最好的 AAC 编码器，第一个回复却是管理员在纠结 48kHz 还是 44.1kHz。
这个编码器做了什么不一样的事
lynne 在帖子中列出了九个具体细节。逐一拆解，你会发现这件事比”换了个更好的算法”要深得多。
第一，彻底放弃 VBR 优先策略。 新编码器是严格的 CBR，码率波动极小。lynne 的逻辑很直接：有了明确的码率预算作为约束，编码决策反而更高效。社区很多人对此有疑虑——毕竟 VBR 理论上是更合理的方案——但 lynne 的回应是：你可以用 -q:a 走真正的 VBR 模式，只不过客观指标会差几个百分点，“反正我们还是会赢”。
第二，逆向工程 Apple 编码器后发现了一个真相。 lynne 反编译了 qaac，发现 Apple 的编码器居然不做任何感知优化。它只是在频带能量上套了一条偏向高频的比特分配曲线。lynne 在这个思路上做了改进：保留类似的曲线，但在 RDO 环节使用掩蔽后的频带能量，而非原始能量。这等于是把”有人这样做过”和”这样做对吗”之间的差距补上了。
第三，所有编码工具全部纳入 RDO 优化循环。 这是技术含量最高的部分。AAC 标准定义了多个编码工具：TNS（时域噪声整形）、PNS（感知噪声替换）、I/S（强度立体声）、M/S（中/侧立体声）。过去的编码器要么只用 TNS，要么用硬编码的阈值来开关其他工具——比如”码率低于 X 时开启 PNS”。
lynne 的做法完全不同：每一个工具都在 RDO 循环内独立评估，没有预设的启发式规则，没有任意切割的码率分界线。“如果一个工具能被用上，它就会被用上。”
这种做法的结果是，编码器在决策时拥有全局视角。它不需要开发者告诉它”高码率时关掉 I/S”，它会自己判断——某个频段用 I/S 编码的失真到底值不值得省下来的那点比特。
第四，顺便发现了一个潜伏多年的解码器 bug。 因为之前没有任何编码器使用立体声 PNS，所以 FFmpeg 的 AAC 解码器在处理立体声 PNS 时存在一个 bug——无人发现，自然无人修复。lynne 在编码器里加了 workaround。
第五，那些频谱图上的”洞”是故意的。 lynne 的原话是：“如果你看频谱图，我们会留下很多空洞。**这是设计意图。**被掩蔽的频带会被置零或用 PNS 替代——既然相邻频带足够响，你根本不会注意到那些缺失的频带。把可听频带编好，比把所有频带都编得一团糟要强。“
48kHz 之争
在 lynne 列出的九条细节中，第八条引发了社区最激烈的反应：
编码器主要针对 48kHz 音频优化。接受现实吧。 现在是 2026 年，重采样是免费的，48kHz 才是标准。44.1kHz 也能用，96kHz 也行，但想要最好质量就用 48kHz。
这句话像一个精准的挑衅，刺中了音频社区最敏感的神经。立刻有人回复：“可世界上绝大多数音频是 44.1kHz……”
争论本身其实有答案——lynne 后来澄清，所有基准测试都是用 44.1kHz 素材跑的。他是在 48kHz 数据上用人耳调参的，部分加窗/瞬态检测逻辑也绑定了 48kHz 的时间精度，但用 44.1kHz 素材测试时发现差异不大，就保留了原样。
但真正有趣的是这个争论背后的隐喻。44.1kHz 是 CD 时代的遗产，它的存在本身就是一个工程妥协的化石——上世纪 70 年代末，Sony 和 Philips 为了让数字音频能存储在 PAL/NTSC 录像带上，把采样率定在了两个电视制式都能容纳的最高值。几十年过去了，全世界数亿张 CD 锁定了这个数字，而今天所有流媒体、所有视频平台、所有蓝牙音频链路都在用 48kHz。
lynne 的态度很明确：这是 2026 年，不是 1982 年。如果重采样到 48kHz 能得到更好的编码结果，那就重采样。在解码端少做一次采样率转换也是一个实实在在的好处。
HN 上 pseudosavant 指出了另一个同样重要的局限：CBR 模式。“无法使用基于质量的 VBR 编码是一个巨大的缺口。”
两个限制叠加在一起，让一部分人对”现在就全面切换”持谨慎态度。但更多人认为，对于一个刚合并进主线两天的编码器来说，讨论这些限制本身就说明了起点之高。
谁写的，怎么写出来的
lynne 并非无名之辈。氢音频论坛的 C.R.Helmrich 指出，lynne 之前还写了 FFmpeg 的原生 xHE-AAC（USAC）解码器——全部代码，一个人。xHE-AAC 是 AAC 家族最新、最复杂的成员，能在 12 kbps 的极低码率下提供可接受的立体声音质。能独自实现 USAC 解码的人，来重写 AAC-LC 编码器，技术栈上完全是降维打击。
测试规模也值得注意：lynne 用自己的音乐收藏做了 3000 首曲目的编码测试。同时坦言语音内容测试很少，编码器在语音上可能需要进一步优化。
更加引人注目的是测试方法——lynne 没有引用任何 ABX 或 MUSHRA 听感测试，而是直接上了 Google 的两个客观感知指标。Zimtohrli 是 Google 最新的音频感知距离度量，ViSQOL 则是专门针对语音和音频质量的客观评估工具。HN 上 CharlesW 对此的评论很克制：“这些工具对编码器开发很有帮助，但它们最多是人类感知的不完美替代品。”
但 lynne 也说了”以及我自己的耳朵”。而且帖子结尾明确邀请大家做 A/B 测试并提交有问题的样本。
这种姿态本身就说明问题。一个对自己的编码器没信心的人，不会把反编译 Apple 编码器的结论公开贴出来，不会放话说”用 TNS 就能公平打败，上 PNS、I/S 和 M/S 后彻底碾压”，更不会对 48kHz 争议用一句”get over it”收尾。
这不像一个厂商的发布公告，更像一个工程师干完活后把结果往桌上一拍：“喏，你们自己听听看。“
这意味着什么
FFmpeg 是世界上使用最广泛的多媒体处理框架。从 VLC 到 OBS，从 YouTube 的转码管线到无数嵌入式设备，FFmpeg 几乎无处不在。这意味着这个新编码器的影响面远超音频发烧友的圈子。
任何依赖 FFmpeg 做 AAC 编码的场景——视频转码、直播推流、媒体服务器——都可以直接受益。不再需要单独编译 libfdk_aac，不再需要为 Windows 用户折腾 qaac 的 Apple Application Support 依赖，不再需要在许可证兼容性和编码质量之间做取舍。
Kamedo2——hydrogenaudio 上长期组织编码器听感盲测的核心成员——在帖子下留言说，他正在进行的 2026 年编码器听感评测已经用上了旧版 FFmpeg AAC 编码器，新版来不及加入。这意味着社区还需要等待一段时间才能看到正式的 ABX 盲测结果。
但考虑到旧版在之前的盲测中常年垫底——C.R.Helmrich 用”quite suboptimally”来形容都算客气——而新版的客观指标直接跳到了和 fdk-aac、Apple 互有胜负甚至略优的水平，这个提升的幅度是罕见的。
之前社区对编码器质量的排序大致是：libopus >> Apple ≈ fdk-aac >> 旧版 FFmpeg aac。现在那张表的含义是：lynne 的新编码器至少在客观指标上，把中间的约等号改写成了大于号，并且向 Opus 靠近了一大步。
在 HN 讨论中，一位用户用最朴素的理由解释了自己为什么在意这件事：“AAC 比 MP3 好，而且我的车载 USB 支持它。”
这就是 FFmpeg 的影响力。一个编码器的改进，最终会抵达数百万辆汽车、数亿台手机、无数个视频平台的后台转码队列。而推动这一切的，只是一个人的一次重写，一篇论坛帖子，和一句”get over it”。
本文基于 hydrogenaudio 论坛原始帖文、Hacker News 讨论及相关公开资料整理。文中技术解释可能存在理解偏差，建议感兴趣的读者前往原文阅读 lynne 的第一手描述。编码器的实际表现需等待社区正式的 ABX 盲测验证。本文不构成任何编码器选择建议。
参考链接：