[FEATURE] Higher Oversampling Options

[ghost]

Is your feature request related to a problem? Please describe. The saturation is great, but certain parameters could benefit from a higher oversampling setting to fight aliasing in the signal.

Describe the solution you'd like I would like to have higher oversampling options within the plugin (x32, x64 or even higher) specially for rendering.

Additional context This plugin might be the most convincing tape emulation I've heard, and I feel that with a little more oversampling It could become almost indistinguishable from the real, modeled tape machine. I don't know how hard this would be to implement, so I apologize in advance In case It's too much to ask. I don't want to be entitled or unreasonable.

Thank you for all you do.

[jatinchowdhury18]

Thank for the feature request! At the moment, we're using JUCE's built-in oversampling class which only supports up to 16x oversampling. I'd have to take a closer look at the implementation to see what it would take to extend that class to support 32x or 64x oversampling, but it's definitely worth a look.

I'm a bit curious if you have any examples of settings/input signals that produce audible aliasing when the "Tape" section of the plugin is running at 16x oversampling? By audible aliasing, let's say any aliasing artifacts that are louder than -100 dBFS.

[ghost]

I prepared a simple test In Reaper to simulate a broadband peak, like the transient of a snare drum. I fed Chowtape two sine waves, one at 10kHz and another at 15kHz. The plugin reports -6dB of input and roughly -3dB of output, It seems like a reasonable range for transient instruments to me.

I first tested the signal with the native oversampling implementation at x16, and then I simulated a x64 oversampling setting adding a x4 Reaper oversampling instance on the plugin. Settings stayed the same.

The improvement seems modest, but the biggest gains happened once the compression module was added.

Next I dialed In a compression setting I'm currently using for a drum bus. In the simulated x64 setting, the Inter modulation distortion was greatly improved. The current native oversampling settings doesn't seem to affect the compression module at all.

Lower bias settings produce more aliasing in general. I've also found that setting the bias to 0.91 gives the least amount of distortion and significantly less aliasing than any other setting. I don't know If this is a coincidence or If it's the result of the modelling.

Unrelated to these tests, I've noticed the plugin runs at 32 bit FP. I've heard from the Tokyo Dawn plugin developers that calculating the processing math at 64 bit FP can yield better sound. I don't really know how that works under the hood, but I'm wondering If It's something you'd be interesting in exploring, or If the plugin already does that and outputs at 32 bit FP.

I'm hoping this is helpful. If you need me to clarify something I'd be happy to answer you.

[jatinchowdhury18]

Thanks for the thorough investigations! Going the through the screenshots in pairs:

With the first pair of screenshots, it looks like going going from 16x -> 64x oversampling reduces the max aliasing artifacts from approx. -80 dB down to maybe -98 dB. So it's a slight difference, but it definitely is there.

The compression is currently using it's own separate oversampling that is fixed (I think at 2x). Probably I should re-arrange some of the code so that the compression uses the same oversampling as the tape module.

It definitely makes sense that lower bias levels would add more harmonics, which would result in more aliasing as well. Maybe another reason why having the 32x and 64x options could be helpful.

Re: single- and double-precision processing, the plugin uses single-precision processing throughout most of the DSP. This is because for most of the processes there is either no difference or an extremely minimal difference between the results of those processes done with single- or double-precision floating-point math, and the single-precision math can be vectorized more efficiently leading to better performance and lower CPU usage. However, there are a couple of processes within the plugin where the extra precision is needed in order to achieve a more "accurate" sound, and for those processes, the plugin will internally switch to double-precision floating-point math.

Anyway, I'm currently a bit busy trying to get the next release out for our BYOD plugin, but I'll definitely come back to this hopefully in a couple of weeks, and look at make some changes to the oversampling code. Thanks again!

[ghost]

No, thank you! I'll check BYOD whenever It's ready and I hope you can make chowtape even better than It already is.