| 很久没发过纠结贴了，来一个，确实也是挺纠结的。 因为现在的电脑其实性能不差， 理论上在同一个工程里完成所有乐器的编曲，然后再让歌手录音，再挂修音，再最后联合人声一起混音，是没什么硬件障碍的。 但是，注意到我上一句提到的“最后联合人声一起混音”，意味着，在录人声之前已经有对乐器进行了混音。 那么，在众多混音或音效处理插件中，有些是带有固有延迟的，比如多段压缩器之类的。 引入个2048个采样点（相当于44100Hz下的46毫秒）的算法延迟是很正常不过的事情。 那么，宿主都是有延迟补偿的，在编曲工程里录人声，实时监听的延迟就会至少有46ms的延迟。对歌手的发挥肯定是会造成问题的。 而有些宿主，是支持一键关闭所有带有延迟的插件（包括最古老的Cubase 5）。 但是关闭后，伴奏听起来和原来还是有很大差别的，同样影响歌手发挥。 而且，很多人也发现，当乐器使用了Key switch后，反复回去再播放，只要不触及KSW的音符，就会使用最后一次激活的KSW奏法。 这样会在反复录某一段的时候，部分乐器的奏法短时间内不正确。 这样同样会导致给歌手录音影响发挥。 注意这里我都不会提到什么内存、CPU不足，硬盘转不过来等用钱就能解决的音素…… 而且，在众多录音棚里，其实也不太可能装上所有的音色库，和所有的音效插件。 这样如果要去录音棚里录音，其实最现实的方法， 依然还是只把伴奏导出一份，然后用独立的工程，给歌手录好干声后 再拿回工作室做混音的吧？ 这个混音就基本都是和原编曲工程混在一起即可，因为已经没有实时录音监听的必要性了。 这里想了解一下，各位是否是一站式、单工程来做一个编曲+录人声+混音的呢？ ==术语解释=== 算法延迟，不因为CPU和内存多高级就能变小的东西。 比如一个算法就是需要囤够2048个采样才能做一次运算（比如FFT），那么你的整个工程的最小延迟就是2048个点（46ms）。 延迟补偿——当一个音轨的固有延迟为A，那么为了让所有音轨与之同步，都推迟A延迟。比如用来录音的人声轨，就会因此而产生最低A延迟的实时响应。 |
zhoujie613 发表于 18-7-8 21:22
我纠结的是一键入库5.8版，虽然便携版比较方便了，可是便携版没有aax,实际上你的一键入库针对安装版得5.8是 ...
hjun 发表于 18-7-19 10:30
如果在cubase混音冻结轨道应该就行了吧