我们在自行编写Wav播放器的时候,有的时候发现经过ffmpeg处理后的wav文件头大小不再是44字节大小,使用 二进制分析工具可以看到其中有一个LIST Chunk部分,不知道为啥上传图片失败了,用hexdump的结果作为替代吧。
00000000 52 49 46 46 46 80 ea 03 57 41 56 45 66 6d 74 20 |RIFFF...WAVEfmt |
00000010 10 00 00 00 01 00 02 00 80 bb 00 00 00 ee 02 00 |................|
00000020 04 00 10 00 4c 49 53 54 1a 00 00 00 49 4e 46 4f |....LIST....INFO|
00000030 49 53 46 54 0d 00 00 00 4c 61 76 66 36 31 2e 31 |ISFT....Lavf61.1|
00000040 2e 31 30 30 00 00 64 61 74 61 00 80 ea 03 00 00 |.100..data......|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
可以看到和普通的Wav文件头不同,这里多了一个LIST, LIST Chunk的结构可以参考下表。
Byte sequence description | Length in bytes | Starts with byte in the chunk | Value |
---|---|---|---|
chunk ID | 4 | 0x00 | The ASCII character string "LIST" |
size | 4 | 0x04 | The size of the sub-chunk less 8 (less the "chunk ID" and the "size") |
list type ID | 4 | 0x08 | Various ASCII character strings. A common one is "INFO" (text information about copyright, authorship, etc.). Other examples, specific to various extensions of the RIFF format (WAVE, DLS, and others) are listed below |
data | various | 0x0C | Depends on the list type ID |
通常在Wav中的LIST的list type ID是info,后续的data则是一个info的数组。
info数组的格式如下。比如ffmpeg导出的wav使用了ISFT这个Info ID.
Info ID (4 byte ASCII text) for information 1
Size of text 1
Text 1
Info ID (4 byte ASCII text) for information 2
Size of text 2
Text 2
LIST CHUNK中的size字段描述的是list type ID+data的大小,并且LIST CHUNK是2字节对齐的,因此在data末尾可能有填充.
在设计一个健壮的播放器的时候,需要考虑到LIST CHUNK的这种情况。不能简单只认为wav文件头只有44个字节。
参考
https://www.recordingblogs.com/wiki/list-chunk-of-a-wave-file