如何用 iTunes 管理大量零散歌曲？

01-15

已經比較習慣 iTunes 用 Library 的形式來管理歌曲和同步，但是個人聽 ACG 歌曲比較多，也經常從蝦米下載一些精選集，而這些都不是以專輯為單位的。因此每次添加到資料庫里的幾十首歌曲，往往屬於幾十首不同的專輯，並且 ID3 信息殘缺。請問在這種條件下，怎麼才能比較有效地管理這些歌曲？
個人目前使用的辦法是：將這些零散歌曲統一歸類到幾個自建的專輯，如「ACG」「J-POP」等下，暫時解決了專輯過多的問題，但是這樣一則工作量大，二則在歌曲更多的時候仍會顯得凌亂。不知道有沒有什麼更好的解決方案？謝謝。

如圖，選中的那些專輯是我自建的。
但是歌曲積累多了，仍會顯得凌亂。

零散歌曲何必管他，原本是什麼專輯就分開處理唄，管理的時候用列表管理

首先，幾乎可以肯定地說，一首ACG歌曲，必然屬於某個專輯，或者是廠商發行的CD，或者是翻唱者的個人專輯，前者肯定有完善的ID3信息，後者一般出於推廣個人、聲明版權的心思，也會有自填的ID3信息。

所以從執行上來說就好辦了，要麼下整張專輯抓軌導入，要麼去翻唱者的個人主頁下載。

以上是針對你的初衷的建議。

對於問題本身，如何用 iTunes 管理（ID3信息殘缺的）大量零散歌曲，答案是只能手工編輯添加修改各個歌曲的ID3信息。而信息來源也只能是自己去找。

像你這樣總是添加來自不同專輯不同作者的很多個歌曲的話，修改就必然是很勞累的，如果你一直保持這樣的習慣，除了到iTunes Store購買正版，別無他法，因為ID3問題本質上是盜版問題。

以上是全部回答。以下介紹一下個人經驗。

---------------------------------------分割線-----------米飯----------配菜---------咖喱---------棉花糖--------------------

首先介紹一下我在數年的使用過程中感受到的一些iTunes的基本理念，我也是在使用過程中逐漸真正的理解和感受到它們的。

一般常說的，正是iTunes的媒體庫理念，這個理念貫穿始終。我因為個人比較懶的原因，沒有主動去探索功能，只是在隨著使用的需要去試圖解決問題，在這個過程中逐漸認識了iTunes的一些特性。

庫理念，是iTunes的核心理念。這個核心理念，體現在、貫穿在iTunes的方方面面，讓我們一點一點說。

首先看一下我的資料庫和播放列表：

如圖所示，我有近千首歌，還有十幾個播放列表，其中大部分是導入的整軌專輯。

嗯，Falcom控和k-on控外加Vocaloid控暴露了，@大果。

這些大部分播放列表都是用WinMount掛載整軌導入的，問題遇到的很少。但是有個播放列表叫做old memory，它是我把以前用酷狗音樂和99塊錢的MP3加10元的耳塞時代的歌曲文件夾里的音樂都一股腦複製過來的產物，那個時候我還頗有潔癖，每次手動下歌后都會手動用Windows的資源管理器一個個把ID3信息全清掉。。。。那時候歌少，根本沒有管理的意識，根本不懂ID3是什麼。這就給我後來帶來了不少的麻煩。

雖然說它現在看起來很好，是這樣的：

但是你要相信，之前他們全都是空白的。不論是表演者還是專輯，那些都是我前幾天花了一個下午加一個晚上的時間自己一首首搜索填上去的。

很遺憾的說，大部分的歌，都只能這樣解決。

但是這樣還有一個坑爹之處就是，有些時候你在iTunes裡面改了，實際文件里的ID3信息不會被更改。iTunes自己創建的Apple Lossless文件和AAC文件是不會出現這樣的問題的，坑爹的是一些MP3文件會有這樣的問題，這樣的話，如果你的iTunes出了問題，那你之前所做的一切努力就都白費了。要解決這個問題，其實只需要將歌曲的ID3標記轉換為V2.3版就可以了，在iTunes中全選，「轉換ID3標記」，就可以了。但在發現這個之前，我被這個困擾了很長時間。

我現在整個iTunes資料庫裡面沒有ID3信息的歌曲極少，就只有不到10首而已，都是實在查不到資料的。

痛苦的修改好之後（還包括組織播放列表，導入CD什麼的），整個iTunes資料庫就成型了，可以同步到各種設備上去聽歌了。但是還要防止有什麼意外事情發生導致前功盡棄，比如iTunes崩潰，系統要重裝什麼的，上面的修改包括未寫入文件的ID3信息，播放列表信息等等就都沒有了，所以要先備份。

整個iTunes資料庫包括三個部分：播放列表信息，每首歌曲的實際文件位置信息，每首歌曲的ID3信息。這三者都可以通過「導出資料庫」獲得一個xml文件。而每首歌曲的ID3信息也已經在備份文件里了嘛，這個待會會用到。（xml文件也包含ID3信息，當它與歌曲本身的ID3相衝突時會怎麼樣，我還沒有探究過。）

xml文件里一個典型項是這樣的：

如圖，那個至關重要的實際路徑，是URL Encode後的一串UTF-8編碼，所以這又就牽扯到兼容性的問題了。先看一下具體的物理地址：

iTunes里有個有意思的設置在這裡：

就是兩個複選框中上面那一個，選中後，資料庫文件夾裡面就會變成這樣：

再細化一下是這樣：

再下一個層級就最細了，是這樣：

以上3圖，就是一個良好的資料庫應該有的樣子，到歌曲的典型路徑是music演唱者專輯名稱歌曲文件名。

如果你比較懶的話，那你幾乎所有的歌都會在這裡：

嗯，這就是我努力的成果啊！！！哦對了，那個《囚歌》是我自己朗誦的語音備忘錄。

對比一下那個xml裡面的地址和實際地址，我們通常只需要複製iTunes這個文件夾（裡面包含了Music文件夾那個放音樂的地方），還有xml文件，然後在丟失了資料庫的iTunes上「導入播放列表」，選擇備份的xml文件，就可以了。

比較有趣的是，那個實際地址，是會動態變化的，無論你是在iTunes中修改了ID3信息，還是自己用了Windows資源管理器的屬性來修改，歌曲文件都會被iTunes瞬間移到新的 music演唱者專輯名稱歌曲文件名這個路徑裡面去，不過就是不同的ID3編輯器之間有時候會不太兼容就是了。

但是如果你思維飄逸聯想了一下然後直接修改了某個文件夾的名字以為這樣就能讓iTunes把一堆歌的歌手/專輯信息更改的話，那就錯了，iTunes會提示你有些文件找不到了。

我在這種反覆試錯過程中認識到的是：這就是庫的理念的體現，使用文件的元數據來管理文件，路徑什麼的都不重要。

從邏輯關係上來說，你看到的是歌曲文件在路徑裡面，以為路徑反映了信息（表演者和專輯），決定了信息，但實際上卻是歌曲文件的元數據信息決定了這個路徑，路徑只是暫時的，可以隨時改變，甚至有些庫中根本就沒有路徑。這個和Windows下人們整理文件的思路是徹底相反的。但是仔細一想，後者顯然更具靈活性，擁有了精確到文件的元數據，可以隨意的生成各種路徑。就像foobar2000里轉格式的時候，想輸出成怎樣的路徑和文件名都可以。

和此配合的是不被人注意的「自動添加到 iTunes」這個文件夾，這就是iTunes為了方便用戶而推出的功能，平時下個什麼的文件夾都設成它，就自動添加到iTunes了。把歌曲或者歌曲文件夾拖進去，拖歌曲自不用說，不管你拖進去的文件夾層級多麼複雜，iTunes都只是去看文件本身，根據其ID3信息在Music文件夾下創建相應的路徑，把原有的文件夾層級全部拋棄掉。（然後再手動改ID3）

而在管理軟體iTunes中，一切都是根據元數據來管理的。所以，對於沒有ID3信息的歌曲，不管之前用文件夾分的怎麼好，轉移到iTunes上都是一場災難。但是對於有數千首音樂並且必然會不斷增長的用戶來說，學習使用ID3和iTunes是一個必然。

--------------------談一下心血來潮的一點暢想-------------------------------------

要是有軟體能夠根據路徑向文件中寫入ID3信息，那就好了，也不難吧？

忘了說之前那個xml里的URL Encode造成的兼容性問題了，之前我曾經把iTunes文件夾整個備份到115網盤，結果下來直接不能用了，自已看了一下，推測是115網盤轉了文件名的字元編碼，造成跟Decode的結果對不上了。這時把整個music下所有文件剪切到「自動添加到 iTunes」就好了，iTunes會自動生成路徑的，當然你的ID3信息要能對的上號，要不然還是會跟xml里的有偏差。