Reaper 小贴士：评说影响 Reaper 渲染性能的因素（二）

在REAPER中，完成编曲、混音工作后，就是通过渲染（render）来导出最终的Mix。每一次渲染，都见证着你的作品从Demo到定稿的精炼过程，也时时刻刻检验着电脑软硬件的性能。若能理解一些改善渲染性能的要素，并着手作出调整，那么编曲制作的体验将大大改善，尤其适用于需要经常打磨作品的场景。

上一篇文章，笔者评说了一些基本的性能影响因素，包括处理器、内存、磁盘、导出格式等，通常改善这些因素就足以使编曲体验实现质的飞跃。实际上，还有其他一些看似微不足道、较容易被忽略的细节因素，例如插件性能、采样率等，也在无形之处关系着渲染的性能表现。且让笔者继续细细评说，若能给大家带来哪怕是小小的一点启发，笔者也荣幸之至。 

系列第一篇文章：《评说影响REAPER渲染性能的因素（一）》

在加载VST、CLAP等插件的情况下，无论是回放还是渲染，REAPER都会按照插件的开发规范，调用它们的音频处理程序来实时处理音频信号。在这一过程中，插件本身的性能起到不容忽视的作用。

然而，各类插件的开发水平参差不齐：遇到设计精妙、经过充分优化的插件，自然能使渲染过程事半倍；而遇到设计失当、优化工作欠火候的插件，则常常会拖慢整体的渲染性能。而对于笔者这样的插件开发维护者来说，有没有在编译插件的过程中启用优化，对插件的性能也起到重要影响。

由于影响插件性能的因素各异，笔者无触及所有可能的方面。那么，笔者就从自己在日常音乐制作、插件开发中感触最深的两个场景，来展示插件性能对渲染表现的影响。

1.1 测试环境

笔者在以下平台进行评测：

• 计算机：ThinkPad R400
• 处理器：In Core 2 Duo P9500 @ 2.53G
• 操作系统：Arch Linux（内核版本6.6.14 LTS）
• REAPER版本：6.83。全程只使用一个音轨，不加载任何效果器。

为简便起见，本文以渲染速率来作为性能指标，以倍数表示，在渲染结果界面中会有显示。注意：

• 所有编码器如未经说明，均采用REAPER的默认参数。尤其是采样率算（Resample mode）保持默认值“Sinc Interpolation: 192pt”。
• 渲染工作模式采用Full-speed Offline（全速离线渲染）。
• 关闭其他导致大量资源占用的程序，如Chrome浏览器、VS Code等。

下文如没有特殊说明，均采用这一测试环境。

1.2 判断插件性能的指标：处理器占用率

一款优化得当的插件，在空载和处理过程中的处理器占用率要尽可能小。如果在同等条件下（相同的电脑配置、声卡配置、音频素材、电脑负载等）处理器占用率偏高，就说明一定是哪一个环节过分消耗着处理器资源，多多少少会拖累REAPER的性能。

例如，在笔者的ThinkPad R400上，一款简易的电子合成器——只有一个OSC和LFO，不带任何效果器——通常处理器占用率可以控制在1.0以内。但是，如果处理器占用率飙升到5.0，甚至两位数，就说明插件内部的设计出了问题，导致不必要的性能损失。

我们可以通过观察插件的处理器占用率，来预判它对接下来渲染过程的影响。REAPER的FX Chain界面左下角，实时显示着当前插件及整个FX Chain的处理器占用情况，如图 1所示。笔者的做是，先进行回放，观察音频处理状态下插件的处理器占用；然后再点击REAPER走带栏的“Stop”按钮，停止回放并使插件进入空载状态，再观察此时的处理器占用情况。

图 1 REAPER FX Chain界面。左下角的两个百分比，分别对应当前插件与整个FX Chain的处理器占用率

1.3 测试场景一：启用优化前后的插件

一款优秀的插件，会在每一次推出新版本之前进行精心的优化，例如优化DSP算、优化图形界面、采用优化的参数来编译，等等。根据笔者在插件开发过程中的体悟，倘若优化工作没有做好，插件性能将会大打折扣，最终会拖慢渲染的速度；相反，做足了优化，就会使插件性能迅猛提升，对你、对广大制作人来说可谓利在千秋。

这里测试的，是一款Moog风格的开源合成器插件——Minaton（详细介绍在这里：《把时间的味道玩出花样：免费模拟仿真合成器插件Minaton评测》）。在使用不同的编译模式构建时，处理器占用率会有较大差异。笔者按如下步骤来进行测试。

1.3.1 调试版本的插件

首先测试调试版本的Minaton。为便于开发者调试，这一版本不仅没有进行任何优化，还增加了一些与调试相关的代码，因此牺牲了性能。

第一步，笔者以调试模式（Debug）来编译Minaton，将其VST 2.4版本到REAPER插件搜索目录中。

第二步，打开REAPER，创建新工程。然后，点击「File」->「Project settings...」，打开工程设置。勾选顶部的“Project sample rate”，将这里的采样率设置为44100 。

图 2 工程设置窗口。红圈处为工程采样率设置，将其设为44100

第三步，建立一个空音轨，将事先准备的一个较长的单音轨MIDI片段导入该音轨中。然后，将Minaton加载到音轨中。试着回放，随着Minaton的播放，CPU占用率迅速升到3.0，即使停止回放也依然保持这一水平。

图 3 加载调试版本的Minaton，回放时处理器占用率达到了3.0左右

第四步，开始渲染。按Ctrl+R打开「Render to file」界面，保持界面中的渲染设置为默认值——重点是采样率保持在44100 ，格式为W 24 bit（以免其他因素影响测试结果）。连续渲染5次，结果如下：

表 1 调试版本Minaton连续5次渲染的速率情况

图 4 调试版本Minaton的渲染情况

全程渲染速率稳定保持在14.0x～16.5x这个区间。考虑到工程只有一个音轨，MIDI片段也很简单，对Minaton来说，如此性能并不理想。

1.3.2 优化版本的插件

调试版本的插件，会给插件的潜能筑起一圈“樊篱”。那么，如果以精心的优化来拆掉“樊篱”，渲染性能会不会有所提高？

第一步，笔者以发布模式（Release）来编译Minaton，这一模式会为Minaton启用完全的优化，提升程序运行效率。编译完成后，将其VST 2.4版本到REAPER插件搜索目录中，覆盖原先的调试版本。

第二步，按照上一节“1.3.1 调试版本的插件 ”，新建工程、载入MIDI片段，加载Minaton，然后试着回放。可见，回放时，处理器占用率降到了0.9～1.0，空载状态下处理器占用也控制在0.7左右，优化效果已经很显著了。

图 5 加载优化版本的Minaton，回放时处理器占用率控制在1.0以内

第四步，开始渲染。按Ctrl+R打开「Render to file」界面，继续保持界面中的渲染设置为默认值——重点是采样率保持在44100 ，格式为W 24 bit。此时，奇迹出现了：渲染速率大幅提升，达到了57.7x，是调试模式速率的3.8倍左右！

图 6 优化版本Minaton的渲染情况

接着连续渲染5次，结果更令笔者惊叹——全程稳定保持在高水平。即使是相对最慢的46.0x左右的速率，也是调试模式下的3倍：

表 2 优化版本Minaton连续5次渲染的速率情况

看似只减少了2.0的处理器占用，却带来了四两拨千斤的效益。可见，仅仅在编译时进行优化，就能为Minaton带来极其显著的优化效果，挣脱性能枷锁，尽情展现其强劲的，助力编曲制作体验的提升。

以上测试足以证明，插件本身优化前后的性能变化，可以从根本上影响最终的渲染效率。

1.4 测试场景二：重点测试一些占用处理器资源极高的插件（以master_me为例）

开发插件时，笔者也会参考一些开源插件，学习作者的设计理念与编程技巧。不过，笔者总会在这一过程中，碰到个别在优化上做得不到位的插件，处理器占用率高达两位数。那么，这样的插件又会如何影响渲染性能？

笔者选择由德国开发者Klaus Scheuermann主导开发的开源母带处理插件master_me，来进行测试。它以流水线的方式，整合了均衡器、门限器、多段压缩器等多个处理流程，提供一站式的母带调优体验。但是，现阶段它仍欠优化，处理器占用率居高不下。

1.4.1 测试master_me

第一步，从官方GitHub页面（https://github.com/trummerschk/master_me/releases/tag/1.2.0）下载1.2.0版本的插件，将其VST3版本到REAPER的插件搜索目录中（在Linux下为“/.vst3”）。

第二步，打开REAPER，创建新工程。按照“1.3.1.3.1 调试版本的插件 ”这一节的说明，将工程采样率设置为44100 。

第三步，添加一个音轨，将笔者事先准备好的音频导入到音轨中。测试的音频为张秀卿的歌曲《车站》，时长4分13秒，FLAC格式，采样率为44100 ，位深度为16 bit。

第四步，将master_me加载到音轨中，并确保仅加载master_me这一个效果器。令笔者惊讶的是，还没开始回放（空载状态），处理器占用率就已经达到了惊人的22.5。随着时间推移，处理器占用率还会飙升到35以上。

图 7 空载状态的master_me。注意，FX Chain窗口显示的处理器占用率达到了22.5之高

第五步，开始渲染。按Ctrl+R打开「Render to file」界面，音频格式设置为W 16 bit（使位深度与测试音频相同），采样率设为44100 。其余设置保持默认值。

渲染过程如下图所示。笔者最直观的感觉，就是整个渲染过程仿佛按下了“慢放键”。渲染速率缓慢，只有2.2x左右；电平表的跳动也变成了“慢镜头”，下方的波形视图像乌龟一样吃力地往前推进。

图 8 master_me的渲染情况

连续渲染5次，结果如下表所示，一直稳定保持在2.2～2.4x的超低水平。

表 3 master_me连续5次渲染的速率情况

1.4.2 对照组之一：禁用所有插件

为了更好地对比master_me启用前后的性能，笔者以禁用插件的场景作为对照。

第一步，找到音轨视图上的“FX”按钮（图 9红圈处），点击该按钮右边的“电源”图标，禁用音轨上的所有效果器（实际上该音轨只加载了master_me）。

图 9 禁用音轨上的所有效果器

第二步，再以同样的渲染配置，进行5次渲染。渲染结果如下方图 10、表 4所示，性能优异，可以达到140.0x左右。

图 10 禁用master_me效果器后的渲染情况

表 4 禁用master_me后，连续5次渲染的速率情况

可见，仅仅是1个master_me，就足以把渲染速率由无效果器状态下的140.0x大幅度拉低到个位数，甚至还没有超过3.0x。它对性能的影响可见一斑。

1.4.3 对照组之二：选用其他插件组合

master_me本身整合了一系列效果器，作为母带处理的流程。在默认设置下，master_me启用了所有的处理流程，它们对性能的影响累加起来，就造成了30.0以上的处理器占用率。

在master_me的界面中，点击“Expert”按钮进入专家视图，就可以看到它支持的所有流程，如图 11所示。为了对比这些流程对性能的影响，笔者将选用同类效果器来实现相近的能，对应关系如下（从左上角开始顺时针列举）：

表 5 master_me处理流程与REAPER插件的对应关系

注：TriLevel2需要使用ReaPack安装，导入Sonic Anomaly团队的软件源（https://raw.githubusercontent.com/Sonic-Anomaly/Sonic-Anomaly-JSFX/master/index.xml）。关于ReaPack的使用方，可以参考笔者的这篇文章：《Reaper 小贴士：背起 ReaPack 的无限可能行囊——包管理器 ReaPack 入门教程》。

图 11 master_me的专家视图，展示了所有支持的处理流程

接下来，开始我们的测试流程。

第一步，继续保持工程只有一个音轨，加载了相同的素材，以及master_me。然后，点击音轨视图上的FX按钮右边的电源图标，启用所有效果器。

第二步，打开音轨的FX Chain窗口，取消效果器列表中master_me前面的勾选，禁用它。

第三步，按照上文中“表 5 master_me处理流程与REAPER插件的对应关系”的顺序，依次将插件添加到列表中，并依次按照下面的截图来调整插件参数，使其尽可能接近master_me的设置。

注意：

• master_me中的很多设置项是REAPER中对应的效果器所没有的，因此不能保证100还原。
• ReaXComp与ReaComp无自定义增益补偿（make-up），只能让其自动设置

图 12 ReaGate的参数。其中，Hold设为50 ms，Release设为500 ms，最左边的Threshold设为-90 db。其余参数保持默认

图 13 Tilt Equalizer的参数。它的设置项与master_me的均衡器不同，无再现其设置，因此暂且保持默认值

图 14 TriLeveler2的设置。与master_me的Leveler只有Speed这个参数是共通的，其余参数保持默认值

图 15 Master Limiter的设置。注意只有Hold参数能保持完全一致。Threshold暂且设置为-6.0 dB，其余参数保持默认值

图 16 ReaLimit（用作砖墙效果器）的设置。将Brickwall Ceiling设为-1.00 dB，其余参数不变。注意Release参数是以每秒衰减的分贝数为单位的，暂且设为默认值15.0 dB/sec。

图 17 ReaXComp的设置。按截图分别设置3个频段的参数，注意不能保证其效果与master_me的MidSide Compressor百分百接近

图 18 ReaComp的参数设置

第四步，设置完成后，进行回放，观察FX Chain窗口中显示的处理器占用率，如图 19所示。左下角第一个百分比为当前选中的插件处理器占用率，第二个百分比则为我们要关注的重点——FX Chain所有已启用插件的处理器占用率总和。

观察第二个百分比的变化，不难发现，即使加载了多达7个性质各异的插件（有VST与JSFX），处理器占用率也依然控制在3.5～4.5以内，远远小于master_me的20以上。

图 19 回放时的情况。FX Chain左下角第二个百分比为所有启用的插件处理器占用率的总和

再点击走带控制栏的“Stop”，停止回放。此时你能见到，空载状态下的处理器总体占用率也不到3.0。

第五步，最后，以同样的渲染配置，进行5次渲染。渲染情况如图 20、表 6所示。

图 20 笔者所选插件组合的渲染情况

表 6 选用笔者所选插件组合，连续5次渲染的速率情况

从测试结果可见，笔者这个FX Chain与master_me不相上下，而渲染的过程要丝滑流畅得多。虽然全程只在12.0～16.0x这个区间，但相比master_me仅有不足3.0x的“龟速”，已经完胜了。如此对比，更能确切证明master_me本身缺乏优化。

当然，master_me仅仅是其中一个个例。在实践中，你也许会见到其他一些优化欠妥的插件。但凡你发现一款插件，其处理器占用率居高不下，高达两位数，那么大多数情况下造成的结果就和笔者的实验所揭示的一样：REAPER的运行速度被拖慢，音频渲染的效率也被大幅度拉低。

1.5 结论

通过对REAPER中插件性能对渲染表现的影响进行深入研究，我们发现插件的设计和优化水平直接关系到整体渲染性能。处理器占用率成为判断插件性能的关键指标，合理的优化能够显著提升插件的性能表现。

在测试中，以Minaton为例，通过在编译过程中启用优化，我们观察到了处理器占用率的显著变化，从而带来了显著的性能提升，渲染速率达到了惊人的57.7x。这凸显了插件在开发过程中优化的重要性，对于提升用户体验和整体渲染效率具有积极作用。

另一方面，通过对master_me插件的测试，我们发现一些优化不足的插件可能对渲染性能产生严重的影响，导致处理器占用率高达两位数，进而拖慢渲染速度。对比测试中选用的插件组合，优化合理的插件组合在相同能实现下表现更为出色，渲染速率更为流畅。

因此，无论是开发者对插件进行优化，还是音乐制作人合理选择插件、合理构建效果器组合，对于确保REAPER的高效运行和音频渲染效果至关重要。在插件开发和使用的过程中，我们应该不断关注和优化插件的性能，以提升整体音乐制作体验。

就音频的采样率来说，通常CD格式的44100 ，以及各类系统平台、音乐平台常用的48000 ，已经能满足日常收听的需求，能很好地保留原始音频。

但是，无论是专业的音乐制作部门与录音棚，还是挚爱极品音质的影音发烧友，专业人群自然不会止步于此，更高的采样率是刚需。音频的采样率越高，就意味着单位时间内能容纳的采样越多，音频越接近传统波形，从而更能忠实地记录声音信息，保证音频呈现的效果。对音乐发烧友来说，96 k到192 k的Hi-Res音乐、Blu-Ray音轨能带来极致的聆听体验，尽显声音的真实魅力；对专业音频工程师来说，高采样率提供了广阔的后期制作空间，利于精细加工音频（尤其是vocal）。

不过，导出高采样率的音频，意味着处理的数据量将会增多，渲染的时间可能会有所延长。因此，如果你的时间紧张，或者是电脑配置相对吃紧，你也需要考虑是否仍需导出高采样率（大于48000 ）的音频。接下来，笔者将会分两类情况，来评测不同采样率对REAPER渲染速度的影响。

笔者评测的第一种情形，是原生音频即为高采样率（如192000 ）的情形。典型的实践是，使用高采样率在录音棚实录人声与乐器，在REAPER中进行处理。那么，渲染高采样率的音频，性能表现如何？

笔者事先准备了一段192000 的音频，位深度24 bit，使用WPack压缩，时长2分33秒。依次进行以下步骤准备：

1. 将该音频加载到空工程中；

2. 点击「File」->「Project settings...」，打开工程设置。勾选顶部的“Project sample rate”，将这里的采样率设置为与音频素材相同的值，以明确告知REAPER以该采样率处理音频。（注：此步骤也会同时设置声卡的采样率。如果声卡不兼容当前采样率，则可跳过这一步。）

图 21 设置工程采样率

3. 然后，按Ctrl+R打开渲染界面，以192000 的采样率导出。确保导出格式为W（无须压缩、重编码，相对来说性能最高），其余所有参数保持默认值：

图 22 将192000 素材按相同采样率渲染的参数

渲染速率如下图所示。可见，相比上一篇文章“第三章 目标编码器格式”里使用的44100 音频（可达到180.0x左右的渲染速率），性能明显低不少，只有19.0x。

图 23 将192000 的素材按相同采样率渲染的情况

重复导出5次，性能表现如下表所示，基本稳定在18.0～19.5x这个区间：

表 7 将192000 的素材，按相同采样率连续5次渲染的速率情况

进一步，如果采用稍低的采样率，性能会不会有所提高？笔者使用第三方软件FFmpeg，将原始音频文件重新采样为不同采样率的版本，再分别创建多个新的工程，遵循与上文同样的步骤进行测试（注意，渲染采样率要与素材采样率保持一致）。结果如下表所示：

表 8 使用重新采样的、不同采样率的音频素材，按各自采样率连续5次渲染的速率情况

从上表可以看出，渲染时间与采样率成正比。由于一些常用的采样率存在2倍的倍数关系（例如48000 、96000 与192000 ），故随着采样率的降低，要处理的数据量也随之减少，渲染速率变化的幅度也明显可辨。

你可以根据目标需求与自己的实际需要，选择合适的渲染采样率。例如，在录音棚导出Demo给团队试听时，为了更快导出作品节省时间，选择44100 或48000 足够；而如果要导出高质量母带用于后期加工，或生成适用于Hi-Res格式的高质量定稿，则可优选96000 或192000 采样率，此时时间的消耗不再是重点。

2.2 测试情形二：重采样

有的制作人会给REAPER的工程设置96000 或192000 的高采样率，并是使用上述采样率的音频素材，以保证音频质量。但很多时候，常常需要渲染44100 、48000 等较低采样率的音频，以供试听、音乐平台发布等。另一种情形是，使用的音源或素材，只提供较低采样率的版本（如，只提供48.0 k采样的Kontakt音源），但是最终却要生成较高采样率的缩混音频。

针对这些需要变换采样率的渲染情景，REAPER本身就提供了完备的重采样（resampling）能，可以在不改变工程采样率的情况下，渲染不同采样率的音频。那么，性能表现又如何？

2.2.1 下采样

将高采样率的音频重新采样为低采样率的音频，即下采样（downsampling）。这里继续使用上一节“测试情形一：原生高采样率音频，按相同采样率导出”中的192000 素材，按其中的步骤来做准备，工程采样率与素材相同。

打开渲染界面，依次将采样率设为更低的值，然后进行导出。测试结果如下：

表 9 按不同采样率对192000 的素材下采样，连续5次渲染的速率情况

相较于以原始采样率导出，下采样会使导出性能明显降低。例如下采样为96000 时，渲染速率还不到原始采样率导出的一半。这是因为REAPER的重采样使用专门的算来实时处理音频，在下采样的过程当中要找出需舍去的采样、保留相应的采样，本身也有一定的性能开销。

而在测试过程中，笔者也留意到，下采样时目标采样率并不必然与渲染速率成正比。例如，44100 比48000 采样率略低，但是渲染速率反而慢于48000 。这可能是因为下采样算在处理特定数据时，性能指标会有所波动。

2.2.2 超采样

与下采样相反，将低采样率的原始音频转换为高采样率的音频，则称为超采样（oversampling）。与下采样的“舍”不同，超采样是要“补”——利用插值算补足采样。

这一次，使用笔者事先准备好44100 音频文件，分别进行上采样渲染。结果如下列表格所示。

表 10 将44100 原始音频上采样，连续5次渲染的速率表现

从总体上看，进行超采样时，目标采样率越高，则渲染速率越低。但它并不是单纯的线性关系，而是呈现出阶梯形的变化——48000 、88200 ，以及96000 、176400 ，这两组采样率在数值上相差不小，但渲染性能相差无几。

总体性能上，超采样的表现也不及以原生采样率导出的情况，因为超采样对计算的要求更高——需要通过专门的算来推算出要补齐哪些采样。而与下采样相比，二者实为难分伯仲。

2.3 结论

采样率对渲染性能的影响，从宏观上是有“采样率越高，渲染速率越慢，处理时间越长”这一规律的。并且在多了重采样这一步后，渲染速率会进一步下降，远不及原生音频导出的情况，但依然落在我们允许的范围内，不至于过分拖累性能。

如果你对渲染时间有要求（例如需要频繁与团队分享Mix Demo），或者是电脑配置不足，你可能要考虑是否仍需导出高采样率的音频。但对于近几年的电脑配置来说，采样率的变化已经不至于造成负担，尽管按照你的预期来选择。

以上就是《评说影响REAPER渲染性能的因素》的第二部分。

笔者详细评测了对渲染性能产生显著影响的另外两大方面——插件本身的性能，以及采样率的选择。它们都属于软件方面，触手可及。

其中，采样率影响数据量，越高的采样率意味着越大的数据量，使渲染速率降低、渲染时间增加；而插件性能的影响甚至更加显著，插件的优化做足、性能提升，自会提升渲染速率，改善音乐制作的体验。这启示每一位音乐制作人，一是要根据自己的实际需要来选择REAPER的采样率，二是要优先选择经过优化的插件，以保证最优的音乐制作体验。

接下来的第三部分，笔者还有更多值得分享的内容，且待笔者下回继续评说。

---

本文出自《midin月刊》2024年06月第219期

 

可下载 Midin for iOS 应用在或平板上阅读（直接在App Store里搜索Midin即可找到，或扫描下面的二维码直接下载），在 iPad 或 iPhone 上下载并阅读。