最流行的无损压缩格式 - FLAC 系列之三：关于FLAC的常见疑问

在使用FLAC格式的过程中，或多或少地会产生一些疑问。在这里，我们找出一些常见的疑问进行了相应的解答。

什么是FLAC格式？
参见本站文章：最 流行的无损压缩格式 - FLAC 系列之一：FLAC格式介绍

有什么播放/编码/解码等软件或硬件支持FLAC？
参见本站文章：最 流行的无损压缩格式 - FLAC 系列之二：FLAC格式应用

FLAC支持哪些种类的标记？
FLAC具有自己的标记系统，类似于Vorbis的标记。通常把FLAC自身的标记系统称为“FLAC 标记”，把Vobris的则称为“Vorbis 注释”。“FLAC 标记”是FLAC的实现中唯一要求和保证支持的。另一方面，参考解码器懂得跳过文件中的ID3标记，以便这些标记不影响解码。但并不是所有的应用软件都支 持FLAC标记以外的任何标记，某些FLAC的实现甚至对嵌有ID3标记的FLAC文件无法正常解码。

FLAC（本地）格式和Ogg FLAC格式之间有什么不同？
所有的音频格式其实都可以视作有两层数据。里层的数据是原始的压缩后的数据，外层的数据是里层数据的容器，或者是用于传输里层数据的传输层。通过外层 实现原始压缩数据的传输、编辑和播放等。
FLAC本地格式的容器层具有最小数据量、能高效存储单一音频流的特点。而Ogg FLAC则是把FLAC压缩数据用Ogg 容器承载。Ogg容器 是由Xiph.org基金会掌控的Ogg项目研发出来的一种功能非常强大的传输层格式，允许把多种不同的流数据混合在一起传送（多路复用）。但耗费的额外开销就比FLAC本地格式要高一些。
使用哪一种容器，主要取决于对压缩数据的用途。但无论使用哪一种，原始的压缩FLAC数据都是一样的，两者之间可以无需重编码便能相互转换。

那么，究竟现在应使用哪一种容器格式，是FLAC本地格式还是Ogg FLAC？
如果你的压缩音频数据主要用途是播放，则目前应继续使用FLAC本地格式。因为FLAC本地格式受到的支持更广泛，且生成的文件较小。如果你需要对压 缩的音频数据进行编辑，或需要把音频和视频进行多路复用并置入Ogg容器，则应使用Ogg FLAC格式。

为何不能在FLAC格式中的演播列表（cue sheet）数据段中存储诸如歌手、标题等各种标记信息？
演播列表格式实质上描述的是CD上的内容在CD中的分布信息，诸如第几条音轨，位置在哪里，索引点等等。虽然后来CD-TEXT作为充实CD内容信息 的规范出现，但CD-TEXT的技术规范过于复杂，基本上没有哪个CD抓轨软件支持导出CD-TEXT信息，而是根据演播列表的内容到一些CD信息提供服 务商（比如CDDB或者FreeDB）那里去查找关于CD的其它信息。

由此，FLAC没有必要在演播列表数据段中提供对演播列表之外的信息的支持。当然，实际上你可以在FLAC文件的元数据段中存储该类信息。比如 Foobar2000便支持在FLAC文件中以FLAC标记的方式嵌入CDDB数据，并能读出显示。但由于元数据的格式多样，目前尚没有一种恰当的元数据 规范可以很好地与数据进行多路复用。

为何FLAC不支持存储WAVE格式所有的元数据？并且，flac工具支持压缩 WAVE格式文件，为何它不干脆搞成一个WAVE文件压缩器？
FLAC格式作为一种通用的音频格式，并不是仅仅面向WAVE文件格式的。WAVE格式是一种复杂的标准，可以在WAVE格式中存储各种各样的其他 （非音频）数据，比如存储图片。FLAC并不打算重现一个大杂烩似的WAVE格式，而是专注于音频的无损压缩。在默认情况下，命令行工具flac在处理 WAVE格式时并不存储WAVE格式中带有的元数据。但是，可以在压缩时指定--keep-foreign-metadata选项来实现存储该类数据，并 在解码时同样给出该选项来还原WAVE/AIFF文件。

为何某些无损压缩格式的比较文章说FLAC格式不支持RIFF段落？
RIFF段落主要用于WAVE格式中，大体的情况就像上一个问题所回答的，可以通过--keep-foreign-metadata选项来实现支持。 当然，这种支持与在音频流中嵌入RIFF段落有所区别。

为何编码选项设置对编码速度有如此大的影响，但却不影响解码速度？
这主要是因为编解码器的设计所使然。由于编码器需要对信号进行各种算法的处理尝试以图逼近信号，较高的设置使得编码器会做更多的算法尝试来寻找最好的 结果，所以速度就越慢。但当寻找的结果确定以后，这个结果以及所使用的算法等信息便被记录在压缩数据流中，解码器只需要根据这些信息进行解码便可，不需要 进行什么尝试，因此算法的复杂程度（所耗费的时间）便是恒定的了。这种设计使得FLAC的解码速度非常快，因此可以更容易地在各种硬件中实现对FLAC格 式的支持。

为何不使用其他一些比FLAC有着更好压缩比的编码方案？
对于大多数用户来说，压缩结果大小的些微差别与FLAC格式所拥有的先进性相比是不足道的。FLAC是开放专利的自由编码方案，基于BSD协议的可移 植开源参考实现，文档化的API，多平台支持，硬件支持，多声道支持等等。尤其是FLAC格式在解码实现方面的简单性是使得FLAC格式获得大量硬件支持 的主要原因。如果为了增加一点点的压缩比例而使得FLAC的解码过程需要耗费更多的计算资源，FLAC将不会获得现有的硬件支持程度。

为何不能使FLAC编码器更快？
FLAC的编码压缩速度其实已经相当快。即使在没有什么计算能力的系统上压缩速度也高于实时，并且比最快的编码方案不会慢多少。由于FLAC的压缩速 度实际上已经被CD抓轨软件要快，因此就算再提升FLAC的压缩编码速度，实际上也会受制于CD抓轨的速度而没有实际效果。另一方面，由于FLAC是不对 称的设计，即以牺牲编码速度为代价地专注于优化解码速度，从而使得更容易实现在各种低端的硬件上进行解码。始终，编码是一次性的，而解码则绝对是多次的。

如何保证FLAC格式是无损的？FLAC在这方面做了多少测试？
首先，FLAC可能是唯一一个具有正式公布和被全面理解的测试方案的无损压缩器。其他格式多数是该编码方案作者的个人测试，又或者依靠该种格式的资 格。对于FLAC格式，你可以下载整个测试方案，并在任何一个版本的FLAC格式上进行试验，甚至修改测试方案以加入你自己的测试数据。测试方案检查 API中的每一个函数，有如用数千个数据流以编码/解码/校验模式进行处理来测试系统中可能存在的隐患和裂缝。即使在快速的机器上也需要多个小时才能完成 一次完整的测试。每一个版本释出前都要在不同的平台上进行完整的测试方案运行。所有这一切都保证了FLAC的每一个版本都是经过仔细、严格的测试的。
其次，在使用flac命令行工具时可以同过-v选项（大多数的图形界面前端也都支持该选项）来实现在编码的同时进行解码校验。该选项使得在编码的同时 并行运行一个解码器，并把即时解码得到的内容与原始数据进行比较，若发现有错误flac会立即停止运行并给出出错信息。
最后，FLAC已经被广泛使用，并已经被许多软件和硬件制造商认为是足够稳定且能集成到他们的产品中去的。

FLAC可以达到的最低比特率（或最高压缩比）是多少？
在压缩FLAC时（以及其他无损压缩编码）不可能像有损压缩那样指定比特率。FLAC的压缩结果其比特率大约地可以认为是与原始信号中包含的信息量成 比例的。如果对白噪音进行压缩，最后的比特率与输入信号的比特率相比会是100%；但如果对安静无声的信号进行编码，则最后的比特率可能会接近零。

FLAC支持多少个声道？
FLAC支持单个音频流中可以有1到8个声道。各个声道只是在FLAC里面组合在一起以便利用声道间的相关性和定以常规的通道分配（比如立体声， 5.1环 绕声等）。当编码大量的独立声道时，可以认为它们是独立编码的，并且在有需要时可在合适的诸如Ogg或Matroska一类的容器中实现多路复用。

FLAC支持什么种类的音频采样？
FLAC支持线性PCM采样，采样位数为4位到32位。FLAC不支持浮点数采样。在某些情况下，可以实现无损地把FLAC不支持的采样格式转换为 FLAC支持的采样格式后再进行压缩编码。FLAC支持线性采样频率，范围以1Hz为增量从1Hz到655350Hz。

为何用metaflac工具编辑FLAC文件时要耗很长的时间？
因为元数据是存储在FLAC文件的开头的，修改原数据时如果其长度发生变化则有可能需要把整个文件都重写一次（不是重编码），因此需要很长的时间。为 避免出现这种问题，可以在编码FLAC文件或使用metaflac工具时为FLAC文件加入填充数据来预留空间。默认情况下，flac命令会自动加入 8kb字节的预留空间。

为何flac/metaflac在Windows平台下不支持Unicode文件 名？
Windows平台对Unicode文件名的支持与其他所有操作系统都有所不同，并且，必须通过不可移植的Windows API来实现支持。更甚的是，在不同版本的Windows操作系统下这些API都有所不同。flac是一个跨平台的工具，因此很难为此提供支持。但这 里有一个权宜的办法(英文)。

为何flac/metaflac在Windows上不支持星号通配符？
Windows 命令行模式对通配符的支持与其他平台不同，需要程序本身去处理各种困难而且带有歧义的情况。真要批量处理，可以通过图形界面前端，或者用Windows的 批处理命令，比如：

for %F in (*.wav) do flac "%F"

但必须确保命令能按照你的设计来执行。

我把一个文件压缩为FLAC格式，压缩时打开了校验功能，但flac工具给出 “Verify FAILED!（校验失败）”的提示，为何？
由于每一个版本的FLAC在释出前已经经过了足够详细的测试，所以可以认为问题并不是flac工具出错，而是由于硬件问题导致的。特别是当你运行同一 条命令去压缩相同的数据，但每次都在不同的位置发生错误或只是某些时候会发生错误时，便可以肯定是硬件的原因。就已知的情况来看，问题通常出在超频/过热 的CPU或有问题的内存上。可以利用一些免费的内存测试软件（比如Memtest86+）进行检测。检测的时候或许需要在测试软件中关闭 CPU Cache以便获得更准确的结果。另据报告有一些系统可以出色地通过测试，但仍会发生不可重复的错误，而这些系统都有一个共同点就是都使用了Asus A7V133或Asus P3V4X主板。因此也有可能这些主板有缺陷。详 情参见这里。

为何把WAVE文件压缩为FLAC格式后再还原，得到的还原文件与原文件不同，比如 少了2个字节这样？
为何在压缩WAVE文件时flac工具给出这样的提示：“warning: skipping unknown sub-chunk LIST”（警告：跳过未知的LIST子段落）？
如前所述，WAVE格式是一种非常复杂的格式，除了音频数据之外还有许多其他格式的数据可以存储在WAVE文件中。出现以上的情况，通常就是这个WAVE 文件中带有非音频数据，而flac工具不支持这些数据。当然，你可以尝试使用--keep-foreign-metadata参数来把这些数据嵌入到 FLAC文件中。无论如何，WAVE文件中的音频数据是必定无损的。可以用其他工具去比较原始WAVE文件和解码后的WAVE文件的音频数据是否一致。ExactAudioCopy有 这样的功能。

为何在不同的机器（平台）上用同样的参数去压缩同一个文件得不到相同的FLAC文 件？
首先需要指出的是，这种情况不表示解码后的内容会有损失。造成这种现象的原因，主要是因为不同的计算机之间，或者不同的FLAC版本之间在数据的处理 上都会存在一定的差异，而这些差异就会导致编码结果的FLAC文件会相互不同。这是一种正常现象。

本站微信订阅号：

本页网址二维码：