KVR Audio

EvilDragon · Post by **EvilDragon** » Sat Mar 22, 2014 11:55 am

I wouldn't worry about that, considering the DSP magicians that are involved here.

FabienTDR · Post by **FabienTDR** » Sat Mar 22, 2014 5:37 pm

@David, @Compyfox: We do not "over" sample anything. Different parts of the algorithm run at their optimal rate (within the context of the algorithm's own properties and our previously defined specifications). That is, the algorithm is of the multi-rate type and dynamically switches to the most appropriate structure depending which features are requested via UI (such as sat modes).

The only reason for the fixed latency is usability. Otherwise, we would have to constantly stress the user with latency changes and blinking warning messages after every click. That would be highly annoying!

With regard to pre-post echoes: SlickEQ's resampling is differential, that is, most part of the output never sees a Nyquist filter, only the "change" is really being filtered by the latter.

Additionally, I'd love to hear or even see such pre-echoes on music signals. I build resampling algos since more than a decade and never ever heard such a thing. The term "pre-echo" is a pretty severe misunderstanding if you ask me (it is really a magnetic tape phenomenon).

That's what happens when people look at impulse responses without having studied what an impulse really represents (this isn't intuitive at all). Let me explain:

A unit impulse is the sum of every representable frequency in the system (even 0.0000001Hz and lower). It is by definition infinitely "wide", it's just that these frequencies are stacked in such a way they look like an infinitely narrow spike. Now, the pre-ripple you see when filtering such an impulse without phase distortion are the lower frequency "waves" that where there since the beginning (but visually hidden)! In fact, it proves that no phase distortion took place!

Just check the Fourier series of the unit impulse, it REALLY explains what happens. Don't forget in reality, you are filtering music signals, not unit impulses!

Interestingly, "Echoes" (in the true sense of the word) and "Ringing" (in the sense of self-oscillation) is something that usually only recursive, minimal phase filters are really able to introduce (such as classic analogue filter models). This makes me think that the whole confusion is probably driven by naive analogue audiophiles who don't even understand this pretty obvious technical fact.

By the way, even your DA converter introduces such "pre" things. So, ironically, you most probably never heard a recorded signal that hasn't been linear phase filtered already.I really recommend to simply use your ears. Yes, linear phase filtering sounds different. But it is sonically in no way inferior if you ask me.

David Else · Post by **David Else** » Sun Mar 23, 2014 12:43 am

Ok fabien, i don't disagree with anything you say, but there is still an issue in my mind.

every plug-in that has an 'over-sample' option i have tried sounds shit when put in that mode. even reaper in its best over-sample mode going from 44.1 to 96k sounds funny. why is this?!?

going from one sample rate to another is not lossless, i am hearing something bad, what could it be? from memory a good example is psp mastercomp 'fat' oversampled mode... is slickeq doing something different from this process?

Compyfox · Post by **Compyfox** » Sun Mar 23, 2014 2:06 am

FabienTDR wrote:The only reason for the fixed latency is usability. Otherwise, we would have to constantly stress the user with latency changes and blinking warning messages after every click. That would be highly annoying!

Hm... so you go the ToneBoosters route (see Barricade).

In case of this limiter (Barricade), the latency is fixed due to one major thing: the "pre-listen" mode creates a specific delay (it's also linked to internal, dynamic OS) that some host simply can't compensate. So the latency is fixed, for usability - which makes this limiter pretty much unusable for "tracking "usage - it's mainly laid out for mastering due to the 1000+samples delay.

At least, this is how I understood Jeroen from email conversations.

It's understandable why you go a similar route. Less trouble on the long run (hosts with faulty, adaptive PDC). with the set back that it won't work properly for tracking purposes, but for mixing and mastering.

But my main concern is still the VST3 SDK and Wavelab's compatibility to be... er... incompatible...

EvilDragon · Post by **EvilDragon** » Sun Mar 23, 2014 8:53 am

David Else wrote:Ok fabien, i don't disagree with anything you say, but there is still an issue in my mind.

It's called confirmation bias.

David Else · Post by **David Else** » Sun Mar 23, 2014 12:13 pm

EvilDragon wrote:
David Else wrote:Ok fabien, i don't disagree with anything you say, but there is still an issue in my mind.
It's called confirmation bias.

So oversampling doesn't effect the sound and I only imagined the difference, it's just a marketing trick... silly me!

So, how much of the below applies to SlickEQ?

https://varietyofsound.wordpress.com/20 ... ing-rates/

Oversampling a plug-in vs. changing the projects host SR

Some plug-ins are offering internal oversampling (re-sampling of the audio signal to a higher SR) as an alternative to a globally higher SR in the host. As always in life, there is a serious tradeoff though. Re-sampling a signal requires steep filtering at Nyquist which in general is a tradeoff between computational cost, steepness of the filter, ripple in the passband and resulting impulse response of the filter. For instance, if a plug-in uses a FIR filter to obtain very steep filtering, pre-ringing occurs. On the other hand, if IIR filtering is used, the filter might be not steep enough to eliminate aliasing content. However, the additional computational cost is a “local” phenomenon opposed to an overall higher SR which causes a higher CPU demand in all software running in the host.

Running an overall higher SR on the other hand avoids tons of up and down sampling and all the artifacts that are typically introduced by doing so and just requires some down sampling at the end which can be done with an high quality offline sample rate converter. If computing power is not an issue my vote goes clearly to use a higher SR instead of local re-sampling.

Hermetech Mastering · Post by **Hermetech Mastering** » Sun Mar 23, 2014 1:06 pm

Sometimes I really miss the Ignore function...

[EDIT from the FUTURE, man...] AAaaagggghhhhh.... Have I made my point? PLEASE bring the "Ignore User" function back.

EvilDragon · Post by **EvilDragon** » Sun Mar 23, 2014 1:09 pm

David Else wrote:
EvilDragon wrote:
David Else wrote:Ok fabien, i don't disagree with anything you say, but there is still an issue in my mind.
It's called confirmation bias.
So oversampling doesn't effect the sound and I only imagined the difference, it's just a marketing trick... silly me!

No - confirmation bias means that since you know there's oversampling involved you're inherently going to look for "errors" even though majority of people find OS just fine and not at all deteriorating the original signal. As long as you see OS mentioned, you're going to find it "wrong" even if it were the best OS method there is. You said you still have an issue in your mind, I just spelled it out for you what that issue is.

audio/fault · Post by **audio/fault** » Sun Mar 23, 2014 1:40 pm

i was about to buy a character-eq soon...
but after seeing this, it seems there's no need to.
looks really exciting and promising. can't wait to try it.

bk · Post by bk » Sun Mar 23, 2014 1:51 pm

I, for one, am looking forward to this release.

Perhaps folks could wait until after that to condemn the plugin.
Just sayin'.

David Else · Post by **David Else** » Sun Mar 23, 2014 2:20 pm

bk wrote:I, for one, am looking forward to this release.

Perhaps folks could wait until after that to condemn the plugin.
Just sayin'.

Hey EvilDragon, I think we had better just agree to disagree.

I hope I didn't seem to condemn it, I am really excited about it! In fact I have never been so excited by an EQ plug-in before, I love the work of TDR and Bootsy and this collaboration is like the 'super group' of audio being formed... the ABBA of plug-ins

EvilDragon · Post by **EvilDragon** » Sun Mar 23, 2014 2:34 pm

David Else wrote:Hey EvilDragon, I think we had better just agree to disagree.

Well isn't that a typical response when you can't think of something else to counter with.

David Else wrote:I hope I didn't seem to condemn it

Your posts sure came across like that.

vladg · Post by **vladg** » Sun Mar 23, 2014 3:55 pm

David Else wrote:every plug-in that has an 'over-sample' option i have tried sounds shit when put in that mode.

A lot of plugins has really bad oversampling implementation. Imho there're 2 reasons:
1. Reduced calculations bit-depth to make implementation CPU-light
2. Audible frequencies are affected by stopband attenuation (anti-imaging and anti-aliasing filters)

After some ear training during Proximity development

I can clearly hear such artifacts as
1. Killed depth in processed signal
2. The processed signal sounds more distant than the original one

You know, oversampling helps to defeat aliasing in non-linear audio processing and thus removes some "dirt" from the resulting audio but what about oversampled EQ in linear mode? For our own wonder we preferred oversampled EQ implementation even for low frequencies (which are far away from Nyquist)!

Check out one of our blind tests:

https://dl.dropboxusercontent.com/u/184 ... s_test.zip

One audio sample was processed with non-oversampled LF band and another one with oversampled. My explanation of this effect, oversampling increases bit-depth and such reduces processing error which leads to more pristine & "slick" sound.

Also we implemented delta-oversampling, it means if all EQ knobs are set to zero, the output is not affected at all (bit-transparent). Only frequencies, which added or subtracted from audio are affected by oversampling!

Eleventh · Post by **Eleventh** » Mon Mar 24, 2014 9:48 am

vladg wrote: Check out one of our blind tests:

https://dl.dropboxusercontent.com/u/184 ... s_test.zip

One audio sample was processed with non-oversampled LF band and another one with oversampled. My explanation of this effect, oversampling increases bit-depth and such reduces processing error which leads to more pristine & "slick" sound.

These examples' RMS does not match. When RMS normalized, they null to approx -95dBFS. Sound1 is 0.51dB louder, is that the "slick" one?

Burillo · Post by **Burillo** » Mon Mar 24, 2014 10:06 am

oversampling increases *bit-depth*? not sample rate?

VOS + TDL + VLADG = SlickEQ