diff options
Diffstat (limited to 'content/article')
| -rw-r--r-- | content/article/got-flac.md | 84 |
1 files changed, 75 insertions, 9 deletions
diff --git a/content/article/got-flac.md b/content/article/got-flac.md index 495ca22c..27158023 100644 --- a/content/article/got-flac.md +++ b/content/article/got-flac.md @@ -22,9 +22,13 @@ FLAC 作为自由的开源项目，不仅包含对 FLAC 音频格式的规格制 什么音频格式是不自由的？亚马逊开发的用于播放有声书的 `.aa` 和 `.aax` 格式，苹果开发的用于 iTunes Store 的 `.m4p`（MPEG-4 Protected），以及微软开发的 `.wma`（Windows Media Audio）都是不自由的封闭格式。[^2]这些格式不仅没有开源编码和解码器（也就是说，除非有人能够逆向工程编写出该格式的编码和解码器，否则就只有它的创造者能够制作和播放这种格式的音频文件），还添加了 DRM 能力。DRM 的全称是数字版权管理（Digital Rights Management），一般是指用户保护版权内容的相关授权和加密技术。 -其实最常见的 `.mp4` 格式并非是自由和开放格式，而 `.mp3` 是（因为版权过期了）。[^3] 开放格式（Open Format）和自由格式的概念不同，开放格式是指这个文件格式的标准和规格说明被定义在人人都可以访问的文档里，大家都能看到这个格式是如何制定的，并且能以此为依据编写编码和解码器。这个概念和开放标准（Open Standards）类似，其实前几天的[一篇文章](https://www.geedea.pro/article/webmention/)提到的 Webmention 也是开放标准，它的文档被 W3C 组织公开[于此](https://www.w3.org/TR/webmention/)，任何人都能根据这篇文档，自己实现 Webmention 发送器和接收器。 +其实 `.mp3` 一开始并不是开放和自由格式，开发它的公司曾经试图向使用者收费，后来才有替代的算法被研发，用于解码和编码 `.mp3` 文件。即便是这样，`.mp3` 在 2017 年 4 月 16 日之前是收到专利保护的，直到最近今年才进入公有领域，成为了自由格式。[^3] -对于普通人而言，这些技术规格的差异意味着什么？显而易见的是，如果使用不自由、不开放的音频格式，尤其是那些带 DRM 保护、由某个企业开发的音频格式，用户很容易被锁死在一个平台上。假设你在网易云音乐上购买了一张专辑，某天你想换到 Spotify，你会发现你没办法把你在网易云音乐上购买的专辑导入到 Spotify 中，因为网易云给音频文件加上了保护，只有网易云音乐播放器才能解码文件。 +开放格式（Open Format）和自由格式的概念不同，开放格式是指这个文件格式的标准和规格说明被定义在人人都可以访问的文档里，大家都能看到这个格式是如何制定的，并且能以此为依据编写编码和解码器。这个概念和开放标准（Open Standards）类似，其实前几天的[一篇文章](https://www.geedea.pro/article/webmention/)提到的 Webmention 也是开放标准，它的文档被 W3C 组织公开[于此](https://www.w3.org/TR/webmention/)，任何人都能根据这篇文档，自己实现 Webmention 发送器和接收器。如果标准不开放，就只能求助于逆向工程了。 + +对于普通人而言，这些技术规格的差异意味着什么？ + +显而易见的是，如果使用不自由、不开放的音频格式，尤其是那些带 DRM 保护、由某个企业开发的音频格式，用户很容易被锁死在一个平台上。假设你在网易云音乐上购买了一张专辑，某天你想换到 Spotify，你会发现你没办法把你在网易云音乐上购买的专辑导入到 Spotify 中，因为网易云给音频文件加上了保护，只有网易云音乐播放器才能解码文件。 这当然很不公平，明明是我自己付了钱买的音乐，为什么没办法随心所欲地播放呢？实体产品可不是这样，如果你购买了一张黑胶，把它放进任何一家企业生产的黑胶唱片机里，都能够播放音乐。 @@ -60,19 +64,19 @@ FLAC 作为自由的开源项目，不仅包含对 FLAC 音频格式的规格制 总之是挺蠢的行为。 -## 无损、有损和音质玄学 +## 音频格式和音质玄学 谈完了政治性极强的内容，这一小节来谈点轻松的话题。需要注意的是，我本人并非音乐相关的从业人士也绝非专业，所以我仅仅是从普通音乐爱好者的角度来谈这个问题。 -我本人对音质其实并不敏感，之前在以前是这样，因为那时我听的大多是我称之为「天生适合跟唱」的歌曲，更关注歌词和旋律，而另一些注重节奏感的音乐则是「跟着摇就完事了」的态度。我之前并不明白一些人所说的「听个响」具体是指什么，只以为那是对低端音频播放设备的轻蔑，实际上并没有那么夸张。 +我本人对音质其实并不敏感，至少在以前是这样，因为那时我听的大多是我称之为「天生适合跟唱」的歌曲，更关注歌词和旋律，而另一些注重节奏感的音乐则是「跟着摇就完事了」的态度。我之前并不明白一些人所说的「听个响」具体是指什么，只以为那是对低端音频播放设备的轻蔑，实际上并没有那么夸张。 是的，实际上这个描述非常准确。 -### 播放设备 +### 播放设备之间的区别 本来《软件杂谈》这个系列里是不该出现硬件相关的描述的，不过音质这个话题的确离不开硬件。当然，再次强调，我仅仅是从自身体验的角度出发讨论这个问题，带有不可避免的主观性，还请读者注意甄别。 -我自己购买过不少价格在 100~200 元左右的普通蓝牙耳机，我现在还在用的是是三百左右的头戴式蓝牙耳机，而我目前主要使用的听歌设备是 AirPods 4（带主动降噪功能的版本）。头戴式耳机是为了保证沉浸感和降噪效果使用的，个人感觉物理隔绝比任何降噪技术都要好用，不过还是要将被动和主动降噪搭配使用才效果最好， +我自己购买过不少价格在 100~200 元左右的普通蓝牙耳机，我现在还在用的是三百左右的头戴式蓝牙耳机，而我目前主要使用的听歌设备是 AirPods 4（带主动降噪的版本）。头戴式耳机是为了保证沉浸感和降噪效果使用的，个人感觉物理隔绝比任何降噪技术都要好用，不过还是要将被动和主动降噪搭配使用才效果最好。 *它们之间的差别真的很大……* @@ -84,9 +88,63 @@ FLAC 作为自由的开源项目，不仅包含对 FLAC 音频格式的规格制 由于我几乎不使用音响，所以这里就不谈了。 -### MP3 vs FLAC +### MP3 vs. FLAC：什么是无损？ + +无压缩、原样录制的音频往往是 `.wav` 格式，由微软开发，苹果也有对应的 `.aiff` 格式。这些音频格式的音质是最好的，`.wav` 往往是音乐发烧友的首选格式之一。[^4]由于没有经过压缩，这类格式的文件体积也很大，储存成本很高。 + +于是就有了支持压缩的音频格式。谈到压缩，就要分出无损和有损两种压缩方式。听起来很像玄学的有损和无损两个词，其实是实打实的技术规格。 + +最典型的有损压缩格式是 `.mp3`，这类格式去除了人类不容易听到的声音，以压缩音频体积。大多数有损压缩格式都是这样，利用心理声学（Psychoacoustics），去掉对人类听觉不重要的声音。这些被去掉的声音就是「损」。自然地，无损压缩就是在不去掉任何声音的情况下减少音频体积。 + +这听起来还是很抽象，让我画个图。 + + +{.dark:invert} + +需要注意，这里的音频并非是物理世界的声波，而是经过**脉冲编码调制**（PCM）转化成的数字信号，是对模拟信号的编码。PCM 就是用比特（0 和 1）表示音频的方法，可以理解为声波在数字世界的一比一复刻（当然实际上不是 100% 精确的）。PCM 比特被输入到编码器中，得到了特定格式的音频文件，音频文件再作为解码器的输入被解码，解码的结果就是 PCM 比特。 + +对于无损压缩格式而言，编码器的输入和解码器的输出在比特层面是完全一致的。 + +对于有损压缩格式，比如 `.mp3`，编码后的音频文件无法通过解码器复原出一模一样的 PCM 比特，因此，音频的质量就被损坏了。 + +### ALAC vs. FLAC：编码与容器 + +FLAC 并不是唯一的无损压缩格式，苹果有开发名为 Apple Lossless 的音频格式，也被称作 ALAC。~~FLAC 听起来更像美味的食物，而 ALAC 更像是化妆品、药品或者医美手术的名字，这就是 ALAC 的第一个缺陷。~~ + +这两种格式并不是完全相同的东西。 + +首先，FLAC 既是音频编码，也是容器格式（container format），所以有拓展名为 `.flac` 的音频文件。而 ALAC 只是音频编码，这种编码的音频需要被放在一个容器里，比如 `.m4a` 和 `.mp4`（是的 MP4 其实是容器格式）。所谓容器格式，就是说这个文件里不仅有音频数据本身，还有相关的元信息，用来告诉读取这个文件的软件容器里放的是什么编码类型的数据。 + +话都说到这了，就谈谈 MP4 吧。一个有趣的事实是：MP4 文件里可以放 FLAC 编码的音频，因为 MP4 是容器而不是编码，只不过 FLAC 有自己的容器格式 `.flac`，所以一般没人会在 MP4 里放 FLAC 音频。里面装着音频的 MP4 一般以 `.m4a` 为拓展名而非 `.mp4`（`a` 应该是指 audio），苹果的 ALAC 就是这样做的。 + +顺带一提，`.wav` 和 `.aiff` 也是容器，里面放的编码是完全未经压缩的 PCM 比特。前面我们提到，FLAC 等无损压缩格式解码后就能得到和编码前完全一致的 PCM 比特，所以 `.wav` 和 `.aiff` 对于听音频的人来说，在音质上和 `.flac` 没有任何区别。 -### 流媒体 vs 本地音乐 +这是 FLAC 的第一个优势（应该算吧）：它不用放在 MP4 容器里。 + +其次，在 CPU 算力相同的情况下，ALAC 的解码时间是 FLAC 的四倍左右[^5]，算法效率不如 FLAC。尽管播放 ALAC 音频时并不会出现明显的延迟，但消耗更多的时间解码意味着消耗更多的电力，对续航能力较差的设备来说不是好事。 + +其他方面，ALAC 和 FLAC 基本相同，但我们先前一直忽略了一个非常重要的指标，就是 PCM 音频本身的质量。如果 PCM 音频的质量本身就不太好，编码为 FLAC 或者 ALAC，最后在解码出来依然会得到一样质量的音频。有没有可能，ALAC 或者 FLAC 因为技术限制，无法编码某种高质量的音频，只能退而求其次去编码更低质量的音频，继而导致音质差异呢？ + +先前已经提过，几乎所有的音频格式都在处理 PCM，也就是对声波信号的数字化编码，而数字化不总是精确的。精度能够量化，最常见的两个数据就是采样率（sample rate）和比特深度（bit depth）。 + +现实中的声波是模拟信号，通常表示为光滑、不断变化的曲线。PCM 做的就是每隔一段时间取一次波形图的高度，并将这次测量结果表示为二进制数，连起来就得到了数字信号，如下图所示。 + + +{.dark:invert} + +采样的频率就是采样率，单位是 kHz（千赫兹），也就是每秒采样几千次。ALAC 支持的最高采样率为 384 kHz，如果采样率更高就无法承受了；而 FLAC 支持的最高采样率为 1.048 MHz。[^6]尽管大部分音乐播放器不一定支持这么高的采样率，音频格式本身也没有这么高（我下载的音乐有不少采样率都只有 44.1kHz，听感依然很好），但…… 为什么不选一个更好的音频格式呢？又没有什么开销。 + +所谓比特深度，就是每次采样包含了多少比特的信息。深度其实就是字长（word length），是每次采样时，声波的振幅。比特深度不同的音频之间的区别，就像是 32 位操作系统和 64 位操作系统之间的区别，都能跑，但就是会有差别。 + +简单理解：采样率类似于帧率，比特深度类似于每帧的分辨率。 + +FLAC 支持 4~32 位的比特深度，而 ALAC 支持 16、20、24 和 32 位。[^7]尽管两者的上限是一样的，但无疑 FLAC 的兼容性更广。 + +关于 FLAC 和 ALAC 以外的无损压缩格式，可以参照 Hydrogenaudio Wiki 上的[这张表格](https://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison#Comparison_Table)。 + +### 流媒体 vs. 本地音乐 + +把整个音频文件都下载到本地后再播放，明显的缺点是慢，等待的时间很长。流式传输就是一边传输数据，一边解析已经收到的数据，就可以做到在没有获得完整音频文件的情况下播放音频。流式传输是很常见的编程实践，本身是中立的技术，但流媒体平台的发展使得 ## 分析统计怎么办？ @@ -99,4 +157,12 @@ FLAC 作为自由的开源项目，不仅包含对 FLAC 音频格式的规格制 [^2]: 参见：[Audio file format - Wikipedia](https://en.wikipedia.org/wiki/Audio_file_format#List_of_formats) -[^3]: 参见：[MP3 - Wikipedia](https://en.wikipedia.org/wiki/MP3) +[^3]: 参见：[MP3 - Wikipedia](https://en.wikipedia.org/wiki/MP3) 和 [音频文件格式 - 维基百科](https://zh.wikipedia.org/wiki/%E9%9F%B3%E9%A2%91%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F#:~:text=1996%E5%B9%B4%EF%BC%8CWinamp1.0%E7%89%88%E7%9A%84%E5%8F%91%E5%B8%83%E6%88%90%E4%B8%BAMP3%E6%A0%BC%E5%BC%8F%E6%B5%81%E8%A1%8C%E7%9A%84%E5%82%AC%E5%8C%96%E5%89%82%E3%80%82Fraunhofer%E5%BC%80%E5%A7%8B%E5%90%91%E9%87%87%E7%94%A8%E4%BB%96%E4%BB%AC%E7%9A%84%E7%AE%97%E6%B3%95%E7%9A%84%E5%85%AC%E5%8F%B8%E7%B4%A2%E8%A6%81%E8%AE%B8%E5%8F%AF%E8%AF%81%E8%B4%B9%E7%94%A8%EF%BC%8C%E5%9B%A0%E6%AD%A4%E5%85%B6%E4%BB%96%E6%9B%BF%E4%BB%A3%E7%9A%84%E5%85%8D%E8%B4%B9%E7%AE%97%E6%B3%95%E5%BC%80%E5%A7%8B%E8%A2%AB%E7%A0%94%E5%8F%91%E3%80%82) + +[^4]: 参见：[WAV - Wikipedia](https://en.wikipedia.org/wiki/WAV) 和 [Audio Interchange File Format](https://en.wikipedia.org/wiki/Audio_Interchange_File_Format) + +[^5]: 来源：[Apple Lossless Audio Codec - Wikipedia](https://en.wikipedia.org/wiki/Apple_Lossless_Audio_Codec#:~:text=ALAC%20has%20been%20measured%20to%20require%20around%20four%20times%20as%20much%20CPU%20power%20to%20decode%20than%20FLAC%20does%2C%5B5%5D%20with%20implications%20for%20battery%20life%20on%20limited%2Dpower%20devices.) + +[^6]: 来源：[RFC 9639](https://datatracker.ietf.org/doc/rfc9639/#:~:text=sample%20rates%20from%201%0A%20%20%20to%201048575%20hertz) + +[^7]: 来源：[RFC 9639](https://datatracker.ietf.org/doc/rfc9639/#:~:text=bit%20depths%20from%204%20to%2032%20bits) 和 [ALAC - Wikipedia](https://en.wikipedia.org/wiki/Apple_Lossless_Audio_Codec#:~:text=ALAC%20supports%20up%20to%208%20channels%20of%20audio%20at%2016%2C%2020%2C%2024%20and%2032%20bit%20depth%20with%20a%20maximum%20sample%20rate%20of%20384%C2%A0kHz.) |