AIFF-C压缩格式容器规范解析
1、AIFF-C与AIFF的区别和注意事项：
（1）AIFF-C和AIFF的区别：
1）FORM标识符已从“AIFF”更改为“AIFC”。这将AIFF-C文件与AIFF文件区分开来。
2）Common Chunk已扩展为包含压缩类型ID和压缩类型名称。因此，AIFF-C能够存储从任何压缩算法生成的压缩音频数据。
3）Sound Data Chunk可以包含压缩音频数据。Chunk格式尚未修改。
4）Sound Accelerator（Saxel）Chunk是全新的。它旨在消除在由标记定义的随机点开始播放时由解压缩算法引起的初始伪像。
5）Format Version Chunk是新的。此Chunk旨在为AIFF-C规范的未来潜在升级提供平滑过渡。
（2）注意事项：
1）Chunk Ordering（块排序）
块没有顺序！它们可能以任何顺序出现在AIFF文件中。
应用程序读取AIFF文件应该被设计为获取块，识别它，然后处理它，而不是假设它被识别之前它是什么块。
2）Modifying Chunks（修改Chunks）
如果应用程序允许修改Chunk，您还必须负责更新基于修改的Chunk的其他Chunks。
3）Registering New Compression Types（注册新的压缩类型）
您必须向Apple注册压缩类型才能建立正式的compressionType和compressionName。
您还应该为压缩类型描述Sound Accelerator Chunk的格式和用法。
4）Number of Sample Frames（样本帧数）
文件中包含的样本帧数的是从Common Chunk中的numSampleFrames参数获得的，而不是Sound Data Chunk中的ckDataSize参数。
5）Remember the Pad Byte!（记住填充字节）
每个Chunk必须包含偶数个字节。对于总内容将产生奇数字节数的块，必须在块的末尾添加零填充字节。此填充字节不包含在ckDataSize中。
6）Format Version Chunk（格式版本Chunk）
Format Version Chunk中标题为“何时读取AIFF-C文件”的部分特别重要。
2、AIFF-C压缩格式规范：
（1）INTRODUCTION（介绍）
音频交换文件格式AIFF-C为存储未压缩或压缩的采样声音提供了标准。
该格式可以存储一系列采样率和样本宽度的单声道或多声道采样声音。
该格式是可扩展的，以处理新的压缩类型和特定应用程序的数据。
AIFF-C基于Audio IFF（AIFF），它符合Electronic Arts开发的“EA IFF 85”交换格式文件标准。
AIFF-C专为交换而设计，尽管应用程序设计人员应该发现它足够灵活，可以用作日常数据存储格式。
如果应用程序使用不同的存储格式，它可以转换为此处定义的AIFF-C格式。这将有助于在应用程序之间和各种计算机平台之间共享声音数据。
1）Data types（数据类型）
char、unsigned char；
short、unsigned short；
long、unsigned long；
extends：80位IEEE标准754浮点数（标准Apple数字环境[SANE]数据类型扩展）。
pstring：Pascal样式的字符串，一个字节计数后跟文本字节。 此数据类型中的总字节数应为偶数。可以在文本末尾添加填充字节以完成此操作。该填充字节不会反映在计数中。
ID：32位，在''（SP，0x20）到'~'（0x7E）范围内的四个可打印ASCII字符的串联。空格（0x20）不能在打印字符之前; 允许尾随空格。禁止控制字符。
OSType：32位。内部定义的由四个字符组成的串接。大写/小写很重要，也就是说，使用简单的32位相等性检查来比较OSType。
2）Data Organization（数据组织）
所有数据均以Motorola 68000格式存储。数字首先存储为高字节。
数据的低位存放在高地址，高位存放在低地址（Big-endian）。
（2）FILE STRUCTURE（文件结构）
交换格式文件的“EA IFF 85”标准定义了用于在文件中存储数据的整体结构。
“EA IFF 85”文件是从许多数据块构建的。Chunks是“EA IFF 85”文件的构建块。块包含一些标头信息，后跟数据。
结构表示如下：
typedef struct {
ID ckID; /* chunk ID */
long ckDataSize; /* chunk data size, in bytes */
char ckData[]; /* data */
} Chunk;
参数解析：
ckID描述了chunk数据部分的格式。程序可以通过检查ckID来确定如何解释chunk数据。
ckDataSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckDataSize使用的8个字节。
ckData是存储在块中的数据。该数据的格式由ckID确定。如果数据的长度为奇数个字节，则必须在末尾添加零填充字节。填充字节不包含在ckDataSize中。
AIFF-C文件是许多不同类型的块的集合。
Common Chunk包含描述采样声音的重要参数，例如其length和sample rate。
Sound Data Chunk包含实际的音频样本。
还有其他几个可选块来定义markers，列出instrument parameters（仪器参数），存储应用程序特定信息等。
AIFF-C文件中的块在容器块中组合在一起。“EA IFF 85”定义了许多容器块，但AIFF-C使用的容器块称为FORM。
FORM具有以下格式：
typedef struct {
ID ckID; /* 'FORM' */
long ckDataSize;
ID formType; /* 'AIFC' */
Chunk chunks[];
} FormAIFCChunk;
参数解析：
ckID始终是'FORM'。这表明这是一个FORM chunk。
ckDataSize包含'FORM'块的数据部分的大小。注意数据部分已分为两部分，formType和chunks []。
formType描述'FORM'块中的内容，非常类似于Mac文件类型。对于AIFF-C文件，formType是'AIFC'。FORMType“AIFC”的FORM块称为FORM AIFC。
chunks是FORM中包含的chunks。这些chunks称为local chunks，因为它们自己的ckID是FORM AIFC的local chunks。FORM AIFC及其local chunks构成AIFF-C文件。
FORM AIFC中对本地块的排序没有限制。
1）Local Chunk Types（本地块类型）
FORM AIFC中需要Common Chunk。如果采样的声音长度大于零，则需要Sound Data chunk。所有其他块都是可选的。
使用FORM AIFC的所有应用程序必须能够读取所需的块，并可以选择有选择地忽略可选块。
2）Dealing with Unrecognized Local Chunks（处理无法识别的本地块）
在读取IFF文件时，程序可能会遇到无法识别的本地块类型，可能是在编写程序后定义的扩展。
在FORM AIFC中，这种情况也适用于具有无法识别的应用程序签名的应用于特定程序的块。（应用程序签名充当块子类型。）
程序在IFF FORM中遇到无法识别的块时应该怎么做？最安全的是在读FORM时简单地丢弃它们。
（3）FORMAT VERSION CHUNK（格式版本块）
Format Version Chunk包含一个日期字段，用于指示AIFF-C规范的格式规则。这将使未来更顺利地升级到此规范。
1）Format Version Chunk
Format Version Chunk数据格式如下：
#define AIFCVersion1 0xA2805140 /* Version 1 of AIFF-C this is 2726318400 in decimal */
typedef struct {
ID ckID ; /* 'FVER' */
long ckDataSize ; /* 4 */
unsigned long timestamp ; /* AIFCVersion1 */
} FormatVersionChunk;
参数解析：
ckID总是'FVER'。
ckDataSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckDataSize使用的8个字节。对于此Chunk，ckDataSize的值为4。
timeStamp表示何时创建AIFF-C文件的格式版本。单位是自1904年1月1日以来的秒数。
只有Apple可能会改变时间戳的值。不要将格式版本与文件的创建日期混淆。
格式版本是指在此文档或将来的文档中包含的规则，这些文档指定如何安排AIFF-C文件。
格式版块是必需的。一个且只有一个Format Version Chunk必须出现在FORM AIFC中。
2）为什么添加了格式版本块
“如果我们在AIFF中有一个版本块，我们就不必更改AIFFC的FORM类型了。hh”
您识别的Chunk名称将包含您熟悉的格式的信息。
如果找不到应用程序所需的Chunk，请检查Format Version Chunk以确定文件是否已损坏，或者应用程序与文件之间是否存在不匹配。
了解以下步骤如何简化您的生活（和我们的生活）以确定FORM AIFC是否可用：
3）读取AIFF-C文件时
1.首先找到FORM AIFC字段。如果找不到，请发出“此文件不包含AIFC标准录音”的提醒，然后退出这些指示。
2.尝试找到对您的应用程序至关重要的所有块（可能是COMM和SSND，但我们可以想象一个只需要COMM块的应用程序，例如确定播放持续时间）。
如果找到，那些熟悉的chunk ID表示块内容采用您期望的格式。
3.如果没有找到，请不要崩溃。而是检查格式版本块。
4）Remember
为了在交换和格式演变中生存，读程序必须对块顺序，缺少块和意外块有强大的作用。
与原始AIFF规范相反，当程序遇到无法识别的块时，它应该跳过它。请勿将其复制到新的已编辑文件中。这是IFF中的一般规则，因为在编辑周围数据时无法保持无法识别的块的完整性。
5）Format Version Chunk如何帮助未来的潜在升级
如果在AIFF中已经有格式版本块，将如何升级AIFF来处理压缩音频：
•压缩是可选的。
•不要更改COMM Chunk的格式。现有程序仍然可以读取它。
•添加一个“Compression Descriptor”块，其中包含4个字母的压缩类型代码和压缩名称字符串。
•用压缩声音数据块“CSND”替换SSND块。（现有程序将忽略它。）
•更改格式版本日期（为了警报）。
•添加可选的Saxel Chunk。
将FORM类型从AIFF更改为AIFC，是由于缺少Format Version Chunk，现有应用程序将无法发出有用的错误消息。如果某些现有应用程序找不到SSND Chunk，它们甚至可能会崩溃。
（4）COMMON CHUNK
Common Chunk描述了采样声音的基本参数。结构如下：
#define CommonID 'COMM' /* ckID for Common Chunk */
typedef struct {
ID ckID; /* 'COMM' */
long ckDataSize;
short numChannels; /* # audio channels */
unsigned long numSampleFrames; /* # sample frames = samples/channel */
short sampleSize; /* # bits/sample */
extended sampleRate; /* sample_frames/sec */
ID compressionType; /* compression type ID code */
pstring compressionName; /* human-readable compression type name */
} CommonChunk;
参数解析：
ckID始终是'COMM'。
ckDataSize是块的数据部分的大小（以字节为单位）。它不包括ckID和ckDataSize使用的8个字节。
对于Common Chunk，ckDataSize是22 +pstring的大小。（当需要填充偶数个字节时，pstring包含填充字节。）
numChannels包含声音的音频通道数。值1表示单声道声音，2表示立体声，4表示四声道声音等。可以表示任意数量的音频声道。
实际的声音样本存储在另一个Sound Data Chunk中，对于多声道声音，来自每个声道的单个采样点是交错的。一组交错的采样点称为采样帧。
对于单声道声音，样本帧是单个样本点。
numSampleFrames包含Sound Data Chunk中的样本帧数。
请注意，numSampleFrames是样本帧的数量，而不是Sound Data Chunk中的字节数和采样点数。对于未压缩的声音数据，文件中的采样点总数为numSampleFrames * numChannels。
sampleSize是未压缩声音数据的每个采样点中的位数。
它可以是1到32之间的任何数字。对于压缩声音数据，sampleSize表示压缩前原始声音数据中的位数。
sampleRate是播放声音的采样率，是sample frames per second（每秒采样帧数）。
程序使用compressionType来识别声音数据上使用的压缩算法（如果有的话）。
compressionName被人们用来识别压缩算法。
使用compressionType选择解压缩例程。当您没有所需的解压缩例程时，使用compressionName显示人类可读的消息。
如果pstring长度不是偶数个字节，用零字节填充compressionName的末尾，但不要在计数中包含填充字节。
compressionType compressionName meaning
'NONE' "not compressed" uncompressed, that is, straight digitized samples
'ACE2' "ACE 2-to-1" 2-to-1 IIGS ACE (Audio Compression / Expansion)
'ACE8' "ACE 8-to-3" 8-to-3 IIGS ACE (Audio Compression / Expansion)
'MAC3' "MACE 3-to-1" 3-to-1 Macintosh Audio Compression / Expansion
'MAC6' "MACE 6-to-1" 6-to-1 Macintosh Audio Compression / Expansion
注意：compressionType是标识压缩算法的标准32位ID值。
相反，compressionName的值可以是特定于国家的，例如 以法语或西班牙语存储。
每个FORM AIFC中必须出现一个且只有一个Common Chunk。
（5）SOUND DATA CHUNK
SOUND DATA CHUNK包含实际的采样帧。
结构定义如下：
#define SoundDataID 'SSND' /* ckID for Sound Data Chunk */
typedef struct {
ID ckID; /* 'SSND' */
long ckDataSize;
unsigned long offset;
unsigned long blockSize;
char soundData[];
} SoundDataChunk;
参数解析：
ckID始终是'SSND'。
ckDataSize是块的数据部分的大小，以字节为单位。
它不包括ckID和ckDataSize使用的8个字节。它包括offset和blockSize占用的8个字节。
如果soundData []包含奇数个字节，则在末尾添加一个值为零的填充字节，以保留此块的偶数长度。此填充字节（如果存在）不包含在ckDataSize中。
为避免混淆，应始终从Common Chunk中的numSampleFrames参数获取实际的采样帧数。
offset确定soundData中第一个样本帧的开始位置。offset以字节为单位。
下面的BlockAligning Sound Data部分解释了用于非零偏移的用法。
blockSize与偏移结合用于块对齐声音数据。它包含声音数据对齐的块的字节大小。
与偏移量一样，大多数应用程序不会使用blockSize，应将其设置为零。
soundData包含组成声音的采样帧。soundData中的样本帧数由Common Chunk中的numSampleFrames参数确定。
如果soundData []包含奇数个字节，则在末尾添加零填充字节（但不用于回放）。
1）Linear Sound Data (not compressed)（线性声音数据）
样本帧中的每个样本点都是线性的2的补码值。
采样点的宽度为1到32位，由Common Chunk中的sampleSize参数决定。每个采样点存储在整数个连续字节中。
一到八位宽的采样点存储在一个字节中; 9到16位宽的采样点存储在两个字节中; 17至24位宽的采样点以3个字节存储; 25到32位宽的采样以4个字节存储。
当采样点的宽度小于8位的倍数时，采样点数据左对齐（使用左移指令），其余位为零。右端的剩余低位设置为零。
例如，12位样本二进制101000010111以左对齐方式存储在两个字节中：
1 0 1 0 0 0 0 1 0 1 1 1 0 0 0 0
12位采样点左对齐 最右边的4位是零填充
2）Sample Frames（采样帧）
采样帧内的采样点按照上面“Common Chunk”中的描述打包在一起。采样帧按照增加的时间顺序存储。采样点之间或采样帧之间没有填充字节。
3）Compressed Sound Data（压缩声音数据）
soundData根据Common Chunk中的compressionType参数进行压缩。
附录C描述了现有Apple Computer音频压缩实用程序的编码格式以及Marker和Saxel Chunks（见下文）与各种压缩类型的使用。
4）Block-Aligning Sound Data
可能存在一些应用程序，为了实现音频的实时记录和回放，希望将采样的声音数据对准固定大小的磁盘块。这可以使用offset和blockSize参数来完成。
第一个样本帧从磁盘块N的开头开始。这是通过跳过soundData的第一个偏移字节来完成的。
blockSize指定对齐块的大小（以字节为单位）。blockSize为零表示声音数据不需要块对齐。
在编写AIFF-C文件时，不关心块对齐的应用程序应将blockSize和offset设置为零。4
写入块对齐声音数据的应用程序应将blockSize设置为适当的块大小。
修改现有AIFF-C文件的应用程序应尝试保留声音数据的对齐，尽管这不是必需的。
如果应用程序不保留对齐，则应将blockSize和offset设置为零。如果应用程序需要将声音数据重新对齐到不同大小的块，则应更新blockSize并相应地进行偏移。
除非Common Chunk中的numSampleFrames字段为零，否则声音数据块是必需的。最多一个声音数据块可以出现在FORM AIFC中。
（6）MARKER CHUNK
Marker Chunk包含指向声音数据中位置的标记。
Markers可用于应用程序所需的任何目的。后面定义的Instrument Chunk使用标记来标记循环起点和终点。
1）Markers
Markers结构如下：
typedef short MarkerId;
typedef struct {
MarkerId id; /* must be > 0 */
unsigned long position; /* sample frame number */
pstring markerName;
} Marker;
参数解析：
id是唯一标识FORM AIFC中marker的数字。只要同一个FORM AIFC中没有其他marker具有相同的id，id就可以是任何正的非零整数。
marker在声音数据中的位置由position指示。marker在概念上落在两个采样帧之间。
落在声音数据中第一个样本帧之前的标记位于零位置，而落在声音数据中第一个和第二个样本帧之间的标记位于位置1.注意位置的单位是样本帧，而不是字节和样本点。
对于压缩声音数据，标记的位置基于扩展（未压缩）声音数据，而不是压缩样本帧的位置。
这允许细粒度分辨率将标记点精确放置在需要的位置（对于循环点尤其重要）。
单个字节的压缩声音数据可以扩展为扩展声音数据的许多字节，从而防止基于压缩数据的标记的高分辨率。
对于现有的Apple音频压缩算法，可以轻松完成压缩声音数据样本帧到扩展声音数据样本帧的映射。
建议音频编辑器程序在编辑音频数据时更新标记。
markerName是一个包含标记名称的pstring。在需要时将填充字节包括为pstring到偶数个字节。
2）Marker Chunk Format
Marker Chunk中数据的格式如下所示：
#define MarkerID 'MARK' /* ckID for Marker Chunk */
typedef struct {
ID ckID; /* 'MARK' */
long ckDataSize;
unsigned short numMarkers;
Marker markers[];
} MarkerChunk;
参数解析：
ckID总是'MARK'。
ckDataSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckDataSize使用的8个字节。
numMarkers是Marker Chunk中的标记数。
numMarkers，如果非零，则后跟标记本身。
由于标记中的所有字段长度均为偶数个字节，因此任何标记的长度始终为偶数。
因此，标记被打包在一起，它们之间没有未使用的字节。标记不需要以任何特定方式排序。
Marker Chunk是可选的。在FORM AIFC中只能出现一个Marker Chunk。
注意：如果包含一个或多个标记的声音数据片段在声音流中重新定位，则必须重新计算要移动的片段内的标记。
（7）COMMENTS CHUNK
Comments Chunk用于在FORM AIFF中存储注释。“EA IFF 85”有一个可用于注释的注释块，但是注释块有两个在“EA IFF 85”块中找不到的功能。它们是：1）评论的时间戳;2）指向标记的链接。
1）Comment
Comments由时间戳，标记ID和文本计数跟文本组成。结构如下：
typedef struct {
unsigned long timeStamp; /* comment creation date */
MarkerId marker; /* comments for this marker number */
unsigned short count; /* comment text string length */
char text[]; /* comment text */
} Comment;
参数解析：
timeStamp表示Comments的创建时间。单位是自1904年1月1日以来的秒数。
Comments可以链接到标记。这允许应用程序将标记的长描述存储为Comments。如果Comments指的是标记，则marker是该标记的ID。否则，标记为零，表示此Comments未链接到标记。
count是组成Comments的文本的长度。这是一个16位的数量，允许比pstring更长的Comments。
text包含Comments本身。必须在末尾用一个字节填充此文本，以确保它的长度为偶数个字节。该填充字节（如果存在）不包括在计数中。
2）Comments Chunk Format：
结构如下：
#define CommentID 'COMT' /* ckID for Comments Chunk. */
typedef struct {
ID ckID;
long ckSize;
unsigned short numComments;
Comment comments[];
} CommentsChunk;
ckID总是'COMT'。ckSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckSize使用的8个字节。
numComments包含Comments Chunk中的Comments数。接下来是Comments本身。Comments长度总是为偶数个字节，因此Comments Chunk中的Comments之间没有填充。
Comments Chunk是可选的。一个FORM AIFF中只能出现一个Comments Chunk。
（8）SOUND ACCELERATOR (SAXEL) CHUNK（声音加速器（SAXEL）CHUNK）
Saxel Chunk旨在通过压缩音频数据流中的任何随机点（由标记指示）提供高质量的播放。
对Saxel Chunk的需求源于音频解压缩器的行为，其在很大程度上依赖于最近解压缩的样本的一些历史来预测下一个要解压缩的样本的值。
在随机点开始解压缩音频流将导致在算法的内部解压缩参数稳定之前听到初始音频伪像。
（9）INSTRUMENT CHUNK
Instrument Chunk定义了仪器（例如采样键盘）可用于回放声音数据的基本参数。
1）Looping（循环）
可以重复声音数据的一部分以延长声音。该部分称为循环段，重复进行，直到被取样键盘上的键释放中断为止。
有两种播放循环的方法：前向循环和前进/后退（或“乒乓”）循环。
要实现前向循环，请反复播放循环段。要实现向前/向后循环，请向前播放循环段，然后向后播放，并反复向前/向后重复此对。
下面的结构描述了一个循环：
typedef struct {
short playMode;
MarkerId beginLoop;
MarkerId endLoop;
} Loop;
参数解析：
playMode指定要执行的循环类型：
#define NoLooping 0
#define ForwardLooping 1
#define ForwardBackwardLooping 2
NoLooping意味着在播放期间忽略这些循环点。
beginLoop和endLoop是标记id，用于标记循环段的开始和结束位置。
开始位置必须小于结束位置，因此环段将具有正长度。（如果不是这种情况，则忽略此循环段。不会发生循环。）
2）Instrument Chunk Format
Instrument Chunk中的数据格式如下所述：
#define InstrumentID 'INST' /* ckID for Instrument Chunk */
typedef struct {
ID ckID; /* 'INST' */
long ckDataSize;
char baseNote;
char detune;
char lowNote;
char highNote;
char lowVelocity;
char highVelocity;
short gain;
Loop sustainLoop;
Loop releaseLoop;
} InstrumentChunk;
参数解析：
ckID始终是'INST'。
ckDataSize是块的数据部分的大小，以字节为单位。
对于仪器块，ckDataSize始终为20。
ckID始终是'INST'。ckSize是块的数据部分的大小，以字节为单位。对于仪器块，ckSize始终为20。
baseNote是工具在没有音调修改的情况下播放声音数据的注释。单位是MIDI（MIDI是乐器数字接口的首字母缩写）音符编号，范围是0到127.中间C是60。
detune决定工具在播放时应改变声音音高的程度。单位为美分（半音的1/100），范围从-50到+50。负数表示声音的音高应该降低，而正数表示应该提高声音的音高。
lowNote和highNote指定键盘上的建议范围以播放声音数据。如果要求乐器在低音符和高音符之间播放音符，则应播放声音数据。基调不必在此范围内。lowNote和highNote的单位是MIDI音符值。
lowVelocity和highVelocity指定播放声音数据的建议速度范围。如果音符开启速度介于低速和高速之间，则应播放声音数据。单位是MIDI速度值，1（最低速度）到127（最高速度）。
gain（增益）是在播放时改变声音增益的量。单位是分贝。例如，0 db表示没有变化，6 db表示每个采样点的值加倍，而-6 db表示每个采样点的值减半。
sustainLoop指定一个循环，当工具维持声音时要播放该循环。
releaseLoop指定当乐器处于播放声音的释放阶段时要播放的循环。释放阶段通常在乐器上的键释放后发生。
Instrument Chunk是可选的。FORM AIFF中只能出现一个Instrument Chunk。
（10）MIDI DATA CHUNK
MIDI数据块可用于存储MIDI数据。
此块的主要用途是存储MIDI系统专用消息，尽管其他类型的MIDI数据可以存储在此块。
随着越来越多的仪器上市，它们可能会有一些参数未包含在AIFF-C规范中。
这些乐器的MIDI系统专用信息可能包含许多未包含在乐器组块中的参数。
例如，新的采样仪器可能具有多于Instrument Chunk中定义的两个环路。
这些循环可能会在新机器的MIDI System Exclusive消息中表示。此MIDI系统专用消息可以存储在MIDI数据块中。
#define MIDIDataID 'MIDI' /* ckID for MIDI Data Chunk */
typedef struct {
ID ckID; /* 'MIDI' */
long ckDataSize;
unsigned char MIDIdata[];
} MIDIDataChunk;
ckID总是'MIDI'。
ckDataSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckSize使用的8个字节。
MIDIData包含MIDI数据流。
MIDI数据块是可选的。FORM AIFF中可能存在任意数量的MIDI数据块。
如果要将多个乐器的MIDI系统专用信息存储在FORM AIFF中，最好每个乐器使用一个MIDI数据块，而不是所有乐器使用一个大的MIDI数据块。
（11）AUDIO RECORDING CHUNK（录音块）
录音块包含与录音设备有关的信息。结构定义如下：
#define AudioRecordingID 'AESD' /* ckID for Audio Recording Chunk */
typedef struct {
ID ckID; /* 'AESD' */
long ckDataSize;
unsigned char AESChannelStatusData[24];
} AudioRecordingChunk;
#define AudioRecordingID 'AESD' /* ckID for Audio Recording Chunk. */
typedef struct {
ID ckID;
long ckSize;
unsigned char AESChannelStatusData[24];
} AudioRecordingChunk;
ckID始终是'AESD'。
ckDataSize是块的数据部分的大小，以字节为单位。对于录音块，ckSize始终为24。
AESChannelStatusData的24个字节在AES推荐的数字音频工程实践 - 线性表示的数字音频数据的串行传输格式，第7.1节，通道状态数据中规定。该文件描述了用于音频设备之间的数字音频的实时数字传输的格式。为方便起见，此信息在音频记录块中重复。一般感兴趣的是字节0的位2,3和4，它们描述了记录强调。
音频录制块是可选的。FORM AIFF中不得出现多个音频录制块。
（12）APPLICATION SPECIFIC CHUNK（应用程序特殊块）
Application Specific Chunk可以用于应用程序制造商的任何目的。结构如下：
例如，编辑声音的应用程序可能希望使用该块来存储编辑器状态参数，例如放大级别，最后光标位置等。
结构如下：
#define ApplicationSpecificID 'APPL' /* ckID for Application Specific Chunk. */
typedef struct {
ID ckID;
long ckDataSize;
OSType applicationSignature;
char data[];
} ApplicationSpecificChunk;
ckID总是'APPL'。
ckDataSize是块的数据部分的大小，以字节为单位。它不包括ckID和ckSize使用的8个字节。
applicationSignature标识特定的应用程序。
对于Macintosh应用程序，这将是应用程序的四个字符签名。
对于Apple II应用程序，applicationSignature应始终为“pdos”或十六进制字节0x70646F73。
如果applicationSignature是'pdos'，则数据区的开头被定义为包含应用程序名称的Pascal样式字符串（长度字节后跟ASCII字符串字节）。
这是必要的，因为Apple II应用程序没有Macintosh应用程序那样的四字节签名。
对于在Apple计算机以外运行的应用程序，应用程序签名应始终为“stoc”。数据区的开头被定义为包含应用程序名称的Pascal样式字符串（长度字节后跟ASCII字符串字节）。
data是Application Specific Chunk的数据。必须根据需要在末尾填充一个字节，以使其长度为偶数个字节。
Application Specific Chunk是可选的。单个FORM AIFF中可能存在任意数量的Application Specific Chunk。
（13）TEXT CHUNKS - NAME, AUTHOR, COPYRIGHT, ANNOTATION
这四个块包含在每个“EA IFF 85”文件的定义中。全是文本块;他们的数据部分仅由文本组成。这些块中的每一个都是可选的。
#define NameID 'NAME' /* ckID for Name Chunk. */
#define AuthorID 'AUTH' /* ckID for Author Chunk. */
#define CopyrightID '(c) ' /* ckID for Copyright Chunk. */
#define AnnotationID 'ANNO' /* ckID for Annotation Chunk. */
typedef struct {
ID ckID;
long ckDataSize;
char text[];
} TextChunk;
ckID是“NAME”，“AUTH”，“（c）”或“ANNO”，具体取决于块是否分别为Name Chunk，Author Chunk，Copyright Chunk或Annotation Chunk。对于版权块，'c'是小写的，并且在右括号后面有一个空格（0x20）。
ckDataSize是块的数据部分的大小，在本例中是文本。
text包含纯ASCII字符。它不是pstring也不是C字符串。text中的字符数由ckSize确定。text内容取决于块，如下所述：
Name Chunk：
text包含采样声音的名称。名称块是可选的。FORM AIFF中可能只存在一个名称块。
Author Chunk：
text包含一个或多个作者姓名。在这种情况下，作者是采样声音的创建者。作者块是可选的。FORM AIFF中可能只存在一个作者块。
Copyright Chunk：
版权块包含声音的版权声明。文本包含版权所有者遵循的日期。
版权块是可选的。FORM AIFF中可能只存在一个版权块。
Annotation Chunk：
text包含评论。在FORM AIFF中不鼓励使用此块。应该使用功能更强大的Comments Chunk。Annotation Chunk是可选的。FORM AIFF中可能存在许多Annotation Chunk。
（14）CHUNK PRECEDENCE
FORM AIFF的几个本地块可能包含重复信息。例如，乐器块定义了循环点，MIDI数据块中的MIDI系统专用数据也可以定义循环点。如果这些循环点不同会发生什么？应用程序应该如何循环声音？
通过定义块的优先级来解决此类冲突：
Format Version Chunk Highest precedence
Common Chunk
Instrument Chunk
Saxel Chunk
Comments Chunk
Marker Chunk
Sound Data Chunk
Name Chunk
Author Chunk
Copyright Chunk
Annotation Chunk(s) -- in the order they appear in the FORM
Audio Recording Chunk
MIDI Data Chunk(s)
Application Specific Chunks Lowest precedence
Common Chunk具有最高优先级，而Application Specific Chunk具有最低优先级。
Common Chunk中的信息始终优先于任何其他块中的冲突信息。Application Specific Chunk总是在与其他块冲突时丢失。
例如，通过查看块层次结构，可以看到Instrument Chunk中的循环点优先于MIDI数据块中发现的冲突循环点。
应用程序负责将数据写入较低优先级的块，以确保更高优先级的块相应地更新。
（15）FORM AIFC的示例
请记住，块可以在FORM AIFC中以任何顺序出现
示例列表：
1.以22.25454 kHz采样的8位单声道声音数据。声音数据未压缩。
2.使用Macintosh Audio Compression＆Expansion实用程序以22.25454 kHz采样的8位单声道声音数据，压缩3倍。
3.以44.1kHz（CD质量）采样的16位立体声数据。声音数据未压缩。
1）一个文件包含大约4.476秒的8位单声道声音数据，采样频率为22.25454 kHz。声音数据未压缩。
2）一个文件，包含大约28.972秒的8位声音数据，以22.25454 kHz采样，并使用Macintosh音频压缩和扩展实用程序压缩3倍。
注意：声音加速器块（Saxel）使用附录D中定义的Saxels的初步版本。
3）包含大约2.325秒的16位立体声声音数据的文件，采样频率为44.1kHz（CD质量）。声音数据未压缩。
（16）Compressed Audio Encoding Format
1. ACE和Macintosh压缩实用程序的编码格式
2. ACE和Macintosh压缩声音数据的标记
3. ACE和Macintosh的Saxels压缩声音数据
编码格式：
针对单声道声音数据示出了编码格式。下面描述多通道压缩音频编码的示例。以下的原始声音数据是8位线性样本。
3：1 Macintosh音频压缩和扩展实用程序 Frame size = 2 bytes
原始未压缩单声道声音数据：
Marker:
0 1 2 3 4 5 6 7 8 9 10
8-bits 8-bits 8-bits 8-bits 8-bits 8-bits 8-bits 8-bits 8-bits 8-bits 8-bits
3:1 Compressed Sound Data: 8-bits 8-bits 8-bits 8-bits
......
标记位置（参见标记块部分）针对扩展（未压缩）声音数据。
因此，必须进行计算以从压缩数据流中的位置映射到未压缩声音数据中的目标位置。
未完...
参考：http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/AIFF.html
AIFF-C压缩格式容器规范解析相关推荐
- AIFF格式容器规范
1. AIFF Container概念: 1)AIFF是音频交换文件格式(Audio Interchange File Format)的英文缩写,是Apple公司开发的一种声音文件格式,是一种文 ...
- unity-贴图压缩格式
title: unity-贴图压缩格式 categories: Unity3d tags: [unity, ios, astc] date: 2017-12-21 20:09:12 comments: ...
- 如何解析(读取)LZ4压缩格式的Spark EventLog日志
为什么需要Spark Event Log? 我们都知道Spark启动后会启动Spark UI,这个Spark UI可以帮助我们监控应用程序的状态.但是如果Spark应用跑完了,Spark UI就无法查 ...
- python 实现文件的批量压缩为.zip格式+.zip格式文件的解析
python 实现文件的批量压缩为.zip格式+.zip格式文件的解析 python 实现文件的批量压缩为.zip格式 Python解析.zip文件的常见函数 python 实现文件的批量压缩为.zi ...
- DICOM笔记-解析JPEG压缩格式DCM文件
项目中使用了DICOM文件保存图像,之前经常遇到DICOM内放置的是short类型或者float类型的二维图像,按照之前的代码处理JEPG压缩的DICOM文件,当然会出现问题:从网上查到资料,是由 ...
- java解析压缩文件，支持zip，rar，7z压缩格式
最近项目有需求对压缩文件进行解析,需要支持市面上比较流行的压缩格式,诸如zip,rar,7z: 由于压缩文件解析比较常见,特将代码整理出来,供后续参考学习: 以下是java代码: maven依赖: & ...
- java json插件安装_IDEAL葵花宝典：java代码开发规范插件：GsonFormat插件将JSONObject格式的String 解析成实体...
前言: GsonFormat插件主要用于使用Gson库将JSONObject格式的String 解析成实体,该插件可以加快开发进度,使用非常方便,效率高. 这个教程主要是学习IntelliJ IDEA ...
- DXT纹理压缩格式解析
我们知道游戏中对于3D物体表面细节的表现最重要的还是靠贴图来实现的,那么越是高分辨率越是真彩色的贴图自然表现力也是越强,但是同时带来的问题是所需占用的内存会成倍的上升,而节省内存这一点在目前的游戏中还 ...
- 各种压缩格式介绍！(摘录2)
http://xpatrick.spaces.live.com/ 简述:DivX和Xvid的历史与未来,基于MPEG-4的两种影音压缩技术 简述:DivX和Xvid的历史与未来,基于MPEG-4的两种 ...
最新文章
- VS2005下开发PPC2003和WM50编译器一些设置
- matlab复数方程的根,matlab解一元三次方程，得到的都是复数根。
- 安装Loadrunner11及破解步骤
- Java 两个复数求和
- UGUI源码之绘制初探
- javascript网页自动填表_javascript实现自动填写表单实例简析
- linux抓肉鸡入侵详细教程,Linux XOR.DDoS入侵排查步骤 | 聂扬帆博客
- NLP 学习笔记9-停用词
- FastDFS原理及工作流程
- lisp绘制直齿圆柱齿轮_直齿圆柱齿轮的知识及其画法
- stub，存根是什么？
- CF869 E. The Untended Antiquity 二位树状数组+hash
- get与post的解释与区别
- 银行网点WLAN无线认证解决方案
- Mac上安装mysql及密码重置
- 2021年中国水果罐头行业进出口贸易及发展前景分析[图]
- leetcode 二分法 最大值最小化/最小值最大化
- Python-提升爬虫速度三种方式
- sanic教程-Sanic 应用
- Flash 与课件制作：加载图片
热门文章
- html table 合计,bootstrap-table 页脚总计(自定义统计总数)
- 处理使用top提示terminal is not big enough
- 易语言服务器怎么断开连接,易语言断开进程网络连接源码
- ios android mid音频文件,iOS 录音 音频 视频 控制中心
- 追溯系统是如何实现的？
- 抓包工具？我只选Fiddler，全网最全教程！
- 计算机桌面总是出现纯黑色,电脑桌面图标变成黑色方块该怎么解决?
- js android打电话,Android开发webview与js的交互总结【安卓巴士博文大赛】
- 时间时区格式转化问题
- ModuleNotFoundError：No module named xxx 罪魁祸首竟是虚拟环境