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播放过。