从托管程序集嵌入WAV资源加载AudioClip时出现音量失真、播放加速问题排查

你遇到的三个异常（音量过高、失真、2倍速播放）是多处实现逻辑错误叠加导致的，没有单独某一个问题能解释全部现象：

逐点错误与现象对应关系 #

• 未跳过WAV文件格式头部
  标准WAV文件由多段RIFF结构块组成，除了纯PCM音频数据，开头还有长度不等的文件标识、格式参数块。你当前直接把整个文件的全部字节当成音频采样读取，格式头的控制字段会被解析成无效采样值，直接造成波形错乱、初始爆音，是失真的核心诱因之一。
• 采样位深匹配错误直接导致2倍速播放
  绝大多数项目内嵌的WAV采用16位整型PCM编码，单个采样仅占2字节；你当前按4字节/采样的规则拆分字节流，原本10秒的有效音频拆完只会得到相当于5秒的采样长度。配合你硬编码的双声道、44100Hz的AudioClip参数，最终生成的音频时长刚好是原文件的1/2，完全对应播放速度为原速2倍的现象。
• 无意义的字节反转逻辑破坏数值正确性
  主流运行平台（Windows、Android、iOS）的字节序本身就是小端，和WAV文件的存储字节序天然匹配。你写的if (BitConverter.IsLittleEndian) Array.Reverse(...)逻辑，反而会把原本正确的字节序改成大端，读出来的浮点数是无意义的极值、溢出值，直接造成音量爆表、硬削波。
• 归一化规则错配放大音量失真
  你当前的浮点转换逻辑是除以0x80000000，这个规则只适配32位整型PCM的转换需求：
  • 如果实际文件是16位整型PCM，正确的归一化应该是每个short值除以32768（即0x8000），你当前的除法逻辑会把正常信号放大成远超有效范围的削波信号，对应音量过高的异常；
  • 如果实际文件是32位IEEE浮点PCM，原始数值本身范围就在[-1,1]，完全不需要额外除法，反而会把音量压缩到几乎不可闻。
• AudioClip参数硬编码放大错配
  你在调用AudioClip.Create时硬写了双声道、44100Hz采样率，没有从WAV头部读取真实的声道数、采样率、总帧数，一旦实际文件参数和硬编码值不一致，会进一步放大失真和播放速度偏差。

核心修正方向 #

• 必须先解析WAV的RIFF头部结构，跳过文件标识、格式参数块，定位到纯PCM数据的起始偏移位置，不要直接从文件第0字节开始读音频数据；
• 按从头部读到的真实位深，选择对应的字节拆分、归一化规则，不要默认按32位浮点格式解析；
• 删掉手动反转字节序的逻辑，主流平台和WAV的字节序天然兼容；
• 创建AudioClip时，用从WAV头读取到的真实声道数、采样率、总帧数作为参数，替换硬编码值。

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