【GY广播电视行业标准】 音频扩展文件格式MBWF/RF64

中华人民共和国广播电影电视行业标准GY/T281-2014
音频扩展文件格式MBWF/RF64
AnextendedfileformatforaudioMBWF/RF642014-12-03发布
国家新闻出版广电总局
2014-12-03实施
范围：
2术语、定义和缩略语
基本用户需求
5RF64文件格式定义
附录A（规范性附录）RIFF/WAVE和RF64/WAVE结构的形式化描述参考文献
GY/T281—2014
GY/T281—2014
本标准按照GB/T1.1-2009给出的规则起草。本标准依据EBU-TECH3306：2009《MBWF/RF64：音频扩展文件格式》起草。
本标准由全国广播电影电视标准化技术委员会（SAC/TC239）归口。本标准起草单位：国家新闻出版广电总局广播电视规划院。本标准主要起草人：张建东、邓向冬、肖辉。II
1范围
音频扩展文件格式MBWF/RF64
本标准规定了专业广播领域内的一种超过4G字节大小的数字音频文件格式要求。本标准适用于数字音频文件的录制、归档和交换。2术语、定义和缩略语
2.1术语和定义
下列术语和定义适用于本标准。2.1.1
audiocodinggeneration3;AC-3
环绕声数学音频编码
在ETSITS102366标准中定义的数字音频压缩编解码标准。2.1.2
broadcastaudio extension:bext广播音频扩展bZxz.net
GY/T281—2014
-种音频数据块，用于定义音频资料文件交换所需的基本参数，如创作者姓名、创作日期等。2.1.3
MPEG-2AAC
在IS0/IEC13818-7标准中定义的数字音频压缩编解码标准。2.1.4
digitaltheater systems;DTs
数字影院系统
种数字音频压缩编解码系统。
DolbyE
-种数字音频压缩编解码系统，可用于音频信号的馈送和分配环节，2.1.6
种基于64位的资源交换文件格式，2.2缩略语
下列缩略语适用于本标准。
GY/T2812014
BWF广播波形格式（BroadcastWaveFormat）GUID
全球唯一标识符（GloballyUniqueIdentifier）MBWF
多声道广播波形格式（MultichannelBroadcastWaveFormat）MPEG
运动图像专家组（MovingPictureExpertsGroup）PCM
脉冲编码调制（Pulse CodeModulation）RIFF
资源交换文件格式（ResourceInterchangeFileFormat）波形音频文件格式（Waveformaudiofileformat）WAVE
3概述
RF64文件格式能够满足多声道声音节目在广播和归档应用中的长期需求。RF64文件格式在RIFF/WAVE文件基本规范的基础上进行了以下扩展：?文件大小超过4G字节：
·扩展了WaveFormatExtensible中多声道参数的定义，可承载最多至18个环绕声道、立体声下混声道和非PCM编码数据比特流信号。RF64文件格式作为RIFF/WAVE格式和BWF及其补充数据块的一种可兼容扩展格式，扩展了RIFF/WAVE和BWF的最大文件容量，以满足多声道声音节目广播和音频归档的应用需求。RF64可应用于从声音采集、编辑到播出的整个节自生产过程，以及多声道文件的短期或长期归档本标准中将包含bext块的RF64文件定义为MBWF（MultichannelBWF）文件，术语“RF64”与“MBWF”可视为同义。
基本用户需求
音频扩展文件格式应满足如下的基本用户需求：文件格式应开放且基于已发布的规范；·
保持与BWF和RIFF/WAVE的兼容；支持线性PCM信号的存储；
支持超过4G节的文件：
至少支持8声道信号存储（5.1+双声道立体声）；适用于包含在单个文件中的5.1声道和双声道立体声信号的同步播出；支持音频码流的存储；
适用于音频信号编辑；
适用于从文件中直接导出浏览版本（文件格式元数据）；包含播放所需的技术元数据（如杜比元数据）；适用于经济易用的软件播放器；易于软件开发者和制造商实现。此外，根据实际系统的运行经验，节目制作和归档中通常需要在单个文件中存储和传送PCM和/或非PCM音频数据，因此在RF64格式中增加了容纳非PCM音频流（如：AC-3和DTS）的机制。5RF64文件格式定义
5.1WaveFormatExtensible声道模板2
GY/T281—2014
WaveFormatExtensible的声道模板包含的前18个“#define”定义，用于指定不同的扬声器位置（声道分配），还有一个“#define”设置为“SPEAKERALL”，表示开启所有扬声器（声道）。WaveFormatExtensible声道模板的扬声器位置/声道分配定义及标识见表1。表1WaveFormatExtensible声道模板扬声器位置/声道分配定义
#define SPEAKER_FRONT LEFT
#define SPEAKER FRONT_RIGHT
#define SPEAKER_FRONT_CENTER#defineSPEAKERLOWFREQUENCY
#define SPEAKER BACK LEFT
#define SPEAKER_BACK_RIGHT
#define SPEAKER FRONT LEFT_OF CENTER#defineSPEAKER_FRONT_RIGHT_OFCENTER#define SPEAKER BACK CENTER
#define SPEAKER SIDE LEFT
#define SPEAKER SIDE_RIGHT
#define SPEAKER_TOP_CENTER
#define SPEAKER TOP FRONT LEFT#define SPEAKER_TOPFRONT_CENTER#define SPEAKER_TOP_FRONT_RIGHT#define SPEAKERTOP_BACKLEFT
#define SPEAKER_TOP BACK CENTER#define SPEAKER_TOP_BACK_RIGHT#define SPEAKERALL
0x00000001
0x00000002
0x00000004
0x00000008
0x00000010
0x00000020
0x00000040
0x00000080
0x00000100
0x00000200
0x00000400
0x00000800
0x00001000
0x00002000
0x00004000
0x00008000
0x00010000
0x00020000
0x80000000
为满足第4章列出的用户需求，RF64需要对基本WaveFormatExtensible的声道模板进行扩展。声道模板的标识使用一个32位变量存储，因此，还可定义另外13个“#define”来满足新增的用户需求。
PCM双声道立体声下混定义扩展
WaveFormatExtensible中不包含PCM双声道立体声信号的定义，因此在声道模板中增加以下定#define SPEAKER_STEREO_LEFT
#define SPEAKER_STEREO_RIGHT0x20000000
0x40000000
使用此定义，可满足在单一文件中包含一个多声道“X.1”信号和一个双声道立体声下混信号。控制数据定义扩展
增加了两个“#define”用于定义控制数据：#defineSPEAKER_CONTROLSAMPLE_1#defineSPEAKER_CONTROLSAMPLE_2控制数据可以存储在文件中，技术或内容元数据定位的方法预留定义。0x08000000
0x10000000
GY/T281—2014
5.4非PCM比特流数据定义扩展
符合IEC61937-1、IEC61937-3、IEC61937-5、IEC61937-6、SMPTE337M、SMPTE338M、SMPTE339M和SMPTE34OM标准的比特流信号包含以各种方式编码的非PCM多声道音频数据。通过文件格式中的比特流存储方式，AC-3、Do1byE、DTS、MPEG-1和MPEG-2（包括所有三个层）、MPEG-2AAC编码的音频数据，与线性PCM信号的存储方式类似，以数据顿的方式存储于文件中。文件格式中比特流音频信号的嵌入结构，类似于线性PCMRIFF/WAVE或BWF文件中两个交织立体声音频声道的结构。
RIFF文件中仅有一个格式块，用于定义音频数据块中所有交织声道的通用参数。如果同一个文件中还存在其他PCM音频，则比特流声道格式必须遵从文件中其他多声道PCM或双声道立体声PCM的声道格式。
在文件的接收端，只有通过AES3或SPDIF接口解码比特流时，方可获知非PCM音频编码的类型，因此将来有必要增加一个新的块定义来指示文件中包含的比特流格式。对WaveFormatExtensible声道模版新增以下4个“#define”定义，用于承载两种非PCM格式：#defineSPEAKER_BITSTREAM_1_LEFT#defineSPEAKERBITSTREAMIRIGHT#defineSPEAKER_BITSTREAM_2_LEFT#defineSPEAKER_BITSTREAM_2_RIGHT5.5支持超过4G字节的文件
0x00800000
0x01000000
0x02000000
0x04000000
4G字节文件大小限制源于RIFF/WAVE和BWF格式中的32位寻址方式，使用32位的最大寻址范围为4294967296字节（即4G字节），为支持超过4G字节的文件，本标准使用64位寻址方式。如果仅将BWF中每个字段的长度改为64位，显然将生成一个与标准RIFF/WAVE格式不兼容的文件。标准RIFF/WAVE文件格式见图1，其中除fmt块数据和音频数据外，其余字段长度均为32位。最多至4G字节的RIFF数据
RIFF块大小（4G字节）
图1标准RIFF/WAVE格式
因此，本标准定义了一种新的基于64位的资源交换文件格式（ResourceInterchangeFileFormat），称为RF64。RF64与原有的RIFF/WAVE格式基本相同，不同之处如下所述：·文件起始的四个字节，以“RF64”标识替代“RIFF”；·文件中定义了一个必须包含的“ds64”（datasize64）块，该块须紧接在“RF64”块之后。“ds64”块包括三个必选的64位整型值，替代RIFF/WAVE格式中原有的三个32位字段：·RIFF块大小；
·data块大小；
·fact块中的样本计数值。
对RIFF/WAVE格式中上述三个32位字段应用以下替代规则：GY/T281—2014
如果字段的32位值不是“-1”（即十六进制的0xFFFFFFFF），则使用该32位值；如果值为“-1”，则使用“ds64”块中的64位值。
种支持64位块大小的可选RF64块结构体（struct）定义见附录A中的A.1和A.2。RF64/WAVE文件格式的完整结构示例如图2所示。图2中除预留64位数据、fmt块数据和音频数据字段外，其余字段均为32位。
多达16E字节的RF64数据
-1-不使用；使用d64块中的值
ds64块包含64位字段
-1=不使用；使用ds64块中的值
标记MBWF文件大小超过4G字节的“RF64”标识图2支持多达16E字节文件大小的RF64/WAVE文件格式的完整结构示例5.6BWF和RF64间归档的兼容性
即使在节目录制中采用更高采样率和多声道音频，也不是所有音频文件都会超过4G字节，因此，对小于4G字节的音频文件仍应使用BWF格式存储。由于录制程序无法预知在录音结束时文件大小是否会超过4G节（即是否需要使用RF64），因此录制程序需具备在所写入数据达到4G字节限制处将录制文件实时从BWF格式转换到RF64格式的功能，同时不影响录制的继续进行。
该项需求可以通过在BWF中插入与“ds64”块同样大小的“JUNK”3块从而预留额外的空间来实现。预留的空间对BWF格式无实际意义，但当需要转换为RF64格式时，使用该空间承载“ds64”块。RIFF/WAVE文件格式的向上兼容性结构见图3。图3中除JUNK块数据、fmt块数据和音频数据字段外其余字段均为32位。
1）“struct”是c/C++中用于定义结构体类型和/或结构体变量的关键字。2）E字节即exabyte（1E字节=2字节）3）“JUNK”块是RIFF/WAVE基本规范的一部分，作用为占位，音频应用程序将忽略该块。5
GY/T281--2014
多达4G字节的RIFF数据
作为占位符的“JUNK”块
图3RIFF/WAVE文件格式的向上兼容性结构eep.
支持RF64格式的应用程序在开始录制时，首先创建第一个块为“JUNK”块的标准RIFF/WAVE或BW格式文件，录制中，应用程序检查RIFF和数据大小，当发现超过4G字节时，将执行以下操作：·以“ds64”替代“JUNK”块标识（将原来的JUNK块转换为ds64块）；。在“ds64”块中，按块定义格式插入RIFF块大小，data块大小和样本计数值；·将原32位的RIFF块大小，data块大小和样本计数值设为-1（0xFFFFFFFF）；以“RF64”标识替代文件的最初4个字节“RIFF”：·
继续录制。
5.7标记块的定义
实际应用中，发现RIFF/WAVE文件格式关于cue块的定义存在如下一些问题：现行的cue块采用32位寻址方式，因此仅对RF64文件的前4G字节音频数据有效：·cue块的定义描述不明确，导致一些开发者在其应用程序中以不当的方式实现标记功能：·
针对数据净荷是线性音频还是压缩数据这两种情况，软件开发者必须以不同的方式对标记进行处理，这将影响软件开发代码的简单性和准确性：标记中的标签（labels）并未跟其一起存储于“cue”块，而是存储在“labl”块中，使对标·
记的处理更加复杂。
因此，本标准定义了一个新的RF64标记块（见附录A3和A4），该块包含了标记的位置及其标签RF64文件很大（通常超过4G字节），如果删除标记时无需对整个文件进行重新处理，将使RF64文件更易于使用。通过在FLAG字段中设置/重置一个比特位，从而将某个标记置为有效或无效来实现。在开始写入data块前预留一些存放标记的空间，在录音和将音频数据写入data块的过程中，将标记也写入文件。
根据统计显示，大多数标记的标签只占用儿个字符的长度，因此可使用一个固定长度的字段来承载标签，相对于动超过4G字节的RF64音频文件而言，由此引入的空间开销很少。例如，3000个典型的标记占用的空间不超过1M字节，在一个4G字节的RF64文件中，10000个标记占用的空间不超过文件大小的0.1%。
最后，可以使用产品和/或供应商专用标记记录一些特定的信息，如颜色等。由于此信息只与特定供应商相关，可使用GUID（全球唯一标识符）标识来区分，确保只有该供应商的应用程序使用此信息，而其他所有软件忽略该数据。此外，由于该信息仅对特定供应商应用程序有用，无需与其他供应商共享，各供应商可按自己的方式使用专用标记中的数据。6
GY/T2812014
注：由于RIFF/WAVE或RF64文件有可能同时包含cue块和RF64标记块，因此强制规定应用程序首先在文件中查找RF64标记块，如找到RF64标记块，则仅使用RF64标记块中的标记信息（cue点），如未找到RF64标记块，则查找并使用“cue”块。
GY/T2812014
附录A
（规范性附录）
RIFF/WAVE和RF64/WAVE结构的形式化描述RIFF/WAVE（BWF）格式中的块和结构体A.1
struct RiffChunk
unsigned int32
struct JunkChunk
unsigned int32
structFormatChunk
unsigned int32
unsigned int16
unsigned int16
unsigned int32
unsigned int32
unsigned int16
unsigned int16
unsigned int16
struct DataChunk
unsigned int32
chunkId[4];
chunkSize:
riffType[4];
chunkId[4];
chunkSize;
chunkData[ j\;
chunkId[4];
chunkSize;
formatType;
channelCount;
sampleRate:
bytesPerSecond:
blockAlignment:
bitsPerSample;
cbSize
extraData[22]
chunkId[4]:
chunkSize;
waveata[]
//声明RiffChunk结构体
‘RIFF’
//传统RIFF/WAVE文件的大小，4字节“WAVE”
//声明JunkChunk结构体
‘JUNK'
块大小，4字节。如果意欲作为“‘ds64”JUNK'
块的占位符，本成员变量的值至少为28。填充字节
//声明FormatChunk结构体
//‘fmt，
//‘fmt块大小，4字节
//WAVEFORMATPCM=Ox0001，等等//1=mono,2=stereo，等等
//32000，44100，48000，等等
//仅对压缩数据格式重要
组样本的容器大小（以字节为单位）//每样本的有效比特16，20或24//需存储的额外信息大小（cbSize之后）/WAVEFORMATEXTENSIBLE的额外数据//声明DataChunk结构体
//‘data'
//‘data'块大小，4字节
//音频样本
RF64/WAVE（MBWF）格式中的新块和结构体4）在RIFF/WAVE文件中有效的其他块在RF64/WAVE文件中同样有效，例如，RIFF/WAVE的BWF扩展项也可在RF64/WAVE文件中不予改变地使用5）空括号“［]”并不符合C/C++的标准句法规则。这里表示数组包括可变数量的元素（甚至也可能是零个元素）。8
struct RF64Chunk
unsigned int32
structChunkSize64
unsigned int32
unsigned int32
chunkId[4]:
chunkSize:
rf64Type[4];
chunkId[4]:
chunkSizeLow;
chunkSizeHigh:
struct DataSize64Chunk
unsigned int32
unsigned int32
unsigned int32
unsigned int32
unsigned int32
unsigned int32
unsigned int32
unsigned int32
chunkSize64
struct Guid
unsigned int32
unsigned int16
unsigned int16
unsigned int32
unsigned int32
chunkId[4];
chunkSize;
riffsizeLow;
riffsizeHigh:
dataSizeLow;
datasizeHigh;
sampleCountLow;
sampleCountHigh;
tableLength;
table[ J;
datal;
data2:
data3：
data4;
data5:
struct FormatExtensibleChunkchar
unsigned int32
unsigned int16
unsigned int16
unsigned int32
unsigned int32
chunkId[4];
chunkSize;
formatType;
channelCount:
sampleRate:
bytesPerSecond:
//声明RF64Chunk结构体
/“RF64'
GY/T 281—2014
//-1=OxFFFFFFFF意味着不使用此数据，代而使用//“ds64”块riffSizeHigh和riffSizeLow成员变量值“WAVE”
//声明ChunkSize64结构体
//chunkID（例如，“bigl”）
//chunk大小，低4字节
//chunk大小，高4字节
//声明DataSize64Chunk结构体
//‘ds64'
//‘ds64’块大小，4字节
//RF64块大小，低4字节
//RF64块大小，高4字节
//data块大小，低4字节
//data块大小，高4字节
//fact块中样本计数，低4字节
//fact块中样本计数，高4字节
//成员数组“table”中有效条目的数量//声明用于WAVE_FORMATEXTENSIBLE的//FormatExtensibleChunk结构体//“fmt”
//“fmt”块大小，4字节
//WAVEFORMAT EXTENSIBLE=OxFFFE//1=mono,2=stereo，等等
//32000，44100，48000，等等
//仅对压缩数据格式重要
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。