GY/T 281-2014.An extended file format for audio MB WF/RF64.
支持RF64格式的应用程序在开始录制时，首先创建第-一个块 为“JUNK”块的标准RIFF/WAVE或BWF格式文件，录制中，应用程序检查RIFF和数据大小，当发现超过4G字节时，将执行以下操作:
以“ds64"替代“JUNK"块标识(将原来的JUNK块转换为ds64块);
在“ds64"块中，按块定义格式插入RIFF块大小，data 块大小和样本计数值:
将原32位的RIFF块大小，data块大小和样本计数值设为-1 (0FxFFFFFF);
以“RF64"标识替代文件的最初4个字节“RIFF"; .
继续录制。
5.7标记块的定义
实际应用中，发现RIFF/WAVE文件格式关于cue块的定义存在如下一些问题:
现行的cue块采用32位寻址方式，因此仅对RF64文件的前4G字节音频数据有效:
cue块的定义描述不明确，导致- -些开发者在其应用程序中以不当的方式实现标记功能:
针对数据净荷是线性音频还是压缩数据这两种情况，软件开发者必须以不同的方式对标记进行处理，这将影响软件开发代码的简单性和准确性;
标记中的标签(labels) 并未跟其一-起存储于 “cue" 块，而是存储在“labl”块中，使对标记的处理更加复杂。
因此，本标准定义了一个新的RF64标记块(见附录A.3和A.4),该块包含了标记的位置及其标签。
RF64文件很大(通常超过4G字节),如果删除标记时无需对整个文件进行重新处理，将使RF64文件更易于使用。通过在FLAG字段中设置/重置一一个比特位，从而将某个标记置为有效或无效来实现。在开始写入data块前预留- -些存放标记的空间，在录音和将音频数据写入data块的过程中，将标记也写入文件。
根据统计显示，大多数标记的标签只占用几个字符的长度,因此可使用一个固定长度的字段来承载标签，相对于动辄超过4G字节的RF64音频文件而言，由此引入的空间开销很少。例如，3000 个典型的标记占用的空间不超过1M字节，在一个4G字节的RF64文件中，10000 个标记占用的空间不超过文件大小的0.1%。.
最后，可以使用产品和/或供应商专用标记记录一些特定的信息，如颜色等。由于此信息只与特定.供应商相关，可使用GUID (全球唯- -标识符) 标识来区分，确保只有该供应商的应用程序使用此信息，而其他所有软件忽略该数据。此外，由于该信息仅对特定供应商应用程序有用，无需与其他供应商共享，各供应商可按自己的方式使用专用标记中的数据。
GY/T 281-2014 音频扩展文件格式MBWF/RF64
https://www.gxjzx.com/zb_users/upload/2023/11/20231126112218170096893815728.rar