WaveLab & Ozone 8 - Crashes when soloing different tracks - partial workaround

WaveLab
#1

Hi everyone,

Just wanted to share an issue I ran into recently and a possible workaround, in case someone encounters the same problem:

Scenario:

  • WaveLab Pro 9.5.40
  • 14 tracks with iZotope Ozone 8.02 on each track
  • Macbook Pro (early 2011), 16 GB RAM, macOS 10.12.6 (Sierra)

Problem:
I use WaveLab for mastering for a music library => Audio Montage view, 14 different tracks from different composers, each with different cutdowns, alt mixes etc. I solo back and forth between the tracks and a reference track. At some point I started running into an issue - when I solo certain tracks and hit play, the green play button lights up, but WaveLab essentially freezes and becomes unresponsive. This keeps happening with the same tracks, even after restarting the program and reopening the session.

Workaround:
On the track causing the issue I save the track’s plugin chain as a preset and load it again. Now everything works fine, at least temporarily - after a while WaveLab seems to screw up the plugins again, I noticed that when it came to render the audio and WaveLab crashed once again.

This is still somewhat cumbersome, so if someone knows of this problem and has a smarter solution I’d be happy to hear it. I’ve poked around on the forum and saw some other people on this forum complaining about issues with Ozone - I can’t believe this, WaveLab is an amazingly powerful mastering tool, Ozone is a great and widely used mastering plugin, how come the two can’t work together more smoothly? Can anyone recommend a similarly powerful host that offers the same batch processing capabilities that works well with Ozone?

#2

I don’t have an ultimate solution but I also do some library music mastering and have a similar setup for that process and might have an idea to help in the short term.

Are you able to use Clip FX instead of Montage Track FX? It could help with the CPU hit but if your songs are broken up into multiple clips, that gets messy.

I’d have to test again but I believe if you have tracks muted, or one track in solo, all the other clip FX go offline and don’t tax the CPU but I have a feeling that track FX are always running and that might be your problem.

I’ve noticed that Ozone hits the CPU pretty hard and in better sessions, I can run into playback stability issues at 96k,

#3

Thanks for the quick reply. Unfortunately Clip FX is not an option, I have around 20-30 clips per track…

I think WaveLab actually does put plugins of muted tracks offline somehow - I just tried to play back one track solo (no issues) and then all tracks at once (instant freeze).

#4

Interesting. PG can probably say more what happens about track FX when you mute tracks. I really only use Clip FX and Montage Output FX, rarely Track FX or Global Master Section.

Are you using the Full Ozone plugin or just certain modules as you can do in advanced?

I haven’t dug too deep yet but when when I’m doing even a somewhat simple master “in the box” on my home rig (2018 Mac Mini 6-core), Adding Ozone 8 Spectral Shaper or Dynamics can often induce playback issues.

I think somehow Ozone is really hitting the CPU hard. It’s always been a heavy CPU plugin but I think somehow WaveLab is extra sensitive to it. Have you tried both VST2 and VST3 to see if there is a difference?

#5

I think somehow Ozone is really hitting the CPU hard

What I know is that each instance of Ozone eats a lot of memory. Each one more than WaveLab itself, if I remember right. Hence when you load that many instances, we may enter a land with corner cases (cases where a lack of memory happens, for example. This is just an hypothesis).
You may try WaveLab’s MasterRig plugin, that have some similarities with Ozone. Though this plugin is also memory intensive, it is not at much as Ozone, AFAIR.

Another thing: because WaveLab keep an undo/redo of plugin changes, and since Ozone changes are memory heavy, you might try to clear the montage undo/redo history, in the History window’s menu.

Philippe

#6

Do you think there is a way to make WaveLab work better with plugins that require a huge amount of CPU and memory?

There are a growing number of mastering grade plugins like DMG, Leapwing, Softube/Weiss, Ozone, and Acustica (which I do not care to use but others do) and some others that I am probably forgetting that seem to use more resources than the average plugin.

This is really amplified when you work at 96k. As I am starting to do a little more work all “in the box” in WaveLab I’m noticing my Macs seem to have a bit more issue with these bigger CPU plugin chains than other DAWs might.

#7

If the problem is memory, then the problem would be the same on any DAW (provided the applications use the same number of plugins).

This being said, WaveLab is architected around a principle: rendering is independent from playback. This is what makes it possible to render multiples files in parallel, eg. in the batch processor, and to playback in the same time. And for each rendering, new instances of plugins are allocated (and released afterwards).

There are a growing number of mastering grade plugins like DMG, Leapwing, Softube/Weiss, Ozone, and Acustica (which I do not care to use but others do) and some others that I am probably forgetting that seem to use more resources than the average plugin

This is right, and this is not very good.

#8

I just wondered, do you have the same Ozone modules enabled, (and same IRC mode in the Maximizer, with similar settings) on the problem tracks? I think the different IRC modes use quite different CPU processing needs. Can you look at Mac Activity Monitor for CPU and Memory when you have the problem track(s) solo’d (and in PLAY even if it won’t “play”) vs. other tracks solo’d and in PLAY that don’t cause the problem?

#9

Do you know if anything can be improved on the WaveLab side? Where I notice it is just basic playback at 96k. Once I get a plugin chain similar to how it is when working with a hybrid of plugins and analog gear, WaveLab playback becomes a bit unstable or sometimes unusable. I had to use an alternative to Ozone Spectral Shaper one time just so I wouldn’t lose playback or have bad playback interruptions.

I do like how WaveLab rendering is independent from playback though.

Side question I always wondered. Is there a reason DDP rendering blocks you from doing anything else but all other rendering lets you do more than one thing at a time?

#10

On the other hand, personally I am prepared to take the CPU/memory hit trade off for the quality and depth of configuration of say Dave Gamble’s (DMG) Equilibrium. And it’s configurable to have a lesser impact if the user wants. I acknowledge that, as I typically only use three plugs for processing (plus gain stage), I’m not all that affected or likely to be challenged by CPU thresholds.

#11

Do you know if anything can be improved on the WaveLab side?

I am currently working on optimizing the playback (next big release). But resource limitations will always remain limitations.

Is there a reason DDP rendering blocks you from doing anything else but all other rendering lets you do more than one thing at a time?

Internally to WaveLab, it’s the same path to burn CDs. And because CDs can’t afford missing blocks, no other process should run. That’s the reason. But maybe this could be changed.

#12

Thanks for the info. For my workflow, by the time I’m rendering a DDP, all the other plugins have been processed so the DDP render is pretty fast and this isn’t really a problem.The only plugin running is Goodhertz Good Dither. However, if people are rendering a DDP straight from the montage with ALL their plugin FX and it’s a slower process, I could see the benefit of the DDP render not locking Wavelab from doing anything else.

Certainly when CD burning it makes sense to block WaveLab from doing anything else that can cause an error.

#13

Thanks a lot for all the replies and sorry for being so late to reply myself…

I use the full plugin.

I’m using the VST2 version; the VST3 crashes WaveLab immediately.

That depends on the track, but usually most tracks use mostly the same modules and IRC modes.

I must admit though that trying to use so many instances of Ozone at once is probably a challenge for any DAW… So for now my workaround is to master one track, render it, save the plugin chain, clear the plugin chain, import the rendered files on a separate track for comparison, master the next track and so on. A little cumbersome when having to go back to change the settings on an already rendered track, but at least this offers a pretty stable solution.