精研物理 格物致知（一）

这几天赶一个项目，经理是一位80年代毕业大学生。听到这个单词就令人肃然起敬了。做一个语音压缩算法。前后过程如下：

先是，国庆的时候叫到公司，接下一个任务说用MELP算法做一个电话控件，以便放在网页上，据说该算法效率高，在语音压缩算法里算是很高的。我看着一大堆c语言的陌生代码，心里一百个不情愿。国庆节期间便没有动手。后来公司催，把代码走了一遍，发现压缩的过程最好能调用 windows 自带的acm中的算法，若要自己实现，会有很多不便。于是汇报说能不能考虑换用 gsm610 或者什么729、723之类的现成算法。经理当时答应了，后来觉得还是用 melp好。于是从头开始做dll，做vb的语音聊天控件。连续几天在c语言里折腾，进展缓慢，一度怀疑该算法的有效性。因为对音频处理没有了解，不清楚该怎么实验，也懒得实验。这样耗下来也算做完了。但到测试时问题变得十分棘手，发过去的包没法放。当时觉得无药可救了，反正用这个算法也不是我的主意。经理和另外一个做嵌入式的同事一块帮忙调，发现第一个包有用，后面的包无用。当时已是晚上12点了。我们一致推测是vb中使用多线程的问题。

第二天我把程序由消息方式改成循环方式，抄袭一个语音聊天的控件源码，进度很快。做完后问题如故。把经理请来一道分析，他估计是压缩解压函数的过程有问题。按照他的思路，把压缩和解压过程分别重复两次，果然是压缩函数有问题。细细推究，原来那个用c写的dll是我从exe改编的，该程序有些全局变量在呼叫后会变化，第二次再调用，结果就不同了。找到原因后，问题很快解决。

在设计中途曾有许多念头：
1.找一个效率更高的acm自带算法
2.找melp的acm codec
3.把dll改成acm codec
4.用delphi，以便使用多线程

第一点是对该算法的不信任，我并不觉得该算法多好，后来测试，用这个算法压一段音频，再还原，放出来很糟糕。后来经理说那段音频不是语音，我依然将信将疑。
第二则是嫌字符麻烦，起初验证时每次都要输入命令压缩音频，之后测试。c语言编写调试也很麻烦，不过回想起来，c语言的日志自己创建新文件fprintf，也就那么几行代码，是不是对.net的ide有了依赖心理。
第三是对c语言的不信任，感觉把exe改成dll多么隆重，颤巍巍的，觉得没把握。
第四是对问题原因不明的情况下，对vb不信任，以为是多线程的问题，而vb无法多线程，故有放弃的念头。

回想起来最关键的是对问题原因不明时的盲动。而正确的理性的处理应该是精研物理。
在知道要做语音处理时，至少应该先少少的看看语音处理的资料，而我完全是空手揖门；在做音频时，应该先看看录音放音的代码是怎么写的，为什么这么写，多了解相关资料，我却没有看这些资料，有点妄图暴力通过的味道；在消息方式出现故障，发现仅仅第一个包有用时，觉得匪夷所思，判断为应该用多线程，属于显然的误判，因为当时也想到，即使是阻塞了，第二个包错过了，第三个第四个也该有效才对，但我没有相信这种理性的显然的判断，坚持误以为是vb的问题。这就像刚刚学c语言的人，偶尔出错后会以为是c语言的问题，宁愿相信自己遇到了自开天辟地以来，违反因果律的第一件事，也不愿循究其理，追本溯源。