Reaper 小贴士:评说影响 Reaper 渲染性能的因素(二)
在REAPER中,完成编曲、混音工作后,就是通过渲染(render)来导出最终的Mix。每一次渲染,都见证着你的作品从Demo到定稿的精炼过程,也时时刻刻检验着电脑软硬件的性能。若能理解一些改善渲染性能的要素,并着手作出调整,那么编曲制作的体验将大大改善,尤其适用于需要经常打磨作品的场景。
上一篇文章,笔者评说了一些基本的性能影响因素,包括处理器、内存、磁盘、导出格式等,通常改善这些因素就足以使编曲体验实现质的飞跃。实际上,还有其他一些看似微不足道、较容易被忽略的细节因素,例如插件性能、采样率等,也在无形之处关系着渲染的性能表现。且让笔者继续细细评说,若能给大家带来哪怕是小小的一点启发,笔者也荣幸之至。
系列第一篇文章:《评说影响REAPER渲染性能的因素(一)》
第一章 插件本身的性能
在加载VST、CLAP等插件的情况下,无论是回放还是渲染,REAPER都会按照插件的开发规范,调用它们的音频处理程序来实时处理音频信号。在这一过程中,插件本身的性能起到不容忽视的作用。
然而,各类插件的开发水平参差不齐:遇到设计精妙、经过充分优化的插件,自然能使渲染过程事半功倍;而遇到设计失当、优化工作欠火候的插件,则常常会拖慢整体的渲染性能。而对于笔者这样的插件开发维护者来说,有没有在编译插件的过程中启用优化,对插件的性能也起到重要影响。
由于影响插件性能的因素各异,笔者无法触及所有可能的方面。那么,笔者就从自己在日常音乐制作、插件开发中感触最深的两个场景,来展示插件性能对渲染表现的影响。
1.1 测试环境
笔者在以下平台进行评测:
- 计算机:ThinkPad R400
- 处理器:Intel Core 2 Duo P9500 @ 2.53GHz
- 操作系统: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 Hz。
图 2 工程设置窗口。红圈处为工程采样率设置,将其设为44100 Hz
第三步,建立一个空音轨,将事先准备的一个较长的单音轨MIDI片段导入该音轨中。然后,将Minaton加载到音轨中。试着回放,随着Minaton的播放,CPU占用率迅速升到3.0,即使停止回放也依然保持这一水平。
图 3 加载调试版本的Minaton,回放时处理器占用率达到了3.0左右
第四步,开始渲染。按Ctrl+R打开「Render to file」界面,保持界面中的渲染设置为默认值——重点是采样率保持在44100 Hz,格式为WAV 24 bit(以免其他因素影响测试结果)。连续渲染5次,结果如下:
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 16.5x | 15.1x | 15.7x | 15.7x | 15.1x |
表 1 调试版本Minaton连续5次渲染的速率情况
全程渲染速率稳定保持在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 Hz,格式为WAV 24 bit。此时,奇迹出现了:渲染速率大幅提升,达到了57.7x,是调试模式速率的3.8倍左右!
接着连续渲染5次,结果更令笔者惊叹——全程稳定保持在高水平。即使是相对最慢的46.0x左右的速率,也是调试模式下的3倍:
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 56.4x | 52.0x | 53.1x | 54.4x | 46.3x |
表 2 优化版本Minaton连续5次渲染的速率情况
看似只减少了2.0的处理器占用,却带来了四两拨千斤的效益。可见,仅仅在编译时进行优化,就能为Minaton带来极其显著的优化效果,挣脱性能枷锁,尽情展现其强劲的本色,助力编曲制作体验的提升。
以上测试足以证明,插件本身优化前后的性能变化,可以从根本上影响最终的渲染效率。
1.4 测试场景二:重点测试一些占用处理器资源极高的插件(以master_me为例)
开发插件时,笔者也会参考一些开源插件,学习作者的设计理念与编程技巧。不过,笔者总会在这一过程中,碰到个别在优化上做得不到位的插件,处理器占用率高达两位数。那么,这样的插件又会如何影响渲染性能?
笔者选择由德国开发者Klaus Scheuermann主导开发的开源母带处理插件master_me,来进行测试。它以流水线的方式,整合了均衡器、门限器、多段压缩器等多个处理流程,提供一站式的母带调优体验。但是,现阶段它仍欠优化,处理器占用率居高不下。
1.4.1 测试master_me
第一步,从官方GitHub页面(https://github.com/trummerschlunk/master_me/releases/tag/1.2.0)下载1.2.0版本的插件,将其VST3版本复制到REAPER的插件搜索目录中(在Linux下为“<主目录>/.vst3”)。
第二步,打开REAPER,创建新工程。按照“1.3.1.3.1 调试版本的插件 ”这一节的说明,将工程采样率设置为44100 Hz。
第三步,添加一个音轨,将笔者事先准备好的音频导入到音轨中。测试的音频为张秀卿的歌曲《车站》,时长4分13秒,FLAC格式,采样率为44100 Hz,位深度为16 bit。
第四步,将master_me加载到音轨中,并确保仅加载master_me这一个效果器。令笔者惊讶的是,还没开始回放(空载状态),处理器占用率就已经达到了惊人的22.5。随着时间推移,处理器占用率还会飙升到35以上。
图 7 空载状态的master_me。注意,FX Chain窗口显示的处理器占用率达到了22.5之高
第五步,开始渲染。按Ctrl+R打开「Render to file」界面,音频格式设置为WAV 16 bit(使位深度与测试音频相同),采样率设为44100 Hz。其余设置保持默认值。
渲染过程如下图所示。笔者最直观的感觉,就是整个渲染过程仿佛按下了“慢放键”。渲染速率缓慢,只有2.2x左右;电平表的跳动也变成了“慢镜头”,下方的波形视图像乌龟一样吃力地往前推进。
连续渲染5次,结果如下表所示,一直稳定保持在2.2~2.4x的超低水平。
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 2.2x | 2.4x | 2.3x | 2.3x | 2.4x |
表 3 master_me连续5次渲染的速率情况
1.4.2 对照组之一:禁用所有插件
为了更好地对比master_me启用前后的性能,笔者以禁用插件的场景作为对照。
第一步,找到音轨视图上的“FX”按钮(图 9红圈处),点击该按钮右边的“电源”图标,禁用音轨上的所有效果器(实际上该音轨只加载了master_me)。
图 9 禁用音轨上的所有效果器
第二步,再以同样的渲染配置,进行5次渲染。渲染结果如下方图 10、表 4所示,性能优异,可以达到140.0x左右。
图 10 禁用master_me效果器后的渲染情况
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 140.4x | 133.7x | 150.9x | 140.8x | 143.6x |
表 4 禁用master_me后,连续5次渲染的速率情况
可见,仅仅是1个master_me,就足以把渲染速率由无效果器状态下的140.0x大幅度拉低到个位数,甚至还没有超过3.0x。它对性能的影响可见一斑。
1.4.3 对照组之二:选用其他插件组合
master_me本身整合了一系列效果器,作为母带处理的流程。在默认设置下,master_me启用了所有的处理流程,它们对性能的影响累加起来,就造成了30.0以上的处理器占用率。
在master_me的界面中,点击“Expert”按钮进入专家视图,就可以看到它支持的所有流程,如图 11所示。为了对比这些流程对性能的影响,笔者将选用同类效果器来实现相近的功能,对应关系如下(从左上角开始顺时针列举):
master_me处理流程 | 对应的REAPER插件 |
Pre-Processing(预处理) | (不进行测试,保持master_me该部分为默认值) |
Gate(门限效果器) | VST: ReaGate |
EQ(倾斜均衡器) | JSFX: Tilt Equalizer |
Leveler(电平自动平衡校准) | TriLeveler2 |
Limiter(振幅限制器) | JSFX: Master Limiter |
Brickwall(砖墙效果器) | ReaLimit(一并提供了砖墙效果器功能) |
Multiband MidSide Compressor(多段压缩器) | ReaXComp |
Knee Compressor(拐点压缩器) | ReaComp |
表 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百分百接近
第四步,设置完成后,进行回放,观察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 笔者所选插件组合的渲染情况
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 14.4x | 13.9x | 12.6x | 13.5x | 14.0x |
表 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 Hz,以及各类系统平台、音乐平台常用的48000 Hz,已经能满足日常收听的需求,能很好地保留原始音频。
但是,无论是专业的音乐制作部门与录音棚,还是挚爱极品音质的影音发烧友,专业人群自然不会止步于此,更高的采样率是刚需。音频的采样率越高,就意味着单位时间内能容纳的采样越多,音频越接近传统波形,从而更能忠实地记录声音信息,保证音频呈现的效果。对音乐发烧友来说,96 kHz到192 kHz的Hi-Res音乐、Blu-Ray音轨能带来极致的聆听体验,尽显声音的真实魅力;对专业音频工程师来说,高采样率提供了广阔的后期制作空间,利于精细加工音频(尤其是vocal)。
不过,导出高采样率的音频,意味着处理的数据量将会增多,渲染的时间可能会有所延长。因此,如果你的时间紧张,或者是电脑配置相对吃紧,你也需要考虑是否仍需导出高采样率(大于48000 Hz)的音频。接下来,笔者将会分两类情况,来评测不同采样率对REAPER渲染速度的影响。
2.1 测试情形一:原生高采样率音频,按相同采样率导出
笔者评测的第一种情形,是原生音频即为高采样率(如192000 Hz)的情形。典型的实践是,使用高采样率在录音棚实录人声与乐器,在REAPER中进行处理。那么,渲染高采样率的音频,性能表现如何?
笔者事先准备了一段192000 Hz的音频,位深度24 bit,使用WavPack压缩,时长2分33秒。依次进行以下步骤准备:
1. 将该音频加载到空工程中;
渲染速率如下图所示。可见,相比上一篇文章“第三章 目标编码器格式”里使用的44100 Hz音频(可达到180.0x左右的渲染速率),性能明显低不少,只有19.0x。
重复导出5次,性能表现如下表所示,基本稳定在18.0~19.5x这个区间:
测试次数 | 1 | 2 | 3 | 4 | 5 |
速率 | 18.3x | 18.8x | 19.0x | 19.1x | 19.2x |
表 7 将192000 Hz的素材,按相同采样率连续5次渲染的速率情况
进一步,如果采用稍低的采样率,性能会不会有所提高?笔者使用第三方软件FFmpeg,将原始音频文件重新采样为不同采样率的版本,再分别创建多个新的工程,遵循与上文同样的步骤进行测试(注意,渲染采样率要与素材采样率保持一致)。结果如下表所示:
测试次数 | 1 | 2 | 3 | 4 | 5 | |
速率 | 176400 Hz | 19.8x | 18.7x | 18.3x | 18.4x | 17.8x |
96000 Hz | 31.5x | 30.8x | 30.7x | 30.4x | 31.0x | |
88200 Hz | 34.1x | 34.7x | 34.8x | 34.0x | 32.3x | |
48000 Hz | 60.9x | 61.7x | 60.1x | 62.2x | 62.8x | |
44100 Hz | 67.5x | 65.8x | 66.5x | 66.4x | 66.3x | |
22050 Hz | 129.5x | 129.7x | 129.5x | 127.8x | 136.9x |
表 8 使用重新采样的、不同采样率的音频素材,按各自采样率连续5次渲染的速率情况
从上表可以看出,渲染时间与采样率成正比。由于一些常用的采样率存在2倍的倍数关系(例如48000 Hz、96000 Hz与192000 Hz),故随着采样率的降低,要处理的数据量也随之减少,渲染速率变化的幅度也明显可辨。
你可以根据目标需求与自己的实际需要,选择合适的渲染采样率。例如,在录音棚导出Demo给团队试听时,为了更快导出作品节省时间,选择44100 Hz或48000 Hz足够;而如果要导出高质量母带用于后期加工,或生成适用于Hi-Res格式的高质量定稿,则可优选96000 Hz或192000 Hz采样率,此时时间的消耗不再是重点。
2.2 测试情形二:重采样
有的制作人会给REAPER的工程设置96000 Hz或192000 Hz的高采样率,并是使用上述采样率的音频素材,以保证音频质量。但很多时候,常常需要渲染44100 Hz、48000 Hz等较低采样率的音频,以供试听、音乐平台发布等。另一种情形是,使用的音源或素材,只提供较低采样率的版本(如,只提供48.0 kHz采样的Kontakt音源),但是最终却要生成较高采样率的缩混音频。
针对这些需要变换采样率的渲染情景,REAPER本身就提供了完备的重采样(resampling)功能,可以在不改变工程采样率的情况下,渲染不同采样率的音频。那么,性能表现又如何?
2.2.1 下采样
将高采样率的音频重新采样为低采样率的音频,即下采样(downsampling)。这里继续使用上一节“测试情形一:原生高采样率音频,按相同采样率导出”中的192000 Hz素材,按其中的步骤来做准备,工程采样率与素材相同。
打开渲染界面,依次将采样率设为更低的值,然后进行导出。测试结果如下:
测试次数 | 1 | 2 | 3 | 4 | 5 | |
速率 | 176400 Hz | 5.7x | 5.7x | 6.0x | 6.5x | 6.5x |
96000 Hz | 13.6x | 14.0x | 13.9x | 13.6x | 15.0x | |
88200 Hz | 11.5x | 10.7x | 11.4x | 11.4x | 11.4x | |
48000 Hz | 18.0x | 17.6x | 18.3x | 18.1x | 18.4x | |
44100 Hz | 16.2x | 15.7x | 15.5x | 16.8x | 10.1x | |
22050 Hz | 17.7x | 17.5x | 18.0x | 17.7x | 17.9x |
表 9 按不同采样率对192000 Hz的素材下采样,连续5次渲染的速率情况
相较于以原始采样率导出,下采样会使导出性能明显降低。例如下采样为96000 Hz时,渲染速率还不到原始采样率导出的一半。这是因为REAPER的重采样使用专门的算法来实时处理音频,在下采样的过程当中要找出需舍去的采样、保留相应的采样,本身也有一定的性能开销。
而在测试过程中,笔者也留意到,下采样时目标采样率并不必然与渲染速率成正比。例如,44100 Hz比48000 Hz采样率略低,但是渲染速率反而慢于48000 Hz。这可能是因为下采样算法在处理特定数据时,性能指标会有所波动。
2.2.2 超采样
与下采样相反,将低采样率的原始音频转换为高采样率的音频,则称为超采样(oversampling)。与下采样的“舍”不同,超采样是要“补”——利用插值算法补足采样。
这一次,使用笔者事先准备好44100 Hz音频文件,分别进行上采样渲染。结果如下列表格所示。
测试次数 | 1 | 2 | 3 | 4 | 5 | |
速率 | 192000 Hz | 6.6x | 6.3x | 6.4x | 6.5x | 6.5x |
176400 Hz | 11.0x | 11.1x | 11.2x | 9.1x | 11.2x | |
96000 Hz | 11.6x | 12.4x | 12.1x | 11.7x | 12.6x | |
88200 Hz | 20.4x | 20.3x | 22.4x | 20.5x | 20.1x | |
48000 Hz | 20.4x | 20.1x | 19.5x | 20.2x | 21.4x |
表 10 将44100 Hz原始音频上采样,连续5次渲染的速率表现
从总体上看,进行超采样时,目标采样率越高,则渲染速率越低。但它并不是单纯的线性关系,而是呈现出阶梯形的变化——48000 Hz、88200 Hz,以及96000 Hz、176400 Hz,这两组采样率在数值上相差不小,但渲染性能相差无几。
总体性能上,超采样的表现也不及以原生采样率导出的情况,因为超采样对计算的要求更高——需要通过专门的算法来推算出要补齐哪些采样。而与下采样相比,二者实为难分伯仲。
2.3 结论
采样率对渲染性能的影响,从宏观上是有“采样率越高,渲染速率越慢,处理时间越长”这一规律的。并且在多了重采样这一步后,渲染速率会进一步下降,远不及原生音频导出的情况,但依然落在我们允许的范围内,不至于过分拖累性能。
如果你对渲染时间有要求(例如需要频繁与团队分享Mix Demo),或者是电脑配置不足,你可能要考虑是否仍需导出高采样率的音频。但对于近几年的电脑配置来说,采样率的变化已经不至于造成负担,尽管按照你的预期来选择。
小结
以上就是《评说影响REAPER渲染性能的因素》的第二部分。
笔者详细评测了对渲染性能产生显著影响的另外两大方面——插件本身的性能,以及采样率的选择。它们都属于软件方面,触手可及。
其中,采样率影响数据量,越高的采样率意味着越大的数据量,使渲染速率降低、渲染时间增加;而插件性能的影响甚至更加显著,插件的优化做足、性能提升,自会提升渲染速率,改善音乐制作的体验。这启示每一位音乐制作人,一是要根据自己的实际需要来选择REAPER的采样率,二是要优先选择经过优化的插件,以保证最优的音乐制作体验。
接下来的第三部分,笔者还有更多值得分享的内容,且待笔者下回继续评说。
可下载 Midifan for iOS 应用在手机或平板上阅读(直接在App Store里搜索Midifan即可找到,或扫描下面的二维码直接下载),在 iPad 或 iPhone 上下载并阅读。