电脑音乐格式之争——MIDI与Tracker（上） 作者：蓬岸 Dr.Quest 编号：27523799 创建于：2017-06-26 23:32:20 修改于：2017-06-29 15:56:33 -------------------- 这篇文章在今年三月份发表在Scali's OpenBlog上，由Gravis UltraSound声卡 展开，探讨了MIDI和Tracker音乐的诸多异同，这篇文章基本上代表了当前Demos cene社区对Tracker和MIDI这两种音乐格式的理解，正所谓“管中窥豹，可见一斑 ”，希望这篇文章能够给中文社区的读者带来一些有价值的启发。 原文：Trackers vs MIDI (Link: https://scalibq.wordpress.com/2017/03/29 /trackers-vs-midi/) 最近一段时间，我正忙着折腾一些音频设备和声音程序，在折腾的过程中，我接 触到不少相关的资料，在这些新旧不一的资料中，我发现了“OS/2博物馆”网站上 一篇关于Gravis UltraSound声卡的文章 (Link: http://www.os2museum.com/wp /gravis-ultras/) 。（这个网站的站长Michal Necasek，是原OpenWatcom编译 器的开发者之一，而我的一些16-bit DOS程序，正是用这款编译器开发的，让人 不禁感叹世界真小）。而特别引起我注意的是Rich Heimlich和其他新闻组成员 之间，关于UltraSound音色(Patch)品质和游戏可用性的论战。 (Image: https://pic1.zhimg.com/v2-07ffcadf9209f6d4a6fde9679fd2aeac_b.j pg) 今天作为Demoscene和Amiga电脑爱好者的我，当年也曾经是Gravis UltraSound （GUS）声卡最早的尝试者，我想读者们应该不会对此感到意外，而这块声卡在 我心中也一直占据着其独特的地位。因此我决定穿越记忆的长廊，回到当年的那 场论战，并试图了解论战双方的论点。 蓝方观点 GUS并非是为完整克隆某个既有标准而实现的，这让它在诸多的声卡中显得颇为 与众不同。与之相对的，初代声霸卡（Sound Blaster）基本是集成了AdLib声卡 的设计，并在此基础上加入了游戏摇杆接口，和用于数字音频的DMA驱动数模转 换器（DAC）。同样，后来的声霸卡型号都是100%兼容之前的AdLib和初代声霸卡 的。与之类似的，罗兰（Roland）MT-32建立起自己的一套标准，而罗兰Sound C anvas在建立了一套新标准的同时，也加入了MT-32兼容模式（但并不是100%兼容 ），而绝大多数其他的MIDI设备，也都试图兼容MT-32或Sound Canvas的标准。 (Image: https://pic3.zhimg.com/v2-82197f3c6f4e762da4da211e8f359d22_b.j pg) 而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内存对于高质量的通用MID I音色库来说还是显得捉襟见肘。在当时使用只读内存（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播放软件，你可以针对每一首曲目使用特定的播放器配 置和音色库。举例而言，专门针对钢琴独奏的配置可以使用整个声卡内存来存储 一个单独的高质量钢琴音色： (Image: https://puui.qpic.cn/qqvideo_ori/0/d0518r7w4t8_228_128/0) The Last Days of Summer_腾讯视频https://v.qq.com/x/page/d0518r7w4t8.ht ml (Link: https://v.qq.com/x/page/d0518r7w4t8.html) 另一个专门为GUS声卡准备的演示曲目 (Image: https://puui.qpic.cn/qqvideo_ori/0/k05189q0qk9_228_128/0) The RainCitadel by Ken Goach_腾讯视频https://v.qq.com/x/page/k05189q0q k9.html (Link: 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 G old开始），则使用了更先进的OPL3。在今天雅马哈仍然是合成器界举足轻重的 大厂，而他们的FM合成器则在80年代大红大紫，特别是革命性的DX7合成器，我 们可以从许多当年的流行歌曲中听到它的声音。 (Image: https://pic4.zhimg.com/v2-94593adbde2a3e7076fb974b0a898283_b.j pg) 但在本文的前面我却提到了Sound Blaster Pro 2.0的声音听起来平淡无味，这 是为什么呢？我猜这大概是MIDI惹的祸。上面提到的Rich Heimlich论战很大程 度上都是围绕着播放MIDI数据的设备之间的功能区别展开的。Rich Heimlich当 时正在为游戏开发商做质量保证（QA），而MIDI对于游戏开发商的重要程度自然 不用多说。 实际上与GUS声卡的芯片类似，出于种种原因雅马哈的芯片也并不非常适合于MID I播放，当然这是相对而言的。对于雅马哈的芯片来说，如果希望在它上面播放M IDI音乐，开发者需要针对特定的乐器音色对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就是一款早期的P C MIDI接口，它包括一块ISA扩展卡和一个带有MIDI接口的分线盒。MPU-401+MT- 32这一组合曾经一度是PC音频的“标配”。 (Image: https://pic2.zhimg.com/v2-58b06abc87459f817afe80c83ec36925_b.j pg) 不过随后罗兰发布的LAPC-I将MPU-401和MT-32集成在了一张ISA扩展卡上。从此P C机不再需要连接到声音模块的物理连线，而之后出现的电脑声卡也大都提供了 对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之间存在着巨大的差异，以至于即使想要得 到及格水平的音乐都需要进行许多特殊的调整，更不用说要达到更好的音乐效果 了。 (Image: https://pic2.zhimg.com/v2-7b06d6143b18ed3bfbb59591f8474cbd_b.j pg) 罗兰在晚些时候推出了SC-55 Sound Canvas，一定程度上这款设备是作为MT-32 的“继任者"而出现的。同时SC-55也是第一款支持”通用MIDI“规格的设备，这一 标准将乐器列表和一系列最低规格标准化，其中就包括了诸如复音和多重音色（ multi-timbral）这样的特性，而出于向后兼容的考虑，SC-55也可以切换为MT-3 2乐器表。 究竟是谁的错？ 虽然标准化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及其扩展系 统。 (Image: https://pic4.zhimg.com/v2-d34fd6f35db047f7b9cbc8bcaafa0e77_b.p ng) 在多年后的今天，Windows内建的软件合成器，以及市售的多数硬件合成器和声 音模块仍然可以支持通用MIDI标准。但上述的问题却仍然没有改变：对于一个随 机的通用MIDI文件来说，在不同设备上的播放效果仍旧是各不相同的，很多时候 这会导致音乐表现力的下降。而“最小通用”原则也意味着合成器表现手段和功能 的损失，使音乐效果更加的“机械”。 所以我认为我现在可以肯定的说，如果通用MIDI标准的目标是使MIDI标准化，并 随时随地都能还原出良好的音乐效果，那么这一目标已经失败了。因此通用MIDI 从未被作为共享音乐的文件格式，并且在许多年前这些用途的尝试就已经结束了 。“经典”的MIDI接口和文件及数据格式仍然被音频软件所使用，但其使用场景已 经逐渐转移到VSTi等虚拟乐器的领域，在这种场景下，我想人们就可以不会被标 准化乐器映射表的一致性所困扰。而MIDI的另外两部分，接口和文件格式则直到 今天仍然运作良好并被广泛使用。 回到我们前面降到的游戏话题，各路开发者们都围绕这MIDI建立起他们的音乐系 统，开发出自己的定制版本及预处理器。其中有一些有趣的例子如ID Software 的IMP，它可以将MIDI数据预处理为针对OPL-2的代码，相似的例子还有Cryo Int eractive开发的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内部有一个简单的“和弦分配器”可以动态的分配和弦到 每一个演奏出的音符上，并在复音数用完时自动停止较“旧”的音符。当设备支持 的复音数充足的时候这一机制可以达到较好的效果。但当可用的和弦数非常有限 的时候，这会导致同时演奏旋律和弦的时候某些音符会因此丢失。 替代品 (Image: https://pic1.zhimg.com/v2-026f3a33620e0e567a69a2a7aa730d44_b.j pg) 最早使用音乐宏语言的电脑：夏普MZ-80K 一个有趣并且值得一提的是音乐宏语言（Music Macro Language - MML）。与MI DI文件格式类似，它是一种独立于实际硬件的，用以存储音符数据的格式。许多 早期的BASIC版本支持这种格式，特别是在日本曾经相当流行，这可能受益于MSX 平台的普及。游戏开发者无论是是围绕MIDI建立自己音乐系统，或是开发自己的 MML解释器，通常都会加入自己的一些扩展功能以更好的利用硬件机能。Chris C ovell曾经对一些Neo Geo游戏中使用的MML解释器做过颇为有趣的分析 (Link: h ttp://www.chrismcovell.com/ADKMML.html) 。 请继续阅读：电脑音乐格式之争--MIDI与Tracker（下） - 知乎专栏 (Link: ht tps://zhuanlan.zhihu.com/p/27591142)