Madlib及其之外

從開始寫Madlib源碼分析時算起到現在，差不多有半年了。Madlib系列一直斷斷續續，至今沒有完結。自知虧欠很多，只得在閒暇的時間彌補這半年的心不在焉。對Madlib的源碼分析裏還有N多沒有涉及到的東西尤其是Mp3解碼算法核心的東西，實在由於本人水平有限不能在文中給出解釋。今天得以閒下來，對我這半年來的經歷和收穫做一總結，有關於Madlib的，也有一些關於FML的牢騷話，只能請列位看官笑納了。
Madlib其名
每當我向人介紹Mad的時候最常說的一句話就是“Mad是MPEG Audio Decoder的縮寫......”。當我第一次看到Mad這個名字的時候的深感作者的玩世不恭和那深入到骨子裏的程序員精神。毫無疑問Mad的代碼是很優秀的，優秀到沒有一點冗餘沒有一點繁複，處處顯示着作者紮實深厚的功底與桀驁不馴的態度，極少量的註釋仿若在說“這裏很簡單，沒必要說明你們（使用者）就應該能看明白....”。
有一部電影叫《Mad money》，如果你有興趣的話大可以找找看。Money對所有人來說都是一個尷尬的話題，再超凡脫俗的人遇到經濟上的困窘都很難再保持浪漫與風度，戛然蒸發出一股銅臭味。影片用一種現實又夢幻的方式解決了經濟的緊迫，儘管不太正當——從美聯儲待銷燬的紙幣裏盜取現金，以維持着生活的光鮮。很難說電影表現的主題是正義的，但涉及到Money的問題時就一定是現實的。與其說現實讓人們變得瘋狂，不如說人們用瘋狂對待現實。
歸根結底，Mad是一個library，爲了遷就Linux的命名習慣和通過前綴找library的規則，Mad有時被稱爲libmad。Linux下的libmad.so還是Win下的libmad.lib，都是編譯之後的產物，但他們終究還是Mad.h和Mad.cpp的結合，之後Mad.h還是要被include進代碼，而Mad.cpp變成了libmad.xxx。所以我習慣叫Mad爲Madlib，Mad代表Mad.h和Mad.cpp，這是它本來的名字；lib代表各平臺的編譯產物。
Mad其物
全然使用簡潔明瞭的C語言，卻用OO的思想管理解碼過程和全部資源。我曾經多次有過使用我更熟悉的C++重新包裝Mad的不切實際的想法，不是說不可行，而是不可避免地要涉及到與編譯器的相關性，不得不處理繁多的C++編譯器對成員函數地址和Vtable的處理策略差異。最後獲得的無非是一堆的#if...#endif亦或是無數的Link error。然而現在的Mad不是完美的，它開放了太多的接口，傳遞了太多的參數，對文件內存映像和播放緩衝的管理是開放式的。這無疑增加了許多潛在的風險，同時使得我們可以最大化地控制解碼過程。
依然記得第一次聽到Mad播放出斷斷續續音樂時激動的心情——因爲雙緩衝的配合銜接處理得不好，5分鐘的歌曲播了將近7分鐘，但我還是耐心地甚至陶醉地聽完，彷彿看到了數據一個比特一個比特地流進解碼器，流出到聲卡音箱。然而短暫的成就感過後又是無盡的思考與煎熬，播放有輕微雜音，高音表現欠佳，最重要的是一個Mp3播放器產品不可能只帶有一個命令行界面。這些問題都不是Mad本身可以解決的，Mad並不等於一個完整的播放器，Mad是一個核心，圍繞這個核心有太多的東西等待我去探索。
Madplay
在研究Mad的過程中，Madplay這個優秀的播放器軟件給了我很大幫助，可以說Madplay是完全繼承Mad衣鉢的，擁有和Mad同樣優秀的特質——代碼簡潔明瞭，功能豐富，最重要的是平臺無關。核心代碼與平臺相關的外圍代碼隔離得很好同時也結合得很緊密，是入門研究音頻解碼的首選。如果你急需在Linux平臺上擁有一款Mp3播放器，Madplay也可以滿足大部分要求——挺比Mad離播放器更近一步。它的編譯也不像Madlib那麼簡單方便，依賴的庫也很多很繁瑣。我的Fedora 10在yum了realplayer之後就在沒用過Madplay播放過。