FFmpeg 报 WAV 文件尾损坏时，先检查长度头

一次音频 smoke test（最小可用性测试）生成了能够正常播放的 WAV，但 FFmpeg 在文件尾部输出了两条令人警惕的信息：

Packet corrupt
corrupt input packet in stream 0

如果自动化看到 corrupt 就判定生成失败，会丢弃仍可使用的音频；直接忽略警告也不安全，因为后续上传平台、剪辑软件或波形工具可能进行更严格的封装校验。排查需要先回答一个更具体的问题：音频采样已经损坏，还是容器声明了错误的长度？

从可测量的长度冲突开始

RIFF/WAVE 容器会保存长度字段。RIFF 头描述外层负载大小，data 区块描述音频负载大小。微软的 RIFF 格式说明记录了外层区块使用的四字节长度值。

对生成文件进行二进制检查后得到：

检查项	结果
实际文件大小	15,790,352 字节
RIFF 头推导的总大小	2,147,483,591 字节
data 区块声明大小	2,147,483,315 字节
可解码音频	约 82.24 秒
音频格式	48 kHz、双声道、16-bit PCM（脉冲编码调制的未压缩音频）

容器声明接近 2 GB，物理文件却在约 15.8 MB 处结束。FFmpeg 按容器声明继续等待数据，先遇到了真实文件尾，因此给出尾部损坏警告。这一长度冲突可以直接解释现象。

同一个文件仍能解码到现有 PCM 负载末尾，解码进程退出码为零。由此可以得出有边界的结论：本次警告来自容器长度不一致，文件中已有的采样负载仍可解码。这组客户端证据无法证明上游服务内部怎样写入文件。

把写入机制保留为推断

一种合理解释是，上游采用流式写入：开始创建 WAV 时还不知道最终时长，先在 RIFF 和 data 长度字段中放入较大的哨兵值，追加采样结束后却没有把它们回写为最终长度。

这个机制符合检查到的数值，但单个客户端文件不足以确认服务端实现。公开结论应停在已验证边界：长度字段与物理文件大小不一致。把合理推断写成确定的服务端根因，会让结论强于证据。

进入下游前重写容器

对于这份 PCM 文件，安全处理方式是让 FFmpeg 解码现有音频，再按完整输出重新写入一份长度正确的 WAV：

ffmpeg -i input.wav `
  -map 0:a:0 `
  -c:a pcm_s16le `
  repaired.wav

随后对修复文件执行严格解码检查：

ffmpeg -v error `
  -i repaired.wav `
  -f null -

第二条命令无错误输出并正常结束；重写后，容器声明长度也与物理文件大小一致。

重写会生成不同的文件，因此即使听感保持一致，SHA-256 也会变化。凡是把审批、来源或费用记录绑定到内容哈希的流水线，都必须显式更新状态。在替换原文件之前，还应对新文件重新核对时长、声道、采样率和完整解码结果。

媒体 QA 不能只匹配一个日志词

这次排查暴露了一个脆弱规则：只要 stderr 出现 corrupt 就立即失败。FFmpeg 日志提供了重要证据，但可靠门禁需要组合判断：

1. 检查进程退出码；
2. 比较物理文件大小与容器声明长度；
3. 确认可解码时长是否符合预期；
4. 把异常封装重写为受控格式；
5. 对重写产物执行严格解码；
6. 在后续审批或发布前记录新哈希。

只看退出码为零同样不够。它说明当前解码器读取了现有采样，不能保证所有下游工具都接受错误长度头。重写容器可以直接消除这项兼容风险，无需让后续每个工具各自容忍异常。

验证边界

本次 smoke test 确认了五项事实：文件已经到达预期本地边界；RIFF 与 data 声明长度大于实际文件；现有 PCM 可解码约 82 秒；FFmpeg 在报告尾部异常时仍成功退出；重写后的 WAV 能在 error 级别下无输出完成解码。

这些证据没有证明两份文件逐字节等价，也不能覆盖所有音频软件，更没有确认上游写入器的源码路径。它们仍属于结论边界之外。

可复用的经验是把媒体警告放回格式边界排查：测量容器承诺的长度，测量文件实际包含的内容，验证解码器能读取多少，再把产物规范化后交给更严格的下游流程。