Fast Bounce VS. Non-Fast Bounce output quality - Voxengo plug-ins

Hi,

I have compared Bounce to track option with Fast Bounce enabled and disabled and here are my results.

Remark: in this case, I am running Win7 32bit and Sonar X1d Expanded 32bit.

Project: 22 tracks, 15 buses
Plugins: Voxengo Gliss, ProChannel, Voxengo Curnchesor, Redline Reverb, Vintage Channel

Running  48/24 resolution.

I have checked multiple times the correct routing from tracks to buses and to the MAIN output. 

I go to Bounce to Track menu and choose:

Source: Main Out
Channel format: Stereo
Dithering: None

Source bus/track: M16DX OUT 1-2 (the only option)

Mix Enables: all checked

I bounce the mix with Fast Bounce checked and with Fast Bounce unchecked.

Then I routed these two new tracks to a new bus and the bus directly to the main out. Muted the Non-fast bounce track, flipped the phase of Fast Bounce track and played the project. I heard loud and clear mid to high frequency part of the mix. It should have canceled each other, right?

Then I muted the Fast bounce track, unmuted the Non-fast bounce track, flipped the phase and played the project. Silence. Perfect match.

As the only difference between the two tracks was the Fast Bounce option, I conclude Fast Bounce degrades the audio quality, mainly in mid and high frequency spectrum.

Could be the difference caused by the plugins not performing the same when Fast Bouncing and Non-fast bouncing?

They should be identical providing all other factors are equal, and it's that last bit that is probably causing the difference.

Are you running any plugs that can produce random time shifts, like Chorus, Flange, LFO's etc.

Unless they are all in exactly the same phase relationship for both bounces, then you're going to get differences

Now I comparing Fast/Non-fast in a test project with only one track and one plguin (Gliss EQ). So far the results are inconsistent.. :)

Just tried approximately the same frequency boost but with Pro Channel EQ.

The Fast Bounced track canceled out with the original track.

So, the Voxengo plugin is not "Fast-bounce" ready...

At least I know for the future :)

That's disturbing.

Aren't some of Cake's plugs rebranded Voxengos?

look what other Sonar X1 user has to say regarding this: http://www.voxengo.com/forum/ar/2779/

Interesting thread. I would not have guessed that oversampling would have a deleterious effect. 

However, because I have more than one frequently-used plugin that performs badly with a fast bounce, I've long been in the habit of using the slow bounce option for both exporting and bouncing. A slow export is still faster than having to re-do a fast export, especially if you don't notice the degradation right away. (Or the worst-case scenario: the client points it out to you after you've burned them a test CD.) 
 
Most of the time it's a soft synth that's the problem. Omnisphere is the worst offender, and it may be related to memory allocation and/or disk streaming. On my RAM-constrained system Omni will often produce unrecognizable garbage when bounced fast. Kontakt, however, never does this despite being equally resource-intensive.

rainmaker, your post has inspired me to do some tests of my own. It would be great if others would do the same, perhaps resulting in a helpful list of plugins known to not do fast bounces well. Hopefully, someone will compare SONAR to another DAW and see if that makes a difference.

Unfortunately, there are plugins that cannot be tested reliably with a null test. Anything that has random modulation cannot be tested this way. For example, a tape echo emulator will likely produce different results each time it's used. 

Equalizers, however, I would expect to be consistent, even ones with dynamic action such as GlissEQ. I'll test that one with and without oversampling, as well as the previous version of the same plugin. I'll also compare it to other equalizers that support oversampling.

OK, I read the Voxengo thread and it makes sense now. GlissEQ only oversamples during a render operation. It's up to the host to signal a plugin that it's in render mode, and SONAR does not do that when doing a slow bounce. GlissEQ therefore does not know it's in render mode and does not turn on oversampling.

Oversampling does cause a slight phase shift, which is normally not a problem because it's no more audible than if you nudged a track. However, if you combine the phase-shifted version with a non-phase-shifted copy, there will be comb filtering and the two tracks will not null.

So what you're seeing is entirely normal and predictable behavior and not an indication of signal degradation as a result of a fast bounce.

Bit is amazing, and a cool hang in person too!

Lance

Since null tests are not applicable, you'll have to compare the spectral signature of a track that's been bounced slow versus one that's been bounced fast. You'll need a spectral display that does averaging over the length of the clip. In the images below, I used Ozone because it has this feature.

The first image is the original file with GlissEQ. The 8x oversampling is not engaged because the spectrum was taken during normal playback.






The second image is a copy of the first track that was bounced using fast bounce. I verified that the "Render" indicator came on during the bounce, indicating that oversampling was enabled. Note that there is no discernible difference between the two, nor was there any difference in the correlation or phase meters. 


This does not mean that they are identical, however. A null test would show a drastic difference, because they are not in phase with one another. In the image below, I have zoomed in very tight on the two tracks so that the shift is obvious:






You would not, however, hear this difference unless you mixed the two tracks together.

This was done with the current version of GlissEQ. You said you heard a distinct loss of high end when you did a fast bounce using an older version of GlissEQ. I haven't tried this yet with the older version. Did you hear the effect with all other plugins removed (not just bypassed) from the project?

[Update: I tried the same test with GlissEQ version 2.9 and got the same results. rainmaker, were you using an older version than that? I have 1.1 around here somewhere... ]

bitflipper


I've misplaced my old help files for GlissEQ. Does anybody know if versions 1 and 2 work the same way as the current version? Is it the Quality button that turns on oversampling, and does it only oversample during Render mode?

Yes. I have version 2.9.1


"Normal/High Quality" 


High Quality uses a two times higher sampling rate. 

bitflipper


Interesting thread. I would not have guessed that oversampling would have a deleterious effect. 

However, because I have more than one frequently-used plugin that performs badly with a fast bounce, I've long been in the habit of using the slow bounce option for both exporting and bouncing. A slow export is still faster than having to re-do a fast export, especially if you don't notice the degradation right away. (Or the worst-case scenario: the client points it out to you after you've burned them a test CD.) 

Most of the time it's a soft synth that's the problem. Omnisphere is the worst offender, and it may be related to memory allocation and/or disk streaming. On my RAM-constrained system Omni will often produce unrecognizable garbage when bounced fast. Kontakt, however, never does this despite being equally resource-intensive.

rainmaker, your post has inspired me to do some tests of my own. It would be great if others would do the same, perhaps resulting in a helpful list of plugins known to not do fast bounces well. Hopefully, someone will compare SONAR to another DAW and see if that makes a difference.

Unfortunately, there are plugins that cannot be tested reliably with a null test. Anything that has random modulation cannot be tested this way. For example, a tape echo emulator will likely produce different results each time it's used. 

Equalizers, however, I would expect to be consistent, even ones with dynamic action such as GlissEQ. I'll test that one with and without oversampling, as well as the previous version of the same plugin. I'll also compare it to other equalizers that support oversampling.

Dave, I'm curious why you would be more inclined to trust EQs to be Consistent; even if they're not Linear phase type?

Now I cannot reproduce the case described in my first post... :( while running the latest Voxengo plugins.

Well I think it is good :) There was definitely something wrong going on, but now it is ok - fast bounce or slow bounce.

kind of late on the draw here, but as bitflipper and ba_midi stated, I have only had problems with Omnisphere and certail large Play libraries. Never crossed my mind that slow bounce would be better quality. All I know is fast bounce sounds like my mix--thats enough for me.

This is an old thread.