CDDB

CDDB的作用包括，但是不限於：

方便網路音樂共享，甚至可以說CDDB是隨著網上音樂共享而發展起來的。想象一下，如果人人都去買CD來聽，CD封面上自然印刷有CD的全部信息（請不要用無良D商出的東西來反駁我的觀點！），還有必要上網查詢嗎？但是網路共享音樂就不同了，不論通過P2P、FTP還是其它協議下載到一張CD的鏡像，如果共享者即忘記掃描CD封面，又忘記把CD信息敲進一個文本文件里和鏡像文件一起共享，您會不會有點找不著北的感覺？這個時候有點動手精神的人，自然就會想到上網搜一下。

方便CD播放。在用電腦上的軟體播放CD時，有些人並不僅僅是聽聽音樂就算，還希望在聽的同時能夠看到每一條音軌的標題。foobar、Windows Media Player、Real Player等軟體在播放CD時，都可以通過在線查詢CDDB顯示CD信息。

方便MP3、WMA等音樂文件的製作、播放。抓軌以後的文件名如果都是Track01、Track02之類的無聊東西，多了以後恐怕管理就會有麻煩，所以EAC在抓軌的時候就會從CDDB查詢CD信息，然後自動生成有意義的文件名，看著都爽。foobar也可以將從CDDB查詢到的信息寫入MP3，這樣單獨播放MP3文件時，在MP3播放器（不論硬體還是軟體，支持ID3v1/2格式的MP3 tag就行）上就可以顯示出音樂標題、專輯名稱、演唱者等信息。

我寫這篇文章的目的，當然不可能是希望促進音樂D版事業的發展，只是希望通過對常見CDDB的介紹，讓大家對它們的特點及查詢方法有所了解，在需要的時候能夠及時從CDDB獲取有用的信息，當然這些信息必須也只能用於合法的目的。

1、freedb

中文支持：很爛

著名用戶：EAC（Exact Audio Copy），foobar

freedb是一個非盈利性組織，該組織維護freedb網站及其CD資料庫，供大家免費查詢CD信息。如果您發現freedb的CD資料庫里沒有的CD，也可以手工輸入信息提交給freedb，充實它的資料庫，體現“人人為我，我為人人”的原則。

freedb不僅可以免費查詢，而且它的所有查詢協議都是公開的，在其網站上有詳細的說明，因此使用freedb的免費軟體很多，包括EAC、foobar在內的一些軟體都用它查詢CD信息，所以人氣較旺。

除了協議公開外，freedb甚至連資料庫內容都公開了：從這裡可以免費下載到freedb的完整資料庫供離線查詢使用。這種事情大概只有以free開頭的網站才會做，.com網站是做不出來的。

不過freedb這種完全靠音樂愛好者提交信息的運行模式也給它的內容帶來了一些限制。從我自己使用的情況看，freedb查詢國外版權的CD（包括國內從國外引進版權的CD）基本上問題不大，但是國內版權的基本上就沒有了，可能和國內音樂愛好者較少向freedb提供信息有關。

另外我對它的中文支持評價為“很爛”，是指：

在它的查詢頁面上，如果直接輸入中文作為關鍵字，什麼也查不到。

從它提供的開發文檔看，從CDDB Protocol Level 6開始支持UTF-8編碼，但是目前大多數軟體都採用CDDB Protocol Level 6以前版本的協議，所以目前支持中文關鍵字查詢freedb的軟體還沒看到。

如果按照CDID（從CD各音軌起始位置、長度計算出來的CD標識，相當於CD的“指紋”，在CDDB里通常用來標識每張CD）查詢，可以查詢出freedb里有的中文CD信息，但是由於計算CDID需要讀取光碟，因此這個只能在軟體里實現（如foobar等），在查詢網頁上很難做到。

2、Gracenote

中文支持：很好

著名用戶：Real Player

Gracenote這個名字對某些人來說可能有點陌生，但是它的前身cddb卻是大名鼎鼎，號稱網上最早、最大、最全的CDDB。不過cddb代表的是充滿理想的免費共享主義時代，現在已經改成商業化運營模式的.com，所以乾脆連名字都改成專有的了。

如果想在軟體中集成查詢Gracenote的CDDB功能，必須取得Gracenote的許可。免費許可比較難申請，至少我的申請就沒有得到回應，所以Gracenote在免費軟體中很少見，多用於商業軟體，如Real Player。

Gracenote對中文的支持很好：

通過網頁查詢時，不僅支持中文關鍵字，而且輸入簡體關鍵字，連繁體CD信息都能查出來。

在通過Gracenote提供的控制項編程查詢某些歐洲發行的CD信息時，如果遇到特殊西歐字元，Gracenote會自動轉換成帶聲調的漢語拼音字元，方便在中文環境下顯示。這個功能似乎是Gracenote獨有，在其它地方我還沒有見過。後來俺在寫解決CUE文件亂碼的軟體CueCode時，把這招學了過來，嘿嘿……

從我個人使用的情況看，Gracenote的數據量無疑超過freedb，和微軟的CDDB相比則各有千秋：國外的CD可能兩個都差不多，國內的有時Gracenote查得出，微軟查不出，有時則相反。

3、微軟CDDB

官方網站：據說正在建設中，尚未正式公布

查詢頁面：未正式公布，下面URL是我從Windows Media Player里抓出來的，有效期不敢保證：

中文支持：很好

著名用戶：Windows Media Player

這個是微軟自己的CD資料庫，Windows Media Player就是從這上面查找CD信息的。有錢人做事畢竟不同，感覺微軟的資料庫比freedb全多了，而且時常可以查到CD的封面圖片，估計是直接從CD廠商獲取的數據。不過到目前為止，微軟尚未公布CD查詢的介面規範，也沒有說是否允許免費使用，因此除了微軟自己的Windows Media Player外，還沒有見過哪個公開發表的軟體使用這個CDDB。

在中文支持方面，微軟的CDDB也不錯：

通過網頁查詢時，不僅支持中文關鍵字，連頁面都是中文的，這點比Gracenote強。

偶爾能查到中文CD的封面。

上面說的都是直接通過IE查詢，但是有些查詢是不能通過IE進行的，只能按照CDDB的查詢協議開發專門的查詢軟體。下面討論的就是這方面的技術，僅供有興趣的人參考。

1、查詢過程

通常通過網頁查詢CDDB，都是先輸入某些關鍵字，如歌曲或專輯名稱、歌手或樂隊名稱等，然後點“查詢”，等待進入查詢結果頁面后，再點擊列出的專輯名稱，查看專輯內容。

在編程實現CD查詢時，按照上述關鍵字進行查詢只是部分情況，大多數軟體是按照光碟本身的信息進行查詢，如EAC、foobar、Real Player、Windows Media Player，都是在用戶將CD插入光碟機后，自動讀取光碟信息，組合成CDID，然後提交給CDDB進行查詢，很少有需要用戶自己輸入關鍵字的時候。

對於freedb和Gracenote來說，由於CD專輯信息都是網友自己上傳的（Gracenote商業化運作后可能直接從CD出版商獲取數據，但是免費時代的底子應該還有保留），難免會出現重複，並且CDID演演算法本身也可能產生碰撞，因此在freedb和Gracenote的開發文檔中，都要求開發者必須處理“模糊（fuzzy）”——其實就是重複的查詢結果。通常的處理方式就是象EAC一樣，彈出一個列表讓用戶自己選。查詢freedb的軟體可能要自己寫這段代碼，Gracenote提供的控制項本身就包含了對重複結果的選擇界面。

對於微軟CDDB來說，我還沒有發現過有重複的現象。可能是因為微軟直接從原始CD出版商那裡拿數據，CDID演演算法也比較嚴格，所以查詢結果比較精確吧，Maybe……

2、TOC和CDID

前面說過，按照CD本身的信息查詢CDDB，需要讀取光碟信息，產生一個CDID（CD 的唯一標識號），然後以此為關鍵字進行查詢。

在freedb的開發文檔中，CDID被稱為DISCID，在這裡有詳細的演演算法說明。在看過這個演演算法后，我又分析過Gracenote、微軟CDDB的CDID演演算法，發現他們的演演算法都差不多：

通過光碟機讀取CD的TOC（table of contents，目錄表），從中獲取CD的音軌數、每條音軌的長度、音軌起始時間。

循環TOC項，從音軌長度、起始時間運算出最終CDID。

雖然演演算法大同小異，但是計算出來的結果不太一樣：freedb的CDID只有32位，Gracenote、微軟CDDB的都長達128位！俺曾經懷疑這可能也是freedb的查詢結果重複率比較高、查詢結果不甚準確的原因之一，不過很難證實。另外從TOC映射到CDID明顯是一個不對稱hash過程，難免有碰撞，因此也就需要允許模糊查詢。

那麼如果手上沒有CD，只有從CD抓出來的APE和cue文件，能不能計算CDID並且據此查詢CDDB呢？

答案是：多數情況下可以，少數情況下不行。

原因就在於按照目前cue文件格式的規定，cue文件中缺少兩樣關鍵的東西：

第一條音軌的起始位置。在真正的CD中，第一條音軌不可能從00:00:00處開始，而在cue文件中（其實是在抓軌過程中），這些空白處都被跳過了，所以cue文件中第一條音軌永遠從00:00:00開始。

最後一條音軌的長度（精確到1/75秒）。其它音軌的長度都可以通過下一條音軌開始時間，減去本條音軌開始時間計算出來，最後一條音軌的長度就沒法這樣計算了。

第一個不足會影響CD刻錄，兩個不足合起來則會影響CDID的計算，從而影響CDDB查詢。

為了解決這個問題，通常的做法是：

假設第一條音軌從2秒開始。

從APE文件計算最後一條音軌長度。

在做出這兩個假設后，大多數情況下就能按照APE+cue從CDDB查詢到CD信息，畢竟就算有點走樣，還有模糊查詢在支撐，但是少數情況下還是會出問題：

雖然大多數CD的第一條音軌都是從2秒開始，但是並非所有CD都是如此，我手上有一張CD，就是第一軌的起始位置錯了1/75秒，在微軟的CDDB上就已經查不到了，但是手工輸入關鍵字查詢卻能查到。

從APE計算最後一條音軌時，如果APE已經分軌，甚至轉換成MP3又轉換回來，往往造成計算結果不準。比如我試了一下查詢10CD的“鄧麗君音樂手札”，沒有分軌、整張盤一個ape文件的查詢起來問題不大，除第9、10張外都查到了，而分軌的第1、3張就全查不到，估計是最後一軌的長度變了。

所以在能夠生成、識別cue文件的軟體全面改進以補全上面說的兩個信息之前，只能祈禱下載到的盤都是從2秒處開始，ape文件也是從真正的原盤，而不是轉換出來的刻錄盤上抓出來的（轉換刻盤可能改變最後一軌長度）。

這個問題也可以這樣描述：假設您買到一張CD，把CD插進光碟機后如果能用Windows Media Player直接查到它的信息，俺不敢肯定這張CD是不是D出來的；但是如果從光碟直接查查不到，但是在Windows Media Player里輸入專輯名稱、演奏者、歌曲名稱等等卻能查到這張CD，那麼俺敢和您打賭一分錢：這張CD十之八九是J商自己從APE，甚至MP3翻刻的。freedb、Gracenote由於有模糊查詢，不太精確的翻刻還有可能矇混過去，微軟CDDB則很難混過去。

關於cue文件的問題，我以前曾寫過一篇《cue文件的不足》，發布在伊美姬網怡紅快綠音樂論壇，不過似乎應者寥寥。

3、編程介面

freedb的查詢協議是完全公開的，相關技術文檔見這裡。已經有很多人按照協議寫過相關的查詢代碼了，有些還開源，可以直接拿來用。如俺寫FreeMP3Tag時，就用了PJ Naughter的MfcCDDB，不過對其中socket連接部分做了改進，以增加連接的成功率。

Gracenote的編程介面更簡單：到這裡申請一個Non-Commercial ID，即可下載一個ActiveX控制項，並且附帶各種開發語言的使用例子，將這個控制項嵌入您自己的運用，再仿照例子調用一下查詢介面就可以了。麻煩的是在開發完成後，如果要正式發行您開發出來的軟體，還需要另外再申請正式的發行ID。不知道別人有沒有申請到，反正我的申請是一直沒有迴音。

微軟的查詢介面一直沒有公開，所以也沒有什麼直接相關的文檔或代碼可供參考。不過對於任何一個能夠看懂HTML源代碼的人來說，只要看一下Windows Media Player和伺服器的交互過程，要猜出來也不是很難。

4、中文支持探討

如果按CDID查詢CD，當然不存在中文問題，因為CDID只是從TOC計算出來的一堆數字。但是按照關鍵字（專輯名稱、歌曲名稱、演奏者等）查詢時，如前所述，三個CDDB的支持程度有所不同。在這裡我想探討一下其原因。

我個人認為中文問題的核心是編碼問題：用戶輸入的中文關鍵字必須發送給CDDB伺服器，IE在發送中文關鍵字的時候，因為中文編碼的高位為1，因此必須先對中文進行編碼，伺服器收到查詢請求后，再對IE的編碼進行解碼。這樣一個編碼->解碼的過程，要求解碼器必須確切知道編碼器所使用的代碼頁。很不幸的是，freedb在這方面做得並不好，所以解碼后就全亂套了。舉個簡單的例子，用戶輸入“鄧麗君”，IE按照簡體中文編碼成UTF8發送出去，但是freedb伺服器在收到這個查詢請求后，並不知道這個UTF8字元串是從簡體中文編碼得來的，因此只能按照它自己設定的一個代碼頁進行解碼，比如說按日語進行解碼，解出來的還會是“鄧麗君”這三個字嗎？如果關鍵字錯誤，自然查詢不到。

下面是三個CDDB查詢“鄧麗君”的結果URL：

http://www.freedb.org/freedb_search.php?words=%26%2337011%3B%26%2320029%3B%26%2321531%3B&allfields=NO&fields=artist&fields=title&allcats=YES&grouping=none

http://www.gracenote.com/music/search-adv.html?q=&qartist=%E9%82%93%E4%B8%BD%E5%90%9B&qdisc=&qtrack=&n=10&x=49&y=15

http://metaservices.windowsmedia.com/CDWizard/CDWizard2.asp?WMPFriendly=true&locale=804&SearchType=Artist&SearchString=-28525,20029,21531&MODE=DISPLAYARTISTALBUMS&AlbumID=&ArtistID={B50F45AB-1870-480A-B1E6-6C626B98709B}&Version=1.0&sVolume=1&sCDTOC=

微軟SearchString中的內容是“鄧麗君”三個字的十進位unicode編碼，gracenote的qartist的內容為“鄧麗君”的3位元組UTF-8編碼，掩碼位為：

U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx

freedb的編碼就猜不出來了。

其實通過網頁查詢的時候，IE在發送給CDDB伺服器的http請求頭中都會包含下面這一行：Accept-Language: zh-cn

我猜微軟、gracenote就是據此判斷查詢請求來自簡體中文頁面，而freedb沒有做這個判斷。微軟在判斷出來后，乾脆把簡體中文的LCID（804）放到URL的locale欄位（簡體中文版Windows XP註冊表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language項下的Default值就是804）。