I just got a new PC that I was hoping would be significantly faster than my old one. It isn’t- at least not in Wavelab.
The old PC was Windows 7, 32GB ram, 6-core i7 3.2ghz. 7200 RPM hard drive.
The new PC is Windows 10, 64GB ram, 16-core i9, really fast M.2 drive.
To render a one hour file takes about 18 minutes on both machines. iZotope RX is the real cpu killer.
Does Wavelab use more than one core for rendering?
thanks,
~Jay
Does Wavelab use more than one core for rendering?
Yes if you render several files in the same time.
But when one file is being rendered, WaveLab can’t force a plugin (iZotope RX) to use several threads, as this is under the plugin responsibility.
Jay, I went through this a few years ago trying to find ways to speed this up on a 6 core processor.
I don’t know if you have logical points of separation anyway in your hour long files, but I did, because they were really just 10 cd tracks all sequenced in an hour long montage.
In reality you could save the hour long montage as 10 separate montages, each having only one of the cd tracks, and get about 10 times faster total render speed of the entire thing, if you have enough cores, processing power and memory, by rendering all of the montages simultaneously, starting them one after the other. Or save the montages, put all the montages in a batch, add the plugin(s) to the batch, and batch render them all at once with all cores selected.
It’s not very practical, but it’s worth trying just to test the power and speed, and see how well, or not well, it works.
Is this something that iZotope can change? Or is that just how plugins work? I guess Moore’s law really did die. CPUs are no faster now than they were 6 years ago - you can just easily put a bunch of them in a PC.
My deadlines aren’t usually so short that I can’t wait 15-20 minutes.
On the bright side, If I have 16 files to master, then they should render faster than I can work.
~Jay
Ah, but if you have 15 different hour-long programs to process all at once, on that computer, you’re all set. Probably 20-25 minutes to do all of them, not much more than doing just one.
The difficulty with audio, is that we deal with ‘data in time’. The sample at time T must be computed after sample at time T-1, because T’s value generally depends a bit on T. This means, T and T-1 can’t be processed in parallel.
Each audio channel could be processed in parallel, if they don’t depend on each other. WaveLab already does that eg. for resampling and FFT computations.
PG, are there any plugins that do this? I haven’t seen any plugins do it, but I haven’t tested for it very thoroughly. And it would still just be the one instance of the plugin? No additional RAM needed?
I don’t know what plugins do. This is invisible to WaveLab.
That is one of the most elegant descriptions of this I have ever seen …
Rather than rely on plugins to process in separate threads to speed this up (none of my plugins seem to do that), what if Wavelab could process a long file in segments, with overlap, temporary files that could be stitched together automatically by the program into one render file in the end. Maybe even with embedded markers at the stitch points for reference. All done behind the scenes transparently.
On a computer with a lot of cores (or even 2 cores) it would make a huge difference in render time.
I’ve tried it manually by placing a 70 minute 96KHz file in a montage, adding 10 process-intensive plugins as clip plugins, including a reverb plugin with a 20 second reverb tail for the entire length. Then I time selected the first half of the 70 minute file and started a time selection render. Next I time selected the last half of the file, using a 30 second overlap and started a time selection render of that. The renders happened in 2 cores instead of one. Total time to render was half of what it would have been if I did it the normal way. When it was done I stitched the segments together in another montage with the stitch point at the 25 second mark of the second segment (to allow for the 20 second reverb tail). The stitch worked perfectly and then I could render the two segments to a full length file, which took a minute and a half.
Even just two processes instead of one makes a big difference. Or 3 or 4 segments for a quad core, or 10-15 segments for a 16 core, render times would be reduced dramatically, and if no one else is doing this, whoever does it will have the fastest processing of a particular file with a particular plugin chain, by a large margin. ~2 to 15 times faster depending on the number of cores mentioned in this forum thread.
Bob, this sounds like a great idea to me!
Thanks Arjan. It’s just so sad Jay is using a 16 core processor and 64 gb of memory, and the computer is using a tiny fraction of that to do the processing.
This is a pretty cool idea actually…
I’d like to ask for something like this for the Regions/All CD Track renders with markers copied, which open the renders in the same track order in a new montage. That’s how I always do it. I only rarely render from or to long single files.
Even if Wavelab could process just two of my clips at a time, it would save me a lot of time. I have some 96k montages with 12 clips, each with 10 clip plugins, and I can have render times be as long as 50 minutes for an hour program. 192k is even worse. And new plugins coming out don’t seem to be getting faster, just the opposite I would say, with longer processing times.
The Wavelab batch processor handles this beautifully with multicore processing. As I said in another thread awhile back (Clips with Plugins Render Speed - WaveLab - Steinberg Forums), I can separate all of my 12 clips with clip plugins to separate montages, dump all the montages in the batch processor with all cores enabled, and it processes everything in a fraction of the time it normally takes. But it’s too much work to do it that way, and I really need for the renders to automatically open in a new montage, in the original order, with track/clip names and markers as intended from the original master montage.
I’ve tried doing this in Reaper and Cubase using the same files and plugin chains, and it takes the same amount of time as Wavelab currently does. And the bad thing about them is you can’t get around it by doing it manually like you can in Wavelab. In the Wavelab montage I can manually start a 2nd task and have it run in another core. I can start CD Track 1 rendering, and then start CD Track 2 rendering, and they’ll run at the same time. Reaper and Cubase don’t seem to allow this, unless I’m missing something basic. Reaper has a render queue, but it just seems to run the tasks one after the other, so it doesn’t make the whole process any faster.
So unless I’m missing something in those programs, Wavelab has the possibility of being 2,3,4,5 times faster to do the same thing than they are, and who wouldn’t want that? And everybody would benefit, unless you’re running real time, because everybody has a multicore processor. Render processing would be faster on any computer.
In the Wavelab montage I can manually start a 2nd task and have it run in another core. I can start CD Track 1 rendering, and then start CD Track 2 rendering, and they’ll run at the same time. Reaper and Cubase don’t seem to allow this, unless I’m missing something basic.
Indeed, this is one of the strength and uniqueness of WaveLab (since version 2/3).
Even if Wavelab could process just two of my clips at a time, it would save me a lot of time
I plan to introduce more multitasking like this, because it’s useful and WaveLab is built with this design in mind.
Your other idea about segmented rendering of a large file is more tricky. Indeed, it means processing various parts of the same file with the different plugins, which means the junction point could depend too much on the plugin behaviour.
I see what you mean PG. A couple of plugins I tried can null perfectly to the normal full length render whether they start at Point A or Point B or Point C in the clip for the junction points, like the Steinberg Brickwall, and (strangely) the Steinberg Roomworks Reverb. But I found I had to use a lot more overlap for the reverb than I thought I’d need to to do that. Like more than a minute. EQ and limiter plugins don’t need anywhere near as much.
Other plugins you’re right. The Steinberg Compressor shows a delta down there no matter where I place it’s start points for the junctions. It would be acceptable to me, because the delta is far enough down for me, and the junctions still look and sound perfect, but technically it makes it “different”. The plugins still should be processing correctly no matter where they start in the program, but I can see how it wouldn’t be considered perfect until all the segments nulled perfectly to the full length render.
Are there perfect start cycle points in the program where more plugins would repeat their processing exactly? Would that be a multiple of the sample rate? I think I tried that without success.
I’ll keep messing around with it because it’s interesting to me, but you’re right, it does have this to consider.
Interesting stuff indeed. And more than a minute overlap with reverb is quite surprising, even though you’d expect that to be the hardest one to get right.