正确解析WAV文件头需逐块遍历，读取子块ID与size，定位"data"块起始位置；PCM数据为小端有符号整数，16位直接转int16_t，24位需符号扩展至int32_t，32位直接映射int32_t。
WAV文件头怎么解析才能拿到PCM数据起始位置
WAV不是纯PCM，它带RIFF头和fmt子块，必须跳过这些元数据才能读到真正的采样字节。直接fseek(fp, 44, SEEK_SET)是常见误区——44字节只适用于标准16位单/双声道、44.1kHz的WAV，一旦有额外的LIST块、fact块或扩展fmt（如WAVE_FORMAT_EXTENSIBLE），实际数据偏移会变。
正确做法是逐块解析：先读4字节确认是"RIFF"，再跳过8字节，然后循环读取每个子块的ID（4字节）和size（4字节）。遇到"data"块时，它的size字段就是后续PCM数据的字节数，而当前文件指针位置就是PCM起始地址。
- 用
fread(&chunk_id, 1, 4, fp)读块ID，注意字节序是小端，但ASCII字符不受影响 - fmt子块必须至少24字节（WAVE_FMT_CHUNK_SIZE），若
wFormatTag为WAVE_FORMAT_EXTENSIBLE（0xFFFE），则实际fmt长度为40字节，需多读16字节扩展区 - 别依赖
sizeof(WAVEFORMATEX)，Windows SDK里这个结构体有可变数组，编译器填充可能不同
如何把PCM字节转成有符号整数数组（int16_t / int32_t）
WAV的PCM数据按样本（sample）连续排列，每个样本的字节数由wBitsPerSample决定：16位对应int16_t，24位需补高位转int32_t，32位直接映射int32_t。关键点在于字节序和符号扩展。
所有WAV PCM数据都是小端序，且有符号：16位PCM是二进制补码的int16_t；24位PCM通常存为3字节小端（低字节在前），读入后要手动符号扩展到32位；32位PCM就是原生int32_t小端。
立即学习“C++免费学习笔记（深入）”；
- 24位处理示例：
int32_t sample = (data[i] | (data[i+1] - 别用
memcpy直接往int16_t*强转——如果原始字节流地址未对齐（比如从奇数offset开始读），在ARM等平台会触发SIGBUS - 声道交错（interleaved）是默认布局：LRLRLR…，提取单声道需步进
channels个样本，例如双声道中左声道索引为i * channels + 0
用C++标准库读WAV比手写fread更安全吗
不推荐用std::ifstream配合read()替代fread()，除非你明确需要RAII或locale无关性。问题在于std::ifstream默认是文本模式（尤其Windows下会把\r\n转\n），而WAV二进制数据里完全可能出现0x0D 0x0A字节序列，导致数据错位。
- 必须加
std::ios::binary标志：std::ifstream file("a.wav", std::ios::binary); -
file.read()不保证一次读完指定字节数，需检查gcount()返回值，否则缓冲区残留脏数据 - 对于大文件（>2GB），
std::ifstream::seekg()在32位off_type下会截断，fseek()配fpos_t或C++17的seekg(pos, std::ios::beg)更稳
为什么读出来的PCM数据播放杂音或静音
杂音大概率是数据类型/字节序/声道顺序没对齐；静音则常因采样率或位深误判导致播放器解码失败。WAV头里的dwSamplesPerSec和wBitsPerSample必须和实际数据严格一致，播放器不会校验——它只按头里写的参数去解释字节流。
- 用
ffprobe -v quiet -show_entries stream=sample_rate,bits_per_sample,channels a.wav交叉验证头信息是否真实 - 导出PCM裸数据调试时，用
xxd -c 16 -g 2 a.pcm | head看前几组16进制，确认是否呈现典型正弦波交替模式（如0x0000, 0x1000, 0x0000, 0xF000…） - 某些录音软件生成的WAV用IEEE float（32位float）格式，此时
wFormatTag是WAVE_FORMAT_IEEE_FLOAT（3），不能当整数解析
实际处理时最易被忽略的是fmt块长度变异和24位数据的手动符号扩展——这两个点不踩坑，剩下的就是按字节搬数据了。
