2.1 标准谱系：从MPEG-2 AAC到HE-AAC与xHE

2.1 标准谱系：从 MPEG-2 AAC 到 HE-AAC 与 xHE

本节摘要：AAC 不是一个编码器而是一族标准。本节沿时间线梳理 MPEG-2 AAC（1997）到 MPEG-4 各 Profile（LC/MAIN/SSR/LTP）、HE-AAC v1/v2、LD/ELD 直至 xHE-AAC（2012）的裂变逻辑——每一次分裂都对应一类新场景对码率或延迟的新要求。

本章开篇：先认清家族成员与各自的定位，后面四节才能精确地讨论"哪个工具属于哪条支线"。本节结尾会把 Opus 的诞生年份放进同一条时间线，让两代编码器的错位竞争关系一目了然。

主干：MPEG-2 到 MPEG-4

MPEG-2 AAC 于 1997 年定稿（ISO/IEC 13818-7），定位是"MP3 的继任者"：同样的心理声学框架，但窗长翻倍、滤波器组更优、立体声工具更强，同码率主观质量明显提升。1999 年 MPEG-4 音频标准（ISO/IEC 14496-3）把 AAC 收编并扩展，从此"AAC"基本都指 MPEG-4 语境下的实现。

MPEG-4 AAC 最初定义了几个 Profile：MAIN（含反向预测，质量最优但算力重，几乎无人实现）、LC（Low Complexity，去掉预测器，成为事实主流）、SSR（分频带子带编码，兼容性差被弃）、LTP（长时预测，少数实现采用）。后来真正活跃的支线是两条："更省码率"的 HE 系与"更低延迟"的 LD 系。

图：AAC 标准演进时间线

省码率支线：HE-AAC v1 与 v2

HE-AAC v1（2003 年前后普及）的思路是"核心编码器只管低半频段，高半频段用参数描述"：SBR（频谱带复制）把约 8 kHz 以下的频谱认真编码，以上部分靠复制低频并施加包络与噪声修饰来重建。这相当于把采样率降一半跑核心编码器，省下的比特远多于 SBR 参数的开销。v2 在此之上再加 PS（参数立体声）：核心只编码单声道，立体声像用少量空间参数恢复。两级参数化叠加后，24 至 64 kbps 的立体声分发成为可能——这正是移动网络早期流量昂贵年代的黄金档位。

代价也明确：参数化重建的高频与声像"听起来像"而非"确实是"，对管弦乐泛音、复杂声场等内容的还原有天花板；码率一高（比如超过 96 kbps），SBR/PS 反而不如直接用 LC。所以工程上的分水岭大致在 64 至 80 kbps：之下用 HE-AAC v2，之上回归 AAC-LC。

低延迟支线：LD 与 ELD

分发场景不在乎延迟，但视频会议在乎。MPEG 在 2000 年前后补出 AAC-LD（低延迟 Profile）：帧长砍到 512 样本、去掉前瞻需求，算法延迟降到约 20 ms；2007 年前后的 AAC-ELD 再压到 15 ms 上下，引入更短窗与改进的窗设计。这条支线的详细机理与延迟账本放在 2.5 节展开——这里先记住定位：它是标准体系对实时场景的"补课"，补课成本是压缩效率的明显让步，而这恰好撞上 Opus 的主场。

统一支线：xHE-AAC/USAC

2012 年定稿的 xHE-AAC（USAC，统一语音与音频编码）是谱系上离"融合两代思路"最近的一次尝试：把语音编码工具（线性预测类）与通用音频工具（变换类）放进同一个框架按内容切换，目标是从 8 kbps 语音到 256 kbps 音乐全覆盖。它在低码率音乐上的效率优于 HE-AAC v2，且内置了响度与动态范围控制（MPEG-D DRC），已被数字广播（DRM+、欧洲数字电台）采纳。它的"语音+音乐双模"思想与 Opus 的双引擎异曲同工——第 6.3 节会把这次合流放进更大的格局里讨论。

Profile 对照与选型速查

一个常被忽略的工程事实：开源世界里 AAC 编码器质量差距很大。FFmpeg 自带的 AAC 编码器在 128 kbps 以上可用性好，但低码率明显逊于 Fraunhofer 的 fdk-aac（后者因授权条款无法进入多数 Linux 发行版的默认构建）。部署低码率 AAC 链路前，先确认你用的是哪支编码器——这比调参数的影响大得多。

用工具核实 Profile：别信文件名

谱系知识要能落地到"这条流到底是什么"。两步核实法：第一步查容器声明（MP4 看 esds 里的 AudioObjectType，ADTS 看 profile 字段）；第二步看实际行为与声明是否一致（HE 流的码流里有 SBR 扩展元素、编码输出带宽是标称的一半量级）。两步都对上，才算确认身份——只做第一步是排障时最常见的偷懒，而"声明与实际不符"恰恰是许多兼容性故障的根源。

命令行核实的姿势：

# 查 Profile 与采样率声明
ffprobe -v error -show_entries stream=profile,sample_rate,channels file.m4a
# 查 ADTS 裸流的帧头
ffprobe -v error -show_entries stream=codec_name,profile file.aac
# Opus 侧的对应核查（实际帧长与码率分布）
opusinfo file.opus
​

核实之后常见的三个意外：标着 HE-AAC v2 的流其实是 v1（封装工具把 PS 位写错或没写）；标着 AAC-LC 的流带 SBR 扩展（部分编码器"隐式"启用，老解码器会播成半带宽）；标着 48 kHz 的 HE 流实际只有 24 kHz 核心带宽加重建高频（正常，但要让团队知道频谱图上看到的是什么）。把"两步核实"写进接入新素材源的流程，能拦下大部分下游的无谓排查。

谱系速记卡

记不住全部支线时，用三句话兜底：第一句"LC 是本体"——绝大多数说"AAC"的场合指它，其余支线都是它的变奏；第二句"HE 管省钱、LD 管延迟"——两词缀分别对应码率与延迟两类场景诉求，v2 比 v1 多一层参数化（声像）；第三句"xHE 是全家桶"——语音音乐统一加响度控制，代表标准体系的最新整合。三句话覆盖日常交流与需求评审的九成场景，具体参数再回查前文表格。

谱系知识还有个隐性用途：读懂技术方案的"暗语"。方案里出现 HE-AAC，意味着预算紧张或移动网络占比高；出现 ELD，意味着实时链路且生态锁定苹果系；出现 xHE-AAC，多半是广播或带响度合规的项目——从格式选择反推约束条件，是评审他人方案时的捷径。

💡 关键直觉：AAC 的谱系裂变史就是一部"场景倒逼标准打补丁"的历史——要省带宽就参数化（HE），要低延迟就砍窗长（LD/ELD），要语音音乐通吃就双模（xHE）。而 Opus 在 2012 年一次性把这些要求写进了初始设计。谱系越庞大，越说明单一框架的场景假设被反复突破。

下一节钻进主流支线 AAC-LC 的内部：那条从 PCM 到比特流的完整流水线，每个工具分别在两本账的哪一页工作。