docs: update draft

1 files changed, 73 insertions, 2 deletions

diff --git a/content/article/got-flac.md b/content/article/got-flac.md
index df23ceca..865a511a 100644
--- a/content/article/got-flac.md
+++ b/content/article/got-flac.md
@@ -248,21 +248,86 @@ Soulseek 还有一个更现代的客户端，叫作 [Nicotine+](https://nicotine
 
 上面这些感受有可能是流媒体平台之间音频质量差异导致的，可能不具有代表性。于是我又在 Steam 上购买了《To The Moon》这款游戏的原声带（Steam 也提供 FLAC 格式下载），听完的感受是：我这辈子所有的《For River》都白听了。*怎么回事？连钢琴的声音都有差别？*
 
-就算不谈可能略有争议的音质，播放本地音乐而不依赖流媒体也有其他无法替代的优势。首先，即便离开了网络，你也能播放喜欢的音乐；其次，即便离开了某个平台，你也能播放喜欢的音乐（因为你一开始就不在任何一个平台上）；再次，即便离开了某个播放器，你也能播放喜欢的音乐，只要使用开放格式和支持解码这种格式的播放器就好。
+就算不谈略有争议的音质问题，播放本地音乐而不依赖流媒体也有其他无法替代的优势。首先，即便离开了网络，你也能播放喜欢的音乐；其次，即便离开了某个平台，你也能播放喜欢的音乐（因为你一开始就不在任何一个平台上）；再次，即便离开了某个播放器，你也能播放喜欢的音乐，只要使用开放格式和支持解码这种格式的播放器就好。
 
 本地音乐还会有一种收集的仪式感，因为必须要自己找音乐、下载、导入播放器。人们习惯了使用流媒体，或许时常忘了音乐是需要自己去发现的东西。即便没有能力消费 CD 和黑胶等实体音乐媒介，也能通过下载音乐到本地来体验收集的乐趣。
 
 而且，以开放格式存储在你的硬盘里的音乐，真的就是你的啊！
 
-### 分析统计怎么办？
+### 我没有那么多硬盘空间怎么办？
+
+你有。
+
+一首采样率为 44.1kHz，比特深度为 16-bit，时长在 2-4 分钟左右的歌，大小约为 30MB。老实说，这比很多人做的 PPT 还小。假设一张专辑包含 15~20 首歌，大小就是 450-600MB。我下载了 18 张时长不一的专辑，占用了大约 7GB 的存储空间。假设一共下载了 100 张专辑，占用的空间大约是 50-60 GB。我记得我用了一年多的 Apple Music，听过的专辑都会本地缓存，才占用 30 GB 左右的本地空间。
+
+放在以前可能很多，但对于现在的大多数人而言，这些存储空间不足为奇，随便买一块 U 盘或者硬盘就能存下。如果设备本身的存储空间就比较大，也可以直接存放在设备上。
+
+对我而言，手机的存储空间除了放照片、聊天记录，剩下的就是音频文件了，管理得当就没有问题。
+
+### 分析统计和推荐怎么办？
 
 我很想发表暴论说，年度回顾和音乐统计之类的东西是流媒体给用户创造的需求，没有人需要被提醒自己今年最喜欢的歌手是谁，最喜欢的专辑是什么，播放得最多的歌是那首——如果你真的喜欢，那你自己会知道的。不过，唉，我其实没资格说这话，因为我的确也想要一些实在的数据。
 
+推荐算法在社交媒体和视频平台上可能是令人成瘾的毒瘤，但对想要发现新音乐的人来说，可能是真的有用。如果离开了流媒体，是不是也没有办法享受这些服务了呢？当然不是。
+
+[Last.fm](https://www.last.fm/) 提供音乐追踪服务，你可以使用支持 last.fm 的播放器或者相关插件，向这个服务发送 Scrobble，它就会记录你播放了什么音乐。所谓 Scrobble 就是对一次播放音乐的记录，只有一首歌播放时长超过一半的时候才会算作 Scrobble。有了记录之后你可以查看上周、上个月和去年的听歌报告，最近听了什么歌，听得最多的艺人和专辑是什么，last.fm 还会显示你当前正在播放什么歌。
+
+他们有提供详细的 [API 文档](https://www.last.fm/api/scrobbling)，只要向对应的 URL 发送 POST 请求即可。如果你是用的播放器不支持 last.fm，大概也能很容易地找到或者自己做一个插件。再者，媒体播放一般都受到操作系统控制，所以理论上可以在操作系统层面监听音乐播放情况，然后发送记录。
+
+值得一提的是，last.fm 是 [Paramount](https://www.paramount.com/)（一家美国的大型娱乐集团）旗下的服务，大概率不兼容 GDPR 法案，注重隐私的用户需要谨慎考虑。不过我觉得，自己听了什么歌这种数据，并没有太敏感。
+
+搜索之后我并没有找到 last.fm 的替代方案（倒是有个 [stats.fm](https://stats.fm/)，但那是给 Spotify 用的），自由软件就别想了。或许可以做一个兼容 Scrobble 的开源自托管后端，把数据都掌握在自己手上。
 
 ### 歌词怎么办？
 
+从我自己的体验来看，听歌时看歌词其实不是硬性需求，音乐播放器又不是全民 K 歌。对我而言，除非我在听华语和英语以外的语言，我基本都能听清歌手在唱什么，而且很多时候听清歌词并不重要，尤其是在听摇滚乐的时候。我回想起小学和初中时看 Minecraft 游戏实况的时候，所有的实况主几乎都没有做字幕，而我也看得很投入，一看就是四十分钟以上，很少出现听不懂的情况。反观现在，给视频加上 AI 识别的低质量字幕已经是惯用手段了。人们愿意用来阅读大段文字的时间变少了，对字幕和歌词的需求却与日俱增，真是令人唏嘘。
+
+就跟写代码的时候其实不需要有一个文件目录树一直放在编辑器界面占位置一样（是的，不需要，只要熟悉项目结构就可以用模糊搜索跳转到文件，速度还更快，不熟悉的话才需要看目录树），听歌的时候也不需要有歌词一直在跑，等需要看歌词的时候再专门找歌词来看就好。
+
+找歌词的平台，最全的应该是 [Genius](https://genius.com/)。如果不想被追踪、不想运行不自由的 JavaScript 代码，它还有两个替代前端 [Dumb](https://codeberg.org/rramiachraf/dumb) 和 [Intellectual](https://github.com/Insprill/intellectual)[^12]，我只用过前者，体验还不错。
+
+大部分时候只享受音乐就好，在需要的时候再找歌词。
+
+至于歌词翻译，我又要发表暴论了，请做好准备：*我不明白为什么人们会执着于那些自以为是、文绉绉、沉溺在自我感动里亵渎艺术家原义、味儿能冲出屏幕的低质量歌词翻译，你都在听外文歌曲了，请欣赏原文！*
+
+我无意指责志愿者无偿的翻译工作，我只是不赞赏这种文化，我也不认为因为做这些工作的人是志愿者就可以忍受低质量的成果。我在《[翻译的吃力不讨好](/essays/翻译的吃力不讨好/)》这篇文章里表达的观点如下：
+
+> 在译文里加上原文没有的东西造成了意思传达的偏差，是不能容忍的；如果这种错误的改动是为了「呈现效果」而非纯粹的技艺不精，做出这种行为的译者是偷懒、不负责任且不尊重原作的。
+>
+> 翻译很难，甚至吃力不讨好，应该被理解，但这不代表坏的翻译应该被容忍。
+>
+> 再好的译者也无法把翻译做到完美，如果想要毫无偏差的呈现，比起对质量尚可的翻译吹毛求疵，不如直接去读原文。
+
+前不久 Apple Music 也添加了歌词翻译[^13]（据说这个平台常年被诟病没有歌词翻译），不过并不是像国内流媒体那样允许用户自己提交歌词和翻译，而是找了专业的人来做翻译，并且要求按照原义呈现。严格翻译标准导致的结果也不能让用户满意，不少人觉得那些直白的翻译很好笑。
+
+我们或许可以同意：诗是没有办法被翻译成另一种语言的。歌词也同理，就算是那些被批评满是口水话的歌，也可能包含双关语等难以被翻译的元素。
+
+综上所述，我的态度是：不需要翻译。
+
 ### 为什么不自建流媒体？
 
+诚然，可以用 [Navidrome](https://www.navidrome.org/) 等开源软件自己搭建流媒体服务，对于有 NAS[^14] 设备的用户来说应该很方便，而且找到支持相关服务的播放器也不难。
+
+可这么做的成本不低，需要一台 NAS 或者云服务器，需要运行软件占用网络带宽和内存资源，反观本地音乐，只需要一个播放器和音频文件本身就够了。在我看来，除非是要给家人和朋友也提供服务，或者托管数量很多的音乐，否则没必要自建流媒体服务。当然，如果是想折腾技术玩玩的话，也是很不错的。
+
+前文已经讲过了，设备的本地存储在大多数时候够用，也可以购买廉价的外部存储作为拓展，存放不常听的音乐。
+
+### 要怎么给朋友分享喜欢的歌？
+
+“嘿，我刚听了 Harry Styles 的《Aperture》，感觉你会喜欢，也推荐你听听。”
+
+~~此处应该有黑人摊手迷因图。~~
+
+话说回来，就算没有离开流媒体，你和你的朋友真的在同一个平台上吗？你在 Spotify 上听的歌若是直接分享给使用网易云音乐的对方，恐怕也是不行的吧？如果是国内的流媒体，分享时还会生成链接卡片指向难用的微信小程序或者无法直接跳转的网页，这真的比直接分享歌名和歌手名字更好吗？
+
+另外，我说过一首歌的大小比很多人做的 PPT 还小，所以…… 为什么不直接发音频文件给对方呢？
+
+至于歌单（或者说播放列表），这的确是个问题，分享歌单没有那么容易。本地播放器大部分都是以专辑为单位管理音乐的，但有一些也支持创建歌单，只不过不能像流媒体那样方便地分享出去。所以…… 为什么不打包成 ZIP 文件发给…… 算了，还是不太现实。不过歌单这个东西，尽管有第三方的同步工具，但仍然是锁死在平台上的，留在流媒体上也没有让分享很方便，除非你和朋友在同一个平台上。
+
+我想或许可以开发一套开放协议，用歌曲元信息组成歌曲列表，以开放格式（比如 JSON）存储歌单信息，让播放器读取。
+
+很主观的建议：忘掉歌单，听一张完整的专辑吧。
+
 [^1]: 参见：[FLAC - 维基百科](https://zh.wikipedia.org/zh-cn/FLAC#:~:text=%E8%87%AA%E7%94%B1%E6%8C%87%E7%9A%84%E6%98%AF%E8%BF%99%E4%B8%AA%E9%9F%B3%E9%A2%91%E6%A0%BC%E5%BC%8F%E5%8F%AF%E4%BB%A5%E5%9C%A8%E4%B8%8D%E9%9C%80%E4%BA%8B%E5%85%88%E8%AE%B8%E5%8F%AF%E7%9A%84%E6%83%85%E5%86%B5%E4%B8%8B%E4%BD%BF%E7%94%A8%EF%BC%88xiph.org%E4%BF%9D%E7%95%99%E4%BA%86%E5%88%B6%E5%AE%9AFLAC%E8%A7%84%E6%A0%BC%E5%8F%8A%E8%AE%A4%E8%AF%81%E5%85%BC%E5%AE%B9%E8%A7%84%E6%A0%BC%E7%9A%84%E6%9D%83%E5%88%A9%EF%BC%89)
 
 [^2]: 参见：[Audio file format - Wikipedia](https://en.wikipedia.org/wiki/Audio_file_format#List_of_formats)
@@ -285,3 +350,9 @@ Soulseek 还有一个更现代的客户端，叫作 [Nicotine+](https://nicotine
 
 [^11]: 不过，如果你想的话，可以去他们的 [Matrix 群组](https://matrix.to/#/#annas:archivecommunication.org)上找人要 BitTorrent 链接。但那是一整个 Spotify 上的音乐，除非是想要帮忙备份，就算了。
 
+
+[^12]: 这个命名方式也太 Genius 了……
+
+[^13]: 参见：[iOS 26 中的 Apple Music 更新](https://artists.apple.com/zh-cn/support/5550-ios-26-whats-new)
+
+[^14]: Network Attached Storage，网络附接存储，一般放在家里当作私人网盘。