Google Music編碼探究

拿到Google Music Beta資格已經好段時間,但因為自己音樂庫的整理不甚完善,所以一直沒有真正拿來使用。最近意外看到一些網站有提到相關研究,覺得結果實在太詭異(說Google會以GBK編碼為中心打入地方市場?…),因此做了一些實驗並記錄。
簡單來說,我使用了MP3Tag這個工具做為基準輔助,研究了一下甚麼樣的編碼餵給Music Manager(Windows版)會讓網頁上的資訊正確。

結論是: 用 “ID3v2.4 UTF8″ 就對啦!

基本上我做法是隨機挑出一些不同時期的檔案(個人在不同時期間的policy和工具不盡相同…這時候倒剛好變成了多樣化的樣品庫呢…)

用MP3Tag看失敗(亂碼)跟正確檔案的差別性(括號內表示檔案有哪些tag 最前面應該是代表MP3Tag以哪個tag為基準):
失敗:
APEv2 (ID3v1 ID3v2.3 APEv2)
APEv2 (ID3v1 APEv2)
成功:
APEv2 (ID3v1 ID3v2.4 APEv2)
ID3v2.4 (ID3v2.4)
ID3v2.4 (ID3v1 ID3v2.4)
因此得到這個結論。

後來為了確切求證,進行實驗如下:
對於上傳亂碼的檔案,我用MP3Tag分別進行了寫入APEv2和寫入ID3v2.4 UTF8 tag的實驗。
(ID3v1個人覺得沒救了,不予理會。對於ID3v1我個人的預定用途是保存Unicode-At-On時代的資料以供日後參照用)

準備被處理的檔案都要在媒體庫資料夾以外的地方進行處理,詳情後述。
檔案處理(用MP3Tag寫入tag)後將原先的項目刪除,包括媒體庫(網頁上)和媒體庫資料夾(Music Manager監控的資料夾)。再將處理完畢的檔案移入媒體庫資料夾讓Music Manager重新上傳後就大功告成。
這樣實驗完成的結果發現,寫入APEv2並沒有幫助,但補寫入ID3v2.4 UTF8的檔案資訊確實順利被Google Music正確解讀了。
大功告成。

上面提到處理要另尋地點的原因,主要是因為測試中偷懶的狀況曾經發生過一些問題。
為了掌握測試狀況,我是使用手動上傳,第一次存ID3v2.4 UTF8後上傳上去亂碼大驚,但第二次存後上傳卻又好了。
頻繁重試幾次抓不太到問題點,最後把其中一個上傳有問題的檔案(在媒體櫃資料夾中加了ID3v2.4 UTF8後我就按上傳了,結果發現亂碼)COPY出資料夾,清除所有記錄(包括網頁上跟媒體櫃資料夾中的檔案),再放回媒體櫃資料夾中給Music Manager上傳,網頁上看到的資料就是正確的了!
因此猜測Music Manager有某種Cache機制,為求保險還是讓他直接看到處理完的檔案穩。不然處理過的資料卻沒被傳上去就哭了~~

最後,有遇到一首歌資訊幾乎都對,但唯獨AlbumArtist掛點。可能要再確認是因為這個欄位沒被Music Manager用一樣方式吃下去,或者是MP3Tag沒處理到,或者是其他問題。

以上。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: