denormal & DC removal

[sinkmusic]

Hi
I was wandering what were the differences between TobyBear DcKiller &Pbugger, KT AUdioHealth, and GNormal.
They all must avoid P4 processor denormalisation when working with many plugins using short samples, and can remove DC offset by cutting inaudible frequencies, but is there any one better than the others and why ? Is there any test to make at home to see which one suits the best to my conif ? (i already tried Pbugger, and, as its names suggest, it bugged my computer !).
They all have features others do not have, so which one is the best (1-for Denormal, and 2- for removing DC offset in realtime) ?
FOr example, on Gnormal, you can change the osc shape : what's the use ?
Thanks if anyone can give me a reply !

[blümchen]

Some heavy mismatch of therms here.
DC and Denormals are completely different shoes.

And a "Denormalisator" can nothing do if a plugin internally produces demormal values. Merely prevent for passing those values thru other effects - in fact: mostly quite useless ...

DC offset has nothing to do with denormals.

I cannot see, what you are actually trying to achieve or what your question is ...

[mandolarian]

de rigour for denormals is de programmers job.

[multree]

And a "Denormalisator" can nothing do if a plugin internally produces demormal values. Merely prevent for passing those values thru other effects - in fact: mostly quite useless ...

some hosts or some plug-ins (Digitalfishphones) can add a low level noise to avoid denormalisation... which means a very quiet noise is inserted so that the CPU doesn't think it has "nothing to do" and simply goes bonkers

KTAudioHealer seems to do both...at least Koen says it does..... avoid denormals and remove DC Offset....

[blümchen]

which means a very quiet noise is inserted so that the CPU doesn't think it has "nothing to do" and simply goes bonkers

"doesn't think it has "nothing to do""

The contradiction is actually the case with the process of denormalization: The CPU thinks, it has "much more" to do and causes those spikes then ...

BTW: Such tools are actually NONSENSE never the less. Because many plugins (at least the good ones) have an input detection algorithm, which switches them off, if the input is zero. (I personally wouldn't develop senseless working plugin effects, which endless work on zero input.)

Normally this is quite useful for reverbs and delays, chorusses and so on, which consume continuous power if plugged into silent audio slots!

Thus, such a *smart* "noise producing plugin" for killing denormalization actually prevents for any such intelligent switching to save processor resources, because it forces those effects to continue processing on inaudible input ...

Oh God, please give developers more brain! Please!

.

[popsych]

Oh God, please give developers more brain! Please!

I'll definetely agree to that. Especially for mixing plugs and synths adding noise just to avoid denormalization makes no sense :

The problem really only manifests on P4's and even then when the host does not switch off plugins when not in use - about that : here's a though for Cakewalk and steinberg can you at least make this a choice ?

Why would I an Athlon user have to deal with the noise and CPU load. I know the noise is a bit of a non-issue (depends on how well the developer implemented it) but the cpu issue could make all the difference for an actually usable 50 different tracks project. I rarely have all tracks going on at the same time. WASTE, waste , waste.

[G-Spot]

I always wondered why anti-denormal plugins add noise to reach the standard floating point range instead of just gating the value to 0; maybe because it's cooler, or to prevent downstream plugins from repeated switching off and on again. CPU waste is bad, but clicks are worse.

[kevink]

I always wondered why anti-denormal plugins add noise to reach the standard floating point range instead of just gating the value to 0; maybe because it's cooler, or to prevent downstream plugins from repeated switching off and on again. CPU waste is bad, but clicks are worse.

I think you answered your own question. Clamping the value to zero as soon as it hits a threshold would produce a discontinuity with some high-frequency energy that might be audible, and "gracefully" fading to zero implies passing throught the denormal value range that we were trying to avoid in the first place...

[blümchen]

I always wondered why anti-denormal plugins add noise to reach the standard floating point range instead of just gating the value to 0; maybe because it's cooler, or to prevent downstream plugins from repeated switching off and on again. CPU waste is bad, but clicks are worse.

Well. The only right way to prevent denormals is to ensure, they will not occur inside (especially) of feedback loops. That's the job for the developers. Then the best way is to set those values to zero.

The other thing (switching off plugins on inaudible output) is quite easy to solve and without any clicking and noises possible.
But that must be done also by the plugin developers for some reasons and not by the host. The hosts don't know anything from the kind of process the plugin does, so the host especially don't know, when the plugin reaches the internal threshold of inaudible audio (over a certain amount of time).

On the other side the plugin can look at any time for incoming new audio to switch itselves on, if required. Because the audio comes always in preroll (a kinda look ahead).

BTW: Also on Athlons is denormalization messurable. Clearly.