Wavelab 'eats' start of the song

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?

Do I overlook anything?

Here’s the waveform before and after rendering:
file in montage_pre + post rendering.JPG

If you don’t have a fade-in/out in your clip, and if you render without plugins, do you get the same result? I guess not…

Did a quick test with and without plugins on a single CD track - it’s working as it should.

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?

Guess I’m just having a mental transition problem from 8.5 > 9 :blush:

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.

Thanks PG for the explanation of the bypass behaviour. They were bypassed in the montage-master via ‘bypass all’. Nice to hear this will become more intuitive in 9.0.20 :wink:

File rendering test results + behaviour:

  • with bypassed plugins as described the plugins are indeed not bypassed but part of the calculation with unwanted fade-in-syndrom

  • without montage-master plugins (completely removed) everything is ok

  • when rendering individual CD tracks everything’s fine


    So the problem just comes up when rendering the whole montage. Maybe through reset/reload of particular plugins for each CD title?

The problematic montage uses a few Fabfilter Pro Q2s as clip fx, master plugins are Slate FG-X + Steinberg Brickwall Limiter (to avoid intersample peaks) + MBit Dither.

The problematic montage uses a few Fabfilter Pro Q2s as clip fx, master plugins are Slate FG-X + Steinberg Brickwall Limiter (to avoid intersample peaks) + MBit Dither.

Remove the plugins one by one, until you find which one behaves badly.

Meanwhile I’m helping myself by rendering all CD titles individually > building a new montage. This is working. Deadline ahead :wink:

Guess it’s FG-X…

BTW, .gpk-files get written to the original location though there’s an own folder defined. It has worked originally, just not today. Doublechecked the image folder settings already.

I just discovered this to be an issue with DMG Limitless, which is too bad because it’s a great sounding plugin.

No word from DMG yet as I believe the developer is on holiday but he apparently said this to another user about the same issue:

“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”

I’m not sure I agree 100% but just passing on the info.

“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.

Philippe

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 :wink:
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…