解析RIFF格式WAV文件头元数据异常，调用fseek能否解决？

核心结论 #

仅在两次读操作之间无差别调用fseek不能解决你的兼容性问题，当前问题是多个底层逻辑错误共同导致的，fseek仅能作为修复方案中的辅助工具，无法单独生效。

现有代码的核心问题 #

• 结构体字节对齐问题：C/C++编译器默认会对结构体成员做内存对齐填充，你定义的三个结构体的实际内存占用和WAV文件里紧凑排列的二进制字段长度不匹配，直接用fread读整个结构体必然会出现数据错位。
• 类型长度不固定问题：你使用的unsigned long、unsigned short等类型的长度随平台、编译器变化，而WAV规范里的字段长度是固定的（32位无符号整数、16位无符号整数），需要改用<cstdint>头文件中定义的uint32_t、uint16_t等固定长度类型。
• 块规则假设错误：
  1. 你默认fmt块的大小和FMT_CHUNCK_DISCRIPTOR结构体大小一致，但WAV规范允许fmt块携带扩展参数，Subchunk1Size可以大于16字节，直接读满整个结构体就会占用后续块的内容。
  2. 你默认块顺序固定为RIFF→fmt→data，但实际WAV文件可以在fmt块和data块之间插入LIST、INFO等自定义元数据块，直接按顺序读三个结构体必然会错位。
• 文件打开模式错误：你用"r"文本模式打开二进制WAV文件，Windows平台下文本模式会自动处理换行符转义，导致二进制数据读取异常，必须使用"rb"二进制模式打开。
• 基础逻辑bug：你定义的fileName指针未初始化就使用，会导致fopen必然失败。

正确修复思路 #

fseek需要配合块遍历逻辑使用，不能直接盲目加在两次读操作之间：

1. 先关闭结构体对齐：定义结构体前添加#pragma pack(push, 1)，定义完成后添加#pragma pack(pop)，强制结构体紧凑排列，取消内存对齐填充。
2. 把结构体里的非固定长度类型全部替换为uint32_t、uint16_t这类固定长度类型。
3. 改成块遍历逻辑：
   • 读取完RIFF头确认是WAV格式后，循环读取每个块的前8字节（4字节块ID + 4字节块长度）
   • 如果当前是fmt块：按需读取需要的字段，如果块长度大于你需要读取的字节数，调用fseek(InFile, 剩余长度, SEEK_CUR)跳过多余的扩展内容
   • 如果当前是data块：记录块信息后按需处理
   • 如果是其他不需要处理的块：直接调用fseek(InFile, 块长度, SEEK_CUR)跳过整个块
   • 直到找到data块或者读完所有头部块即可

内容的提问来源于stack exchange，提问作者Omar