info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
电脑音乐格式之争——MIDI与Tracker
15 views
Skip to first unread message
Pengan
May 29, 2018, 10:17:24 PM5/29/18
to
电脑音乐格式之争——MIDI与Tracker
这篇文章在今年三月份发表在Scali's OpenBlog?上，由Gravis UltraSound声卡展开，探讨了MIDI和Tracker音乐的诸多异同，这篇文章基本上代表了当前Demoscene社区对Tracker和MIDI这两种音乐格式的理解，正所谓“管中窥豹，可见一斑”，希望这篇文章能够给中文社区的读者带来一些有价值的启发。
原文：Trackers vs MIDI
https://scalibq.wordpress.com/2017/03/29/trackers-vs-midi/
最近一段时间，我正忙着折腾一些音频设备和声音程序，在折腾的过程中，我接触到不少相关的资料，在这些新旧不一的资料中，我发现了“OS/2博物馆”网站上一篇关于Gravis UltraSound声卡的文章。【链接1】（这个网站的站长Michal Necasek，是原OpenWatcom编译器的开发者之一，而我的一些16-bit DOS程序，正是用这款编译器开发的，让人不禁感叹世界真小）。而特别引起我注意的是Rich Heimlich和其他新闻组成员之间，关于UltraSound音色(Patch)品质和游戏可用性的论战。
【链接1】 http://www.os2museum.com/wp/gravis-ultras/
今天作为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播放软件，你可以针对每一首曲目使用特定的播放器配置和音色库。举例而言，专门针对钢琴独奏的配置可以使用整个声卡内存来存储一个单独的高质量钢琴音色：
【链接2】https://v.qq.com/x/page/d0518r7w4t8.html
另一个专门为GUS声卡准备的演示曲目
【链接3】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内部有一个简单的“和弦分配器”可以动态的分配和弦到每一个演奏出的音符上，并在复音数用完时自动停止较“旧”的音符。当设备支持的复音数充足的时候这一机制可以达到较好的效果。但当可用的和弦数非常有限的时候，这会导致同时演奏旋律和弦的时候某些音符会因此丢失。
替代品
一个有趣并且值得一提的是音乐宏语言（Music Macro Language - MML）。与MIDI文件格式类似，它是一种独立于实际硬件的，用以存储音符数据的格式。许多早期的BASIC版本支持这种格式，特别是在日本曾经相当流行，这可能受益于MSX平台的普及。游戏开发者无论是是围绕MIDI建立自己音乐系统，或是开发自己的MML解释器，通常都会加入自己的一些扩展功能以更好的利用硬件机能。Chris Covell曾经对一些Neo Geo游戏中使用的MML解释器做过颇为有趣的分析。
配图文字：最早使用音乐宏语言的电脑：夏普MZ-80K
然后我们来说说Tracker！
那么Tracker和MIDI的区别究竟是什么呢？其实他们之间有着一些根本的区别，主要有：
1. Tracker将乐器的数据与音符的数据存储在一起。一般来讲乐器的音色被嵌入在Tracker软件所使用的“模块”（module）文件当中。不过有一些早期的Tracker是将乐器音色存储在单独的文件中，并在主文件中引用他们，这样的话可以更容易的让一张磁盘上的多首歌曲同时使用一组音色。
2. 音符被以“图案”（pattern）的形式输入并组成一张存储音符的二维矩阵。一个“图案”通常是一小段音乐片段，这些图案被以一定的顺序输入，从而构成了乐曲的顺序，在音乐中，一个图案可以被使用许多次。
3. 图案中的每一列则是一个“通道”（channel），每个通道被直接映射到音频硬件的一个和弦，而每个通道都是单声道的，这符合音频硬件的一般特性。
4. 而图案中水平的行则代表着时间线。时序通常与帧率同步（在不同的硬件系统上，这个频率可以是50、60或70赫兹），而乐曲的节奏也以每一行有多少帧来决定。
这听起来是不是受到了诸多的限制呢？没错，就是这样，这确实有些不合常理。相比MIDI这种“高级”的音乐数据解决方案来说，Tracker可以提供非常高的灵活度和精确性。如果你把MIDI看作是C语言，那么Tracker就像是汇编语言，再或者说，你可以把MIDI想象成HTML，它描述了每个部件在页面上的位置，并大致的描述了布局，但由于不同的浏览器、屏幕尺寸、安装的字体等因素，都会让一个页面在不同的场合下略有不同。而Tracker就像是PostScript或者PDF一样“精确地”描述了页面的外观。接下来让我们详细的了解下Tracker的这四大特征。
文件内的乐器数据
最初Tracker仅仅是用于特定硬件的音乐编辑器，大多数情况下被是C64和Amiga电脑所采用。而Tracker软件也通常针对特定的硬件功能所开发，这样造成的一个结果是，Tracker模块通常只能在特定的硬件（或他们的模拟器）上播放。不过由于Tracker文件内同时包含了完整的音符和乐器数据，实际上Tracker文件完整的定义音乐的演奏效果，而不是像MIDI文件和通用MIDI标准那样仅仅描述了乐曲中使用某个乐器是“钢琴”或“吉他”这样笼统的信息。
最流行的Tracker音乐制作方法，是使用Amiga电脑及SoundTracker、NoiseTracker和ProTracker等软件。在本文的上半部分，我曾经提到了Amiga电脑上革命性的Paula声音芯片。由于这款芯片可以支持四个数字声音流串流，因此在Amiga电脑上。播放模块音乐要在方式要比其他的电脑平台如PC或者Atari ST更加容易。
以“图案”输入音符
在前面我或多或少的已经提到了这一点，Tracker使用图案序列来制作音乐，我想对于解释图案这个概念来说，一张好图胜千言：【插图：ProTracker】
如果你熟悉鼓机软件的话，其实你已经在使用类似的方式进行创作了。一个“图案”就是音乐中一个段短暂的切片，通常只包含几个小节，而一首完整的歌曲正是由一系列图案所组成的“序列”构成的，在一首歌曲中重复使用相同的图案，可以节省制作的时间和存储音乐数据所需的空间。
图案通常是以垂直方式排列的，多数软件会有64行来摆放音符。这些行代表着乐曲的“节拍”，这取决于你设置了多快的播放速度（速度越快，单位时间内播放的行数也就越多）以及乐曲的“密度”。举例来说，你可以在一个图案中摆放四个小节，而如果以原来的两倍距离摆放音符，并将速度播放速度设置为原来的两倍，那么它们听起来就会是一样的。虽然此时同样的64行只能放下两个小节，但也因此获得了更高的“分辨率”，即在同样的播放时间里，可以容纳之前两倍数量的行数。
“图案列”既“和旋”
这可能是MIDI和Tracker之间最大的不同了：Tracker中的任何的复音都是明确定义的，每个通道（Channel）都是单声道，并直接映射到硬件上的一个和弦（voice），这种设计非常适合于和弦数量非常有限（C64只有三和弦，而Amiga只有四和弦）的声音芯片。而MIDI仅仅是简单的发送音符起止事件，再通过解释器将MIDI事件转换为硬件内部的信号，因此硬件需要决定如何分配和弦，而当遇到音符开启时没有更多和弦可用的情况时，硬件就会自行结束正在演奏的某些音符。
对于Tracker来说，由于你已经明确地定义了每个音符所使用的通道和和弦音色，也因此可以确定的知道哪些音符应该被启用而哪些应该被禁用，这样音乐的作者就可以更加高效地利用有限的通道数量，另外音乐作者也可以将旋律和低音部分交错（weave）在一个通道中，比如说Rob Hubbard的这个例子，从4分03秒开始：
【链接4】 https://v.qq.com/x/page/x0520qnv6z2.html?start=243
在段落的开始，仅有的一个通道将鼓声和旋律交织在一起，接下来第二个通道加入了低音和更多的打击乐。然后，第三个声道带入了主旋律和更多的修饰。音乐家使用一颗仅有三个通道的芯片，演奏出超过三个声部的音乐效果。而这正是通过针对硬件特性进行的人工优化，对每个音符进行巧妙的摆放而完成的。
这里有另外的一个例子，来自芬兰著名Demo团队Future Crew的Purple Motion，仅仅使用了两个通道就完成了这首歌曲。
【链接5】https://v.qq.com/x/page/h0519qxtr73.html
下面的一段视频中他同样只使用了两个声音通道，通过合理的优化展现出非常精彩的听觉效果。
【链接6】https://v.qq.com/x/page/s0520a2c0mu.html
上面的几个例子，恰到好处的展现了Tracker在开发者手中是何等强大的创作工具。
图案中的水平“行”构成的时间轴
这一部分并不直接关系到音乐，却与创作的效率和优化息息相关。你可能记得我在更早些时候曾经写过关于图形编程和“与光赛跑”般的极限优化相关的文章。自然而然的，人们也会希望在游戏和Demo中加入音乐，并且希望音乐程序的加入不会打断在屏幕上绘制像素的速度。因此开发者们希望能够发展出一种声画同步的方法，这正是Tracker的时序通常于显示器刷新率相关的原因。
举例来说，Amiga电脑上的Tracker通常以50Hz（PAL制式）的频率运行，也就是说，游戏和演示引擎可以简单的在绘制每一帧时呼叫一次声音程序，而速度指令则可以控制播放每一行所使用的帧数，如果你设置速度为6，那么音乐程序就会倒数6帧之后才会处理下一行。
你可以选择在某一帧的中间呼叫音乐程序，你可以在光栅扫描事件中保留一个时槽，通常是垂直扫描间隔中的某个时间点来播放音乐。也因此我们知道这代表了音乐程序在一帧中的其他时间不会做任何事情，因此你可以按照自己的喜好精确的定义代码的周期。音乐以行为单位被明确的组合在一起和进行同步，让播放过程对CPU的使用非常的高效而且可控。播放音乐所需要的时间可能仅仅与绘制几条扫描线的时间相当。
而对于普通的MIDI来说它们就没有这样的本领。MIDI有着非常精确的时序，几乎每一首MIDI歌曲都不可避免的在一帧中处理多个MIDI事件。图形程序员乎没有可能知道下一条MIDI事件发生的实际。这也是为什么游戏开发中经常对MIDI进行向下量化（quantize）的原因。不过将所有的MIDI都量化为50或60赫兹的效果并不理想，因此通常会使用更高的频率，通常是200~700赫兹之间。如果你不追求“与光赛跑”的话，这是一种可以接受的妥协。
让我们再回来讨论下UltraSound声卡
上面这些Tracker音乐独有的特性和优点解释了为什么Tracker在Demoscene社区如此流行的原因。也由此可以推断出为什么Demoscene也同样热爱UltraSound声卡：这块声卡看起来就像是为播放基于采样的Tracker模块“量身定做”的一样。ProTracker软件仅仅依靠四通道和8-bit采样就已经可以制作出相当精彩的音乐，虽然在PC上使用软件方式混音需要消耗不少CPU资源。
但UltraSound有着多达32个声音通道，支持16-bit采样精度，以及更加强大的：高质量的硬件混音，这让它可以与Amiga电脑一样在播放音乐时基本不需要消耗CPU资源。UltraSound就像是一块“Tracker加速卡”。如果你听过上面那些使用C64或Amiga电脑上原始的声音芯片所发出的2通道或3通道音乐，你就可以想见UltraSound声卡所具备的巨大潜力。
UltraSound的主要问题在于缺少足够的游戏开发者为其进行适配，这确实有些奇怪，在Amiga电脑上，多数的游戏音乐都使用了某种流行的Tracker进行创作，大部分是ProTracker。曾经我们以为UltraSound也会是类似的情况。但由于种种原因，许多开发人员仅仅将UltraSound作为MIDI设备使用，因此UltraSound在游戏中的表现并不像在Demoscene中那样令人印象深刻。
因此，我们来听一下当时我最喜欢的两段Demo音乐，他们代表了UltraSound在Demoscene社区中所展现出的最高水平。首先是传奇般的《第二现实（Second Reality）》中优秀的配乐（可以说是这段Demo的亮点），它“仅仅”使用了8个通道：
【链接7】 https://v.qq.com/x/page/y0520xcio5q.html
然后则是Triton的《水晶之梦II（Crystal Dream II）》中精彩的Tracker音乐，我猜测它可能同样“仅仅”使用了8个通道，至少我可以确定它一定没有使用UltraSound提供的全部32个通道（你可以注意到设置菜单中显示的声卡型号正是UltraSound）
【链接8】 https://v.qq.com/x/page/g0520vvygl7.html
有趣的是，这两个Demo团队都开发了自己的Tracker软件。 Future Crew开发了Scream Tracker，而Triton则开发了FastTracker。这两款软件在后来成为了PC平台和UltraSound声卡上最流行的Tracker软件。
那么是谁笑到了最后呢？事实上是没有，UltraSound出现的有点太迟了。 至少有三个重要的技术进展，或多或少的导致了UltraSound的淡出：
1. CPU性能迅速增长，并强大到足以在后台实现32通道混音，16-bit采样精度和线性插值等功能。这让任何具备16-bit DAC的声卡如 Sound Blaster 16或Pro Audio Spectrum 16）都可以以和UltraSound几乎相同的音质播放Tracker音乐。
2. CD-ROM进入主流市场，许多游戏开始仅仅使用CD音轨作为音乐，任何声卡都无法在这一领域展开竞争。
3. 游戏从DOS平台迁移到Windows平台。在DOS下游戏可以直接访问音频硬件，而Windows中音频硬件则被抽象出来，并必须通过API进行访问。但这种API并不特别适合像UltraSound这类基于RAM的波表合成器，这让开发者们被拘束在通用MIDI的世界中。
而上面所讲到的第二点也至少在游戏领域宣告了MIDI使命的终结。游戏配乐被事先“预制”在CD音轨或CD上的数字音频文件中，再串流到16-bit立体声DAC解码。在这一流程中MIDI同样没有它的一席之地。
（配图文字：最早支持CD音轨的游戏主机TurboGrafx-CD）
可以说，在那之后通用MIDI同样也过时了，它可能仍然是被市场所认可的标准之一，但我不认为人们会出于在电脑上听音乐的需求而使用它，因为它从来没有表现得非常出色。
MIDI标准本身仍然被用作连接合成器和其他设备的基础，同时大多数的数字音频工作站（DAW）软件都支持导入及导出标准MIDI文件。当然，这类软件通常具有自己专用的内部格式，这些格式可能包括了对MIDI的扩展，或是数字音轨信息。今天你在收音机里听到的许多歌曲中，都可能使用了某些MIDI技术进行创作。
而Tracker技术也同样被人们所使用，不仅仅是Demoscenes社区，也包括了“芯片音乐”社区，从某种程度上讲，“芯片音乐”社区是从Demoscene社区中所分离出的一部分。许多音乐家仍然会定期的发布Tracker歌曲，而许多爱好者也仍然喜欢收听Tracker音乐。
【链接9】 https://v.qq.com/x/page/l0519tlzlut.html
这篇文章在今年三月份发表在Scali's OpenBlog?上，由Gravis UltraSound声卡展开，探讨了MIDI和Tracker音乐的诸多异同，这篇文章基本上代表了当前Demoscene社区对Tracker和MIDI这两种音乐格式的理解，正所谓“管中窥豹，可见一斑”，希望这篇文章能够给中文社区的读者带来一些有价值的启发。
原文：Trackers vs MIDI
https://scalibq.wordpress.com/2017/03/29/trackers-vs-midi/
最近一段时间，我正忙着折腾一些音频设备和声音程序，在折腾的过程中，我接触到不少相关的资料，在这些新旧不一的资料中，我发现了“OS/2博物馆”网站上一篇关于Gravis UltraSound声卡的文章。【链接1】（这个网站的站长Michal Necasek，是原OpenWatcom编译器的开发者之一，而我的一些16-bit DOS程序，正是用这款编译器开发的，让人不禁感叹世界真小）。而特别引起我注意的是Rich Heimlich和其他新闻组成员之间，关于UltraSound音色(Patch)品质和游戏可用性的论战。
【链接1】 http://www.os2museum.com/wp/gravis-ultras/
今天作为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播放软件，你可以针对每一首曲目使用特定的播放器配置和音色库。举例而言，专门针对钢琴独奏的配置可以使用整个声卡内存来存储一个单独的高质量钢琴音色：
【链接2】https://v.qq.com/x/page/d0518r7w4t8.html
另一个专门为GUS声卡准备的演示曲目
【链接3】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内部有一个简单的“和弦分配器”可以动态的分配和弦到每一个演奏出的音符上，并在复音数用完时自动停止较“旧”的音符。当设备支持的复音数充足的时候这一机制可以达到较好的效果。但当可用的和弦数非常有限的时候，这会导致同时演奏旋律和弦的时候某些音符会因此丢失。
替代品
一个有趣并且值得一提的是音乐宏语言（Music Macro Language - MML）。与MIDI文件格式类似，它是一种独立于实际硬件的，用以存储音符数据的格式。许多早期的BASIC版本支持这种格式，特别是在日本曾经相当流行，这可能受益于MSX平台的普及。游戏开发者无论是是围绕MIDI建立自己音乐系统，或是开发自己的MML解释器，通常都会加入自己的一些扩展功能以更好的利用硬件机能。Chris Covell曾经对一些Neo Geo游戏中使用的MML解释器做过颇为有趣的分析。
配图文字：最早使用音乐宏语言的电脑：夏普MZ-80K
然后我们来说说Tracker！
那么Tracker和MIDI的区别究竟是什么呢？其实他们之间有着一些根本的区别，主要有：
1. Tracker将乐器的数据与音符的数据存储在一起。一般来讲乐器的音色被嵌入在Tracker软件所使用的“模块”（module）文件当中。不过有一些早期的Tracker是将乐器音色存储在单独的文件中，并在主文件中引用他们，这样的话可以更容易的让一张磁盘上的多首歌曲同时使用一组音色。
2. 音符被以“图案”（pattern）的形式输入并组成一张存储音符的二维矩阵。一个“图案”通常是一小段音乐片段，这些图案被以一定的顺序输入，从而构成了乐曲的顺序，在音乐中，一个图案可以被使用许多次。
3. 图案中的每一列则是一个“通道”（channel），每个通道被直接映射到音频硬件的一个和弦，而每个通道都是单声道的，这符合音频硬件的一般特性。
4. 而图案中水平的行则代表着时间线。时序通常与帧率同步（在不同的硬件系统上，这个频率可以是50、60或70赫兹），而乐曲的节奏也以每一行有多少帧来决定。
这听起来是不是受到了诸多的限制呢？没错，就是这样，这确实有些不合常理。相比MIDI这种“高级”的音乐数据解决方案来说，Tracker可以提供非常高的灵活度和精确性。如果你把MIDI看作是C语言，那么Tracker就像是汇编语言，再或者说，你可以把MIDI想象成HTML，它描述了每个部件在页面上的位置，并大致的描述了布局，但由于不同的浏览器、屏幕尺寸、安装的字体等因素，都会让一个页面在不同的场合下略有不同。而Tracker就像是PostScript或者PDF一样“精确地”描述了页面的外观。接下来让我们详细的了解下Tracker的这四大特征。
文件内的乐器数据
最初Tracker仅仅是用于特定硬件的音乐编辑器，大多数情况下被是C64和Amiga电脑所采用。而Tracker软件也通常针对特定的硬件功能所开发，这样造成的一个结果是，Tracker模块通常只能在特定的硬件（或他们的模拟器）上播放。不过由于Tracker文件内同时包含了完整的音符和乐器数据，实际上Tracker文件完整的定义音乐的演奏效果，而不是像MIDI文件和通用MIDI标准那样仅仅描述了乐曲中使用某个乐器是“钢琴”或“吉他”这样笼统的信息。
最流行的Tracker音乐制作方法，是使用Amiga电脑及SoundTracker、NoiseTracker和ProTracker等软件。在本文的上半部分，我曾经提到了Amiga电脑上革命性的Paula声音芯片。由于这款芯片可以支持四个数字声音流串流，因此在Amiga电脑上。播放模块音乐要在方式要比其他的电脑平台如PC或者Atari ST更加容易。
以“图案”输入音符
在前面我或多或少的已经提到了这一点，Tracker使用图案序列来制作音乐，我想对于解释图案这个概念来说，一张好图胜千言：【插图：ProTracker】
如果你熟悉鼓机软件的话，其实你已经在使用类似的方式进行创作了。一个“图案”就是音乐中一个段短暂的切片，通常只包含几个小节，而一首完整的歌曲正是由一系列图案所组成的“序列”构成的，在一首歌曲中重复使用相同的图案，可以节省制作的时间和存储音乐数据所需的空间。
图案通常是以垂直方式排列的，多数软件会有64行来摆放音符。这些行代表着乐曲的“节拍”，这取决于你设置了多快的播放速度（速度越快，单位时间内播放的行数也就越多）以及乐曲的“密度”。举例来说，你可以在一个图案中摆放四个小节，而如果以原来的两倍距离摆放音符，并将速度播放速度设置为原来的两倍，那么它们听起来就会是一样的。虽然此时同样的64行只能放下两个小节，但也因此获得了更高的“分辨率”，即在同样的播放时间里，可以容纳之前两倍数量的行数。
“图案列”既“和旋”
这可能是MIDI和Tracker之间最大的不同了：Tracker中的任何的复音都是明确定义的，每个通道（Channel）都是单声道，并直接映射到硬件上的一个和弦（voice），这种设计非常适合于和弦数量非常有限（C64只有三和弦，而Amiga只有四和弦）的声音芯片。而MIDI仅仅是简单的发送音符起止事件，再通过解释器将MIDI事件转换为硬件内部的信号，因此硬件需要决定如何分配和弦，而当遇到音符开启时没有更多和弦可用的情况时，硬件就会自行结束正在演奏的某些音符。
对于Tracker来说，由于你已经明确地定义了每个音符所使用的通道和和弦音色，也因此可以确定的知道哪些音符应该被启用而哪些应该被禁用，这样音乐的作者就可以更加高效地利用有限的通道数量，另外音乐作者也可以将旋律和低音部分交错（weave）在一个通道中，比如说Rob Hubbard的这个例子，从4分03秒开始：
【链接4】 https://v.qq.com/x/page/x0520qnv6z2.html?start=243
在段落的开始，仅有的一个通道将鼓声和旋律交织在一起，接下来第二个通道加入了低音和更多的打击乐。然后，第三个声道带入了主旋律和更多的修饰。音乐家使用一颗仅有三个通道的芯片，演奏出超过三个声部的音乐效果。而这正是通过针对硬件特性进行的人工优化，对每个音符进行巧妙的摆放而完成的。
这里有另外的一个例子，来自芬兰著名Demo团队Future Crew的Purple Motion，仅仅使用了两个通道就完成了这首歌曲。
【链接5】https://v.qq.com/x/page/h0519qxtr73.html
下面的一段视频中他同样只使用了两个声音通道，通过合理的优化展现出非常精彩的听觉效果。
【链接6】https://v.qq.com/x/page/s0520a2c0mu.html
上面的几个例子，恰到好处的展现了Tracker在开发者手中是何等强大的创作工具。
图案中的水平“行”构成的时间轴
这一部分并不直接关系到音乐，却与创作的效率和优化息息相关。你可能记得我在更早些时候曾经写过关于图形编程和“与光赛跑”般的极限优化相关的文章。自然而然的，人们也会希望在游戏和Demo中加入音乐，并且希望音乐程序的加入不会打断在屏幕上绘制像素的速度。因此开发者们希望能够发展出一种声画同步的方法，这正是Tracker的时序通常于显示器刷新率相关的原因。
举例来说，Amiga电脑上的Tracker通常以50Hz（PAL制式）的频率运行，也就是说，游戏和演示引擎可以简单的在绘制每一帧时呼叫一次声音程序，而速度指令则可以控制播放每一行所使用的帧数，如果你设置速度为6，那么音乐程序就会倒数6帧之后才会处理下一行。
你可以选择在某一帧的中间呼叫音乐程序，你可以在光栅扫描事件中保留一个时槽，通常是垂直扫描间隔中的某个时间点来播放音乐。也因此我们知道这代表了音乐程序在一帧中的其他时间不会做任何事情，因此你可以按照自己的喜好精确的定义代码的周期。音乐以行为单位被明确的组合在一起和进行同步，让播放过程对CPU的使用非常的高效而且可控。播放音乐所需要的时间可能仅仅与绘制几条扫描线的时间相当。
而对于普通的MIDI来说它们就没有这样的本领。MIDI有着非常精确的时序，几乎每一首MIDI歌曲都不可避免的在一帧中处理多个MIDI事件。图形程序员乎没有可能知道下一条MIDI事件发生的实际。这也是为什么游戏开发中经常对MIDI进行向下量化（quantize）的原因。不过将所有的MIDI都量化为50或60赫兹的效果并不理想，因此通常会使用更高的频率，通常是200~700赫兹之间。如果你不追求“与光赛跑”的话，这是一种可以接受的妥协。
让我们再回来讨论下UltraSound声卡
上面这些Tracker音乐独有的特性和优点解释了为什么Tracker在Demoscene社区如此流行的原因。也由此可以推断出为什么Demoscene也同样热爱UltraSound声卡：这块声卡看起来就像是为播放基于采样的Tracker模块“量身定做”的一样。ProTracker软件仅仅依靠四通道和8-bit采样就已经可以制作出相当精彩的音乐，虽然在PC上使用软件方式混音需要消耗不少CPU资源。
但UltraSound有着多达32个声音通道，支持16-bit采样精度，以及更加强大的：高质量的硬件混音，这让它可以与Amiga电脑一样在播放音乐时基本不需要消耗CPU资源。UltraSound就像是一块“Tracker加速卡”。如果你听过上面那些使用C64或Amiga电脑上原始的声音芯片所发出的2通道或3通道音乐，你就可以想见UltraSound声卡所具备的巨大潜力。
UltraSound的主要问题在于缺少足够的游戏开发者为其进行适配，这确实有些奇怪，在Amiga电脑上，多数的游戏音乐都使用了某种流行的Tracker进行创作，大部分是ProTracker。曾经我们以为UltraSound也会是类似的情况。但由于种种原因，许多开发人员仅仅将UltraSound作为MIDI设备使用，因此UltraSound在游戏中的表现并不像在Demoscene中那样令人印象深刻。
因此，我们来听一下当时我最喜欢的两段Demo音乐，他们代表了UltraSound在Demoscene社区中所展现出的最高水平。首先是传奇般的《第二现实（Second Reality）》中优秀的配乐（可以说是这段Demo的亮点），它“仅仅”使用了8个通道：
【链接7】 https://v.qq.com/x/page/y0520xcio5q.html
然后则是Triton的《水晶之梦II（Crystal Dream II）》中精彩的Tracker音乐，我猜测它可能同样“仅仅”使用了8个通道，至少我可以确定它一定没有使用UltraSound提供的全部32个通道（你可以注意到设置菜单中显示的声卡型号正是UltraSound）
【链接8】 https://v.qq.com/x/page/g0520vvygl7.html
有趣的是，这两个Demo团队都开发了自己的Tracker软件。 Future Crew开发了Scream Tracker，而Triton则开发了FastTracker。这两款软件在后来成为了PC平台和UltraSound声卡上最流行的Tracker软件。
那么是谁笑到了最后呢？事实上是没有，UltraSound出现的有点太迟了。 至少有三个重要的技术进展，或多或少的导致了UltraSound的淡出：
1. CPU性能迅速增长，并强大到足以在后台实现32通道混音，16-bit采样精度和线性插值等功能。这让任何具备16-bit DAC的声卡如 Sound Blaster 16或Pro Audio Spectrum 16）都可以以和UltraSound几乎相同的音质播放Tracker音乐。
2. CD-ROM进入主流市场，许多游戏开始仅仅使用CD音轨作为音乐，任何声卡都无法在这一领域展开竞争。
3. 游戏从DOS平台迁移到Windows平台。在DOS下游戏可以直接访问音频硬件，而Windows中音频硬件则被抽象出来，并必须通过API进行访问。但这种API并不特别适合像UltraSound这类基于RAM的波表合成器，这让开发者们被拘束在通用MIDI的世界中。
而上面所讲到的第二点也至少在游戏领域宣告了MIDI使命的终结。游戏配乐被事先“预制”在CD音轨或CD上的数字音频文件中，再串流到16-bit立体声DAC解码。在这一流程中MIDI同样没有它的一席之地。
（配图文字：最早支持CD音轨的游戏主机TurboGrafx-CD）
可以说，在那之后通用MIDI同样也过时了，它可能仍然是被市场所认可的标准之一，但我不认为人们会出于在电脑上听音乐的需求而使用它，因为它从来没有表现得非常出色。
MIDI标准本身仍然被用作连接合成器和其他设备的基础，同时大多数的数字音频工作站（DAW）软件都支持导入及导出标准MIDI文件。当然，这类软件通常具有自己专用的内部格式，这些格式可能包括了对MIDI的扩展，或是数字音轨信息。今天你在收音机里听到的许多歌曲中，都可能使用了某些MIDI技术进行创作。
而Tracker技术也同样被人们所使用，不仅仅是Demoscenes社区，也包括了“芯片音乐”社区，从某种程度上讲，“芯片音乐”社区是从Demoscene社区中所分离出的一部分。许多音乐家仍然会定期的发布Tracker歌曲，而许多爱好者也仍然喜欢收听Tracker音乐。
【链接9】 https://v.qq.com/x/page/l0519tlzlut.html
0 new messages