摘要

  • RFC 9639 规定 FLAC 位流如何无损重建编码器输入的整数 PCM 样本，而不是如何认证一段录音的历史身份。
  • 帧 CRC、STREAMINFO MD5、外部文件摘要、可信签名、声道校验与播放观察各有对象，不能互相借用权威。
  • 完整回执应连接来源保管、编码输入、位流与容器、PCM 比对、声道和元数据、具体实现、资源上限及下游结果。

档案系统还原出的每一个 PCM 样本都完全一致，播放时却发现中置与低频声道走错了出口。

这并不否定“无损”。恰恰相反，它说明无损命题成立的范围非常精确：样本值被重建了，声道语义与播放路由则属于别的现实层。RFC 9639 为 Free Lossless Audio Codec 给出了标准轨道规范，让帧、子帧、元数据、校验与可流式子集都有明确边界。标准越精确，运营者越不应把一个局部绿灯扩张成万能证明。

无损必须带宾语

FLAC 处理整数 PCM。“无损”指解码输出可与编码输入保持样本级相等。如果编码前已经重采样、选错母带、交换声道或截短，FLAC 会忠实保存这些状态。它保证的是入口到出口的关系，而不是入口的历史正确性。

因此回执必须写清比较双方：采样率、位深、声道数与顺序、样本总数、输入指纹、编码器版本与参数、解码器版本以及比较方法。只写“无损验证通过”，却不指出验证的对象，相当于删除了结论最重要的边界。

三类校验不是一枚印章

每个 FLAC 帧头带 CRC-8，帧尾带 CRC-16。STREAMINFO 还可保存对未编码音频数据计算的 128 位 MD5。外部摘要则可覆盖整个原生文件或容器字节。

它们回答不同问题。单帧校验通过不代表序列完整；PCM 的 MD5 匹配不代表封面、索引或容器时间轴正确；文件摘要一致也不能证明“艺术家”“日期”或“授权”字段真实。STREAMINFO 还允许未知值：帧大小可为零，样本总数可为零，全部为零的 MD5 表示未知。未知不能在报表里被美化成成功。

RFC 6151 划出了安全界限：需要抗碰撞能力时不应依赖 MD5；只为发现传输或存储错误的内嵌校验则是另一种用途。FLAC 的 MD5 不是数字签名，不能认证提交者，也不能证明保管链。需要来源真实性时，应另有可信清单和签名，并明确签名覆盖哪个对象。

声道标签不会搬动样本

FLAC 对常见声道数规定默认顺序。非默认布局可通过 Vorbis comment 携带 WAVEFORMATEXTENSIBLE 声道掩码。但掩码只说明扬声器集合，并不会自动重排样本；写入端和读取端必须使用相同语义。依赖这条 comment 还会使文件不属于可流式子集。

所以多声道档案不能只检查摘要。它需要把每个声道索引与生产记录连接，用受控信号或可信来源验证顺序，并记录实际播放映射。同一组样本送往不同扬声器，编解码层仍然“完全一致”，听觉结果却已改变。

标题、表演者、日期、许可和图片同理。元数据块能够保存陈述，却不能证明陈述。应保留原始字节，同时记录字段由谁提供、依据什么目录、何时审阅、是否存在冲突。

容器可能拥有另一只钟

FLAC 可以原生存在，也可进入 Ogg，并与 Matroska 或 MP4 生态的结构相遇。容器可能重复时长、采样率、声道或样本边界。若两层不一致，静默选择一个值会抹掉重要证据。

合格回执应保存两种读数，标明解析器与优先规则，再观察具名实现的行为。正确的 PCM MD5 无法裁决容器时间轴；正确的容器索引也无法代替样本比对。

“可流式子集”也不是所有播放器的通行证。它缩小组合以提高兼容性，但 RFC 9639 明确提到早期或质量较差的解码器可能只实现常见功能。兼容性必须由具体软件、版本、功能组合、输出指纹与错误路径来证明。

正确解码不等于无限制地安全解码

RFC 9639 指出，一个仅 49 字节的帧可以展开为超过 2 MiB 的 PCM，元数据也可能包含海量字段和字符。格式正确与资源安全是两项判断。生产系统需要限制内存、时间、输出规模、元数据数量与隔离级别，并记录被拒绝的路径。

回执应从保管开始：原始对象、提交者、时间、传输渠道与外部锚定摘要。随后记录编码前 PCM、任何转换、编码器构建与参数。分别识别位流和容器，公开 STREAMINFO 中的零值与未知，分开报告帧 CRC、音频 MD5 和 PCM 精确比对。

再协调采样率、位深、时长、声道和容器时间，保留每项元数据的来源。用具名解码器在声明的资源上限内执行，若承诺“成功播放”，就附上播放链路证据，而不是让编解码结果代言。

这样得到的不是一个万能徽章，而是一条分权证据链：保管负责身份，编码器负责转换，位流负责承载，校验负责发现有限范围内的变化，解码器负责重建，元数据负责描述，容器负责调度，播放系统负责最后的效果。

来源