作者：蓬岸 Dr.Quest
知乎文章编号：27523799
创建于：2017-06-26 11:32:20
修改于：2024-06-01 10:54:53
这篇文章在今年三月份发表在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声卡准备的演示曲目
这种方式很适合播放单独的曲目，因为事先就可以知道哪些乐器有被使用而哪些没有。但是对于像游戏这样的通用应用来说，所有的乐器都有可能被用到，也因此你不得不将所有的通用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来说也算不上是太大的负担，在这种情况下硬件混音的优势很难体现出来。
正如我们之前所了解的，声霸卡和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一词的三种“形态”
接口
先说句题外话，早期的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至少有以下两种原因：
而第二个问题则是MIDI自身的问题。由于MIDI仅仅发送音符的起止命令，而没有明确的复音指令。因此你可以没有上限的启动音符，并制造出“无限复音”。由于MIDI设备往往比较“高端”，所以通常可以支持较多的复音，比如说MT-32就可以同时演奏32和弦。MT-32内部有一个简单的“和弦分配器”可以动态的分配和弦到每一个演奏出的音符上，并在复音数用完时自动停止较“旧”的音符。当设备支持的复音数充足的时候这一机制可以达到较好的效果。但当可用的和弦数非常有限的时候，这会导致同时演奏旋律和弦的时候某些音符会因此丢失。
替代品
最早使用音乐宏语言的电脑：夏普MZ-80K
一个有趣并且值得一提的是音乐宏语言（Music Macro Language - MML）。与MIDI文件格式类似，它是一种独立于实际硬件的，用以存储音符数据的格式。许多早期的BASIC版本支持这种格式，特别是在日本曾经相当流行，这可能受益于MSX平台的普及。游戏开发者无论是是围绕MIDI建立自己音乐系统，或是开发自己的MML解释器，通常都会加入自己的一些扩展功能以更好的利用硬件机能。Chris Covell曾经对一些Neo Geo游戏中使用的MML解释器做过颇为有趣的分析。