什么？还有人在用 iTunes？
一直以来，iTunes 似乎都扮演着一个滑稽又可恨的角色——体积臃肿、逻辑诡异、性能糟糕，但广大 iOS 用户又不得不使用它来进行一些必要的操作。在 macOS 更新到 Catalina 之后，你终于可以在 Finder 内更加直接、快捷地管理 iOS 设备了。被拆分和「遗弃」的 Music.app 则在国内网易云、虾米等流播音乐平台的映衬下显得几乎没有存在的价值。
但对于像我一样下载和囤积了大量音乐档案的乐迷来说，Music.app（或者 iTunes，下文统一用 Music.app 代称）仍是管理本地曲库的最佳工具之一。作为一个用 iTunes 管理音乐的多年老用户，我最近刚好遇到了一个从 iTunes 到 Music.app 转移过程中因为数据结构变化而导致的小 bug，我也借此机会重新梳理了自己使用 Music.app 加 Google Drive 管理个人曲库的思路，并通过本文分享给你。
认识 Music.app 的数据储存结构
随着音乐收藏的量的逐渐增大，我的硬盘开始逐渐吃紧了起来。如上文所说，我目前的音乐收藏总共有 260G 左右，而且还在不断增加，而我的主要设备 MacBook 却只有 512GB 的硬盘容量。有一段时间里，我的电脑一半的容量都被音乐塞满，导致我需要经常清理各种缓存和其他内容，非常难受。
我想过将一部音乐文件收藏放在移动硬盘里，但是这个方案有很大的缺点——首先，Music.app 本身对于非本地的资料库的支持相当不好，如果将资料库放在移动硬盘中，在硬盘离线时打开 iTunes 会直接显示找不到文件；此外，对于每个资料库只能设置一个媒体文件夹，因此如果只想将一部分音乐放在外置存储设备中，那我将不得不把自己的资料库拆成两份，操作起来非常麻烦。
因此，合适的方法似乎就只剩下了一种——
将文件放到云端；
让 Music.app 以为文件在本地。
在讲云端化方案之前，我们需要先熟悉一下 Music.app 的存储机制。一个 Music.app 资料库的结构非常简单，分为两个部分——资料库文件和媒体文件夹。
文件结构对比
这两个部分（默认都是在你的用户文件夹下的 Music 文件夹中）是可以分别单独指定位置，互不干涉的。资料库文件通常是一个几 MB 左右的单文件（即图中的 .itl 或 . musiclibrary 文件），记录了你的资料库中所有内容的元信息，包括每一个音频文件存储的位置、关联的专辑封面等等，当然还有最重要的，媒体文件夹的位置。这个文件可以任意移动，无论你把它放到哪里，只要用 Music.app 打开它，程序就会自动加载它所关联的媒体文件夹。
媒体文件夹的位置可以方便地通过设置中的 Files 选项卡来指定，如果你想充分利用 Music.app 自动整理你的音频文件，记得将「Keep Music Media folder organised」和「Copy files to Music Media folder when adding to library」两个选项都勾上，这样 Music.app 就会自动将你的所有新添加的文件都储存在媒体文件夹中，并且根据 ID3 来命名。
搭建你的个人音乐流播服务
在早一些的时候，我无意中发现了 Google Drive File Stream（以下简称 GDFS）这个神器。GDFS 是 Google 针对团队版 Google Drive 推出的一款本地同步程序。Google Drive 个人版的同步程序 Backup & Sync 只能指定一个同步文件夹，但 GDFS 可以将你的整个 Google Drive 作为一个远程硬盘挂在在你的文件系统上，且不直接占用你的本地硬盘，只有在你实际使用某个文件时才会将文件缓存到本地。
这对于 Music.app 来说简直完美——只要你将媒体文件夹放到 Google Drive 中并联网挂载，Music.app 就会把你放在云盘里的音乐文件像本地文件一样顺利识别和加载，当你播放的时候，GDFS 会实时将你播放的文件实时加载到本地，达成类似在线流播的效果。经过我的测试，家庭宽带的速度足以让你流畅地在线播放 16bit / 44.1kHz 的 Apple Lossless 格式无损音频，速度和表现都非常理想。
至于资料库文件，因为它的大小实际上只有几个 MB，而且也只是一个单个的文件，为了让它可以在本地尽可能稳定的访问，我把它仍然放在了本地的个人文件夹中。
挂载在本地的 Google Drive
不过，目前 GDFS 只对团队版的 Google Drive 开放，而团队版需要通过 G-Suite 服务才能开启。但有许多类似的工具可以达成类似的效果，例如少数派也 介绍过的 CloudMounter，或者 Rclone 等，都可以将各大主流网盘作为硬盘挂载到本地，进而达到和上文同样的效果。
脱离桌面客户端，在手机上也能在线听音乐
说了这么多，但 Music.app 终究只是一个桌面软件，而今天谁都有在移动设备上听音乐的需求。既然所有的音乐都已经在 Google Drive 上，那么直接从云盘上读取音乐就是一个非常自然的选择了。
目前，手机上已经拥有众多基于各大云盘的音乐播放器，例如 CloudBeats 或者 ?GoPlayer 等，可以直接扫描云盘上的音频文件播放。这些 app 都可以扫描你云盘中的指定目录，自动读取艺人、专辑等音乐元数据。配合你在 Music.app 里已经整理好的曲库，你就能在手机上流播自己收藏的音乐了。
我自己购买了 VOX 的订阅服务，VOX 是一个知名音乐播放器，同时提供了无限容量的音乐私有云，并配有支持 iOS、macOS 和 Sonos 音箱的流播客户端。我在 Music.app 中的所有音乐都会同步上传 VOX（你可以设置自动上传文件夹，VOX 开启时如果文件夹中有新的文件加入，就会自动上传），因此在移动设备上，直接打开 VOX 就可以收听了。
在流媒体服务盛行的今天，在线播放本地曲库已经不是大众需求，但希望我的思路可以多少给你一些启发。如果你是命令行的重度用户，可以考虑安装 ncmpcpp，这是一款极为强大的 mpd 客户端，可以根据你的需要扫描、管理和编辑音乐文件和元数据，并且提供了（对于命令行来说）简洁方便的介面；如果你是高端的 hi-fi 玩家，你可以考虑 Roon Labs，它可以架设在家庭 NAS 或者服务器上，并提供全平台的无损播放器客户端，还整合了 Tidal 的服务；如果你除了音乐，还想在搭建电影、照片等全方位的云端媒体库，Plex 提供了全流程的解决方案。
拓展阅读：为什么你依然需要 Music.app
在本文的最后一个部分，我想回到文章的起点，和你探讨这个问题：在今天使用 Music.app 仍然有意义吗？
现在的音乐市场中，流播平台占据了绝对的主流，国内如网易云、虾米、QQ 音乐，国际如 Spotify、Apple Music，乃至主打音质的 Tidal 等，从免费到付费方案层出不穷，几乎覆盖了大多数人对于音乐的所有想象。但是对于一个走得足够远的音乐爱好者来说，流播平台的缺陷也是显而易见的：
没有一个平台可以拥有所有的版权。版权之争是目前的流播平台之间最大的竞争之一，各大平台都视优质的独家资源为自身吸引用户的一大优势。然而对于用户来说，甲之独家也就意味着乙之空缺，如果你想仅靠流播来听全所有的独家内容，那只能选择注册（甚至花钱订阅）多个平台了；
线上平台与用户之间的关系使用永远是租用而不是贩售。所有平台都保留着删除平台上的音乐的权力，而这至少在目前，并不会为我们付了多少钱订阅他们的服务而转移，中国大陆的音乐爱好者对此应该有着尤其深刻的感受。而传统的音乐贩售模式，传统的黑胶、CD、磁带，哪怕是数字文件，只要你付钱购买，音乐就是你的了。只要你妥善保存相应的介质，你就可以永久而几乎无限制地使用你的音乐。
有许多音乐是没有公开发行的数字版的。这些音乐世界角落般的存在包括一些因为版权或者不够出名而从来没有进行数字化的古旧唱片、音乐现场的 bootleg 录音、甚或你自己录制的作品。讽刺的是，可能是因为流播平台的用户体验太过方便，如今的用户对于音乐文件的熟悉程度似乎比过去的用户还要退化了——在过去，拿到一个 .mp3 文件之后将它放入音乐播放软件打开收听是一件非常自然的事情，而今天如果你在微信上突然收到一个音频文件，我相信不少人的脑子里会闪过这样的困惑——我要怎么听它？要把它存到哪去？直接在微信里打开很麻烦，也没法继续保存，而多数人的手机里现在可能也很少特地去安装一个用来播放本地音乐的 app 了。那么，对于这些音乐来说，一个本地的音乐管理——至少是播放——软件，就几乎是不可或缺的了。
就我个人而言，上面几点对于我的聆听过程来说相当重要，而相反，流播平台的大多数优势，例如便捷地听到最新的音乐、可以搜索各平台的音乐内容、社交分享等，都是或多或少可以妥协的（况且，这也不妨碍我在手机里装上各大流播平台 app 按需取用，不是么）。因此，为了满足这些需求，我需要的本地音乐管理软件应该具有这些特性：
具有清晰透明的文件管理结构。无论是 CD 抓轨还是购买 / 下载的数字音频文件，它最初出现在我们手上时都是以单个的文件的形式，而用文件系统管理的形式——例如一张专辑一个文件夹——也是最可靠、最安全、最传统的。因此，我希望音乐管理软件在我导入音频文件之后，仍然可以维持一个人类可读的，即使脱离软件本身也可以使用的存储模式。很幸运的是，与苹果公司其他软件一贯的「将所有东西都藏在黑箱中」的作风不同，Music.app 的音频文件存储模式相当清晰。只要你在设置中勾选了「添加到资料库时将文件拷贝到音乐『媒体』文件夹」，你所有的音乐文件都会以专辑艺术家——专辑名——音乐文件的结构存储在 Music.app 的资料库中，即使不通过 Music.app，这个文件结构在 Finder 里也非常易读。相比之下，一些更加纯粹的播放软件，例如大名鼎鼎的 foobar2000，虽然也很优秀，但是在整理音乐方面，缺少了 Music 这种只要无脑导入，你的音乐文件就会被自动整理到一个固定的文件结构中的方便。
典型的 Music.app 文件结构
具有方便的 ID3 编辑功能。脱离了流播平台，ID3 就是你整理音乐时最好的朋友。在当下，几乎所有可以播放音频文件的软件都可以很好的识别 ID3 标签，但是由于音频文件的来源非常复杂——CD 抓轨、黑胶抓轨、Bandcamp 等数字音频商店购买、论坛下载等等，一个趁手的 ID3 编辑器是非常重要的。Music.app 的 ID3 编辑功能相当完整且方便，可以满足我的大部分需求。在一些比较复杂的情形下（例如对一些连曲目序号都没有的「裸」文件，或者需要从 discogs.com 等资料网站导入专辑信息），我会使用 Kid3 来初步生成 ID3 信息，再导入 Music.app。
Music.app 的 ID3 标签编辑窗口
有相对美观的图形介面。当你的专辑收藏达到几百张的时候，光凭脑子可能已经很难记住你拥有的所有音乐了。在这个时候，一个清晰美观的图形介面对你的收听和收藏的体验都会很有帮助。Music.app 的专辑浏览介面是经典的封面墙形式，并提供了完善的搜索功能。Music.app 提供两级的专辑排列，这对于大量专辑的排序非常有帮助，例如，我是采取以艺术家首字母作为一级排序，专辑发行日期作为二级排序的方式，这样我的列表中所有的专辑都是以每个艺术家从早到晚来排列的，浏览起来非常方便。
此外，Music.app 有一个特有的「Sorting」功能，对于乐迷来说相当方便，这个功能可以让你手动为曲目或者专辑设置一个排序用的别名，例如，在我的收藏中，Oiseaux-Tempête、Farewell Poetry、FOUDRE! 这几个乐队都是以艺术家 Frédéric D. Oberland 为主脑的乐队，因此我希望我可以在封面墙上看到他们排在一起，所以我在 Sorting 选项卡中把这几个乐队的专辑艺术家 - sort as 都设置成了 Frédéric D. Oberland，Music.app 在就会将它们都按照 F. D. O. 进行排序了。
Music.app 中的 sorting 设置
综合以上的几个原因，再加上我在自己的设备上并没有碰到过明显的性能问题（我有大约 1000 张左右的专辑，大部分是 Apple Lossless 无损格式，文件总量 260GB 左右，主要使用的设备有 MacBook Pro 13″ Early 2015 和 MacBook Pro 13″ 2020，这应该算是个不小的量了），Music.app 对于我来说就是一个相当完美的工具了。如果你和我有着相似的需求——有大量以音频文件形式存在的音乐、想要一个相对傻瓜的文件管理流程、需要方便的浏览和播放你的音乐收藏——那么 Music.app 绝对是一个免费又优秀的选择。
