Satin, different sound at different sample rates, be aware of it

Official support for: u-he.com
RELATED
PRODUCTS
Satin$149.00Buy

Post

Hi all,

I observed that Satin sounds quite different at different sample rates, so it will really not sound the same at 44.1k, 88.6k/96k and 177.2k/192k.

Really be aware of this.

I meticulously created a preset at 44.1k and it sounds totally different at 96k. Even the analyzer display will show you the difference, even if you enable the “Bypass Tape” function, and set both the Rec and Repro EQ to flat.

The same applies to factory presets, the studio presets: Studer that, Ampex this, "based on real measurement & tweaked using phase revers, until maximum cancellation occurred". OK. But at what sample rate? And so on.

So be aware this problem, check it for yourself. Probably the easiest way is to use headphones and Repaer’s “FX instance oversampling” function, but what you set here will be active after a playback stop and start, not on the fly.

I hope this info will spare some obscure pain and problem for others.

Post

IIRC the only thing that changes internally for 48k vs 96k is the oversampling factor. The actual process always works at 352.3k or 384km depending on 44.1k x 1/2/4 or 48k x 1/2/4. So by design, it shouldn't sound any different no matter what.

I'd be interested in knowing how exactly you switch, I'm not an expert of Reaper. If we can reproduce it, maybe we can find out if and why Satin wouldn't switch its internal processing as expected.

Post

Dear Urs, Thank You for your reply. I attached two screenshot.
On one of it you can see the problem with one of Satin's own preset and displayed on its own analyzer. On the other you can find how to choose oversampling for a given plugin in Reaper.
You do not have the required permissions to view the files attached to this post.

Post

This problem can be reproduced with the Windows and Linux version of the plugin, with the 32bit and 64bit versions, in Reaper, Ardour and Kushview Element, probably in any DAW, with one project at 44.k and another one at 96k and another one at 192k and comparing them. The "RP A800 30ips" preset is a revealing one.
You do not have the required permissions to view the files attached to this post.

Post

Ok! I'll check it out. Hopefully just something as simple as a missing reset or so.

I'm fairly sure that all presets were done at 44.1/48kHz.

Post

odd. i work at 48k like 99% of the time, but i can confirm the internal graph also changes on Logic / AU, and so does the frequency response (the same as the graph in satin).

restaring logic/satin does not affect it, so the sound is different on reload as well.
Image

Post

Urs wrote: Sun Sep 25, 2022 10:17 am I'm fairly sure that all presets were done at 44.1/48kHz.
I would like to note that the like difference/problem is there between 44.1k and 48k also. So 44.1k and 48k are also not the same.

Post

Traverser wrote: Mon Sep 26, 2022 8:58 am
Urs wrote: Sun Sep 25, 2022 10:17 am I'm fairly sure that all presets were done at 44.1/48kHz.
I would like to note that the like difference/problem is there between 44.1k and 48k also. So 44.1k and 48k are also not the same.
You do not have the required permissions to view the files attached to this post.

Post

Ok, I totally agree there's something very odd going on!

My first step to get into this was to check how accurate the graph is for higher samplerates. So I hacked the process and inserted a plain bandpass filter at 100Hz to see what's happening at different samplerates:



So this thing is very sensitive to samplerate, particularly in the low frequencies. It uses a 2048 point FFT, which is "good enough" for most purposes, but at 192kHz the lowest frequency it can quantify is 180Hz. Anything below that we'll see incredibly huge differences as all we do is a hermite interpolation of very few, sparse FFT bins...

So my next step is to either downsample the graph or simply increase the resolution. Bot options increase CPU usage for higher samplerates, so maybe I just do that while checking out what else is going on, and where.

- U

Post

To continue, I'm downsampling the impulse response to 44.1/48kHz before taking the 2048 point FFT:



This looks much better!

Now the differences in samplerate are by far not as bad as they were when visualising Satin. However, somehow high settings of Speed ips and Pre-Emphasis still have an effect on different sample rates. I'll continue my investigation tomorrow...

Post

Thank You! What you found did not surprised me, I always suspected that the analyzer is untruthful.

And I would like to note again, that even with the tape part bypassed, and with flat rec/repro eq there are differences in sound. You can easily check that with null testing.

Back in January when I contacted the support, I also found that the Pre-Emphasis is surely at the source of the problem, probably with many other things. Way too complex is this plugin :)

Post

I'm onto it. This is very complex code, but I think it's more related to how the different oversampling stages interact with the samplerate than the actual tape model itself. I think it's mostly "higher samplerate results in more pre-emphasis", which also exaggerates the visual error on the analyser.

When I switch off the optimisation for higher sample rates, I can easily dial in perfect matches by slightly adjusting pre-emphasis and/or speed.

I'll keep you posted.

Post

Thank You!

Post

I'm hitting a bit of a wall. The pre-emphasis highpass filter is not oversampled. So at 44.1/48khz the response by nature is quite a bit different towards 20kHz as it is with samplerates like 96/192khz. It's easily fixed by oversampling it, but then we'd get the response of 88.2/96 kHz. However, I'm sure Satin was designed to sound correct at 44.1/48kHz. So the physical constraint of the filter may be a feature.

Not sure where to go from here. The difference isn't huge, but with all the following stages (which I have not fully investigated yet), things may accumulate.

OTOH not oversampling it was done to save CPU. I would argue that this isn't much of an issue anymore, and we do have an ongoing project to rewrite parts of Satin to optimize it a bit more for modern CPUs.

Post

Maybe hold off on making changes until you do the optimization and then offer the old behavior as a "legacy mode" to maintain project compatibility?

Post Reply

Return to “u-he”