Stereo Tool

I have to re-up this whole DSP versus VST topic (and the differences).
Though now it seems as if it is even more a topic about realtime listening versus file rendering.

I have concentrated on the VST version and there still is something wrong:

Having a VST version it means that it is intended to be used most of the time for file rendering (so not in realtime like SA for broadcasting).

And everybody that uses a VST plugin expects that WYHIWYG.
The problem is:
There are differences whether you use the VST plugin in realtime - for example with Wavelabs FX rack - or listen to the rendered file (even without AGC usage).
So with hundreds of different VST plugins (even AGC type) I have tried over the years WYHIWYG works.
The only exception is Stereo Tool.
And I cannot understand why (maybe I am too stupid ?).

Sorry, I am not an expert (like Hans and others), but from my naive point of view I would expect, that there must be some kind of automatic detection/compensation whether a plugin is used in realtime or for file rendering ?
So that even AGC should work.
I cannot believe that any calculation inside a plugin's core is based on realtime values.
It must work with samples (=counting samples), or not ?
The only problem:
The plugin must know what the sampling rate is and then apply this knowledge to its internal sample counting for processing (e.g. to decide if 44100 samples are a second or 192000 samples are a second, etc.).

Sorry, for my naive words (so feel free to laugh).
But I hope it is clear what I wanted to say.


The point is (most obvious while listening to relative quiet intros):
Used for realtime listening the VST version applies less gain than the DSP version.
But when I compare the VST and the DSP version and their rendered output files, it is the other way round:
The VST rendered output file's intro is obvious louder than the one rendered with the DSP version (listening and visual comparing of waveforms).
So the biggest discrepancy is VST realtime listening (the most quiet) versus VST file rendered (the loudest).

With DSP version it is a similar (but not the same) discrepancy:
Rendered file's intro is a little bit louder than realtime listening output.
But the difference (realtime listening versus file rendering) is not as big as with VST version !


I have especially used a 44.1KHz/16 bit WAV song:
"BAP- Verdamp lang her".
For file rendering I have alternatively used Wavelab 6 (VST plugin and wrapped DSP !), dBpoweramp Reference (VST), Winamp 2.95 (DSP).
For realtime listening/playing I have used Wavelab 6 (VST plugin and wrapped DSP !), Winamp 2.95 (DSP) and alternatively the combination of foobar2000 and BA Live as host for DSP and wrapped VST.
(Of course using "bypass" while listening to previously rendered files !).

Maybe it is interesting (and good news !):
I have alternatively used in dBpoweramp the "CPU Throttle" option.
But there is no difference whether I render the files with 3.7x realtime speed (that is what I get without "CPU Throttle" - with one CPU core of my old Athlon X2 6000+ dual core processor) or slowed down with 1.0x realtime speed.
So, this is the way it should work (like with every other VST plugin) and it does !
Good !!!
But I still do not understand why we have this difference: File rendering versus realtime listening !?


By the way:
If anybody here uses dBpoweramp Reference, too ?
Is it possible to use multiple cores (so two in my case) for one file ?
I know that I can use my two cores when I have more than one file,
so that every core is rendering one file at the same time.
But I wonder if I can use both cores for rendering one file (a long recording), too ?

About dBpoweramp:
Simple answer for Multicore rendering ONE file is ... Impossible.

Now I am not being judgemental here. I'd just explain what I do to render processed soundtracks (from DVD rips ) using dBpoweramp. Bojcha is right to say that it's not possible to process/transcode 1 file using multiple cores.
The trick is to split the intermediate .wav file. The downside is you need diskspace and RAM(lots of it). I don't mind the latter as my 120 mins movie soundtrack is encoded(alongwith stereotool porcessing) in 12~15 mins utilising all 4 cores to aac/mp3. Later stitch the files together using specific tools.
So ultimately it's your call michi.

I know it would've felt good for OSs to distribute CPU cycles among it's different cores, but that's talking future stuff in 'parallelism' at present!

_________________
visit website

I still don't have a clue what's going on here, but please note this: Most Stereo Tool filters 'remember' their state. So for example in case of the AGC, after some loud audio it takes time (typically upto 30 seconds or so!) before most of the effect of that loud audio is gone.

So if you split a .WAV file into 2 parts, where you combine the two you might get weird effects.

Similarly, it's a difference whether you play the intro AFTER having played something else, or after a fresh start of Stereo Tool - Stereo Tool is not and should not be aware of boundaries between tracks!

I'm not sure, but it could be that the AGC startup values are more or less random (that would be bad, I know...). Which could explain the difference between the outputs.

Some time ago someone - I think it was Phoenix (?) - sent me 2 files, one processed with DSP and one with VST, and while they were different at the start, after a while (1 minute or so) they became identical except for rounding errors.

I'll check what the startup AGC levels are.

I don't think that it is a problem of AGC.
It must be something else.
Why ?
Because it happens also with presets without AGC processing.
My shown example were created with such (AGC off) preset.

I know that the VST version is reseted when you load it with the host application.
For all my rendering tests I load the STS preset and all settings for VST and DSP are definetly the same.
I use the clear buffer option and the rendering and listening takes place with the same single file source (clean start from Zero).
So I don't think that these differences are based on mistakes, because VST and DSP have identical rendering and listening conditions (except the differences based on the different interfaces).

As you see in my examples with the more or less static, stable intro level ( indication that I do not use AGC !) it seemingly is based on differences (it is static !) in pre gain.

The biggest differences occur with the VST version:

Play source files with quiet intros in real time through Stereo Tool VST hosted (in Wavelab or whatever you use) and compare these with the file rendered versions (using the identical settings for Stereo Tool VST !).
It is like day and night.

I understand that there are differences between rendering and playing (skipping from one track to another) especially in conjunction with AGC usage.
But for clean, fresh linear playing a single file or rendering it, there should not be these (static !) differences (even with enabled AGC).

The odd thing is that in the VST version, I don't even know if you're rendering or playing......

I have found the root of all evil !!!
I can see clearly now.

It is not AGC or Pre Amp.
All remarkable differences are based on Noise Gate processing !
I always use very heavy Noise Gate processing (and compensate it with heavy EQ inside Multiband).
So without Noise Gate or very light standard usage it is very difficult to identify remarkable (!) differences (I had not the time for serious listening tests - I have only rendered files and compared the waveforms VST versus DSP tonight).

So what is the difference for Noise Gate in DSP versus VST version and for playing realtime versus rendering files ?

I hope this helps to solve it, because now you know that you have to focus on Noise Gate behaviour in conjunction with different interfaces.

There is for sure a bug in VST version !
It does not apply Noise Gate settings correctly when I load my STS preset if this contains different Noise Gate settings than what is used in RAM preset and of course after reset

Checking the GUI everything seems to be correct.
But I have to switch Noise Gate section "off" and then "on" again or drag the main Noise Gate slider before the settings visible in GUI are really be applied.

I don't know if this is it (if this solves everything ?) ?
Ok, this might be the key for the VST versus DSP differences.
But in practice it depends on the degree of Noise Gate processing you use to hear or not to hear remarkable differences.
So this relation (degree of Noise Gate usage) explains why Phoenix and I have noticed strong differences, while others (like Hans) did not.

But how can this explain the differences between real time listening and file rendering (DSP internal and VST internal) ?

Great! I've added this to my todo list for version 6.01! And I never use that much noise gate - never thought of it as a possible cause if the difference is this big.

Indeed I don't know what this could have to do with playing vs. rendering, but I'll at least fix this one.

I hope that it is not the other way round !?
If the VST version would apply the Noise Gate settings from STS correctly, that would mean that not only DSP version, no the whole GUI interaction for Noise Gate processing (maybe other modules too ?) would be buggy.

Ok, here is a simple (my heavy Noise Gate setting only) preset:
# Ultra Noise Gate - for debugging only.sts

Load this with VST version while realtime playing.

I had written that the muddy sound disappears when you drag the main Noise Gate slider.
This is true when you stop dragging it.

But while dragging (using my preset) especially in the range from 5 to 10 percent you hear the difference again (this muddy sound)

It disappears (normal degree of expansion as expected takes place) when you stop dragging (relative to latency).