Wavelab 12 render extending past splice marker into the next song

WaveLab
1

Hi, I’m tearing out my hair with this issue.

I have an album already mastered and sequenced in WL 12 Pro. It has a couple of songs that merge into each other so the accuracy of the markers is a huge deal.

The first song on this album plays into the second, and the second starts right into a big kick, just after a splice marker.

When I play from that splice marker in WL it plays fine, I hear the kick just fine. When I listen to the render the attack of that first kick is in the end of the first song. It’s around 100ms off I’d say.

I’ve been rendering titles/all titles and title groups. I think that when I render the full album to one file (title group) the sequence plays perfectly as I hear on WL. Rendering the clip works fine too, but that’s of no use to me here as I need the overlap of song 1 into song 2.

I’m using reputable plugin companies in their latest versions, or the next to the last version, as I regularly check for updates. This project is all Softube, UAD, Plugin Alliance, TDR, Isotope, Sonnox and Crave. All in the box.

My first guess is some kind of issue with PDC, but it plays fine on the WL timeline, and the issue is still there even when doing a real time render.

“Add reverb tail” is unselected. The plugins are only on the clips, nothing on the (single) track, nor the output, nor the master section. Fade in/out boundaries status makes no difference.

The render duration is the exact duration it shows in WL. I’m guessing the start is getting delayed (can’t be sure as the first song starts in a fade in, and I’m unsure if the rest of the album has this same issue).

Any thoughts?

2

At least 1 of your plugins indicates an incorrect latency value to Wavelab, which prevents Wavelab from performing a perfect latency compensation.

In the list you mentioned, I see 4 names that had bugs in the past. I don’t know their current state and probably most of these past cases are fixed. But what I mean by that is that the word “reputable” should be considered carefully in the real world.

You have to disable all your plugins and then re-enable them 1 by 1, making a render each time to find where is the problem.

3

I usually process my files before doing an album…FWIW…it prevents a LOT of PROBLEMS!!!

4

Having a one stop solution is the entire reason I switched to mastering in Wavelab, I hated sequencing in Pro Tools. I’m thinking this was a bad idea..

5

I use all of these in Pro Tools every day, and sometimes in Logic and Live. Never had any problems with latency. Why just Wavelab?

6

ProTools and Logic use plugin formats. Maybe the problem only affects the VST-3 version of the plugin.

7

Ok, found the culprit.

The “low latency” option in Weiss DS1 wasn’t reporting its latency properly. The solution was to turn it off, save and relaunch.

Whose fault it is I don’t know and frankly don’t care much either. All I know is now I can’t fully trust Wavelab anymore.

Even if it’s Softube’s fault, how can I work confidently now that I know even the biggest plugin companies don’t care about Wavelab/vst3?

Maybe Steinberg should be on top of the popular mastering plugins because I know I won’t be doing all sorts of test to know if they’ll work properly when I should be working.

8

More than half a milion Wavelab users worldwide

What do you think?

9

WaveLab allows you to identify a buggy plugin, and your conclusion is that you should not trust WaveLab. That’s quite ironic :slightly_smiling_face:

10

Try looking at it from the user’s perspective.

The biggest plugin developers don’t seem to care much about bugs affecting WaveLab users.

That leaves me with two options: either spend hours scientifically testing every plugin in WaveLab just to make sure nothing comes back to bite me later, or simply use something else.

It would be in Steinberg’s best interest to stay on top of compatibility with the most widely used plugins, work with their developers to resolve issues, and make sure WaveLab remains a reliable platform. That’s good for your users, and ultimately for your business as well.

I’m saying all this because I searched for this issue, and it keeps coming up. The response is almost always, “Talk to the plugin developer.” Doesn’t it concern you that a plugin from Weiss, of all companies, doesn’t work properly in your DAW while it works fine everywhere else?

Even in this very thread there’s a frustrated user recommending that people process their audio before sequencing it in WaveLab. That should be a red flag.

Think about it. You might spend less time talking to plugin developers than arguing with your own customers.

13

To be fair … this Weiss unit has had well reported latency problems going back some time in other DAWs including Ableton and Sequoia.

Here for example is a user report going back to 2020
‘2020: I insert any Softube Weiss plugin in Ableton 10 the latency compensation needed is so high that there is a probably 300 ms delay between hitting start and audio playing.’

I also have Sequoia 17 (current version) and honestly, plugin compatibility there is all not a bed of roses either. For example, I don’t use UAD plugins but there are reports that just inserting them can cause Sequoia to crash.

I should say that I’ve always been a Daniel Weiss fan and own the Softube Bundle as well as SaraCon.

14

TBH the reverse of this argument might also be true. In other words, it’s a concern that Weiss, of all companies, do not ensure their plug-ins work flawlessly within Wavelab.

15

But PG1 is in my opinion one of the fastest reacting developers of any DAW out there.

I do it that way for over 20 years now. So I guess there is nothing wrong with it.
And the problems mentioned are not related to Wavelab alone.

16

Welcome to WaveLab. When I moved from Pro Tools to WaveLab in 2011 or so, I was pretty shocked at how many 3rd party plugins had issues inside WaveLab. I was spoiled as a Pro Tools user as it seems that’s where a large majority of testing resources goes.

I went from never even thinking about plugin bugs to being on the beta testing team of many of the major 3rd party plugin developers very quickly to help report and verify fixes on the bugs their plugins exhibited in WaveLab. It was like a minefield of bugs.

Many larger plugin companies like iZotope don’t even list WaveLab as a supported host for their plugins. One newer plugin created by basically one-man company told me he spent an additional $10k in money with his coding person to get it working in WaveLab.

I never used SoundBlade but from my understanding, SoundBlade also had a lot of 3rd party plugin bugs due to lack of testing and small/niche user base…not totally unlike WaveLab.

You can blame WaveLab all you want but the reality in my 15 years of using WaveLab is that 98% of the time, plugin rendering bugs in WaveLab need to be fixed by the plugin developer. WaveLab can’t go in and control how plugins behave within their framework.

Too many of the plugin developers only test Cubase and assume if it’s OK in Cubase, it will be OK in all Steinberg products and VST hosts but it’s not. WaveLab is a totally separate app and requires separate testing. It renders audio in a different manner in that rendering is normally a background task allowing you to continue to do things during the render. WaveLab also has Clip Effects. To my knowledge, Cubase doesn’t do either of these two things. So, there are many differences that would require WaveLab-specific testing and tight coding to VST3 spec to mitigate issues.

What I do is I have a plugin render test montage that I keep saved in a handy location. If I want to incorporate a new plugin into my workflow, I test it first for any issues when it comes to GUI, playback processing, and how it renders.

From time to time I test my go to plugins as well to make sure no new issues have popped up or if I suspect something is wrong.

As for rendering, I don’t think it’s specific to WaveLab but rendering the full montage first as one file to bake in the plugin processing (other than dither and sample rate conversion) before rendering a WAV of each track isn’t too uncommon in the mastering world. I got the idea from a Sequoia (or maybe former SoundBlade) user to help mitigate rendering issues. The plus side is that after the main render is done to bake in the plugin processing, all other renders go VERY fast. I wouldn’t do it any other way at this point, even if were mastering in Pro Tools.

The reality is that rendering specific time regions with moderate to heavy CPU load plugins is asking for some kind of issue, especially if there is gapless audio where audio is present in the very first and very last sample, and needs continuity with the preceding and following WAV file.

On a daily basis I use FabFilter, Plugin Alliance, Make Believe/Metric Halo/Sontec, Sonnox, Tokyo Dawn, Oeksound, Tone Projects, iZotope, Goodhertz, and Leapwing plugins without issue. So, you can use 3rd party plugins but you do need to have some responsibility to ensure that what you meant to render is what gets rendered. Mastering is quality control after all.

I do fully agree that Steinberg could and should do a better job of outreach to the major 3rd party plugin developers to encourage them to test WaveLab, list it as a supported host, and provide some documentation and test tools to help ensure WaveLab compatibility with their plugins.

So to summarize:

  1. Test the plugins you want to use.
  2. Render the full montage first to bake in plugin processing (aside from dither).
  3. Use the “Null Test Track” to verify renders are accurate to the playback and meet your expectations, especially when using new or newly updated plugins or working in a way you don’t normally work.
17

The only daw that gives you homework! Unbelievable :joy:

18

IMO a skewed perspective. Various plug-ins are known to cause issues in other DAWs so you’d need to do ‘homework’ with those DAWs too! But, to be accurate, the vast majority of issues are on the plug-in side anyway and so the ‘homework’ is being set by the plug-ins and not the host DAWs. In this scenario, would you really consider it reasonable to expect the DAW companies to debug or troubleshoot faulty plug-ins from third party developers?

See one example above: Wavelab 12 render extending past splice marker into the next song - #12 by Marker

19

Well that depends on your confidence level in plugin developers.

As a full time mastering engineer, looking at what plugins are doing under the hood before committing them to the stable and a label’s project is not only necessary, it’s routine.

Not everything is always as you’d expect … even from name developers. Stuff like Plugin Doctor didn’t appear for no reason. Plugin coders don’t issue patches for no reason either. I know I am not alone with this approach. This month I’ve ditched two plugins that I purchased for this reason: quality control fail.

Really, this is no different from checking what an analogue unit is really doing or needs before committing it to the chain.

This quality control process has nothing to do with the DAW, WaveLab or otherwise. That said, part of the process includes how it works with the DAWs.

Anyway, this is merely a perspective based on experience and another approach is not ‘wrong’.

20

If I were using analog tube gear, as many mastering engineers do, I would routinely be checking my equipment for defects and problems.

Why is it so hard to understand that any new plugin is suspect until it is fully checked out in your own studio?

I also have to say that rendering a file before putting it into a montage is the “smart way to work”. FWIW

21

I see from another forum that you appear to have resolved the issue through a setting in the plugin?