1.6.2 未压缩音频格式（Uncompressed Audio Format）

未压缩音频格式（Uncompressed [Uncompressed Audio Format]） 即 没有经过任何压缩算法处理，而直接将数字信号的数字码，作为存储格式保存的音频格式。因此，未压缩音频格式的存储格式（Data Format） 与 原数字信号 在音频数据内容部分，具有 完全一致的数字码值。

常见的未压缩音频格式，除了前文反复提到的 PCM 格式外，还有 PDM、WAV、AIFF、AU 等。PCM、PDM 格式自不必多提，而在系统中常用的 WAV 、SND/AU、AIFF等 则需额外引申。

首先的一个疑问就是，为什么会有这么多未压缩音频格式？

未压缩音频格式种类的产生

如此结果的产生，主要来自于 两个重要因素：调制模式的差异，和 描述信息的不同。

调制模式的差异，造成了如 PCM、PDM 之类的区分，这也是上节末尾我们所谈到的（其具体原理，已经于前面的章节中讲解，如有疑问可以回顾），是来自于不同 AD/DA 方法论的区别。

描述信息的不同，则指向该格式，是否携带了 描述音频的头部信息（Header Information） 用来标记当前音频文件对应音频数据的全局附加信息。而这，则是来自于 系统文件规范（System File Specifications） 指定的人为因素。

WAV 音频格式

自微软在早期 IBM 时代提出了 资源交换档案标准（RIFF [Resource Interchange File Format]） 规范后，所有于 Windows 系统内的数据存储文件，都需要按照：

的形式，完成数据封装。而音频数据所对应的，即为 波形格式数据（Wave File Format），也就是所谓 WAV（.wav） 格式。同时，随着 Windows 系统的极大普及，WAV 格式也成为了一种于多系统间的通用基础音频格式类型。

Windows 系统以后缀来区别具体归属 RIFF 类型。而不论是否采用 PCM 调制模式，想要存储且不采用压缩算法的音频数字信号，都需要按 RIFF 要求进行封装。当然，现行的 WAV 格式文件，基本都是对 PCM 数据的 RIFF 套壳。

RIFF 规定，WAV 数据格式包含了三部分数据，分别是：

• 分块描述信息块（Chunk Descriptor），存放基于 RIFF 体系的当前块标记；
• 音频格式子块（fmt sub-Chunk），存放当前存储音频相关数据的附加信息；
• 音频数据子块（data sub-Chunk），存放当前存储音频的存储数据；

不同区域，包含的信息（即各自参数）的 目标作用域 是不同的。分块描述信息块，主要是基于 RIFF 体系的 相对宏观存储信息记录，目的是为了方便于计算机系统据此进行数据归纳处理。而 音频格式子块 和 音频数据子块 才是对该 数字信号 代表的 音频实际信息的描述和保存。

因此，三部分各有参数标记各自重点。

分块描述信息块（Chunk Descriptor） 主要包含 3 个属性，分别是：

音频格式子块（FMT sub-Chunk） 主要包含 8 个属性和 2 个额外字段，分别是：

需要注意的是，音频格式子块（FMT sub-Chunk）中的 ExtraParamSize 和 ExtraParams 并不是始终存在的。对于 以 PCM 数字信号数据为主要载荷信息的 WAV 格式，该两个字段在 fmt 子块中，是不存在。

即，ExtraParamSize 和 ExtraParams，在 WAV 中并不占用任何有效数据字段。

音频数据子块（DATA sub-Chunk） 主要包含 3 个属性，分别是：

所以，音频数据子块（DATA sub-Chunk） 其实就是 PCM 音频格式时，被存储到计算机系统中的 PCM 存储文件（.pcm）有效数据部分。

三个 WAV 的组成部分以固定顺序排布，如下所示：

共同构成了一则有效的 WAV 音频格式文件。

现在，让我们再来看一段 72 bytes 的 WAV 音频文件（十六进制格式单字节展开）：

按照上述划分，就能得到各自子块的信息了：

从上可知，样例其实是从一段 2048 Bytes 的 PCM 音频对应 WAV 文件 中，从头 截取 72 Bytes 数据 组成的。所以，利用头部信息来交验数据完整性，或取得更早阶段（即调制阶段）的信息，在 WAV 这种 具有 分块描述信息块（Chunk Descriptor） 的音频格式（Audio Format）里成为了可能。

这也是为何类 WAV 结构音频格式（包括将要提到的 SND/AU 和 AIFF 等），会代替了直接以 PCM 在电脑中进行非工程化存储的原因。

不过，这也引申出了 两种截然相反的，有关未压缩音频格式的 制定思路：缩减头文件信息减少复杂度 ，和 增加头文件所能涵盖的辅助数据。典型代表，分别是 SND/AU 和 AIFF 音频格式。

SND/AU 音频格式

SND/AU 是一种极简的，携带有描述信息的未压缩音频格式。该格式由已于 2009 年被 甲骨文（Oracle）收购的 美国昇阳电子有限公司（Sun Microsystems, Inc） 提出，用于解决麦克风录制转换后的 PCM 数字信号，快速简易存储的问题。

SND/AU 音频格式（.snd/.au） 不以 块（Chunk）/子块（sub-Chunk） 形式对关键数据进行分离，而是 直接将存储分为三个部分区段，分别是：

• 头信息区段（Header），存储必要的最基本音频描述信息；
• 变长辅助信息区段（Variable-length Informational Field），存储需要的额外信息；
• 音频数据区段（Data），存放当前存储音频的存储数据；

初看之下可能感觉同 WAV 格式并无太大差异，然而事实并非如此。SUD/AU 的相关音频数据的参数，以及自身有关文件系统的标志，都被 集中于头信息字段的 6 个固定参数中。而涉及音频本身，诸如版权信息、作者名称等数据，则并未规范如何存储，只指定了必须放入 变长辅助信息区段 的要求。这使 系统并不需要管理这部分信息。而音频数据区段，则只能存放 PCM 数字信号的数字码数据。

所以，变长辅助信息区段（Variable-length Informational Field） 只规定 必须占用 4 bytes 大小，并在有 额外信息 时，以整数字节增加，如：5（4+1） bytes、6（4+2） bytes 等。而 音频数据区段（Data）则紧随其后，直接以 PCM 采样按通道（Channels）数，交替分 blocks 存储即可（同 WAV 的 data 部分）。

头信息区段（Header） 主要包含 6 个属性，分别是：

不难发现，我们认为的 比特率（bitrate），或者至少该有的 采样位深（Sampling Bit Depth） 信息，并没有直接体现在头信息字段的参数中。这 并不 意味着没有包含该信息，而是 SND/AU 音频格式，通过 固定格式可支持类型 的方式，将这部分信息 封入了头信息字段的 encoding 子段 里，间接表示 了。

而 SND/AU 所支持的 PCM 采样规格，总计有 12 种，如下：

通过 标记 encoding 取指定 ID 的方式，锚定规定好并确认具体参数的规格档次，来简化了头内容。当然弊端也很明显。由于选定的规格，并指定了档次，使得 相关参数是固定的，无法使用同规格下的其他参数组，而 无法进行动态扩展。这一部分仅了解即可，如使用到相应详细参数，再行查阅。

三个 SND/AU 的组成部分以固定顺序排布，如下所示：

较之 WAV 格式，简化了大量块信息。

但也正是因为这些原因，使得工程上在处理 SND/AU 格式时，需要花费额外的工作，来处理被固定的信息成分。这相当于另一种通过规定来实现的压缩手段了，变相的增加了系统处理资源消耗。因此，除了在 NeXT 系统上得到了大范围应用外，现如今 SND/AU 格式已成为逐步被淘汰的一种类型。

而与之相对的，WAV 和 AIFF 则仍被大量使用在 Windows/Linux 和苹果 MacOS/iOS 系统中。让我们不得不考虑，过渡的简化信息，是否仍有必要。

AIFF 音频格式

音频交换文件格式（AIFF [Audio Interchange File Format]），即 AIFF 音频格式（.aif/.aiff），正如刚刚所提，是一种被使用在 MacOS/iOS 上的未压缩音频格式。是一种隶属于 交换文件格式（IFF [Interchange File Format]） 文件管理体系的 文件格式（File Format）。该格式的特点相比 WAV 的 RIFF 分块体系而言，有着 更为复杂的子块类别。极大提升了能够涵盖辅助信息的广度，并以此为 苹果/Linux 等系统的文件管理，提供了更为方便的归类参考项。

AIFF 音频格式，从整体角度包含量种成分：

• 文件格式块（FORM Chunk），用以描述服务于系统文件管理的文件本身信息；
• 附属信息子块（INFO sub-Chunks），一系列不同类型的持续存储子块；

附属信息子块 也被称为 本地信息块（Local Chunks），所有的 本地信息块 都以 参数值的形式，保存于 文件格式块的 chunks 数组参数属性中，作为数组值存储。

于是，由这两类共同构成了一个完整的 AIFF 文件结构，如下：

从此处即可看出，IFF 体系与 RIFF 体系的差异了。IFF 体系下，子块是以树状从属关系，挂载在 IFF 文件格式块的。而 RIFF 则是 分块描述信息块 和 子块 同属一级。

IFF 文件格式块（FORM Chunk） 主要包含 4 个属性，分别是：

所有 IFF 文件都有以上属性，而不同 IFF 文件区别，主要存在于 本地信息块的差异上，即 chunks 数组内容的不同。

对于 AIFF 音频格式来说，它的子块情况是什么样的呢？

AIFF 将子块（sub-Chunk）拓展到了共计 12 种。且所有子块，在 AIFF 文件中，只能存在一份，或完全不存在。有（按优先程度，非组装顺序，见后文）：

如果说 SND/AU 是精简的一端，那 AIFF 无疑将尽可能多的信息装填到了音频文件中。这种复杂的数据归纳，使 AIFF 格式中，出现了 多级数据结构。

我们分别来看一下，各个分块中的参数。

通用信息块（Common Chunk） 主要包含 6 种属性，分别是：

音频数据块（Sound Data Chunk） 主要包含 5 种属性，分别是：

标记信息块（Marker Chunk） 主要包含 4 种属性和 1 种 子数据体（sub-Data Info），本身具有 两层数据结构模型：

乐器信息块（Instrument Chunk） 主要包含 11 种属性和 1 种 子数据体（sub-Data Info），本身具有 两层数据结构模型：

乐器信息块 是一种用来记录音乐背景节奏，或者特殊效果器的附属信息子块。其中的 “乐器” 并不是由该块本身所指定的，而是来自于 sustainLoop 和 releaseLoop 所标定的，来自于 音频数据块（Sound Data Chunk） 的 Looper 子参数 指定 序号 beginLoop～endLoop 范围 的音频帧构成的原声片段中，采样到全部相关乐器的集合。

片段分两部：持续播放片段 和 收尾播放片段。即该信息块最后两个参数所指定的信息。

• 持续播放片段（sustainLoop），被用于通过序号（间接）存放声音正常播放过程中，在进入结束阶段（Release Phase）前，需要循环播放的音频帧区段。
• 收尾播放片段（releaseLoop），被用于通过序号（间接）存放声音正常播放过程中，在进入结束阶段（Release Phase）后，需要循环播放的音频帧区段。

而何时进入所谓 结束阶段（Release Phase），是由 标记信息块（Marker Chunk）标记数组（Markers） 中的 “结束阶段”标记（Marker） 决定的。因此，标记信息块的重要程度，要高于乐器信息块。

那么，循环的播放模式，即 循环模式（playMode） 都有哪些呢？

主要有 3 种，在无自定义情况下，分别是：

• 无循环模式（NoLooping），标记 0 ，表示片段只需单次顺序播放即可；
• 前向循环模式（ForwardLooping），标记 1 ，播完后从头部重新开始顺序播放；
• 前后循环模式（ForwardBackwardLooping），标记 2 ，播完后反向时序播放，以此循环；

三种模式的直观效果如下：

所以，乐器信息块 的 “乐器” ，实则为该指代片段数据中，用于乐理节奏或乐理意义上背景节拍器（Metronome）的乐器组合的抽象代称。

至于，乐理基调（baseNote）、偏移音高（detune）、最低音调（lowNote）、最高音调（highNote）、播速下限（lowVelocity）、播速上线（highVelocity）、音高增减益（gain）参数，则都是对整个信息块中，全部循环片段的 补充修饰，以 方便达到最佳放音效果。

评论信息块（Comment Chunk） 主要包含 4 种属性和 1 种 子数据体（sub-Data Info），本身具有 两层数据结构模型：

评论信息块 存放的 评论信息，其索引标记和其他块中 以音频帧序列号 的方式 有所不同。是 直接采用音频时间戳来标记的。注意区分差异。

同时，评论内容可以通过 marker 参数，挂靠到 标记信息块 的标记中。这让相关评论数据能够同音频产生 一定程度的直接交互，该点即为评论信息块使用中的优势。

在评论信息块之后的优先级顺序中，出现了 一连 4 个文字块（Text Chunk），分别是： 命名文字块（Name Chunk）、 作者文字块（Author Chunk）、 版权文字块（Copyright Chunk）、 声明文字块（Annotation Chunk）。这 4 个文字块，拥有着相同的参数体系，为 包含 3 种属性的单层结构。

我们放在一起说明：

于 4 个文字块后的 3 类信息块，相对于 AIFF 持有的 PCM 数据来说，则并不是特别重要。当然，此处的重要性是相对于音频数据本身而言的，并不是指该 3 类信息块完全没有意义。

实际上，该 3 类信息块，即 录制信息块（Audio Recording Chunk）、 迷笛数据块（MIDI Data Chunk）、 应用信息块（Application Specific Chunk），对于分别所处的 音频工程协会（AES）规格领域、 迷笛编辑器领域、 指定的系统应用 来说，都有 至关体系设定之直接存储、操作、保存的重要性。

因此，当传递的 AIFF 文件 有涉及该三类领域时，这 3 个信息块的作用是无可替代的。不过，如非非录音师、调音师或专业乐理工程师的话，则仅需要做简单了解即可。

录制信息块（Audio Recording Chunk） 主要包含 3 种属性，分别是：

迷笛数据块（MIDI Data Chunk） 主要包含 3 种属性，分别是：

对于 迷笛数据块 中，可能与 乐器信息块 产生冲突的数据，在 无 迷笛（MIDI）设备（涵盖软硬件） 的情况下，乐器信息块 的优先级高于 迷笛数据块。而当 存在 迷笛解析器 的情况下，两套块设备内的同类信息，将以不同的 迷笛配置（MIDI Profile） 形式，展现在解析软件中。

应用信息块（Application Specific Chunk） 主要包含 3 种属性，分别是：

到此， 12 种 附属信息子块（INFO sub-Chunks），即 本地信息块（Local Chunks），的作用介绍完毕。而各个子块的 信息内容优先级，便有如下顺序：

信息优先级高的子块，在出现同类信息的情况下，会被优先参考。不过对于特殊情况，也需要注意体系内差异。

而如果我们按照 AIFF 格式，去同样 封装一段 PCM 数字信号数据 时，它的文件结构有：

显然，AIFF 相较于 WAV、SND/AU 来说，更加的复杂。这也是为何 AIFF 格式的运用没有 WAV 更为宽泛的原因。但富余而详细的子数据块，也使 AIFF 在多体系任务系统下，会更加的游刃有余。

借此，常用的 三种未压缩编码格式（或者说两种，即 WAV 和 AIFF） 与 PCM 基础格式，共同构成了 音频格式的地基。

但如此直接或相对直接的对 PCM 数据的存放方式，还是会有 大量空间占用浪费。于是，为了进一步缩减音频数据，在计算机系统中的持续化存储问题，工程师们开始采用压缩算法来提高空间利用率。这带来了携带压缩算法的，无损压缩编码格式（Lossless [Lossless Compression Audio Format]） 和 有损压缩编码格式（Lossy [Lossy Compression Audio Format]）。