I’m facing an old problem here today which I thought was already overcome since some major versions:
When rendering a montage including clip fx there’s a fade-in-thing happening on the beginning of the rendered result, usually on the right side.
It only becomes obvious when the actual song start and file (clip) start are very close, when there’s not enough silence.
My montage has clip fx and plugins in the montage master out as well. Feels like the calculation drops in after a few ms but not right at the beginnning.
I know some workarounds but simply can’t imagine that behaviour to be ‘by design’. Just makes no sense for a mastering application, does it?
Did a quick test with and without plugins on a single CD track - it’s working as it should.
This means, one of your plugin is causing the problem.
At the moment there’s a rendering running for the whole montage with montage-master plugins bypassed - which takes exactly as long as if they were not bypassed. Is that normal?
How is it bypassed? There is a “Bypass All” button in the plugin tool window. If this is checked, then bypass only works for playback, not for rendering (this was also like this in WaveLab 8.5). Buf if the plugin is bypassed itself (box unchecked near the plugin name), then bypass is effective also for rendering.
BTW, what I explains above for “Bypass All” above, will be changed in 9.0.20, so that bypass also is effective for rendering.
“it should be the DAWs task to start the rendering slightly before the actual export-area, in order to let the lookahead algorithm tune in”
What if the audio range starts from 0? If the host sends zeroed samples, what the interest of this for the plugin? The plugin should be aware of the “start state”, and should behave accordingly.
Take a plugin that needs to analyse samples. If you “insert” other samples, the analysis will be (slightly wrong), as other samples will be taken into account. This can’t be a default behaviour.
Now, I can agree that when you process a sub-range, this could be useful. But certainly as an option.
That’s how I feel. There was a workaround for a live album where I rendered the entire thing as one file and then brought into a new montage to render the final seamless tracks, but we still have a problem for any renders with audio at the very start of the file or montage which is common with library/production audio.
I hope Dave @ DMG will be back from his holiday soon to respond to this.
Regardless of lookahead, I see no reason to add a fade in.
I remember having had the problem long ago, Wavelab 5 or 6 maybe. Didn’t happen (or I haven’t realized it) untill today.
If the problem is to have no silence at the beginning of a file/clip/cd title plus using a plugin that uses lookahead: why doesn’t Wavelab create a little invisible preroll-including-rendering that gets automatically chopped of, so that the rendered file has the expected length? Working with such plugins in Cubase ain’t a problem, completely different audio engine?
The problem didn’t dissapear by rendering all CD titles in the montage individually though I stated that before. The clips that had audible data at the very beginning still were affected. I’m going some long ways around to get the thing finished at the moment…
why doesn’t Wavelab create a little invisible preroll-including-rendering that gets automatically chopped of, so that the rendered file has the expected length?
This could be possible, as I mentioned earlier. But as also mentioned, adding silence should not make a difference.
Actually, the WaveLab batch processor has a plugin to solve this kind of case: the “Instructor” plugin. This plugin gathers the first samples, send them twice to the plugin, then chop them at the end. This plugin was mainly done for plugins that need some sensible amount of samples to be analysed before processing. For instance, a denoiser that needs to analyse a noise print before actually denoising.
But I would say that a plugin that implements a filter that needs to be “warmed up”, should do this trick itself: plugin latency support is done for this.
I remember that I had some issues back in WL 8.5 where some tracks that were meant to be seamless were not because of an EQ plugin that needed some “warm up time”. I haven’t seen this problem since so I’m not sure if PG ever implemented a fix for that behind the scenes but this issue seems to be along the same lines.
Regarding the Limitless fade in issue, there are reports of the same thing in Sequoia and Triumph but in Pro Tools, the problem doesn’t exist.
So, I lean towards the plugin developers needing to fix this but it also would be nice if WL also had a safety net to help avoid these issues as they can really be an issue at times.
Cool to know about ‘Instructor’. I’ve read in the manual about it, just had no time to play around with most of the new features.
I completely understand that the issue could origin on the plugin developers side but on the other hand a professional mastering suite should take care of such shortcomings. As Justin mentions Sequoia and Triumph (never used one of them myself) seem to create similar effects while Pro Tools doesn’t. Neither does Cubase. So it’s possible to get a properly processed file even if a plugin has several shortcomings. It must be possible in Wavelab then.
Really would love to see an easy solution in Wavelab
It’s hard to do reliable work - especially with clients in the room and a tight ‘time budget’ - while your trust in the software has just 3 of 4 legs…