FLAC 元数据检查器

使用方法

1. 把 .flac 文件拖进方框。只读取文件开头部分，所以很长的专辑曲目和很短的文件打开一样快。
2. 先看流信息卡片：采样率、位深和声道来自 STREAMINFO，时长是精确值，因为总采样数是存下来的而不是估的。
3. 把压缩率和旁边的未压缩 PCM 大小对照着看：那才是这个文件真正省下的量，压缩率不好通常说明的是母带风格，而不是编码器。
4. 看块表格了解文件结构：有哪些块、各自从哪里开始、哪一块是最后一块，以及音频帧从哪个偏移开始。
5. 在注释列表里留意标着“重复”的字段：它们带有多个值，也正是标签编辑器最常合并成一个的字段。

常见问题

同一个标签出现了两次，是出错了吗？

不是，这正是该格式保存多个值的方式。Vorbis 注释块是一串 NAME=value 行，而不是字典，所以合作作品里 ARTIST 出现三次、跨风格唱片里 GENRE 出现两次都完全合法。字段名不区分大小写，artist 和 ARTIST 是同一个字段，行的顺序就是编码器写入的顺序。把这个块解析成普通映射的程序，每个名字只会留下一个值，其余的一声不响地丢掉——这就是为什么标了三位艺人的曲目，经过某些标签编辑器往返一次就只剩一位。本页按文件顺序列出每一行，并标出出现不止一次的名称。

STREAMINFO 里的 MD5 是什么？它能证明文件没损坏吗？

它是解码后音频的 MD5——即从解码器出来的、交错排列的有符号小端采样——而不是文件本身的 MD5。它的价值正在于此：把同样的音频用另一个压缩级别重新编码，文件的每个字节都会变，而这个 MD5 不变，这就能证明转换是无损的。反过来说，光看文件是核对不了它的：必须解码整条流再对结果求哈希，flac -t 做的就是这件事。有些编码器把这个字段留成十六个零字节，那表示没有存签名，而不是签名校验失败。

时长显示未知、总采样数是 0，文件坏了吗？

这是流，不是坏文件。STREAMINFO 里的采样数要等编码器知道输入有多长才最后写入；往管道或直播流里写的编码器无法回头补写，就留下 0，规范明确允许这样做。播放器的做法是一直解码到帧结束，有些播放时显示的时长还会不断变长。STREAMINFO 里其余的值——采样率、声道、位深、MD5——依然有效，文件也能正常播放。把它解码后重新编码成真正的文件，这个数字就会被写进去。

我的 FLAC 为什么以 ID3 标签开头？

因为写它的工具主要是处理 MP3 的。FLAC 的标签放在 VORBIS_COMMENT 块里，规范中根本没有 ID3 的位置，但 ID3v2 本来就设计成放在文件开头，于是一些抓轨软件、播放器和手机应用照样加了上去。多数解码器会跳过它；少数会因为 fLaC 不在偏移 0 而直接拒绝这个文件。本页会检测这个标签、说明它占多少字节，并从标记真正开始的位置读取真实元数据。要注意：写在那个 ID3 里的内容对懂 FLAC 的软件是不可见的，所以同一个文件在这里和别处可能显示不同的标题。

FLAC 的压缩率一般是多少？

多数音乐落在未压缩 PCM 的 50% 到 70% 之间，本页给出的数字就是按这个定义算的：最后一个元数据块之后的字节数，除以总采样数 × 声道数 × 位深 ÷ 8。安静、稀疏的素材压得好得多；响度高、限制很重的母带差得多；接近噪声的内容几乎压不动。编码器级别（-0 到 -8）只影响编码耗时并让体积变化几个百分点，绝不改变音频，因为每个级别都是无损的。24 位母带的压缩率通常比 16 位差，因为最低几位接近随机，没有可预测的东西。

文件会被上传吗？这个工具能验证音频吗？

两个都不会。文件用浏览器的 File API 打开并在页面内解析；甚至不会整个读完，因为元数据在开头，后面的帧只是量一下大小。没有任何内容被发送出去，也没有可发送的服务器。答案的后半同样重要：这里的任何数字都不是对音频本身的保证。块长度、标签和图片都来自元数据，帧从不解码，存下的 MD5 也只是抄出来而不是校验——所以一个元数据完好、音频损坏的文件，在本页看起来完全健康。能查出这一点的只有解码。

相关工具