Reaper 小贴士:评说影响 Reaper 渲染性能的因素(二)

安小匠 发布于2024-07-30 暂无评论

在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次渲染的速率情况


图 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 Hz,格式为WAV 24 bit。此时,奇迹出现了:渲染速率大幅提升,达到了57.7x,是调试模式速率的3.8倍左右!


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

接着连续渲染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左右;电平表的跳动也变成了“慢镜头”,下方的波形视图像乌龟一样吃力地往前推进。


图 8 master_me的渲染情况

连续渲染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百分百接近


图 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 笔者所选插件组合的渲染情况


测试次数

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. 将该音频加载到空工程中;

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


图 21 设置工程采样率

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


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

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


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

重复导出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月刊》2024年06月第219期

 

可下载 Midifan for iOS 应用在手机或平板上阅读(直接在App Store里搜索Midifan即可找到,或扫描下面的二维码直接下载),在 iPad 或 iPhone 上下载并阅读。

 


文章出处 https://magazine.midifan.com/detail.php?month=2024-06#92

转载新闻请注明出自 Midifan.com

共有 0 条评论