- 第 3 页 -
ibicfyou 发表于 20-5-31 15:54
目前导了25分钟了， CPU的占用没有任何变化， 还是很低。 我取消导出了， 再等几个小时已经没有意义了。
...
别争了兄弟，真的。你拿你自己的需求非往别人身上套根本没多大意义。你是不是从来没有在工程已经收尾的阶段录过音？在1024的缓冲下能进行录音吗？你调到128再试试？都不用让你挂很多插件，就挂个RX7 Voice De-noise降噪加个Waves的PRS箱模好了（实际上一个效果链上的插件肯定会更多），试试看？
第二个实验里，你更是犯了一个基础性错误。你把一个文件复制次数再多，可实际上还是重复调用那一个文件而已，得要把它们并轨一次才行啊。
沙人 发表于 20-5-31 21:49
别争了兄弟，真的。你拿你自己的需求非往别人身上套根本没多大意义。你是不是从来没有在工程已经收尾的阶 ...
我没有太理解你一直在重复的这个大buffer不适合录音的事情。 所有人都知道录音时需要尽量小的buffer。 我前面截图是说在混音中， 所以buffer调成了1024。 你如果在工程收尾时或任何时间需要录音就再把buffer调小不就行了吗？ 所有和录音无关的插件旁通掉就好了啊？ 有人录音时要挂着6百多个插件吗？ 那是个典型的混音的例子， 临时要补录东西就把buffer临时调小， 这个有什么操作难度吗？ 你在补录东西的时候也把所有轨道上混音用的所有插件全开着的？
第二个例子里我不认为有什么基础性的错误。 同一个音频块复制很多次和一个单独很长的音频块在插件处理上并不会有什么区别。 晚点我会把那轨内录成完整的一个人声轨然后再导出一次， 给你看下CPU占用并不会有什么区别。
ibicfyou 发表于 20-5-31 22:16
我没有太理解你一直在重复的这个大buffer不适合录音的事情。 所有人都知道录音时需要尽量小的buffer。 我 ...
你说了半天全不在重点上，我所表达的意思是你在1024缓冲的时候尽管看着CPU有百分之50富裕，但调到128很可能就录不下去。当然如果真的录不下去的时候肯定要再想办法，但那是另一码事。
第二个问题，你就太太太天真了。一个文件复制一百次，它的体积还是那么大，但是如果把它合并一次你知道它体积有多大吗？
沙人 发表于 20-5-31 22:42
你说了半天全不在重点上，我所表达的意思是你在1024缓冲的时候尽管看着CPU有百分之50富裕，但调到128很可 ...
第二个问题， 也不知道是我太太太天真还是你太太太会异想天开。 我从来不知道插件实时动态处理所占CPU还跟音频块的体积有关系， 呵呵。 照你要求， 本身音频块是6分钟左右长度， 我复制之后导出了一个大约24分钟的， 一个3个半小时的。 然后再挂上一模一样的插件分别并轨了一次（人声轨上挂了10个插件包括2个EQ， 2个压缩， 2个通道条， 2个混响， 1个降噪， 1个trim， 总线上挂了1个通道条1个前面那个朋友要求的L316压缩）。
3次并轨的截图如下： 6分钟的音频并轨CPU最高核心占用25%峰值46%， 24分钟的是27%和41%， 3个半小时的是26%和46%。 说明并轨时音频素材的长度对CPU的占用率没有任何影响。这也很好理解， 因为插件是实时动态处理的， 对CPU的占用并不会随着时间累积， 并不会一直占着不放所以时间越长就占用越高。
用事实说话， 别想当然， 也别人云亦云。
ibicfyou 发表于 20-6-1 01:19
好吧， 第一个问题， 你坚持要讨论无论录还是混都要128轨640多个插件全开并且保持128buffer不能改， 这种情 ...
说你抓不住重点你还真是抓不住啊。
我之前说的有什么地方不清楚吗？
一条效果链只能运行在一个CPU核心上，就说明核心频率越高，在越低的延迟缓冲下可支持的实时处理越强。这个很难理解吗？
你自己看你截的那图，是不是就算在离线处理状态下，CPU依然也就是两轨走了俩核心？假如我CPU最高频率是5G，你CPU是3G，那有很大可能性我运行在128缓存下就可以很好的完成实时录音的任务，而你就不行！这个也很难理解吗？
第二，我所指出你的“基础性错误”是你竟然是把“1个文件复制多次”当成“单个素材文件”，就算你拿占用率说事，跟我说的也没什么关系。并且，重点是：我们讨论的是核心频率越高，越有利于完成一条效果链的处理（这里根本没说核心的数量就不重要，完全是两码事）。你自己截的图你倒是再看看去？你现在的CPU没有满载是因为你就俩轨道，当你轨道数几倍于核心数量的时候，你cpu肯定满载，这时候核心频率越高的CPU，导出速度肯定就越快！这是基本逻辑好不好，就这还用得着再做个实验吗？
也懒得再跟你争了，希望围观的网友们看完这个帖子之后能够知道自己该如何选择自己需要的CPU，也就算没浪费时间吧。
沙人 发表于 20-6-1 02:07
说你抓不住重点你还真是抓不住啊。
我之前说的有什么地方不清楚吗？
哈哈哈 你可真逗。
首先 截图里并不是两轨走了两核心。 只是两个线程， 并不是两个核。 而且你数一下就会发现， 那两个线程是属于同一个核心的。 也就是说我现在2个轨道只是用了一个核心（因为这么低的占用率根本不需要其它核心参与）。 哈哈哈， 打脸吗？ 而且照你的逻辑一轨如果要单独的一核， 那我前面128轨时怎么没有128个核占用呢？你这个所谓一轨只能由一核来处理简直是我今年听过的最搞笑的段子了。
“轨道数几倍于核心数时肯定满载”？ 前面128轨的截图你又忘了？ 满载了吗？我CPU仅仅只有6核而已。
在CPU满载之前， 导出速度是由daw决定的， 和CPU没关系。 前面的截图已经证明了无数次了， 不要再误导人了 本帖最后由 ibicfyou 于 20-6-1 02:49 编辑
观众反应
ibicfyou 发表于 20-6-1 02:22
哈哈哈 你可真逗。
首先 截图里并不是两轨走了两核心。 只是两个线程， 并不是两个核。 而且你数一下 ...
你把你那128轨的工程离线并轨一下给我们看看CPU满载不满载？你拿一个两轨的工程在这自欺欺人呢！我说128缓冲下实时录音考验核心主频，你就非要用1024缓冲下混音来说事；我说轨道较多的工程“离线并轨”时CPU会满载你让我看你没并轨时的实时CPU状态。今天我终于懂了一个成语“鸡同鸭讲”！ 本帖最后由 沙人 于 20-6-1 11:21 编辑
沙人 发表于 20-6-1 11:16
算了，祝你玩的高兴吧，都挺忙的。 本帖最后由 沙人 于 20-6-1 11:23 编辑
行， 128轨插件挂满离线并轨导出， 自己看图吧
不止是没有满载， 而是还差的很远很远。
还有你那个一轨只能由一个核心处理的论调， 这可是128轨哦， 但CPU只有6核， 自己看图， 哈哈哈。
ibicfyou 发表于 20-6-1 13:31
行， 128轨插件挂满离线并轨导出， 自己看图吧
你赢了！我说真的。
虽然明明你截图里PT的并轨速度从3x下降到了1x，但是你的CPU都看着很闲啊！
虽然到现在你也看不懂一轨的信号流只能通过一个核心来处理代表什么意思，但是你现在会算数了啊！
虽然傻瓜都知道同样核心数量前提下cpu的频率越高越好，但是你不是傻瓜啊！
所以，你赢了。再见！
沙人 发表于 20-6-1 15:49
你赢了！我说真的。
虽然明明你截图里PT的并轨速度从3x下降到了1x，但是你的CPU都看着很闲啊！
啧啧啧， 音频上几千分的大神们原来很多都是这种水平， 连电源管理是什么都不知道一有问题就给CPU甩锅， 自己用的DAW平台里的优化问题也敢替其它所有平台下结论一概而论说是某个硬件对音乐制作的影响 。
我跑32轨不满载你说是因为工程小， 我跑128轨不满载你说是因为文件是复制的没导出， 我导出2轨再跑不满载你说是因为只有两轨， 而且是因为在混音阶段不是导出阶段， 如果离线导出必定满载， 我又跑了128轨离线导出依然不满载， 你又开始阴阳怪气人身攻击。 哈哈哈， 佩服佩服。
不过无所谓了， 反正大神们的电脑也不是我出钱买的， 随便怎么用都是你们自己的事情， 轮不到我说话， 我闭嘴了。 配10G的CPU都没问题， 只要你们乐意，祝大神们用的开心。哈哈哈。
songzhuo 发表于 20-8-10 22:36
pt开工程按住shift 可以旁通所有插件。然后总线对付下音量，应该也是可以迅速展开收尾录音工作。
我的PT怎么是按住win键点击插件效果，后面的效果全部旁通，而且还是只针对这一条轨道，有没有一键旁通所有轨道插件，包括主推子轨道的快捷键呢？谢谢！
三棵树 发表于 21-5-26 01:52
哇，这么专业！弱弱的问：不管是混音还是编曲，工程保存时间久，何解？cpu：i7 宿主：nurndo10 硬盘：固 ...
工程保存，从原理上考虑。
都是从内存里，通过CPU的计算，给硬盘保存（大部分需要先通过缓存），内存方面不用考虑，缓存基本也不用考虑。主要是CPU和硬盘的问题