音频数据的通用容器专利检索-逻辑文件软件专利检索查询-专利查询网

音频数据的通用容器

阅读：657发布：2024-01-27

专利汇可以提供音频数据的通用容器专利检索，专利查询，专利分析的服务。并且本发明涉及音频数据的通用容器。一种方法包括：存储作为音频文件一部分的音频数据，该音频数据表示以多个格式中的任一种进行了编码的音频流，以及与音频数据有关的元数据信息；其中，音频数据包括一个或多个分组，一个或多个分组中的每个包括一个或多个样本帧，每个样本帧包括用于一个或多个声道中的每个的一个样本，一个或多个分组中的至少一个分组包括多个样本，元数据信息包括用于标识音频数据中的一个或多个分组的每个分组的信息，元数据信息明确指示：在每一样本帧中有多少个声道，以及有多少位被用来表示每个样本帧中的每个样本。，下面是音频数据的通用容器专利的具体信息内容。

权利要求

1.一种方法，包括：
存储作为音频文件一部分的
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
2.如权利要求1所述的方法，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
3.如权利要求1所述的方法，还包括：
采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息；以及其中，所述元数据信息包括所述一组统计信息。
4.一种系统，包括：
用于存储作为音频文件一部分的如下内容的装置：
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
5.如权利要求4所述的系统，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
6.如权利要求4所述的系统，还包括：
用于采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息的装置；
以及
其中，所述元数据信息包括所述一组统计信息。
7.一种方法，包括：
解析音频文件，所述音频文件包括：
(a)音频数据，所述音频数据表示以多种格式中的任一种进行了编码的音频流，以及(b)与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
8.如权利要求7所述的方法，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
9.如权利要求7所述的方法，还包括：
采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息；以及其中，所述元数据信息包括所述一组统计信息。
10.一种系统，包括：
用于解析音频文件的装置，所述音频文件包括：
(a)音频数据，所述音频数据表示以多种格式中的任一种进行了编码的音频流，以及(b)与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
11.如权利要求10所述的方法，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
12.如权利要求10所述的方法，还包括：
用于采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息的装置；
以及
其中，所述元数据信息包括所述一组统计信息。
13.一种方法，包括：
接收数据流，所述数据流包括：
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
14.如权利要求13所述的方法，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
15.如权利要求13所述的方法，还包括：
采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息；以及其中，所述元数据信息包括所述一组统计信息。
16.一种系统，包括：
用于接收数据流的装置，所述数据流包括：
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
17.如权利要求16所述的系统，其中，所述元数据信息还包括指示以下内容的信息：
所述流中每秒有多少样本帧，
每个分组中有多少字节，以及
每个分组中有多少样本帧。
18.如权利要求16所述的系统，还包括：
用于采样所述音频流以生成与所述音频流中的数据点相对应的一组统计信息的装置；
以及
其中，所述元数据信息包括所述一组统计信息。
19.一种系统，包括：
用于存储音频文件的装置，所述音频文件包括包含有音频数据块和多个元数据块的一组块；
其中，所述音频数据块包括与经编码的音频的流相对应的一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述一组块中的每个块包括元数据，该元数据指示块版本，块大小，以及
块类型；
其中，所述一组块包括在所述音频文件中的所述音频数据块之前的格式块，所述格式块包括元数据，所述格式块的元数据明确指示：
所述流内的所述音频数据中的每秒样本帧数，
指示在所述流内的数据一般类型的数据，
在每分组数据中有多少字节，
在每分组数据中有多少样本帧，
在每帧数据中有多少声道，以及
有多少位被用于表示每个样本帧中的每个样本。
20.一种计算设备，包括：
一个或多个处理器，以及
被编码在一个或多个计算机可读介质中的逻辑，其中，所述逻辑由所述一个或多个处理器执行以使得：
存储作为音频文件一部分的
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
21.一种计算设备，包括：
一个或多个处理器，以及
被编码在一个或多个计算机可读介质中的逻辑，其中，所述逻辑由所述一个或多个处理器执行以使得：
解析音频文件，所述音频文件包括：
(a)音频数据，所述音频数据表示以多种格式中的任一种进行了编码的音频流，以及(b)与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。
22.一种计算设备，包括：
一个或多个处理器，以及
被编码在一个或多个计算机可读介质中的逻辑，其中，所述逻辑由所述一个或多个处理器执行以使得：
接收数据流，所述数据流包括：
音频数据，所述音频数据表示以多种格式中的任一种格式进行了编码的音频流，以及与所述音频数据有关的元数据信息；
其中，所述音频数据包括一个或多个分组；
其中，所述一个或多个分组中的每个分组包括一个或多个样本帧；
其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；
其中，所述一个或多个分组中的至少一个分组包括多个样本；
其中，所述元数据信息包括用于标识所述音频数据中的所述一个或多个分组的每个分组的信息，所述元数据信息明确指示：
在每一样本帧中有多少个声道，以及
有多少位被用来表示每个样本帧中的每个样本。

说明书全文

音频数据的通用容器

[0001] 本申请是申请号为200580029600.X、申请日为2005年6月9日、题为“音频数据的通用容器”的发明专利申请的分案申请。

技术领域

[0002] 本发明总地涉及数字音频，更具体地涉及音频数据的一种通用容器。

背景技术

[0003] 标准AIFF、AIFC以及WAVE文件，它们由信息“块”组成，并限于4GB。如今高分辨率音频要求有更大尺寸的文件。例如，5.1(即，6个声道)的、以96KHz采样速率且每个样本24位的4GB文件有41分钟的播放时间，而5.1的、以192KHz采样速率和每个样本32位浮点的4GB文件具有15分钟的播放时间。对于8、6、32或者更多的声道，则播放时间甚至就会更短。

[0004] 对于AIFF和WAVE文件，音频应用程序在记录时具有两种选择。第一种选择是记录音频数据然后在记录会话的结尾处更新该文件中的音频数据大小字段。应用程序依赖大小字段来正确解析该文件。因此，假如音频应用程序过早地终止或者在记录的同时又有功率损耗，那么，大多数应用程序就因该大小字段不正确而不能读取该文件。第二种选择就是，在音频数据被写入该文件的同时又反复地更新大小字段。这一过程要求与文件正被存储于其上的硬盘进行相当数量的交互作用，这就极其负面地影响了性能。进一步来说，假若正在记录的应用程序在更新大小字段的过程当中终止，则该文件也就损坏并且不能被正确读取。

[0005] 随着现代音频格式的演变和复杂化，需要开发更通用和更强力的装置来容纳这些格式。基于前面所述，需要有避免现有音频格式上述局限的音频文件格式。

[0006] 本节中描述的方法可以被推行，但不一定是先前已经构思或推行的方法。因此，除非另外指出，否则，就不应该臆断本节中所描述的任一方法仅仅由于其包含在本节中就认为是现有技术。

发明内容

[0007] 根据本发明的实施例，提供了用于存储、解析音频文件以及接收数据流的方法和系统。一种方法包括：存储作为音频文件一部分的音频数据，该音频数据表示以多个格式中的任一种格式进行了编码的音频流，以及与音频数据有关的元数据信息；其中，音频数据包括一个或多个分组；其中，一个或多个分组中的每个分组包括一个或多个样本帧；其中，每个样本帧包括用于一个或多个声道中的每个声道的一个样本；其中，一个或多个分组中的至少一个分组包括多个样本；其中，元数据信息包括用于标识音频数据中的一个或多个分组的每个分组的信息，元数据信息明确指示：在每一样本帧中有多少个声道，以及有多少位被用来表示每个样本帧中的每个样本。附图说明

[0008] 在附图中通过实例来示出本发明的实施例，而不是来限制本发明。附图中类似的参考标号用于表示类似的元素，其中：

[0009] 图1为根据本发明的实施例示出音频文件总布局的框图；

[0010] 图2为根据本发明实施例示出用于处理音频信息的第一方法的流图；

[0011] 图3为根据本发明实施例示出用于处理音频信息的第二方法的流图；

[0012] 图4为示出本发明的实施例可在其上执行的计算机系统框图。

具体实施方式

[0013] 在以下描述中，为了解释的目的且为了提供对本发明的实施例的全面理解，阐述了许多具体的细节。然而，应该明白，没有这些具体细节也可以实现本发明的实施例。在其它实例中，用框图形式显示公知结构和装置来避免使本发明的实施例含混不清。

[0014] 通用容器概述

[0015] 描述了用于音频数据的通用和可扩展容器格式(称为XAF：可扩展音频格式)，其提供了一种机制来存储以多种不同音频编码格式之任一格式进行编码的音频数据。

[0016] 在本发明的一个方面，音频数据编码的基础格式在音频格式块中被参数化定义，封装了用于描述音频数据流的基本格式属性的所有信息。基本的参数定义了足以描述具有相同大小的声道的任一恒定位速率音频格式的音频流的属性。在分组表块中被定义的附加参数可用于对足够描述任一可变位速率格式的音频流的属性进行描述。基于指定的参数，音频数据甚至在实际编码格式对于执行操作的软件来说尚不可知的时候就能进行存取并执行这样的操作。例如，可能是这种情况，即，对音频数据以在被用来操作该音频数据的软件之后才被开发出来的某种格式进行编码。从而，容器为通用和可扩展的，因其能用于存储以任一格式编码的音频数据，包括现在已知以及尚未开发的那些。因此，XAF文件的任一解析器、阅读器、编辑器或者播放器都不要求有具体的软件代码分别用于可能包含在XAF文件中的每个不同音频编码格式。

[0017] 音频数据块大小综述

[0018] 在本发明的另一方面，使用标志来对文件的音频数据部分的大小的存储进行管理，以使得音频记录会话过早地终止不会导致不可读的损坏文件。因而，重新启动在另一记录会话中的音频数据的记录过程就可以起始于前一会话停止的记录处。

[0019] 在一实施例中，这一音频大小管理能力通过将标志初始设定成某个值得以实现，该值与有效音频数据大小并不对应且指出文件中的最后块含有该音频数据。优选地，一旦成功完成记录，就将标志更新到表示实际音频数据大小的值。因此，在解析文件的同时：(1)如果标志具有未对应有效音频数据大小的值，那么，实际音频数据大小就可基于音频文件的大小和该文件最后块的起始位置而确定；以及(2)如果标志具有有效音频数据大小的且表示实际音频数据大小的某个值，则实际音频数据大小就可从该标志中被确定。如果该标志未被更新成表示实际音频数据大小的某个值，则实际音频数据大小仍可基于音频文件的大小和该文件最后块的起始位置而被确定。前述技术也为将音频数据添加到现存音频数据块以及将元数据块添加在所述音频数据块之后而做好了准备。

[0020] 相依性跟踪综述

[0021] 包含有根据本文所述的通用容器格式的给定音频文件，可包括依赖于相关音频数据的元数据。例如，音频文件的概况块(“overviewchunk”)可用于存储表示音频数据概况的信息。在本发明的一个方面，维护音频文件中音频数据的状态信息以有效指示该文件的版本。存储相依性指示符以用于相依元数据，而相依性指示符又指示了元数据与其相依的音频数据状态。因此，通过把元数据的相依性指示符与音频数据的当前状态信息进行比较，在任何给定时间都可确定元数据是否有效。

[0022] 前面的综述展示了XAF文件格式简化并承认以下两者，即，(1)不同类型的音频数据以及(2)与该音频数据共同存储的信息种类。XAF格式提供64位文件支持，从而向文件提供了比其它音频格式更长的音频持续时间以及，在一个实施例中，单个文件内的音频的多个声道相互交错。

[0023] 术语定义

[0024] 如下定义了本文所用的部分术语。

[0025] 样本-来自于一个声道的一个数。

[0026] 帧-每个声道的一个样本。例如，立体声音频的一帧为两个样本，一个样本用于左声道，一个用于右声道。

[0027] 分组-对于PCM，一帧。对于压缩格式，其为将会解压成某一数量的帧。例如，AAC的分组解压成PCM的1024帧。

[0028] 采样速率-每秒出现的帧数。例如，普通光盘(CD)的采样速率是44.1KHz，或者每秒44100帧(对于每个帧，一个左声道样本和一个右声道样本)。术语“采样速率”在本文中是普通用法，然而更准确来说，本文中的采样速率是帧速率，它表示每秒n声道样本数。因此，普通立体声CD以44.1KHz播放，其实际上为每秒88200样本。

[0029] 在编码解码器领域，术语“帧”通常用来描述经过编码的数据的离散分组。然而，术语“分组”在本文用来描述经过编码的数据的离散单元。这样，在经过编码的音频格式中，分组表示音频数据的最小的、不可分割的块(“block”)。总之，(a)分组根据格式而由一个或多个帧组成；(b)一个帧由n声道样本构成；以及(c)采样速率描述了每秒的样本帧数。

[0030] 音频格式综述

[0031] 可使用XAF格式进行描述的无数的音频格式实例包括下列：

[0032] (A)PCM-8、12、16、24、32位带符号的整数；32、64位浮点整数，按或大或小的尾数(“endian”)来排序；

[0033] (B)恒定位速率编码音频(如，IMA)；

[0034] (C)恒定帧，可变位速率(如，AAC、MP3)；以及

[0035] (D)可变帧、每编码分组的可变位速率。

[0036] XAF文件中的音频数据主要作为分组来处理。音频数据分组的内容基于音频编码格式而基本不同，但是，读取和写入音频数据到XAF文件的一般途径并没有不同。

[0037] 分组类型

[0038] (A)恒定位速率格式

[0039] 恒定位速率(CBR)分组类型由具有诸如PCM、PWM和CBR压缩格式的XAF格式支持。对于CBR格式，XAF格式块完整描述每个数据分组的大小，因此，解析器就可既读取也写入不带进一步信息的任一分组。

[0040] (B)可变位速率格式

[0041] 对于可变位速率(VBR)分组类型，通过提供分组块，解析器就可既读取也写入分组到XAF文件，而无需知晓有关在这些单个分组中的位的构造的任何事情，且与音频数据的编码格式无关。在一实施例中，对于XAF格式块不能以其完全描绘(“de-lineate”)分组边界的任一音频数据编码格式，则如后文所述来使用分组块。

[0042] (C)压缩格式

[0043] VBR数据格式既可内部也可外部分帧(“framed”)。即，音频数据的每个分组的边界或是在数据流中描述(内部分帧)或是所述流的附加物(外部分帧)。例如，MP3是内部分帧，并且使用同步信号(“synch”)标号器(“marker”)来给分组标记(“mark”)添加完整性。MPEG 4-AAC是外部分帧，因为分组边界被外部存储到数据流。

[0044] 对于外部分帧的分组，不需要提供专门信息给特定位流以解析该位流，同时又或读取或写入文件。进一步来说，当数据内部分帧时，解析器就不得不解析整个数据段来分辨分组边界在何处、文件有多长等等，这在打开文件进行读取(迄今为止最为平常的操作)时就强加了相当大的代价。

[0045] XAF文件中压缩格式的每个分组的格式都将会有经过描述的数据格式，其通常由负责压缩格式的标准或行业团体进行描述。例如，MP3(精确地说，MPEG 1&2，层3)分组格式包含(1)开始：同步信号字的开始；以及(2)结束：下一同步信号字的开始之前的字节。另举一例来说，AAC利用MPEG4所定义的访问单元(“Access Unit”)。然而，作为XAF文件的解析器，其唯一责任就是基于分组表所描述的边界来读取和写入分组。编码解码器作为这些分组的产生方或使用方来负责提供和使用具有指定构造的音频数据。

[0046] XAF块的具体类型

[0047] 在一实施例中，在XAF文件中找到的数据结构值是按网络(大尾数“big-endian”)排序的。在一实施例中，指定标准的块用小写字符进行描绘(包括mFileType ID)，即，使用仅在ASCII“a”到“z”范围内的且包括空格和“.”字符这两者的字符。在一实施例中，用户定义的块类型或信息关键字包括在XAF块头部信息中的前述4字节mChunkType字段范围之外的至少一个字节值。在一实施例中，添加块定义的用户使用如下所述的“uuid”块类型和语义。

[0048] 优选块

[0049] XAF文件可包含各种类型的信息块。XAF文件可用的某些块类型被称为“优选”块，因为它们被视为XAF文件的基本块，而这对于俘获由XAF文件格式提供的某些基本特征来说是必要的。

[0050] 优选块包括下列，其每一个都在后文进行描述。

[0051] (A)XAF文件头部信息块；

[0052] (B)格式块，其根据音频数据进行编码的基础编码方案，包括音频流的属性(即，参数)描述；以及

[0053] (C)数据块，其包括实际音频数据。在一实施例中，数据块的大小可以未被特别指定或者设定为某个无效的尺寸(如，设定成值-1)，这就指明该数据块是文件中的最后块以及从数据块开始到文件结束的所有内容都是音频数据。如果所述尺寸大于零，那么在数据块之后可能就有附加块，并且该尺寸就被用来确定所含音频数据的实际大小。

[0054] 此外，对于VBR数据，使用分组表块。进一步来说，如果格式要求“魔块”(“magic cookie”)块，则使用魔块，如后文所述。

[0055] 在一实施例中，文件头部信息块、格式块以及数据块都被要求用于XAF文件。

[0056] 推荐块

[0057] 如所提及的，XAF文件可包含各种类型的信息块，其带有被认为俘获XAF文件格式基本结构的块的优选块。XAF文件格式的附加结构可通过使用一种或多种类型的、被称为“推荐”块的块来俘获，因为它们被推荐在XAF文件中使用。

[0058] 一种推荐块如下，其将在后文更详细地描述。

[0059] (A)声道描述块。声道描述对包括在XAF文件中的声道的含义和顺序进行描述。对于单声道或者双声道数据，声道描述块的缺失分别暗示单声道或立体声(左/右)音频。
声道描述块将在后文更详细地描述。

[0060] 附加推荐就是，数据块中的数据大小被正确设定成音频数据的实际大小。

[0061] 可选块

[0062] XAF文件格式的附加结构可通过使用一种或者多种类型的被称为“可选”块的块来俘获，因为它们可选地在XAF文件中使用。可在XAF中使用一个或多个可选块来提供更富有特征的音频文件。可选块如下所列，其每一个都将在后文更详细地描述。

[0063] (A)标号器块；

[0064] (B)区域块；

[0065] (C)概况块；

[0066] (D)峰(“Peak”)块；

[0067] (E)UMID块；

[0068] (F)信息块；

[0069] (G)编辑注释块；以及

[0070] (H)MIDI块。

[0071] XAF文件的总布局

[0072] XAF文件布局实例

[0073] 图1是根据本发明的实施例示出音频文件总布局的框图。音频文件100包括一组信息块，通常包括音频数据和元数据。图1示出了可在XAF音频文件中出现的一些可能的块。然而，音频文件100的描述既不是可能出现在这样一种文件中的所有块的详尽图示，也不是对本发明的所有实施例来说都是必要的且又描述于音频文件100中的所有块。在音频文件100中描述的块的顺序是任意的，除非本文另行指出。

[0074] 从右至左来看，音频文件100包括数据块102、声道描述块112、概况块122、格式块142以及分组表块132，其中的每一个都将在本文中进行详细描述。

[0075] 数据块102包括数据块头部信息104、音频数据106和状态信息110。数据块头部信息104包括各种信息或者诸如音频数据块大小标志108(在本文其它地方被称为mChunkSize)的元数据。音频数据块大小标志108(还有用于每个块的类似标志)包含某一值，该值不时指示音频数据106的大小。包含在音频数据块大小标志108中的其它值可能具有其它含义，诸如在一个实施例中，用于音频数据块大小标志108的“-1”，指示数据块102是音频文件100中的最后块(本文会更详细地描述)。状态信息110包含了标识数据块102中音频数据106当前版本的信息。正如本文中更详细地描述，状态信息110可针对来自依赖于(例如，源自于)音频块102(诸如，来自于概况块122的相依性指示符124)的其他块的相依性指示符进行比较以确定(鉴于音频数据106当前版本)相依块中的信息是否仍然有效。

[0076] 声道描述块112包含一组音频声道描述，其在一实施例中指定每个包含在文件中的声道的顺序和位置(即，角色或用法)。声道描述块112将在本文中更详细地描述。

[0077] 如上所提及的，在一实施例中，概况块122包含相依性指示符124，其指示从其导出诸如导出统计126的概况数据的版本信息。例如，导出统计126源自于音频数据106的特定版本，其由状态信息110标识并与相依性指示符124相关联。因此，如果音频块102的状态信息110匹配于概况块122的相依性指示符124(或来自于与音频数据106相依的音频文件100中任何其它块的任何其它相似功能相依性指示符)，那么，概况块122中的概况信息就可被认为仍然有效，如同其源头一样。概况块122将在本文中进行更详细的描述。

[0078] 分组表块132用于VBR编码格式。分组表块132表示了经过编码的位流的特性，诸如音频流的(1)在样本帧中的持续时间，(2)任何附加的准备(“priming”)帧以及(3)剩余帧，其中每一个都将在本文中进行更详细的描述。分组表块132也将在本文中进行更详细的描述。

[0079] 格式块142包括对包含在文件(即音频数据106)内的音频数据格式进行描述的信息。格式块142，与分组表块132一起，启动诸如音频文件100的XAF音频文件的自描述(即，通用)功能，以使得处理这一音频文件的软件不需要先验地了解关于音频数据编码的特定格式。格式块142将在本文中进行更详细的描述。

[0080] XAFFileHeader

[0081] 在一实施例中，XAF文件始于文件头部信息，“XAFFileHeader”，其可如后文所述来被构造。文件头部信息后跟随着一系列数据或元数据块。在一实施例中，包含在文件头部信息字段中的值以大尾数顺序进行排序。

[0082] struct XAFFileHeader

[0083] {

[0084] UInt32 mFileType；//′.xaf′

[0085] UInt16 mFileReserved；

[0086] UInt16 mFileVersion；

[0087] }；

[0088] XAFChunkHeader

[0089] 在一实施例中，每个块的前面都是块头部信息(如图1中的数据块头部信息104)，“XAFChunkHeader”，其可如后文所述来被构造。在一实施例中，包含在块头部信息字段中的值以大尾数顺序进行排序。

[0090] struct XAFChunkHeader

[0091] {

[0092] UInt32 mChunkType；

[0093] UInt16 mChunkFlags；

[0094] UInt16 mChunkVersion；

[0095] SInt64 mChunkSize；

[0096] }；

[0097] 其中，mChunkType是块头部信息所适用的块类型，其在一实施例中是四字符的、大尾数排序的代码；

[0098] mChunkFlags被用来描述能够影响给定块数据将会如何被解释的块的数据之中的任何差异；

[0099] mChunkVersion被用来提供块格式的版本号。可想象得到，给定块的格式在XAF文件格式的未来修订版本中可能是不同的，在这种情况下，块版本将会被修订来反映这些变化。

[0100] mChunkSize是数据块的大小，该数据块跟随但不包括此头部信息，这在一实施例中是用多个字节来表示的。

[0101] 格式描述

[0102] 在一实施例中，文件头部信息之后的第一块为格式块(如，图1中的格式块142)，“XAFAudioFormat”，其使用参数值来描述音频编码格式。在一实施例中，格式块必须在音频数据块之前。在一实施例中，格式块的头部信息，“formatChunkHeader”，如后所述而被构造。

[0103] formatChunkHeader

[0104] XAFChunkHeader formatChunkHeader；

[0105] formatChunkHeader.mChunkType＝′desc′；

[0106] formatChunkHeader.mChunkFlags＝0；

[0107] formatChunkHeader.mChunkVersion＝0；

[0108] formatChunkHeader.mChunkSize＝32；

[0109] 其中，mChunkType字段将块类型标识为描述(即，格式描述)块；以及[0110] mChunkSize字段将块大小标识为32字节。

[0111] 在前述实例的头部信息中，格式块头部信息的标志和版本字段这两者都被设定为默认值零。

[0112] XAFAudioFormat

[0113] 音频格式块，“XAFAudioFormat”，跟随格式块头部信息。音频格式块描述了包含在文件中的音频数据的格式。在一实施例中，音频格式块如下文所述来被构造。

[0114] struct XAFAudioFormat

[0115] {

[0116] Float64 mSampleRate；

[0117] UInt32 mFormatID；

[0118] UInt32 mFormatFlags；

[0119] UInt32 mBytesPerPacket；

[0120] UInt32 mFramesPerPacket；

[0121] UInt32 mChannelsPerFrame；

[0122] UInt32 mBitsPerChannel；

[0123] }；

[0124] 音频格式块封装了对描述音频数据流的基本格式属性有必要的全部信息。包含在音频格式结构中的这一信息足够来描述具有相同大小的声道的任一恒定位速率格式。要求附加信息以用于可变位速率数据，如后文根据分组表块所述。“0”值表明该字段或是未知的，或是不可用，或是另外不适合于该格式而应被忽略。应注意到，对于mFormatFlags字段中一些格式，“0”可能是有效值。

[0125] 音频格式块中每一个参数字段都如下文所述。

[0126] mSampleRate-在音频流中音频数据的每秒的样本帧数。在一实施例中，此为IEEE-754浮点表示。

[0127] mFormatID-四字符代码，指示在流中的数据一般类型。

[0128] mFormatFlags-针对每个格式的标志。

[0129] mBytesPerPacket-在数据分组中的字节数。

[0130] mFramesPerPacket-在数据的每个分组中的样本帧数。

[0131] mChannelsPerFrame-在数据的每个帧中的声道数。

[0132] mBitsPerChannel-用于数据帧中每个声道的样本数据的位数。

[0133] mFormatID

[0134] 以下是为mFormatID字段所定义的值。此为示例性的、未详尽的以及非限制性的一列值。

[0135] enum

[0136] {

[0137] kAudioFormatLinearPCM ＝′lpcm′，

[0138] kAudioFormatAppleIMA4 ＝′ima4′，

[0139] kAudioFormatMPEG4AAC ＝′aac′，

[0140] kAudioFormatMACE3 ＝′MAC3′，

[0141] kAudioFormatMACE6 ＝′MAC6′，

[0142] kAudioFormatULaw ＝′ulaw′，

[0143] kAudioFormatALaw ＝′alaw′，

[0144] kAudioFormatMPEGLayer3 ＝′.mp3′，

[0145] kAudioFormatAC3 ＝′ac-3′，

[0146] kAudioFormat60958AC3 ＝′cac3′

[0147] }；

[0148] mFormatID字段的前述值如下文所述。

[0149] kAudioFormatLinearPCM-线性PCM，使用下述的与PCM相关的标志。

[0150] kAudioFormatAppleIMA4-IMA 4:1ADPCM的Apple实现方式；不带标志。

[0151] kAudioFormatMPEG4AAC-MPEG-4AAC；标志字段包含了指示数据具体类型的MPEG-4音频对象类型常数。

[0152] kAudioFormatMACE3-MACE 3:1；不带标志。

[0153] kAudioFormatMACE6-MACE 6:1；不带标志。

[0154] KAudioFormatULaw-μLaw 2:1；不带标志。

[0155] KAudioFormatALaw-aLaw 2:1；不带标志。

[0156] kAudioFormatMPEGLayer3-MPEG-1或-2，层3音频；不带标志。

[0157] kAudioFormatAC3-AC-3；不带标志。

[0158] kAudioFormat60958AC3-AC-3封装用于通过符合IEC60958标准的数字音频接口进行传输；使用标准标志来用于此格式。

[0159] mFormatFlags

[0160] 对于要求进一步描述的格式，使用mFormatFlags字段。在没有进一步描述的情况下，此字段应被设成零。保留未被指定用于任一公开格式的任何标志以备将来使用。考虑到兼容性，那些标志位(或标志值)应该被设成零。以下是用于mFormatFlags字段的定义值。此为示例性的、未详尽的以及非限制性的一列值。

[0161] (A)线性PCM标志：

[0162] enum

[0163] {

[0164] kXAFLinearPCMFormatFlagIsFloat ＝(1L＜＜0)，[0165] kXAFLinearPCMFormatFlagIsLittleEndian ＝(1L＜＜1)

[0166] }；

[0167] 下文描述mFormatFlags字段的每个前述值。线性PCM的标志字段，当被设成零时就表示整数的、大尾数样本格式。

[0168] kXAFLinearPCMFormatFlagIsFloat-设定表示浮点，清空表示整数。

[0169] kXAFLinearPCMFormatFlagIsLittleEndian-设定表示小尾数，清空表示大尾数。

[0170] (B)AAC标志

[0171] 这些标志具有为AAC定义的MPEG-4音频对象类型。

[0172] enum

[0173] {

[0174] kMP4Audio_AAC_Main_ObjectType ＝1，

[0175] kMP4Audio_AAC_LC_ObjectType ＝2，

[0176] kMP4Audio_AAC_SSR_ObjectType ＝3，

[0177] kMP4Audio_AAC_LTP_ObjectType ＝4，

[0178] kMP4Audio_AAC_Scalable_ObjectType ＝6，

[0179] kMP4Audio_ER_AAC_LC_ObjectType ＝17，

[0180] kMP4Audio_ER_AAC_LTP_ObjectType ＝19，

[0181] kMP4Audio_ER_AAC_Scalable_ObjectType ＝20

[0182] }；

[0183] 下文描述mFormatFlags字段的每个前述值。

[0184] kMP4Audio_AAC_Main_ObjectType-AAC主对象。

[0185] kMP4Audio_AAC_LC_ObjectType-AAC低复杂度对象。

[0186] kMP4Audio_AAC_SSR_ObjectType-AAC可扩充采样速率对象。

[0187] kMP4Audio_AAC_LTP_ObjectType-AAC长期预测器对象。

[0188] kMP4Audio_AAC_Scalable_ObjectType-AAC可扩展的对象。

[0189] kMP4Audio_ER_AAC_LC_ObjectType-差错可恢复(ER)AAC低复杂度(LC)对象。

[0190] kMP4Audio_ER_AAC_LTP_ObjectType-差错可恢复(ER)AAC长期预测器(LTP)对象。

[0191] kMP4Audio_ER_AAC_Scalable_ObjectType-差错可恢复(ER)AAC可扩展的对象。

[0192] 用于标志字段的任何其它值将依赖于由MPEG-4标准团体对AAC对象类型的任何将来的修改。

[0193] 格式块实例

[0194] PCM音频的下列变化应该被所有XAF解析器所支持：(1)任一采样速率；(2)16、24和32位带符号整数的样本(既有大尾数也有小尾数)；以及(3)32和64位浮点样本(既有大尾数也有小尾数)。在一实施例中，浮点值符合IEEE-754规范。

[0195] 存在两种可能的方式使24位样本存储在文件之中，并且两者相当普通：(1)压缩在3字节内；以及(2)压缩在4字节容器内。后文描述两种方式的压缩过程。

[0196] 线性PCM

[0197] 本实例关于16位、大尾数立体声、44.1KHz音频数据。对于所有PCM格式，bytesPerPacket和framesPerPacket是等价的(即，1)，因为，通过定义，PCM格式是每分组一帧。

[0198] XAFAudioFormat simplePCM16；

[0199] simplePCM16.mSampleRate＝44100.；

[0200] simplePCM16.mFormatID＝kAudioFormatLinearPCM；

[0201] simplePCM16.mFormatFlags＝0；//big endian integer；

[0202] simplePCM16.mChannelsPerFrame＝2；

[0203] simplePCM16.mBitsPerChannel＝16；

[0204] simplePCM16.mFramesPerPacket＝1；

[0205] simplePCM16.mBytesPerPacket＝4；

[0206] 下一实例关于24位、小尾数立体声、48KHz音频数据。

[0207] XAFAudioFormat simplePCM24；

[0208] simplePCM24.mSampleRate＝48000.；

[0209] simplePCM24.mFormatID＝kAudioFormatLinearPCM；

[0210] simplePCM24.mFormatFlags＝kXAFLinearPCMFormatFlagIsLittleEndian；

[0211] simplePCM24.mChannelsPerFrame＝2；

[0212] simplePCM24.mBitsPerChannel＝24；

[0213] simplePCM24.mFramesPerPacket＝1；

[0214] simplePCM24.mBytesPerPacket＝6；

[0215] 在此情况下，24位被压缩在其容纳字节(即，每24位样本占据文件中的3个字节)。为每24位样本保留4字节也是常见的。在此情形下，24位在4字节字段中被调高对齐。关于此情形的格式会被描述为：

[0216] XAFAudioFormat sparsePCM24；

[0217] sparsePCM24.mSampleRate＝48000.；

[0218] sparsePCM24.mFormatID＝kAudioFormatLinearPCM；

[0219] sparsePCM24.mFormatFlags＝kXAFLinearPCMFormatFlagIsLittleEndian；

[0220] sparsePCM24.mChannelsPerFrame＝2；

[0221] sparsePCM24.mBitsPerChannel＝24；

[0222] sparsePCM24.mFramesPerPacket＝1；

[0223] sparsePCM24.mBytesPerPacket＝8；

[0224] 如后文所述，与非字节对齐样本宽度一样，样本在其容纳字节宽度中被调高对齐。解析器然后就可对其处理，就好像它曾是32位整数(因为，最低的、或最低有效的8位都将是零)。在盘(“disk”)上，这就看起来好像：(MM是最高有效的字节，LL是最低有效的，XX居中，而0则未被使用)

[0225] 00LL XX MM

[0226] 相同布局的大尾数排序版本(4字节中的24位音频)看似：

[0227] MM XX LL 00

[0228] 下一实例用于32位浮点、大尾数6声道、96KHz音频数据。

[0229] XAFAudioFormat simplePCM96；

[0230] simplePCM96.mSampleRate＝96000.；

[0231] simplePCM96.mFormatID＝kAudioFormatLinearPCM；

[0232] simplePCM96.mFormatFlags＝kXAFLinearPCMFormatFlagIsFloat；

[0233] simplePCM96.mChannelsPerFrame＝6；

[0234] simplePCM96.mBitsPerChannel＝32；

[0235] simplePCM96.mFramesPerPacket＝1；

[0236] simplePCM96.mBytesPerPacket＝24；

[0237] 下一实例用于64位浮点、小尾数4声道、192KHz音频数据。

[0238] XAFAudioFormat simplePCM192；

[0239] simplePCM192.mSampleRate＝192000.；

[0240] simplePCM192.mFormatID＝kAudioFormatLinearPCM；

[0241] simplePCM192.mFormatFlags＝kXAFLinearPCMFormatFlagIsFloat

[0242] |kXAFLinearPCMFormatFlagIsLittleEndian；

[0243] simplePCM192.mChannelsPerFrame＝4；

[0244] simplePCM192.mBitsPerChannel＝64；

[0245] simplePCM192.mFramesPerPacket＝1；

[0246] simplePCM192.mBytesPerPacket＝32；

[0247] IMA4

[0248] 当描述以XAF文件格式的压缩格式时(是否每个分组可变或恒定位速率和/或帧)，格式块在某些部分中就描述了对压缩分组进行解压的结果将会提供什么。因此，格式块包含声道数以及采样速率。

[0249] IMA4是恒定位速率，每分组格式的恒定帧，其根据如下格式块形式来进行描述。

[0250] mSampleRate表示在压缩分组中编码的音频单个帧的采样速率；

[0251] mChannelsPerFrame描述了在压缩分组中编码的声道数；

[0252] mFramesPerPacket表示了在每个压缩分组中编码的帧数。

[0253] mBitsPerChannel为零；以及

[0254] mBytesPerPacket为非零值。

[0255] IMA以示例的目的示出，然而，前述条件对于这一性质的任一格式都为真。作为信息点，IMA4总是把64个样本帧编码为每声道34字节的单个分组之中。因此，BytesPerPacket为ChannelsPerFrame*34。从而，将提供44.1KHz、立体声音频的IMA4数据就可描述如下：

[0256] XAFAudioFormat imaDesc；

[0257] imaDesc.mSampleRate＝44100.；

[0258] imaDesc.mFormatID＝kAudioFormatAppleIMA4；

[0259] imaDesc.mFormatFlags＝0；

[0260] imaDesc.mChannelsPerFrame＝2；

[0261] imaDesc.mBitsPerChannel＝0；

[0262] imaDesc.mFramesPerPacket＝64；

[0263] imaDesc.mBytesPerPacket＝imaDesc.mChannelsPerFrame*34；

[0264] AAC

[0265] 根据定义，MPEG-4AAC为可变位速率、每分组格式的恒定帧。MP3具有既是CBR(类似于以上IMA实例)也是VBR(近似于本例)的变化。对于提供可变位速率的、每分组恒定帧的音频格式，使用以下信息来描述该格式：

[0266] mSampleRate表示在压缩分组中编码的音频单个帧的采样速率；

[0267] mChannelsPerFrame描述在压缩分组中编码的声道数；

[0268] mFramesPerPacket表示在每个压缩分组中编码的帧数。

[0269] mBitsPerChannel为零；

[0270] mBytesPerPacket为零，其表示包含在每个分组中的字节数是可变的。

[0271] 因此，包含MPEG-4AAC(使用低复杂性音频对象格式)的文件，其中，经过编码的数据表示44.1KHz、立体声音频可描述如下：

[0272] XAFAudioFormat aacDesc；

[0273] aacDesc.mSampleRate＝44100.；

[0274] aacDesc.mFormatID＝kAudioFormatMPEG4AAC；

[0275] aacDesc.mFormatFlags＝kMP4Audio_AAC_LC_ObjectType；

[0276] aacDesc.mChannelsPerFrame＝2；

[0277] aacDesc.mBitsPerChannel＝0；

[0278] aacDesc.mFramesPerPacket＝1024；

[0279] aacDesc.mBytesPerPacket＝0；

[0280] IMA和AAC这两种类型音频的每个分组的持续时间可通过mSampleRate除以mFramesPerPacket来进行计算。

[0281] 可变位速率、每分组可变帧

[0282] 一些经过编码的音频格式对分组进行编码，这些分组不仅具有可变数据大小，而且也用未压缩音频源的(其当被解压时就将生成可变数量的帧)可变数量的每分组帧。对于该性质的格式，应用下列信息：

[0283] mSampleRate表示在压缩分组中编码的音频的单个帧的采样速率；

[0284] mChannelsPerFrame描述在压缩分组中编码的声道数；

[0285] mFramesPerPacket为零，其表示包含在每个分组中的帧数是可变的；

[0286] mBitsPerChannel为零；

[0287] mBytesPerPacket为零，其表示包含在每个分组中的字节数是可变的。

[0288] 实例性可变位速率、每分组音频文件的可变帧可如下所述：

[0289] XAFAudioFormat vbr_vfp_Desc；

[0290] vbr_vfp_Desc.mSampleRate＝sampleRateOfAudio；

[0291] vbr_vfp_Desc.mFormatID＝kVariableFramesPerPacket；

[0292] vbr_vfp_Desc.mFormatFlags ＝ ...；//any flags appropriate to theformat(适合于该格式的任何标志)

[0293] vbr_vfp_Desc.mChannelsPerFrame＝numberOfChannelsOfAudio；

[0294] vbr_vfp_Desc.mBitsPerChannel＝0；

[0295] vbr_vfp_Desc.mFramesPerPacket＝0；

[0296] vbr_vfp_Desc.mBytesPerPacket＝0；

[0297] 非字节对齐的格式

[0298] 可适用的假设(对现存的MPEG音频格式是成立的)就是，压缩音频格式为字节对齐的。然而，在某些实例中，该假设并不适用。

[0299] 线性PCM

[0300] 一些PCM位深度不是字节对齐的，例如，12位或18位PCM音频。这些格式应该遵守以下要求：(1)格式在字节对齐的样本宽度中被压缩；以及(2)样本在封闭的字节对齐宽度内被调高对齐。因此，12位PCM音频数据(在以下情况中，此为大尾数)在某一2字节(16位)的字中被压缩，并且将会表达为：

[0301] XAFAudioFormat PCM12；

[0302] PCM12.mSampleRate＝44100.；

[0303] PCM12.mFormatID＝kAudioFormatLinearPCM；

[0304] PCM12.mFormatFlags＝0；//big endian integer(大尾数整数)

[0305] PCM12.mChannelsPerFrame＝2；

[0306] PCM12.mBitsPerChannel＝12；

[0307] PCM12.mFramesPerPacket＝1；

[0308] PCM12.mBytesPerPacket＝4；

[0309] 下面紧跟着是18位PCM数据的类似方案，其中音频数据可在3字节(24位)字中被调高对齐。这就允许这一格式的解析器(不包括它们专门利用样本的位深度这一情况)以使用与用于其字节对齐格式相同的算法来解析和转换样本数据。因此，在上述12位的案例中，解析16位压缩数据的代码也可解析12位样本数据，以相同方式来对待之。指定数据实际是12位就可对该音频数据的一些使用提供某些优势。

[0310] PWM

[0311] PWM是其中每个样本都是一位的格式。PWM用作SACD(超音频CD)的数据格式。以下描述PWM立体声数据将会在XAF文件中如何被压缩和描述。

[0312] XAFAudioFormat pwmDesc；

[0313] pwmDesc.mSampleRate＝2822400.；

[0314] pwmDesc.mFormatID＝kAudioFormatPWM；//′pwm′

[0315] pwmDesc.mFormatFlags＝0；

[0316] pwmDesc.mChannelsPerFrame＝2；

[0317] pwmDesc.mBitsPerChannel＝1；

[0318] pwmDesc.mFramesPerPacket＝8；

[0319] pwmDesc.mBytesPerPacket＝2；

[0320] 对SACD位流的采样速率是2.8224MHz。此刻，并不存在已知的且被要求用于PWM格式的标志。这一特定的流是2声道并且每声道有1位。存在每分组8帧，从而每分组2字节(在文件中1个字节用于每个声道)。因此，PWM被压缩如下(以二进制)：LLLLLLLL RRRRRRRR。即，一个字节表示8个单个声道值，以及每个声道的交错过程在字节边界上(而不在单个样本或位边界上)完成。

[0321] 音频数据块

[0322] 在一实施例中，XAF文件包含一个且仅有一个音频数据块(如图1中的数据块102)，其跟随着音频数据块头部信息(如图1中的数据块头部信息104)。

[0323] 在一实施例中，数据块如下建立：

[0324] struct XAFData

[0325] {

[0326] UInt32 mEditCount；

[0327] UInt8 mData[kVariableLengthArray]；

[0328] }；

[0329] 其中，

[0330] mEditCount是标识音频数据的当前版本的信息，其在本文也被称为音频的“状态信息”；

[0331] mData是可变长度字段，其包含音频数据(如图1中的音频数据106)；

[0332] 音频数据块头部信息如下。

[0333] XAFChunkHeader dataChunkHeader；

[0334] dataChunkHeader.mChunkType＝′data′；

[0335] dataChunkHeader.mChunkFlags＝0；

[0336] dataChunkHeader.mChunkVersion＝0；

[0337] dataChunkHeader.mChunkSize＝-1；

[0338] //set:mEditCoout＝0；

[0339] 音频数据大小参数

[0340] mChunkSize的值“-1”表示音频数据从文件的此部分开始到文件的结尾。当最终完成文件时就优选地更新该字段以反映音频数据块的真正大小。

[0341] XAF允许应用程序将音频数据块大小字段(如，音频数据块大小标志108，用于图1中的音频数据106)设置成“-1”以及进行记录而无需执行文件查找来更新该大小字段。
当程序完成记录时程序就能更新音频数据块大小字段，mChunkSize。其音频数据块大小字段被设成“-1”的文件被很好定义且应能够被支持XAF文件的任一程序所打开。在此状态下的文件意味着音频数据块是文件中的最后块并且音频数据从该块的开始延伸到文件的结尾。因此，应用程序可在存储文件中轻易找到音频数据结尾的位置，以使得非音频元数据的新块可容易地添加到该文件。如果有在音频数据之后的任何其它数据，那么，mChunkSize就必须全部时间都有效。当读取文件时，如果mChunkSize被设成小于零，那么，阅读器就应该将此更新为正确的文件大小(尺寸)。

[0342] 在一实施例中，XAF文件不把文件大小存储在其文件头部信息中，就象AIFF或者WAVE文件那样。由于该文件的大小可从文件系统或者传输层获得，所以这一信息将会是冗余的。

[0343] 图2为根据本发明的实施例示出用于处理音频信息的方法的流程图。

[0344] 在框202处，读取音频数据大小信息。举例来说，诸如mChunkSize的音频数据块大小标志108(图1)，被从数据块102(图1)的诸如XAFChunkHeader的数据块头部信息104(图1)中读取出来。

[0345] 在框204处，确定在大小信息中指示的大小是否是诸如音频数据106(图1)的音频数据的有效大小。如果所指示的大小就是音频数据的有效大小，那么，在框206处，基于所指示的大小来访问音频数据。举例来说，如果音频数据块大小标志108(图1)指示了某一大于零的尺寸，那么，就从数据块102(图1)中读取音频数据106(图1)。否则，如果所指示的大小并不是音频数据的有效大小，那么就假设音频数据块是音频文件的最后块，并且用整个音频文件的大小来确定音频数据的大小。例如，“-1”值在音频数据块大小标志108中被指示出来，这就表明了无效的大小。因此，音频数据106的实际大小就可基于完整音频文件100(图1)(如，来自于操作系统或者文件系统)与文件中最后块(即，音频块102)的起始点之间的比较而被确定出来。

[0346] 编辑以及交叉块相依性

[0347] XAF文件可包含多个块，其对另一个块的特定状态具有相依性，典型地，实际音频数据存储在该数据块之内。例如，概况数据基于音频数据的特定内容而生成。因此，假如音频将改变，则该概况将会作废。为了说明这一情况，数据块具有无论何时程序编辑音频数据块的内容其都会增加的mEditCount字段(如图1中的状态信息110)，用以识别音频数据的当前状态(或版本)。在一实施例中，相依于数据块的特定状态的块也具有mEditCount字段(如图1中的相依性指示符124)，其在相依块生成时被设成数据块mEditCount字段的值，从而识别该相依块从中导出的音频数据的状态(或版本)。

[0348] mEditCount字段在创建新文件时初始设为零。在以任一方式编辑数据块的内容的任一时间，该字段必须通过编辑程序来递增。本文中会参考总块和峰块更详细地描述这项功能。

[0349] 在一实施例中，相依于数据块的特定状态的块字段也具有mEditCount字段，其在填充(“populated”)相依字段时被设成数据块的mEditCount字段的值，并因此而识别出该相依字段从中导出的音频数据的状态(或版本)。

[0350] 图3为根据本发明的实施例示出用于处理音频信息的方法的流程图。

[0351] 在框302处，相依性指示符从来自于音频文件的块(称为“第一块”，而并不暗指其实际就是音频文件中的第一块)中读取出来，其中该块包含相依于音频文件中另一块的信息。例如，来自概况块122(图1)的导出统计126(图1)依赖于或者源自于音频块102(图1)的音频数据106(图1)，相依性指示符124(图1)(如mEditCount)被从概况块122中读取。在此例中，相依性指示符122指示导出统计126从音频数据106的哪个版本导出过。总的来说，给定块的或者块中给定参数的相依性指示符，与关联于给定块或参数所相依的信息的版本的状态信息相匹配。

[0352] 在框304处，状态信息从另一块(第一块)相依的块(被称为“第二块”，而并不暗指其实际就是音频文件中的第二块)中读取出来。例如，读取数据块102(图1)中的当前状态信息110(图1)，其指明音频数据106(图1)的当前版本。因此，在抉择框306处，确定相依性指示符与状态信息是否匹配。例如，确定第一块的mEditCount(其与第一块中的至少某些信息相关联)，是否与第二块(第一块中的信息所相依的块)的当前mEditCount相同。

[0353] 如果相依性指示符与状态信息匹配，那么，就意味着第一块中的信息所相依的第二块中的信息，自从第一块中的信息生成以来未改变过。例如，导出统计126(图1)曾从中生成的音频数据106(图1)自从导出统计126生成以来就未被改变过，因此，导出统计仍然有效并且与音频数据106相一致。这样，在框308处，使用来自于第一块的现存元数据，或者在第一块之中的、相依于第二块的无论什么信息。

[0354] 如果相依性指示符与状态信息不匹配，那么就意味着第一块中的信息所相依的第二块中的信息，自从第一块中的信息生成以来已经改变了。例如，导出统计126(图1)曾从中生成的音频数据106(图1)自从导出统计126生成以来已经改变了，因此，导出统计可能不再有效并且可能与音频数据106不一致。这样，在框310处，为第一块生成新的元数据，或者在第一块之中的、相依于第二块的无论什么信息。例如，重新生成或者更新所述导出统计126以反映音频数据106的当前状态，音频数据106与当前状态信息110(图1)相关联。

[0355] 此外，在框312处，更新相依性指示符来反映为第一块所生成的新的元数据。例如，更新与所述导出统计126相关联的相依性指示符124(图1)(如mEditCount)来反映与音频数据106相关联的当前状态信息110(如mEditCount)，从而指示当前导出统计126重新有效并与该统计所依赖的信息(即，音频数据106)一致。

[0356] 分组表块

[0357] 分组表块(如图1中的分组表块132)表达了经过编码的位流的特性，即，音频流的(1)样本帧中的持续时间，(2)任一附加的准备(可被认为是等待时间(“latency”))帧，以及(3)剩余帧(曾在编码进程中被执行以刷新每分组样本的最后部分帧的任一填充(“padding”))。需要分组表块以用于VBR格式，其中分组表块的存在由为零的格式块的mBytesPerPacket字段来确定。

[0358] 在一实施例中，如下构造分组表块。

[0359] struct XAFPacketTableHeader

[0360] {

[0361] SInt64 mNumberPackets；

[0362] SInt32 mPrimingFrames；

[0363] SInt32 mRemainderFrames；

[0364] }；

[0365] 其中，

[0366] mNumberPackets是包含在文件中的音频数据的总的分组数；

[0367] mPrimingFrames是经过分组(“packetized”)的流用作准备和/或处理等待时间的帧数；

[0368] mRemainderFrames是最后分组遗留下的帧数。例如，AAC位流可能仅有在其最后分组中有效的313帧。每分组的帧为1024，所以，在此情形，mRemainderFrames是(1024-313)，其表示了当进行解码时应该从最后分组的输出中裁剪下来的样本数。

[0369] 如果经过编码的位流正被编辑，那么就推荐在将会占据至少mPrimingFrames的编辑点之前的分组应该被所述编辑所采用，以从编辑点中确保音频的完美再现。当然，在随机访问文件中的不同分组以便播放时，mPrimingFrames就应该被用来在所想要的点上重新构造音频。

[0370] 在一实施例中，分组描述中的值使用可变长度编码整数。每个字节都包含7位的尺寸信息。如果设定了高位(即，字节值＞＝128)，那么在流中的下一字节就包含了该尺寸的延续。通过找到具有＜127值的字节来确定整体大小。

[0371] 例如，

[0372] 值表示

[0373] 1 1 (Ox01) 1Byte

[0374] 127 127 (0x7F) 1Byte

[0375] 128 1 128 (0x01 0x80) 2Bytes

[0376] 129 1 129 (0x01 0x81) 2Bytes

[0377] 等等。

[0378] 在一实施例中，参考了其它一些块(如，概况块、峰块等等)进行描述的编辑计数语义并不适合于分组表块，因为其状态必须总是与对音频数据执行的任何编辑同步。

[0379] 以恒定位速率格式进行使用

[0380] 在一实施例中，分组块甚至以恒定位速率(每分组的恒定帧以及每分组的恒定字节)格式出现，以表达以下两条可能的信息之中的一条：(1)由于编码解码器的性质所引起的任何等待时间(mPrimingFrames)；(2)任何剩余帧，其中原始资料(“sourcematerial”)与该编码解码器的每分组边界的帧不一致。在此用法中，mNumberPackets应该设成零，并且应该被解析器所忽略。例如，IMA将样本编码为每帧64个样本帧的分组。假如原始资料不可被64帧等分，那么，IMA内容的最后分组就将解码到比被分组所呈现的64个更少的样本。因此，IMA内容的XAF文件可具有分组表，其中最后分组仅具有5个有效样本，如下：

[0381] mIMAPacketTable.mNumberPackets ＝ 0；//set to zero，ignored forcodecs where the desc’s mBytesPerPacket！＝ 0(设成零，在描述的 (“desc’s”)mBytesPerPacket！＝0的情况下被编码解码器所忽略)

[0382] mIMAPacketTable.mPrimingFrames ＝0；//IMA has nolatency(IMA没有等待时间

[0383] mIMAPacketTable.mRemainderFrames＝59；//64(frames perpacket(每分组的帧))-5

[0384] 此情形中的该块大小将为16，因为在此类型的格式中不存在分组描述。这是此类型格式的可选块。

[0385] 以每分组格式的恒定帧进行使用

[0386] 在一实施例中，当每分组字节为零以及每分组帧是非零时分组块就存在。分组描述包含一个可变长度的整数，以对每个分组都包含的字节数进行描述。

[0387] 例如，给定被编码为44.1KHz(立体声)、3074个样本帧的AAC源的音频数据，该格式就被描述成每分组1024帧以及每分组0字节。数据块将包含6个首尾相连的AAC分组，以及分组表块如下所示。

[0388] XAFChunkHeader packetChunkHeader；

[0389] dataChunkHeader.mChunkType＝′pakt′；

[0390] dataChunkHeader.mChunkFlags＝0；

[0391] dataChunkHeader.mChunkVersion＝0；

[0392] dataChunkHeader.mChunkSize＝calc_sizeOfThePacketTable；

[0393] XAFPacketTableHeader packetTable；

[0394] packetTable.mNumberPackets＝5；

[0395] packetTable.mPrimingFrames＝2112；

[0396] packetTable.mRemainderFrames＝958；

[0397] 在这之后会是5个可变大小的整数，其描述用于所述5个分组中每一个的字节数。整个calc_sizeOfThePacketTable至少会是被用来对分组大小进行编码的字节数加16(sizeOf(XAFPacketTableHeader))。在此情况下，分组与其编码/解码帧的下列关系为：

[0398] 分组： 1 2 3 4 5 6

[0399] 有效帧：0 0 960 1024 1024 66

[0400] 以每分组格式的可变帧进行使用

[0401] 在一实施例(由描述具有既用于每分组的帧又用于每分组条目的字节的零值这一事实确定出来)中，分组描述包含了用于每个分组的两个值(两者都被编码为可变长度整数)(1)包含在分组之中的帧数；以及(2)以字节为单位的分组大小。

[0402] 一些音频编码解码器(诸如MPEG-2中的主轮廓(“MainProfile”)AAC或者MPEG-4中的AAC长期预测对象)既使用来自先前范围又来自随后范围中使用样本，该范围将在特定的、经过编码的分组中被编码。然而，一旦被编码，在跟随当前分组的任何数据的这些分组之中就没有相依性，虽然对mPrimingFrames描述的先前分组具有相依性。

[0403] 在一实施例中，如果音频格式在其被编码的位流中不具有前向相依性，分组表块就不包含描述这样一种相依性的字段。在一实施例中，如果某种格式在其被编码的位流中不具有前向相依性，分组表块就可被用来对其进行解释。

[0404] 声道描述块

[0405] 声道描述块(如图1中的声道描述块112)包含了一组音频声道描述，其在一实施例中指定包含在文件中的每个声道的顺序和位置(即，角色或者用法)这两者。在一实施例中，声道描述块的结构如下。

[0406] mChunkType＝′chan′

[0407] struct AudioChannelDescription

[0408] {

[0409] AudioChannelLabel mChannelLabel；

[0410] UInt32 mChannelFlags；

[0411] Float32 mCoordinates[3]；

[0412] }；

[0413] 包含在声道描述块中的声道描述的数量与在格式块中指定的声道数相同。声道描述的顺序描述了音频数据的、经过匹配的声道。即，第一声道描述描述了第一声道，第二声道描述描述了第二声道，如此等等。声道标签(“label”)、坐标规格和标志(“flag”)将在后文提供。

[0414] 不带声道描述的XAF文件可解释成：

[0415] 1声道-单声道

[0416] 2声道-立体声

[0417] ＞2声道-没有有关声道或者其预期的用法的隐含信息是已知的。

[0418] 把多声道的混和分割成单声道文件的汇集是常见的操作。在这一情况下，建议这些被分割(并因此相互依赖)的文件中的每一种都包含声道描述，其描述该文件的声道的预期使用。例如，不是单个立体声文件，而是两个文件：一个用于左声道，一个用于右声道。左声道文件具有将声道标记为左声道的单个声道描述，而右声道文件具有将声道标记为右声道的单个声道描述。这就避免了仅仅在文件名中包括这种声道信息的脆弱但又常见的操作。

[0419] 在一实施例中，声道标签仅仅描述了声道的标签(左、右等等)。基于标签的声道的位置当被如此指定时就从该声道的标准位置中推断出来。例如，除了声道标签之外，描述还可指定位置。该位置可能是该标签的预期位置，或者适合于给定文件的声道的定制位置。

[0420] 通过指定标签的方式，解析软件就可导出正由文件呈现的类属(“generic”)声道布局。例如，具有指示了左、右、左环绕、右环绕、中间以及LFE的标签的6声道文件可被呈现为包含5.1内容的文件。将在后文介绍通常使用的、具有其已知的声道组分的声道布局。

[0421] 后文所述的信息块，还提供关键字，其用于表示包含在文件中的声道布局的、用户可提供的名称。

[0422] 将在后文中“杂项描述”标题之下描述可用来标识声道的声道描述定义、可用来指定将被呈现的各自声道的位置的声道坐标，以及普通(“common”)声道布局。

[0423] 可选块

[0424] 下列块是可选块，因为它们并不都在所有XAF文件中显示。

[0425] 自由块

[0426] mChunkType＝′free′

[0427] 此为用于在文件中保留空间的填充块。自由块的内容没有任何含义。

[0428] 魔块块

[0429] mChunkType＝′kuki′

[0430] 魔块块包含了由含在文件之中的格式所要求的专用数据。一旦有可能，魔块的结构就由其描述的格式来定义。通过定义和提供符合标准的“kuki’s”，解析和播放这些文件的其它代码就几乎不会失败。因此，对于以下格式，一旦出现，魔块就定义为：

[0431] MP3-无魔块(因为其并不被数据流所要求)；

[0432] AAC-在MPEG-4定义中被定义为特定到编码解码器的数据的ESDS。

[0433] 与分组数据格式的布局一样，拥有或管理音频格式的团体或公司也被要求来描述魔块的格式(尽管对于该格式来说这是必需的)。而且，如果某一格式为专有格式，那么，该格式的所有者就应该描述魔块格式并且还负责对魔块内容所要求的任何数据划分版本，即，块头部信息的版本字段并不被用来对包含在魔块中的数据的不同数据格式进行划分版本。

[0434] 标号器块

[0435] XAF格式提供了富标号器格式(其也被用来定义区域)，这就提供有效和强劲的记录和编辑能力。标号器包括SMPTE时间戳，以及能用于包含当控制(“mastering”)时所用信息的可扩展标志。在一实施例中，标号器块按如下构造。

[0436] mChunkType＝′mark′

[0437] //SMPTE Time Types(SMPTE时间类型)

[0438] enum

[0439] {

[0440] kXAF_SMPTE_TimeType24 ＝1，

[0441] kXAF_SMPTE_TimeType25 ＝2，

[0442] kXAF_SMPTE_TimeType30Drop ＝3，

[0443] kXAF_SMPTE_TimeType30 ＝4，

[0444] kXAF_SMPTE_TimeType2997 ＝5，

[0445] kXAF_SMPTE_TimeType2997Drop ＝6，

[0446] kXAF_SMPTE_TimeType60 ＝7，

[0447] kXAF_SMPTE_TimeType5994 ＝8

[0448] }；

[0449] struct XAF_SMPTE_Time

[0450] {

[0451] UInt8 mHours；

[0452] UInt8 mMinutes；

[0453] UInt8 mSeconds；

[0454] UInt8 mFrames；

[0455] UInt32 mSubFrameSampleOffset；

[0456] }；

[0457] typedef struct XAF_SMPTE_Time XAF_SMPTE_Time；

[0458] struct XAFMarker

[0459] {

[0460] UInt32 mMarkerSize；//length in bytes of the[0461] marker.(以字节为单位的标号器长度)

[0462] UInt32 mType；

[0463] Float64 mFramePosition；

[0464] SInt32 mMarkerID；

[0465] XAF_SMPTE_Time mSMPTETime；

[0466] UInt16 mChannel；

[0467] UInt16 mReserved；

[0468] UInt8 mName[kVariableLengthArray]；

[0469] //null terminated UTF8string(以null结束的UTF8字符串)

[0470] }；

[0471] typedef struct XAFMarker XAFMarker；

[0472] //marker types(标号器类型)

[0473] //markers(标号器)

[0474] 以下是示例性的、未详尽的以及非限制性的值列表且该值有不同的标号器类型。

[0475] enum{

[0476] kXAFMarkerType_Generic ＝0，

[0477] kXAFMarkerType_ProgramStart ＝′pbeg′，

[0478] kXAFMarkerType_ProgramEnd ＝′pend′，

[0479] kXAFMarkerType_TrackStart ＝′tbeg′，

[0480] kXAFMarkerType_TrackEnd ＝′tend′，

[0481] kXAFMarkerType_Index ＝′indx′，

[0482] kXAFMarkerType_RegionStart ＝′rbeg′，

[0483] kXAFMarkerType_RegionEnd ＝′rend′，

[0484] kXAFMarkerType_RegionSyncPoint ＝′rsyc′，

[0485] kXAFMarkerType_SelectionStart ＝′sbeg′，

[0486] kXAFMarkerType_SelectionEnd ＝′send′，

[0487] kXAFMarkerType_EditSourceBegin ＝′cbeg′，

[0488] kXAFMarkerType_EditSourceEnd ＝′cend′，

[0489] kXAFMarkerType_EditDestinationBegin ＝′dbeg′，

[0490] kXAFMarkerType_EditDestinationEnd ＝′dend′，

[0491] kXAFMarkerType_SustainLoopStart ＝′slbg′，

[0492] kXAFMarkerType_SustainLoopEnd ＝′slen′，

[0493] kXAFMarkerType_ReleaseLoopStart ＝′rlbg′，

[0494] kXAFMarkerType_ReleaseLoopEnd ＝′rlen′

[0495] }；

[0496] struct XAFMarkerChunk

[0497] {

[0498] UInt32 mSMPTE_TimeType；

[0499] UInt32 mNumberMarkers；

[0500] XAFMarker mMarkers[kVariableLengthArray]；

[0501] }

[0502] typedef struct XAFMarkerChunk XAFMarkerChunk.

[0503] 如果特定标号器的SMPTE时间无效(即，未被设定)，那么，在用于该标号器的SMPTE时间中的所有字节都应被设成“0xFF”，这就是本文的无效SMPTE时间。如果mSMPTE_TimeType为零，那么，就没有标号器包含有效SMPTE时间(即，所有SMPTE时间都必须被标记为无效)。如果mSMPTE_TimeType非零，那么该字段就表示包含在给定标号器中的任何有效SMPTE时间的帧速率轴。然而，在这样一种情况下，标号器仍可包含无效SMPTE时间。

[0504] 提供了mSubFrameSampleOffset字段以使得样本位置的SMPTE相关性能够被子帧化(“sub-frame”)(以及精确子帧化的样本)。其为对HH:MM:SS:FF时间戳的样本偏移。

[0505] 区域块

[0506] mChunkType＝′regn′

[0507] struct XAFRegion

[0508] {

[0509] UInt32 mNumberMarkers；

[0510] XAFMarker mMarkers[kVariableLengthArray]；

[0511] }；

[0512] typedef struct XAFRegion XAFRegion；

[0513] struct XAFRegionChunk

[0514] {

[0515] UInt32 mSMPTE_TimeType；

[0516] UInt32 mNumberRegions；

[0517] XAFRegion mRegions[kVariableLengthArray]；

[0518] }

[0519] typedef struct XAFRegionChunk XAFRegionChunk.

[0520] mSMPTE_TimeType字段的含义和解释与对标号器块所描述的相同。

[0521] 概况块

[0522] 在XAF文件中，音频概况元数据(举例来说，关于诸如最大振幅和最小振幅的音频数据的样本的统计)存储在与实际音频数据相同的文件内的某一概况块(如图1的概况块122中的导出统计126)之中。在一实施例中，该概况块的结构如下。

[0523] mChunkType＝′ovvw′

[0524] struct XAFOverviewSample

[0525] {

[0526] SInt16 mMinValue；

[0527] SInt16 mMaxValue；

[0528] }；

[0529] struct XAFOverview

[0530] {

[0531] UInt32 mEditCount；

[0532] UInt32 mNumFramesPerOVWSample；

[0533] XAFOverviewSample mData[kVariableLengthArray]；

[0534] }；

[0535] typedef struct XAFOverview XAFOverview；

[0536] 其中，

[0537] mNumFramesPerOVWSample描述了由单个OVW样本表示的音频数据帧数；

[0538] mData-在该概况样本的每个字节中的数据是大尾数、带符号的16位整数。每个样本有两个数据点，最小和最大振幅。

[0539] 概况块的头部信息包括UInt32大小的字段mEditCount。当创建概况块时，mEditCount字段(如图1的相依性指示符124)应该设成用来创建该概况的数据块的编辑计数字段的当前值。因而，通过将概况的编辑计数值与数据块的编辑计数当前值进行比较，程序就可确认概况是否仍然有效。如果它们不匹配，那么，概况就应被认为无效而被重新生成。可能有多个概况数据块，其可包括不同分辨率的相同的统计。

[0540] MIDI块

[0541] mChunkType＝′midi′

[0542] MIDI块的内容为标准MIDI文件。MIDI块可被用来表示有关音频数据的元信息，例如，节拍信息、音调符号(“key signature”)、拍子记号(“time signature”)、等同于音频数据的MIDI等等。

[0543] 峰块

[0544] mChunkType＝′peak′

[0545] struct XAFPositionPeak

[0546] {

[0547] Float32 mValue；

[0548] UInt64 mFrameNumber；

[0549] }.

[0550] 峰块产生了带符号的最大绝对振幅，其规范到了在[-1.0，+1.0]区间之中的浮点范围，并且在所述峰出现的文件中产生帧。整数值应该通过二的适当幂分到区间[-1.0，+1.0]。例如，最大正16位值为(32767.0/32768.0)。mValue字段符合IEEE-754规范。

[0551] 峰块的数据大小为：

[0552] mChunkSize ＝ sizeof(XAFPositionPeak)*numChannelsInFile+sizeof(UInt32).

[0553] 这里，sizeof(UInt32)用于mEditCount字段。因此，对于2声道文件，峰块将看起来像是这样：

[0554] mChunkSize＝26；//12*2+4

[0555] mEditCount＝//edit count of data chunk(数据块的编辑计数)

[0556] myPeakData.mValue[0]＝//maximum dBFS value of channel 0(声道0的最大dBFS值)

[0557] myPeakData.mFrameNumber[0] ＝ //sample frame location of thismaximum value for channel 0(声道0的这一最大值的样本帧位置)

[0558] myPeakData.mValue[1]＝//maximum dBFS value of channel 1(声道1的最大dBFS值)

[0559] myPeakData.mFrameNumber[1] ＝ //sample frame location of thismaximum value for channel 1.(声道1的这一最大值的样本帧位置。)

[0560] 与概况块一样，当创建峰块时，该块的编辑计数字段就应被设成数据块mEditCount字段的值。在文件中，应该仅有一个峰块。如果峰块的编辑计数与音频数据块的编辑计数不匹配，那么，峰块的数据就应被认为无效，因而被重新生成。在此规范中，标志和版本字段应该被设成零。

[0561] UMID块

[0562] mChunkType＝′umid′

[0563] 唯一资料标识符(“Unique Material Identifier”)由SMPTE组织(SMPTE330M-2000)定义并在广播和其它行业中使用，以唯一标识包含在某一文件和文件汇集中的资料。UMID块大小为64字节。在一个文件中仅能有一个UMID块。如果使用32字节基本UMID，后面32字节就应该设成零。预计在XAF文件使用中会坚持欧洲广播联盟(EBU)公布的、为具有音频内容的UMID所用的指南。

[0564] 信息块

[0565] mChunkType＝′info′

[0566] struct XAFStringsChunk

[0567] {

[0568] UInt32 mNumEntries；

[0569] // struct{

[0570] // UInt8 mKey[kVariableLengthArray]； //[0571] null terminated UTF8 string(以null结束的UTF8字符串)

[0572] // UInt8 mValue[kVariableLengthArray]；//

[0573] null terminated UTF8 string(以null结束的UTF8字符串)

[0574] // } mStrings[kVariableLengthArray]； //

[0575] variable length(可变长度)

[0576] }；

[0577] 信息块可包含任何数量的字符串键值对，其中键值对本身是相当随意的。信息块的mChunkSize大小为键值字符串所占据的字节数与用于mNumEntries字段的4字节之和。

[0578] 在信息块中的信息也可在XAF文件内的其它块之中出现。在此情况下，其它块比该信息块优先。例如，文件既可同时包含音调符号条目和信息块中的节拍这两者，也可包含带有音调和节拍MIDI事件这两者的MIDI块。如果有冲突，那么包含在MIDI块中的信息就优先于信息块中的信息。

[0579] 以下为示例性的、未详尽的以及非限制性的信息关键字值列表。

[0580] base note为音频数据的基调(如果适用的话)。该字符串包含了MIDI音调数(“note number”)并可以为小数来处理“走调”样本(如，“60.12”在中央C音上十二森特)。“.”字符必须作为音调号及其小数部分之间的隔离符来使用。

[0581] tempo是以每分钟拍子为单位的音频数据的基节拍。

[0582] key signature-例如，″C″，″Cm″，″C#″，″Cb″。音调是从A到G的值的大写，“m”用于小调，“b”用于降半音，“#”用于升半音。

[0583] time signature-例如，“4/4”、“6/8”。

[0584] artist标识音频的音乐家/创作者

[0585] album标识唱片/音乐集的名称，如果有的话。

[0586] track number唱片/音乐集的曲目数。

[0587] year唱片/音乐集制作的年份。

[0588] composer标识音频的作曲家，如果有的话。

[0589] lyricist标识歌词作者，如果有的话。

[0590] genre标识音频的风格，如果适用的话。

[0591] title为所含歌曲/循环/样本等等的名义标题或者名称。该标题不同于文件名。

[0592] recorded time-天字符串的时间。

[0593] comments-

[0595] source encoder-例如，″My AAC Encoder，v4.2″。

[0596] encoding application-例如，″My App，v1.0″。

[0597] nominal bit rate-例如，″128kbits″。

[0598] channel layout-例如，″stereo″(“立体声”)，″5.1 Surround″(″5.1环绕″)，″10.2 Surround″(″10.2环绕″)等等。

[0599] 在一实施例中，可执行呈现的代码来预先考虑版权关键字的字符串“Copyright ”而不是在该版权关键字的值中包括这一字符串。

[0600] 放置“.”字符作为关键字的第一个字符意味着键值对通常不显示。这就允许不同的应用程序来存储应该由其它程序保留的专门信息，而不必把无潜在意义的或者易令人混淆的数据显示给用户。

[0601] 编辑注释块

[0602] mChunkType＝′edct′

[0603] 该块类型用于经过时间戳的、人类可读的注释，该注释与对包含在XAF文件中的数据进行编辑相一致。该块的内容使用与“info”块相同的布局(即，UInt32 mNumEntries，以及一对键值对)。然而，在编辑注释块中，关键字为天字符串的时间以及可概括所进行的编辑的注释。包含在XAF文件中的天时间戳的任何时间具有由ISO-8601规范定义的格式。该格式细节按如下描述。

[0604] 可扩充性和UUID块

[0605] mChunkType＝′uuid′

[0606] 该块类型用来提供用于定制块的、经过保证的唯一标识符，其基于UUID标识符的ISO 14496-1规范。在一实施例中，UUID块按如下构造。

[0607] struct XAF_UUID_ChunkHeader

[0608] {

[0609] XAFChunkHeader mHeader；

[0610] UInt8 mUUID[16]；

[0611] }；

[0612] XAF_UUID_ChunkHeader uuidChunkHeader；

[0613] uuidChunkHeader.mHeader.mChunkType＝′uuid′；

[0614] uuidChunkHeader.mHeader.mChunkFlags＝0；

[0615] uuidChunkHeader.mHeader.mChunkVersion＝0；

[0616] uuidChunkHeader.mHeader.mChunkSize ＝

[0617] including UUID>；

[0618] memcpy(uuidChunkHeader.mUUID，generatedUUID，16).

[0619] 跟随UUID块头部信息之后的任一数据都由该UUID定义。UUID块的mChunkSize必须包括被生成的16字节UUID的大小。如果UUID块相依于数据块的编辑计数，那么就应该存储在mUUID字段之后。

[0620] 对于有些块，如Markers、Regions、和Information，该块的实际数据尺寸可能大于其当前有效内容。这就允许用在块的实际数据段中的某些动态余量(“headroom”)来创建文件，以添加附加的内容。这些类型的块包含了用于有效条目数的指示器(“specifier”)并且，该指示器当解析时就应该是用来返回有效数据的基本目标。

[0621] 杂项描述

[0622] 天数数据格式(ISO-8601)

[0623] YYYY ＝四位数年份

[0624] MM ＝两位数月份(01＝一月，等等)

[0625] DD ＝月份的两位数日(01到31)

[0626] ′T′ ＝日期和时间片段之间的分隔符

[0627] hh ＝两位数的小时(00到23)(不允许am/pm标识)

[0628] mm ＝两位数的分钟(00到59)

[0629] ss ＝两位数的秒(00到59)

[0630] 一些实例格式如下：

[0631] 年：

[0632] YYYY(如1997)

[0633] 年和月：

[0634] YYYY-MM(如1997-07)

[0635] 完整日期：

[0636] YYYY-MM-DD(如1997-07-16)

[0637] 完整日期加上小时、分钟和秒：

[0638] YYYY-MM-DDThh:mm:ss(如1997-07-16T19:20:30)

[0639] 按照该标准的定义，带小数的秒数不在该结构的任何XAF用法中进行描述。所有时间都基于UTC(全球标准时间)进行描述。

[0640] 声道描述定义

[0641] 根据一实施例，下列声道标签被用来标识声道。

[0642] enum

[0643] {

[0644] kAudioChannelLabel_Unknown ＝0xFFFFFFFF，//

[0645] unknown or unspecified other use(未知或未指定的其它用途)

[0646] kAudioChannelLabel_Unused ＝0， //

[0647] channel is present，but has no intended use or destination.(声道存在，[0648] 但无计划性的使用或目标)

[0649] kAudioChannelLabel_UseCoordinates ＝100，//

[0650] channel is described solely by the mCoordinates fields.(声道仅仅由[0651] mCoordinates字段进行描述)

[0652] kAudioChannelLabel_Left ＝1，

[0653] kAudioChannelLabel_Right ＝2，

[0654] kAudioChannelLabel_Center ＝3，

[0655] kAudioChannelLabel_LFEScreen ＝4，

[0656] kAudioChannelLabel_LeftSurround ＝5，//

[0657] WAVE：″Back Left″(声波：“后左”)

[0658] kAudioChannelLabel_RightSurround ＝6，//

[0659] WAVE：″Back Right″(声波：“后右”)

[0660] kAudioChannelLabel_LeftCenter ＝7，

[0661] kAudioChannelLabel_RightCenter ＝8，

[0662] kAudioChannelLabel_CenterSurround ＝9，//

[0663] WAVE：″Back Center″or plain″Rear Surroun d″(声波：“后中”或平[0664] 常“后环绕”)

[0665] kAudioChannelLabel_LeftSurroundDirect ＝10，//

[0666] WAVE：″Side Left″(声波：“侧左”)

[0667] kAudioChannelLabel_RightSurroundDirect ＝11，//

[0668] WAVE：″Side Right″(声波：“侧右”)

[0669] kAudioChannelLabel_TopCenterSurround ＝12，

[0670] kAudioChannelLabel_VerticalHeightLeft ＝13，//

[0671] WAVE：″Top Front Left(声波：“顶前左”)

[0672] kAudioChannelLabel_VerticalHeightCenter ＝14，//

[0673] WAVE：″Top Front Center″(声波：“顶前中”)

[0674] kAudioChannelLabel_VerticalHeightRight ＝15，//

[0675] WAVE：″Top Front Right″(声波：“顶前右”)

[0676] kAudioChannelLabel_TopBackLeft ＝16，

[0677] kAudioChannelLabel_TopBackCenter ＝17，

[0678] kAudioChannelLabel_TopBackRight ＝18，

[0679] kAudioChannelLabel_RearSurroundLeft ＝33，

[0680] kAudioChannelLabel_RearSurroundRight ＝34，

[0681] kAudioChannelLabel_LeftWide ＝35，

[0682] kAudioChannelLabel_RightWide ＝36，

[0683] kAudioChannelLabel_LFE2 ＝37，

[0684] kAudioChannelLabel_LeftTotal ＝38，//

[0685] matrix encoded 4 channels(矩阵编码的4声道)

[0686] kAudioChannelLabel_RightTotal ＝39，//

[0687] matrix encoded 4 channels(矩阵编码的4声道)

[0688] kAudioChannelLabel_HearingImpaired ＝40，

[0689] kAudioChannelLabel_Narration ＝41，

[0690] kAudioChannelLabel_Mono ＝42，

[0691] kAudioChannelLabel_DialogCentricMix ＝43，

[0692] kAudioChannelLabel_CenterSurroundDirect ＝44，//

[0693] back center，non diffuse(后中，非漫射)

[0694] //first order ambisonic channels(第一顺序高保真立体声声[0695] 道)

[0696] kAudioChannelLabel_Ambisonic_W ＝200，

[0697] kAudioChannelLabel_Ambisonic_X ＝201，

[0698] kAudioChannelLabel_Ambisonic_Y ＝202，

[0699] kAudioChannelLabel_Ambisonic_Z ＝203，

[0700] //Mid/Side Recording(中/侧记录)

[0701] kAudioChannelLabel_MS_Mid ＝204，

[0702] kAudioChannelLabel_MS_Side ＝205，

[0703] //X-Y Recording(X-Y记录)

[0704] kAudioChannelLabel_XY_X ＝206，

[0705] kAudioChannelLabel_XY_Y ＝207，

[0706] //other(其它)

[0707] kAudioChannelLabel_HeadphonesLeft ＝301，

[0708] kAudioChannelLabel_HeadphonesRight ＝302，

[0709] kAudioChannelLabel_ClickTrack ＝304，

[0710] kAudioChannelLabel_ForeignLanguage ＝305

[0711] }；

[0712] 以下常数在mChannelFlags字段中使用。

[0713] enum

[0714] {

[0715] kAudioChannelFlags_RectangularCoordinates ＝(1L＜＜0)，[0716] kAudioChannelFlags_SphericalCoordinates ＝(1L＜＜1)，[0717] kAudioChannelFlags_Meters ＝(1L＜＜2)

[0718] }；

[0719] kAudioChannelFlags_RectangularCoordinates-该声道由扬声器位置的笛卡儿坐标来指定。该标志与kAudioChannelFlags_SphericalCoordinates互斥。

[0720] kAudioChannelFlags_SphericalCoordinates-该声道由扬声器位置的球坐标来指定。该标志与kAudioChannelFlags_RectangularCoordinates互斥。

[0721] kAudioChannelFlags_Meters-设定则指示以米为单位，而清除则指示这些单位与单位立方体或者单位球面相关。

[0722] 如果声道描述没有提供坐标信息，则mChannelFlags字段就被设成零。

[0723] 声道坐标

[0724] (A)直角坐标：

[0725] 负为左而正为右。

[0726] 负为后而正为前。

[0727] 负为低于地平面，0为地平面，而正为高于地平面。

[0728] (B)球坐标：

[0729] 0为前部中心，正为右，负为左。这以度为单位进行测量。

[0730] +90为最高点，0为水平，-90为最低点。这以度为单位进行测量。

[0731] 普通声道布局

[0732] 以下是示例性的、未详尽的以及非限制性的一些普通声道布局值的列表。所用的缩写为：

[0733] L-左

[0734] R-右

[0735] C-中心

[0736] Ls-左环绕

[0737] Rs-右环绕

[0738] Cs-中心环绕

[0739] Lrs-左后环绕

[0740] Rrs-右后环绕

[0741] Lw-左宽

[0742] Rw-右宽

[0743] Lsd-左环绕直接

[0744] Rsd-右环绕直接

[0745] Lc-左中心

[0746] Rc-右中心

[0747] Ts-顶部环绕

[0748] Vhl-垂直高度左

[0749] Vhc-垂直高度中心

[0750] Vhr-垂直高度右

[0751] Lt-左矩阵总计。用于矩阵编码立体声。

[0752] Rt-右矩阵总计。用于矩阵编码立体声。

[0753] 在以下描述中，并没有暗示用于给定布局的声道的排序。例如，虽然5.1被描述为L，R，Ls，Rs，C，LFE，但文件可能以任一顺序来包含这些声道。在文件的声道描述块中的声道描述的顺序就确定了包含在那个特定文件中的声道被呈现的顺序。

[0754] 2声道文件

[0755] Stereo-标准立体声流(LR)-隐含播放；

[0756] StereoHeadphones-标准立体声流(LR)-隐含耳机播放；

[0757] MatrixStereo-矩阵编码立体声流(Lt，Rt))；

[0758] MidSide-中/侧记录；

[0759] XY-相合的麦克风对(通常是2个8字形)；

[0760] Binaural-双耳立体声(左，右)。

[0761] 3声道文件

[0762] MPEG 3.0-L，R，C；

[0763] ITU 2.1-L，R，LFE。

[0764] 4声道文件

[0765] Quadraphonic-前左、前右、后左、后右；

[0766] Ambisonic_B_Format-W，X，Y，Z；

[0767] MPEG 4.0-L，R，C，Cs。

[0768] 5声道文件

[0769] Pentagonal-左、右、后左、后右、中心；

[0770] MPEG 5.0-L，R，Ls，Rs，C。

[0771] 6声道文件

[0772] Hexagonal-左、右、后左、后右、中心，后；

[0773] MPEG 5.1-L，R，Ls，Rs，C，LFE；

[0774] MPEG 6.0-L，R，Ls，Rs，C，Cs。

[0775] 7声道文件

[0776] MPEG 6.1-L，R，Ls，Rs，C，Cs，LFE；

[0777] MPEG 7.0-L，R，Ls，Rs，C，Lrs，Rrs；

[0778] MPEG 7.0(B)-L，R，Ls，Rs，C，Lc，Rc。

[0779] 8声道文件

[0780] Octagonal-前左、前右、后左、后右、前中、后中、侧左、侧右；

[0781] Cube-1左、右、后左、后右、顶左、顶右、顶后左、顶后右；

[0782] MPEG 7.1-L，R，Ls，Rs，C，Lrs，Rrs，LFE；

[0783] MPEG 7.0(B)-L，R，Ls，Rs，C，Lc，Rc，LFE；

[0784] SMPTE_DTV-L，R，C，LFE，Ls，Rs，Lt，Rt(MPEG 5.1加上矩阵编码的立体声混和)。

[0785] 16声道文件

[0786] TMH 10.2标准-L，R，C，Vhc，Lsd，Rsd，Ls，Rs，Vhl，Vhr，Lw，Rw，Csd，Cs，LFE1，LFE2。

[0787] 21声道文件

[0788] TMH 10.2 Full-(TMH 10.2标准加)Lc，Rc，HI，VI，Haptic。

[0789] 硬件综述

[0790] 图4是示出了本发明的实施例可在其上被执行的计算机系统400的框图。图4所示出的计算机系统仅仅是本发明的实施例可在其上被执行和实施的一种可能系统。举例来说，本发明的实施例可在任一合适构造的设备上执行，诸如，手持或者其它便携式设备、台式设备、机顶盒设备、联网的设备等等被构造来记录、处理或者播放音频文件的装置。因此，对于执行本发明的实施例来说，参照图4示出和描述的所有组件不一定是必需的。

[0791] 计算机系统400包括：总线402或其它通信机构，以便于信息交换；以及与总线402连接的一个处理器404，以用于处理信息。计算机系统400还包括了连接到总线402的诸如随机存取存储器(RAM)或其他动态存储装置的主存储器406，其用于对信息和将由处理器404执行的指令进行存储。主存储器406还可用于在处理器404将执行指令期间存储临时变量或其他中间信息。计算机系统400还包括了连接到总线402的只读存储器(ROM)408或其他静态存储装置，用于用于给处理器404存储静态信息和指令。提供诸如磁盘、光盘或磁光盘的存储装置410，并连接到总线402，用于存储信息和指令。

[0792] 计算机系统400可经由总线402连接到用于将信息显示给系统用户的显示器412，如阴极射线管(CRT)或者液晶显示器(LCD)。在计算机系统400作为音频记录和播放系统的环境中，计算机系统400可连接到诸如扬声器或者头戴式耳机插孔等音频输出设备，以把音频播放给系统用户。包括字母数字和其他键的输入装置414连接到总线402，用于将信息和命令选择传输到处理器404。另一种用户输入装置是诸如鼠标、跟踪球、输入笔或光标方向键的光标控制器416，其用于将方向信息和命令选择传输到处理器404，并用于控制在显示器412上的光标移动。该输入装置通常具有在第一轴(例如x)和第二轴(例如y)这两个轴上的两个自由度，这就允许该装置指定平面中的位置。

[0793] 本发明涉及使用计算机系统400来执行本文所述技术。根据本发明的一个实施例，通过计算机系统400为了响应于执行含在主存储器406中的一个或多个指令的一个或多个序列的处理器404而执行这些技术。这种指令可以从诸如存储装置410的另一个机器可读的介质读入主存储器406。执行含在主存储器406中的指令序列以使得处理器404执行本文描述的处理步骤。在其它实施例中，可以用硬连线电路代替软件指令或将硬连线电路与软件指令相结合以实施本发明。因此，本发明的实施例并不限于硬件电路和软件的任何具体组合。

[0794] 本文使用的术语“计算机可读介质”指的是参与将指令提供给处理器404以用于执行的任何介质。这种介质可以采用多种形式，包括但不限于非易失性介质、易失性介质和传输介质。非易失性介质包括，例如，诸如存储装置410的光盘、磁盘或磁光盘。易失性介质包括诸如主存储器406的动态存储器。传输介质包括同轴线缆、铜线和光纤，还有构成总线402的导线。传输介质也可以采用声波或光波的形式，诸如在无线电波和红外数据通信中生成的那些波。

[0795] 计算机可读介质的通常形式包括：例如，软盘、可折盘(“flexibledisk”)、硬盘、磁带或其他任何磁性介质、CD-ROM、DVD或任何其他光学介质、穿孔卡、纸带、其它任何具有孔状式样的物理介质、RAM、PROM、EPROM、FLASH-EPROM、任何其他存储芯片或盒式磁带、下文中描述的载波，或计算机能从中读取的任何其他介质。

[0796] 各种形式的计算机可读介质可参与将一个或多个指令的一个或多个序列传送到处理器404执行。例如，指令可最初承载在远程计算机的磁盘上。远程计算机能够将指令装入其动态存储器并使用调制解调器通过电话线发送这些指令。计算机系统400的本地调制解调器能够接收电话线上的数据并使用红外发射器将数据转换为红外信号。红外探测器能够接收红外信号中携带的数据并且适当的电路能够将数据放到总线402上。总线402将数据传送到主存储器406，处理器404从主存贮器406中取回数据并执行指令。由主存储器406接收的指令可以在被处理器404所执行之前或之后，可选地存储在存储装置410上。

[0797] 计算机系统400还包括了连接到总线402的通信接口418。连接到与本地网422相连的网络链路420的通信接口418提供双路数据通信。例如，通信接口418可以是综合服务数字网络(ISDN)卡或调制解调器，用于提供到相应类型的电话线的数据通信连接。作为另一个实例，通信接口418可以是局域网(LAN)卡，用于提供到兼容的LAN的数据通信连接。也可以实现无线链路。在任何这样的实现方式中，通信接口418都发送和接收带有表示各种类型信息的数字数据流的电信号、电磁信号或光信号。

[0798] 通常，网络链路420通过一个或多个网络向其他数据装置提供数据通信。例如，网络链路420可以通过本地网422提供到主机424或到由互联网服务提供商(ISP)426所操作的数据设备的连接。ISP426又通过现在通常称作“互联网”428的全球分组数据通信网络来提供数据通信服务。本地网422和互联网428都使用带有数字数据流的电信号、电磁信号或光信号。将数字数据传送到计算机系统400和从计算机系统400传送数字数据的信号，即，通过各种网络的信号、在网路链路420上的信号和通过通信接口418的信号，是传输信息的载波的示例性形式。

[0799] 计算机系统400能够通过网络、网络链路420和通信接口418发送消息和接收数据(包括程序代码)。在互联网实例中，服务器430可通过互联网428、ISP 426、本地网422和通信接口418来传输被请求的应用程序代码。

[0800] 当代码被接收到时，所接收的代码就可以由处理器404执行和/或存储在存储装置410或者其他非易失性存储装置中，以便今后执行。这样，计算机系统400就可以获得载波形式的应用程序代码。

[0801] 扩展和替代

[0802] 贯穿上述说明书并在最便于理解实施例环境的地方描述了本发明的其它实施例。进一步来说，已参照其具体实施例描述了本发明。然而，很清楚，可对其进行各种修改和变化而不偏离本发明的更广阔的精神和范围。因此，本说明书的和附图的含义将被视为示例性而不是限制性。

[0803] 此外，在该说明书中，某些处理步骤是以特定顺序来阐述的，并且可能使用了字母和字母数字标号来标识某些步骤。除非在说明书中具体指明，本发明的实施例不一定局限于按任何特定顺序来执行这些步骤。特别地，这些标号仅仅是便于步骤识别而不意味着指定或者要求按特定顺序执行这样的步骤。

标题	发布/更新时间	阅读量
视频监控设备中闪存卡的数据存储方法及其系统	2021-12-09	0
一种电机性能测试平台	2020-06-04	1
一种版本比对方法和装置、家电设备、网络设备	2020-08-18	0
一种EAM平台监控管理方法及系统	2020-12-08	1
信息备份/恢复处理装置、以及信息备份/恢复处理系统	2023-04-07	0
国民价值链规划配置全息对接均衡表列技术	2022-08-13	0
一种基于人工智能的高校招生数据采集方法及系统	2020-07-12	1
用于分布式智能遥感系统的系统	2020-07-19	0
一种CDN网络中批量处理大量主机的方法及装置	2022-01-23	0
Management of file images in a virtual environment	2022-01-29	1

音频数据的通用容器

音频数据的通用容器

技术领域

背景技术

发明内容

具体实施方式

该功能需要专业版企业版VIP权限，您可以：