WAV文件Data块起始位置须通过解析RIFF头及子块动态定位，不可硬跳44字节；需遍历找到"data"块标识，读取其后4字节长度字段，再跳过该字段才得真实样本起始地址，并用fread精确读取data_size字节。
WAV文件头结构决定Data块起始位置
WAV是RIFF容器格式，Data块不是固定从第44字节开始——那是16位单声道PCM的常见情况，但只要采样位数、声道数、是否含fact块或LIST扩展信息，偏移量就可能变化。硬写fseek(fp, 44, SEEK_SET)在真实音频文件上大概率读错数据。
必须逐块解析RIFF头和子块，定位到"data"标识符后紧跟的4字节长度字段，再跳过这4字节，才是真正的音频样本起始地址。
-
"RIFF"开头，接着4字节文件总长（含RIFF头），再4字节"WAVE" - 之后是若干子块：每个子块以4字符ID（如
"fmt "、"data"）开头，后跟4字节块长度，再是块内容 -
"fmt "块必须存在且先于"data"；它至少16字节，但实际常为18或40字节（含扩展字段） - 遇到
"data"块时，读其后4字节得data_size，接下来data_size字节才是原始样本
用fread精准读取Data块样本，别用fseek硬跳
一旦通过块遍历确认了Data块起始偏移（即"data"四字节 + 长度字段之后的位置），就该用fread直接读取，而不是再fseek一次——多一次seek可能因文件系统缓存或流状态出偏差，尤其在内存映射或非标准I/O流中。
示例关键逻辑：
立即学习“C++免费学习笔记（深入）”；
uint32_t data_offset = 0;
uint32_t data_size = 0;
// ...（块遍历后得到data_offset和data_size）
<p>uint8_t* samples = new uint8_t[data_size];
size_t nread = fread(samples, 1, data_size, fp);
if (nread != data_size) {
// 实际只读到部分数据，可能是文件截断或IO错误
}</p>-
data_size是"data"块声明的长度，不是文件剩余字节数，务必校验nread == data_size - 若需按样本类型解析（如16位有符号整数），记得考虑小端序：
int16_t sample = (int16_t)(buf[i] | (buf[i+1] - 不要假设
data_size一定能被样本字节数整除——有些录音软件会补零凑整，需按fmt块里的bits_per_sample和num_channels反推合法样本数
fmt块里藏着采样格式陷阱
fmt 块不光告诉你声道数和采样率，wFormatTag字段才是关键：值为1才是PCM，3是IEEE Float，0xFFFE是扩展格式（需看cbSize往后读额外字段）。很多代码只检查"fmt "存在就默认PCM，结果遇到32位浮点WAV直接解析成乱码。
- 读
fmt块前4字节得subchunk_size，至少为16；若≥18，第16–17字节是wFormatTag -
wFormatTag == 1才安全当PCM处理；否则需查WAV规范或跳过（除非你明确支持该编码） -
bits_per_sample在fmt块第14–15字节，它决定每个样本占几个字节，也影响Data块内样本对齐——比如24位样本通常存为3字节紧排，无填充
Windows平台下FILE*读二进制必须用"rb"模式
在Windows上用fopen打开WAV文件，如果用"r"而非"rb"，换行符转换机制会把0x0D 0x0A误判为文本换行，悄悄吃掉一个字节，导致后续所有偏移错位。这是Windows特有、极易忽略的问题。
- Linux/macOS下
"r"和"rb"行为一致，但跨平台代码必须统一用"rb" - 哪怕你只读
char数组、不涉及字符串操作，也得加b——因为C标准规定文本模式对二进制数据不可预测 - 错误示范：
fopen("test.wav", "r")→ 正确写法：fopen("test.wav", "rb")
偏移量不准，往往不是算法问题，而是头没读全、模式开错、或把fmt块长度当成了固定值。真要“精准”，就得老老实实按RIFF规范一帧一帧啃块头。
