AAC 格式详解
AAC 格式详解
AAC 简介
AAC(Advanced Audio Coding)是一种现代的音频编码技术,用于数字音频的传输和存储领域。AAC是MPEG-2和MPEG-4标准中的一部分,可提供更高质量的音频数据。
AAC被认为是MP3的继任者。AAC比MP3的压缩率更高,压缩后的文件越小,二是保真性比MP3强。ACC最开始是基于MPEG-2的音频编码技术,MPEG-4标准出现后,AAC重新集成了其特性,加入了SBR技术和PS技术。
特点:
- 更好的声音质量和更低的压缩比,减少了由于压缩而引入的失真和噪音。
- 支持多种采样率、声道数和比特率。
- 具有很好的灵活性和可扩展性。
总之,AAC是一种现代的音频编码技术,具有高质量的音频数据、较低的比特率、灵活性和可扩展性等优点。由于其广泛应用于数字音频传输和存储领域,它已经成为音频压缩领域的标准之一。
AAC 编码规格
目前常用的AAC格式有:AAC LC、AAC HE V1、AAC HE V2。
名称 | 技术 | 码率 |
---|---|---|
LC-AAC | 传统AAC | 高码率>=80Kbps |
HE-AAC | AAC+SBR | 中码率<=80Kbps |
HE_AACv2 | AAC+SBR+PS | 低码率<=48Kbps |
它们之间的关系:
频带重现(Spectral Band Replication)
SBR是一种全新的音频编码增强工具,并已经在ISO/IEC 14496-3:2001/Amd.1:2003中被标准化。它提供了改善低比特率音频和音频编码音质的可能性,这是通过增加在特定比特率的音频带宽或改善在特定质量水平的编码效率而实现的。
SBR可以扩大传统感知编码在低比特率下所能提供的有限的音频带宽,因此它的性能表现相当于或超过模拟FM的音频带宽(15kHz)。SBR也可以改善窄带音频编码的质量,可为广播电台提供12kHz音频带宽的纯音频频道,可用如诸如多语言广播等场合。
由于大多数音频编码都是被严格地限制带宽的,因此SBR的重要性不仅体现在提高音频质量上,而且也体现在提高音频的可读性和理解性上。SBR是以后处理为主的,不过为能指导解码过程,在编码时编码器要先做一些预处理工作。
从技术角度而言,SBR是在音频压缩算法中的一种实现高效高频率的编码新方法。
当联合SBR一起使用,其主体编码器(比如MP3)只负责处理音频频谱的低频部分。高频部分则由SBR解码器产生,这是紧跟在传统波形解码器之后的一个后处理过程。SBR基于对主体编码器处理得到的低频信号进行的分析,在解码器上重建了高频部分。为了确保精确的重建,一些指导信息以非常低的数据率夹杂在主体编码器产生的码流中一同传输。
重建对于和声和噪声成分同样有效,同时允许在频率范围和时间范围进行适当的修整。结果是,SBR实现了在非常低数据率下的全带宽音频编码,与主体编码器相比,明显地增加了压缩效率。
SBR的性能分析:
SBR可以改善感知音频编码的效率,在中等至低比特率下能提高大约30%(在某些特定情况下可能更高)。SBR具体能够提供的改善程度同时也依赖于其主体编码器。
举例说,联合MP3一起使用SBR(参考mp3PRO相关文章),我们可以在64kbps下达到相对传统的大于100kbps的立体声mp3的音频质量。SBR可应用于单声道,立体声甚至多声道的音频。
因此,可以说,SBR在主体编码器本身可编码的音频信号比特率范围和在有限的音频带宽下的可接受的编码噪音(coding artifacts)水平内提供了最大的效率。
参量立体声(Parametric Stereo)
PS是为提高低比特率立体声信号的音频压缩效率的下一个主要举措。参量立体声在MPEG-4中被完整地定义,并且是aacPlus v2中的新的组成部分。目前,参量立体声技术已面向16-40 kbps的范围进行优化,并能在像24 kbps这样低的比特率下提供高音频质量。
参量立体声编码器从音频信号的立体声影像中分解出其参量表示,而在传统模式下原始信号只会被编码为单声道表示。立体声映像信息被表现为少量的高质量的参量立体声信息,与单声道信号在比特流中同时传输。然后,基于接收到的参量立体声信息,解码器便可重建立体声映像,如下图。
这种做法类似于SBR的做法,也带有MP3中的Joint Stereo联合立体声的味道。
结果是,合并有参量立体声的低比特率, 例如 24 kbps 的音频比特流, 所能让听众感受到的音频质量是显著地高于不具备参量立体声的相似音频比特流的质量。
参考:
- http://www.wavecn.com/content.php?id=117
- http://www.wavecn.com/content.php?id=120
AAC 音频文件格式
AAC的音频文件格式有以下两种:
-
ADIF(Audio Data Interchange Format):音频数据交换格式。这种格式的特征是可以确定的找到这个音频数据的开始,不需进行在音频数据流中间开始的解码,即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。
-
ADTS(Audio Data Transport Stream):音频数据传输流。这种格式的特征是它是一个有同步字的比特流,解码可以在这个流中任何位置开始。它的特征类似于MP3数据流格式。这种格式可以用于广播电视。
简言之。ADIF只有一个文件头,ADTS每个包前面有一个文件头。
ADIF
ADTS
在ADTS文件中,每个AAC音频帧都以一个长度为7或9个字节的ADTS帧头开始,其中包含了同步标记、帧大小、采样率、声道数和其他元数据。接下来是AAC编码的原始音频数据,这些数据会被添加到ADTS帧中,以形成完整的音频帧。
ADTS头部又分为固定头部、可变头部,下面简单介绍ADTS头部的各个字段含义。
固定头部
固定头部各个字段解析:
字段 | 比特数 | 说明 |
---|---|---|
syncword | 12 | 所有位必须为1,即0xFFF |
ID | 1 | 0代表MPEG-4, 1代表MPEG-2 |
layer | 2 | 所有位必须为0 |
protection_absent | 1 | 1代表没有CRC,0代表有 |
profile | 2 | 配置级别 |
sampling_frequency_index | 4 | 标识使用的采样频率,具体见下 |
private_bit | 1 | see ISO/IEC 11172-3, subclause 2.4.2.3 (Table 8) |
channel_configuration | 3 | 取值为0时,通过inband 的PCE设置channel configuration |
original/copy | 1 | 编码时设置为0,解码时忽略 |
home | 1 | 编码时设置为0,解码时忽略 |
详细介绍:
-
syncword:同步位,12bit。
同步字是ADTS文件的标志符,它用于确定音频帧的开始位置和结束位置,通常为0xFFF。 -
ID:MPEG Version,1bit。
ID指示使用的MPEG版本。值为0表示MPEG-4,值为1表示MPEG-2。 -
Layer:2bit
Layer定义了音频流所属的层级,对于AAC来说,其值为0。 -
Protection Absent:1bit
Protection Absent指示是否启用CRC错误校验。设置 1 表示没有CRC,整个ADST头为7字节;0 表示有CRC,整个ADST头为9字节。 -
Profile:AAC规格,2bit
该字段的解释取决于ID位的值。如果ID等于1,则该字段包含与ISO/IEC 13818-7中定义的ADTS流中的配置文件字段相同的信息,也就是MPEG-2的规格;当ID为0是表示的是MPEG-4的规格,该字段的值等于 Audio Object Type 的值减1。字段取值如下面图片的表格。
-
Sampling Frequency Index:采样率下标,4bit
Sampling Frequency Index表示采样率的索引,它告诉解码器当前音频数据的采样率。这个值的范围是0到15,每个值表示一个特定的采样率。
-
Private Bit:私有比特,1bit
编码时设置为0,解码时忽略。 -
Channel Configuration:音频配置,3bit
Channel Configuration指示音频的通道数,如单声道、立体声或多声道等。
-
Originality:1bit
Originality指示编码数据是否被原始产生。编码时设置为0,解码时忽略。 -
Home:1 bit
编码时设置为0,解码时忽略。
可变头部
可变头部字段解析:
字段 | 比特数 | 说明 |
---|---|---|
copyright_identification_bit | 1 | 编码时设置为0,解码时忽略 |
copyright_identification_start | 1 | 编码时设置为0,解码时忽略 |
frame_length | 13 | 当前 ADTS 帧的长度,包括 ADTS 头(固定+可变)和 AAC 原始流,单位byte |
adts_buffer_fullness | 11 | 0x7FF 表示码率可变的码流,0x000 表示固定码率的码流 |
number_of_raw_data_blocks_in_frame | 2 | 该字段表示当前ADST帧中所包含的AAC帧的个数减一。为了最大的兼容性通常每个ADTS frame 包含一个AAC frame,所以该值一般为0。一个AAC原始帧包含一段时间内1024个采样及相关数据 |
AAC ES
AAC ES(AAC Elementary Stream)是AAC音频编码的一种基本数据格式,也是AAC音频数据在流式传输和文件存储中的常见格式之一。
AAC ES不同于其他容器格式(如MP4、M4A等),它不包含额外的元数据或结构信息,仅包含未经任何封装或压缩处理的原始音频数据。这些原始数据可以作为音频文件或流传输的基础,同时也可以用于对AAC音频进行转码、编辑或重组。
AAC ES 通常由一系列连续的AAC音频帧组成,每个帧以一个特定的标志符开始,该标志符表示这是一个AAC音频帧。在AAC ES中,每个音频帧拥有相同的长度(1024个样本时间段),但是并不一定包含相同数量的采样点,因为采样率和声道数量可能会发生变化。
AAC ES 的另一个关键特征是其比特流顺序,即数字音频数据的组织方式。AAC ES 采用大端字节顺序,其中高位字节排在前面,低位字节排在后面。此外,在AAC ES中,音频数据按照从左到右、自上而下的顺序排列,与典型的文本文件不同。
总结:AAC sequence三层
第一层:AAC sequence:多个AAC Frame。
第二层:AAC Frame:AAC header+AAC ES。
第三层:AAC ES。音频数据,不包含header。flv,mp4的音频数据来自这一层,也就是说不包含header。
注意:第2层的AAC Frame,一般下只有1个AAC ES,但也有可能有两个AAC ES。这取决于number_of_raw_data_blocks_in_frame的值,ACC ES 格数 = number_of_raw_data_blocks_in_frame + 1。
实例:AAC文件解析
下图是用编辑器打开一个AAC文件,用十六进制查看的截图:
没有CRC的情况下,文件开头的7个字节是ADTS帧头部,这里7个字节的数据是:0xff 0xf1 0x4c 0x80 0x20 0x02 0x80,我们按照ADTS帧的头部数据来解析看看这7个字节表示什么?
前面1-12bit为 0xff 0xf,对应了ADTS头部的 syncword 字段,表示ADTS帧的开始。
13-16bit为0x01,二进制是 0001,也就是说:
- ID的1bit为0(MPEG-4);
- layer的2bit为00;
- protection_absent的1bit为1,表示没有CRC,整个头部7个字节。
17-24bit为0x4c,二进制是 0100 1100,意思是:
- profile_ObjectType的2bit为 01,结合前面ID为0,表示MPEG-4 AAC LC 规格;
- sampling_frequency_index的4bit为0011,也就是0x3,表示采样率为48000;
- private_bit的1bit为0;
剩余1bit,结合后面的再看;
25-32bit为0x80,二进制是 1000 0000,意思是:
- channel_configuration的3bit(结合前面剩下的1bit)为 010,表示双声道;
- original_copy的1bit为0;
- home的1bit为0;
- copyright_identification_bit的1bit为0;
- copyright_identification_start的1bit为0;
剩余2bit,结合下个字段再看;
33-44bit为0x200,二进制是 0010 0000 0000,加上前面剩下的2bit,就是00 0010 0000 0000:
- frame_length的13bit为00 0010 0000 000,也就是0x100,表示这个ADTS帧的长度是0x100;那么下个ADTS就是0x100开始的;
剩余1bit,留到下个字段再看;
45-56bit为0x280,二进制是 0010 1000 0000,加上前面剩下的1bit,就是 0 0010 1000 0000:
- adts_buffer_fullness的11bit为 0 0010 1000 00,十六进制0xa0;
- number_of_raw_data_blocks_in_frame的2bit为 00,表示包含一个AAC frame。
后面的ADTS帧也可以类似上面的过程去解析。frame_length是代表了整个ADTS的大小。
解析AAC文件的C语言代码
参考
- https://blog.csdn.net/sjp1992/article/details/108639633
- https://blog.csdn.net/leixiaohua1020/article/details/11822537
- https://moonfdd.blog.csdn.net/article/details/130408276
- https://blog.csdn.net/gdliweibing/article/details/125118290
- https://blog.csdn.net/wkd_007/article/details/135112250
- https://blog.csdn.net/yunxiaobaobei/article/details/130785456
- https://blog.csdn.net/leixiaohua1020/article/details/50535042
- https://www.cnblogs.com/daner1257/p/10709233.html
- https://blog.csdn.net/jay100500/article/details/52955232