電腦音樂格式之爭——MIDI與Tracker（上）
這篇文章在今年三月份發表在Scali"s OpenBlog?上，由Gravis UltraSound音效卡展開，探討了MIDI和Tracker音樂的諸多異同，這篇文章基本上代表了當前Demoscene社區對Tracker和MIDI這兩種音樂格式的理解，正所謂「管中窺豹，可見一斑」，希望這篇文章能夠給中文社區的讀者帶來一些有價值的啟發。
原文：Trackers vs MIDI
最近一段時間，我正忙著折騰一些音頻設備和聲音程序，在折騰的過程中，我接觸到不少相關的資料，在這些新舊不一的資料中，我發現了「OS/2博物館」網站上一篇關於Gravis UltraSound音效卡的文章。（這個網站的站長Michal Necasek，是原OpenWatcom編譯器的開發者之一，而我的一些16-bit DOS程序，正是用這款編譯器開發的，讓人不禁感嘆世界真小）。而特別引起我注意的是Rich Heimlich和其他新聞組成員之間，關於UltraSound音色(Patch)品質和遊戲可用性的論戰。
今天作為Demoscene和Amiga電腦愛好者的我，當年也曾經是Gravis UltraSound（GUS）音效卡最早的嘗試者，我想讀者們應該不會對此感到意外，而這塊音效卡在我心中也一直佔據著其獨特的地位。因此我決定穿越記憶的長廊，回到當年的那場論戰，並試圖了解論戰雙方的論點。
藍方觀點
GUS並非是為完整克隆某個既有標準而實現的，這讓它在諸多的音效卡中顯得頗為與眾不同。與之相對的，初代聲霸卡（Sound Blaster）基本是集成了AdLib音效卡的設計，並在此基礎上加入了遊戲搖桿介面，和用於數字音頻的DMA驅動數模轉換器（DAC）。同樣，後來的聲霸卡型號都是100%兼容之前的AdLib和初代聲霸卡的。與之類似的，羅蘭（Roland）MT-32建立起自己的一套標準，而羅蘭Sound Canvas在建立了一套新標準的同時，也加入了MT-32兼容模式（但並不是100%兼容），而絕大多數其他的MIDI設備，也都試圖兼容MT-32或Sound Canvas的標準。
而GUS音效卡則選擇了另外一條道路，它被設計為一款基於隨機訪問內存（RAM）的波表合成器，這種類似於Amiga電腦上Paula晶元的設計，讓它在已有的PC系統中顯得非常另類。開發者需要上傳採樣到GUS音效卡的內存，並指定採樣回放時的音調、音量、以及在立體聲中的位置(panning)。當時有一個大膽的嘗試，希望開發一個軟體兼容層來實現GUS音效卡與聲霸卡的兼容（SBOS），但由於硬體本身的差異，使其無法很好的模擬雅馬哈OPL2 FM聲音晶元，因此並沒有達到預期想要的效果。
理論上講GUS音效卡很適合MIDI應用，也有針對於MT-32和Sound Canvas（Mega-Em）開發的模擬器。但完整的通用MIDI（General MIDI）音色需要佔用很多內存，這成了GUS音效卡的一大瓶頸。早期的GUS音效卡只有256KB內存，而晚一些的型號則具有512KB內存，並且可以升級到1MB。即便如此，1MB內存對於高質量的通用MIDI音色庫來說還是顯得捉襟見肘。在當時使用只讀內存（ROM）的頂級合成器中所使用的音色庫，多數都在4MB左右。
由於GUS音效卡在當時比較新而且並不怎麼出名，所以當時沒有多少遊戲直接支持這款音效卡，因此你不得不時常依賴於那些並不很完善的模擬器。即使是那些原生支持GUS音效卡的遊戲，許多時候表現也並不理想。這也是本文所關注的重點，在文章的後半部分會展開討論。
我個人從未使用過SBOS，因此我對GUS音效卡的看法可能會跟其他人略有不同，我是用過的第一款音效卡是Sound Blaster Pro 2.0，幾年之後我購入一塊GUS音效卡的時候（作為C64/Amiga的忠實粉絲，SBPro並沒有給我留下很深的印象。音樂效果很平淡，而且音效卡本身的噪音也很明顯）我並沒有將SB Pro音效卡拆掉，因此兩邊的好處都叫我佔到：一邊有著完整的AdLib/SB兼容性，同時在需要的時候我也有GUS支持（和MT-32/Sound Canvas模擬器）。
紅方觀點
如果你了解UltraSound音效卡的功能，並懂得揚長避短（比如不完善的模擬器）的話，那麼這款音效卡就值得讓你擁有和喜愛。
Gravis推出了自己的MIDI播放軟體，你可以針對每一首曲目使用特定的播放器配置和音色庫。舉例而言，專門針對鋼琴獨奏的配置可以使用整個音效卡內存來存儲一個單獨的高質量鋼琴音色：
另一個專門為GUS音效卡準備的演示曲目
The RainCitadel by Ken Goach_騰訊視頻 https://v.qq.com/x/page/k05189q0qk9.html
這種方式很適合播放單獨的曲目，因為事先就可以知道哪些樂器有被使用而哪些沒有。但是對於像遊戲這樣的通用應用來說，所有的樂器都有可能被用到，也因此你不得不將所有的通用MIDI樂器都擠進有限的音效卡內存當中。
由於GUS音效卡與Amiga電腦的Paula晶元非常相似，這款音效卡很快被Demoscene社區所採用。此時Demoscene社區對PC平台的關注才剛剛開始，愛好者們開始將Amiga電腦上的ProTracker音樂移植到PC上。起初的方案是利用軟體將多通道音樂混音輸出到像PC喇叭，Covox音效卡或是聲霸卡等單聲道設備上，而GUS音效卡的出現則讓愛好者們有了一種「萬事俱備」的感覺：這款音效卡正是為播放模塊音樂所準備的，每個模塊僅僅包含其所需要採樣，隱私音效卡的內存空間一點也不會被浪費。而音效卡晶元還支持硬體混音，因此播放音樂只消耗很少的CPU資源，而最終的音樂效果則堪稱完美。
在Amiga電腦上，所有的遊戲都是用音軌序列（tracked）音樂。對於PC上的GUS音效卡來說，這看起來也是個很好的解決方案不是？但事實卻非如此，PC上使用音軌序列的音樂寥寥無幾，而僅有的一些多數是從Amiga電腦移植而來，並原封不動的照搬了Amiga電腦上的4通道8-bit音樂，這讓硬體功能強大，支持16-bit採樣和32通道混音的GUS音效卡幾無用武之地。此外四通道的混音對於當時的CPU來說也算不上是太大的負擔，在這種情況下硬體混音的優勢很難體現出來。
雅馬哈FM合成器
正如我們之前所了解的，聲霸卡和AdLib音效卡都使用了雅馬哈的FM合成器晶元。最初被使用的是OPL2型，而晚一些的型號（從Sound Blaster Pro 2.0和AdLib Gold開始），則使用了更先進的OPL3。在今天雅馬哈仍然是合成器界舉足輕重的大廠，而他們的FM合成器則在80年代大紅大紫，特別是革命性的DX7合成器，我們可以從許多當年的流行歌曲中聽到它的聲音。
但在本文的前面我卻提到了Sound Blaster Pro 2.0的聲音聽起來平淡無味，這是為什麼呢？我猜這大概是MIDI惹的禍。上面提到的Rich Heimlich論戰很大程度上都是圍繞著播放MIDI數據的設備之間的功能區別展開的。Rich Heimlich當時正在為遊戲開發商做質量保證（QA），而MIDI對於遊戲開發商的重要程度自然不用多說。
實際上與GUS音效卡的晶元類似，出於種種原因雅馬哈的晶元也並不非常適合於MIDI播放，當然這是相對而言的。對於雅馬哈的晶元來說，如果希望在它上面播放MIDI音樂，開發者需要針對特定的樂器音色對FM合成器進行編程，如果只是使用通用的音色庫，那麼得到的音樂效果也會……平淡無奇。
當然（使用通用的音色庫）也無法充分利用雅馬哈晶元作為FM合成器的特色，像是實時調整各種工作器（Operator），以及像變頻濾波（filtersweeps）這類老式合成器上常見的酷炫音效。
為什麼是MIDI？
那麼MIDI又是為什麼如此流行呢？讓我們先明確一下MIDI的定義，因為「MIDI」這個詞對於不同的人群來說其含義是不同的。
我想我們首先需要區分一下MIDI一詞的三種「形態」
- MIDI可以用來指連接音樂設備的物理介面
- MIDI可以用來指存儲和回放音樂的文件格式
- MIDI可以指通用MIDI（General MIDI）
介面
先說句題外話，早期的PC MIDI方案實際上是單獨的MIDI介面（而不是音效卡）。舉例來說，本文前面所提到的MT-32和Sound Canvas實際上是「聲音模塊」（MIDI音源），這些設備基本上可以看作是沒有鍵盤的合成器。而利用這些設備產生聲音的唯一方法是向這些設備發送MIDI數據。而這些數據可以由任何的MIDI數據源產生，比如說MIDI鍵盤或是安裝有MIDI介面的PC。羅蘭MPU-401就是一款早期的PC MIDI介面，它包括一塊ISA擴展卡和一個帶有MIDI介面的分線盒。MPU-401+MT-32這一組合曾經一度是PC音頻的「標配」。
不過隨後羅蘭發布的LAPC-I將MPU-401和MT-32集成在了一張ISA擴展卡上。從此PC機不再需要連接到聲音模塊的物理連線，而之後出現的電腦音效卡也大都提供了對MPU-401的兼容性，將MIDI數據重定向至音效卡板載的合成器（如啟用了MegaEm模擬器的GUS，或是安裝了WaveBlaster的Sound Blaster 16，以及AWE32音效卡）。同樣值得一提的是IBM音樂功能卡（IBM Music Feature Card），這塊擴展卡的概念與LAPC-I類似，但其MIDI介面並不與MPU-401兼容，所搭載的合成器也不是流行的MT-32，而是雅馬哈的FB-01。
因此對於PC來說，物理意義上的MIDI介面已不再重要。曾經的MPU-401硬體逐漸成為向聲音模塊傳送MIDI數據的「API」事實標準，物理上的MIDI介面是否存在對於軟體開發者來說都不會有任何區別。
文件格式
MIDI標準的另一個部分，則是將通過MIDI介面傳送的數據存儲在電腦文件中的格式，這種格式的官方名稱叫做「標準MIDI文件」即SMF（Standard MIDI file）。簡單的講這一文件格式就是對通過MIDI介面傳輸的數據的實時日誌：MIDI數據事件序列，加上非常高精度的時間時間戳（可以達到微秒級解析度）。這種文件就是我們所熟知的「.MID」文件。不過這種文件格式與PC遊戲的關係也並不密切，這種格式通常只被用於初期的音樂創作，而大多數的開發商在開發流程中的某個環節都會將其轉換為更加適合遊戲硬體實時播放的自定義格式。
通用MIDI
這一部分才是與音效卡，特別是GUS音效卡密切相關的部分。最初，MIDI的定義只包括上面所講到的兩點：即介面和文件格式。這之後出現了一個什麼問題呢？此時的MIDI只是描述了一些「時間」，如音符的起止，顫音等等。因此MIDI事件只是告訴了聲音模塊要演奏什麼，這樣的數據類似於「選擇3號程序，以顫音級別87演奏C#4」。
那麼問題來了……「3號程序」究竟該是什麼？MIDI事件中並未對此做出描述，不同的聲音模塊可能將同一程序分配給完全不同種類的樂器。即使選擇了同樣的樂器，比如「鋼琴」，不同聲音模塊的音色也很可能截然不同，一些聲音模塊可以支持觸後（aftertouch）這樣的特性，而另一些則未必支持。這會導致音樂表達上的顯著區別。
在PC領域，MT-32由於其作為第一款被PC用戶廣泛使用的MIDI設備的先發優勢而成為事實上的標準。大部分的遊戲都假設用戶已經連接了MT-32聲音模塊，因此他們可以以此得知特定的程序編號所對應的樂器。而IBM音樂功能卡在市場上的失敗的原因之一，正是FB-01與MT-32之間存在著巨大的差異，以至於即使想要得到及格水平的音樂都需要進行許多特殊的調整，更不用說要達到更好的音樂效果了。
羅蘭在晚些時候推出了SC-55 Sound Canvas，一定程度上這款設備是作為MT-32的「繼任者"而出現的。同時SC-55也是第一款支持」通用MIDI「規格的設備，這一標準將樂器列表和一系列最低規格標準化，其中就包括了諸如複音和多重音色（multi-timbral）這樣的特性，而出於向後兼容的考慮，SC-55也可以切換為MT-32樂器表。
究竟是誰的錯？
雖然標準化MIDI的想法聽起來很高大上，但在現實中卻從未真正實現過。首先，即使你定義了1號程序永遠是鋼琴，17號程序永遠是管風琴，但這仍然無法保證它們在所有的設備上聽起來都是一樣的，不同的聲音模塊可能會有不同的發聲機制，預置了不同的聲音採樣等等，因此幾乎沒有兩款聲音模塊的聲音是完全相同的，更糟的是，完整的音樂曲目（這在遊戲中很常見）演奏時通常混合了許多不同的樂器，這種差異累積在一起導致的差異可能會更大，實際上用戶最終聽到的每一個樂器可能都與作曲家所聽到的截然不同，而這更加放大了用戶所聽到的聲音與作曲家創作意圖之間的區別。
實際上即使是SC-55也被相同的問題所困擾，雖然它支持MT-32模擬模式，但它卻並沒有使用與真實的MT-32相同的線性聲音生成演算法，因此SC-55的樂器與MT-32的樂器聽起來並不相同。讓那些特別為MT-32設計的遊戲音樂聽起來並不完美，有時甚至令人難以接受。
第二個問題則是一些開發人員針對MT-32聲音模塊特製了一系列聲音效果，這些為適配MT-32專門開發的音效被稱作「系統特定」音效。正如這一名稱所暗示的，這些聲音指令只能支持特定的「系統」而無法被其它設備所接受，因此SC-55可以播放標準的MT-32音樂，但無法處理那些使用了非標準的編程手段的音樂。
這導致了「最小通用」的問題：由於通用MIDI標準需要面對的設備千差萬別，因此開發者不可能針對每一個設備都去定製特定的音效。因此開發者們會盡量避免使用定製音效。這種困擾出現在許多標準和擴展機制當中，比如OpenGL及其擴展系統。
在多年後的今天，Windows內建的軟體合成器，以及市售的多數硬體合成器和聲音模塊仍然可以支持通用MIDI標準。但上述的問題卻仍然沒有改變：對於一個隨機的通用MIDI文件來說，在不同設備上的播放效果仍舊是各不相同的，很多時候這會導致音樂表現力的下降。而「最小通用」原則也意味著合成器表現手段和功能的損失，使音樂效果更加的「機械」。
所以我認為我現在可以肯定的說，如果通用MIDI標準的目標是使MIDI標準化，並隨時隨地都能還原出良好的音樂效果，那麼這一目標已經失敗了。因此通用MIDI從未被作為共享音樂的文件格式，並且在許多年前這些用途的嘗試就已經結束了。「經典」的MIDI介面和文件及數據格式仍然被音頻軟體所使用，但其使用場景已經逐漸轉移到VSTi等虛擬樂器的領域，在這種場景下，我想人們就可以不會被標準化樂器映射表的一致性所困擾。而MIDI的另外兩部分，介面和文件格式則直到今天仍然運作良好並被廣泛使用。
回到我們前面降到的遊戲話題，各路開發者們都圍繞這MIDI建立起他們的音樂系統，開發出自己的定製版本及預處理器。其中有一些有趣的例子如ID Software的IMP，它可以將MIDI數據預處理為針對OPL-2的代碼，相似的例子還有Cryo Interactive開發的HERAD。
開發「定製」版本的MIDI至少有以下兩種原因：
- 只有像IBM音樂功能卡以及MPU-401 / MT-32 / Sound Canvas這樣的高端設備可以直接解碼MIDI。而對於其他設備，如PC揚聲器，PCjr和Tandy的音樂晶元，或是AdLib以及Game Blaster音效卡而言，必須將MIDI數據轉換為針對於特定晶元指令才可以播放出正確的音符。
- 大多數的音頻設備可以同時播放的樂器和複音的數量都非常有限。
而第二個問題則是MIDI資深的問題。由於MIDI僅僅發送音符的起止命令，而沒有明確的複音指令。因此你可以沒有上限的啟動音符，並製造出「無限複音」。由於MIDI設備往往比較「高端」，所以通常可以支持較多的複音，比如說MT-32就可以同時演奏32和弦。MT-32內部有一個簡單的「和弦分配器」可以動態的分配和弦到每一個演奏出的音符上，並在複音數用完時自動停止較「舊」的音符。當設備支持的複音數充足的時候這一機制可以達到較好的效果。但當可用的和弦數非常有限的時候，這會導致同時演奏旋律和弦的時候某些音符會因此丟失。
替代品
最早使用音樂宏語言的電腦：夏普MZ-80K
一個有趣並且值得一提的是音樂宏語言（Music Macro Language - MML）。與MIDI文件格式類似，它是一種獨立於實際硬體的，用以存儲音符數據的格式。許多早期的BASIC版本支持這種格式，特別是在日本曾經相當流行，這可能受益於MSX平台的普及。遊戲開發者無論是是圍繞MIDI建立自己音樂系統，或是開發自己的MML解釋器，通常都會加入自己的一些擴展功能以更好的利用硬體機能。Chris Covell曾經對一些Neo Geo遊戲中使用的MML解釋器做過頗為有趣的分析。
請繼續閱讀：電腦音樂格式之爭--MIDI與Tracker（下） - 知乎專欄
推薦閱讀：