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

[Urs]

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?

That's something we're discussing, indeed.

I'd rather do the fixes first though. Gotta see if it's fixable

[Traverser]

Urs, what you found is interesting, because the manual of Satin suggests that the whole plugin runs at 352-384 kHz sample rate. At least I understood it this way, so: input->upsampling->processing->downsampling->output.

[Urs]

The actual tape model, compander and everything runs at that samplerate, indeed. To save CPU however a few linear things run at the host samplerate, like input gain, output gain and stuff, and that includes the pre-emphasis of high frequency content. That, as far as I can see now, is the main culprit for audible differences, but I have not yet looked into anything else really.

The tape model itself, which contains most of the voodoo, seems to run fine at any samplerate, which I'm glad about. Once I find a solution for the pre-emphasis, I'll also check the EQs and companders.

[sascha]

My memory is vague re. what parts are internally oversampled, but I would reckon I left the pre-emphasis out since it's not adding nonlinearities by itself. AFAIR all filters are sample-rate aware (unless there is an actual error, or the pre-emphasis filter overall phase response is the problem). Maybe at 44k1 & 48k, warping towards nyquist is also creating a discrepancy, compared to 88-192k.

Apart from that, beware of directly judging the frequency response through the internal graph. The culprit is that measurement is taken through a dirac impulse. Thus, the response changes with applied saturation, or with any kind of (in)harmonic distortion generated in subsequent stages. A better way would have been sinusoidal sweeps, but that would have been more taxing on the CPU, along with creating ripples in the spectral view. Satin's graph is most precise at low distortion levels, and precision diminishes with added artifacts, which is natural/by-design in this case.
I would suggest to check measurements against an external graph software that uses sweeps, such as VSTPluginAnalyzer (if it's still around, don't know), especially with input levels that are likely to generate additional distortion.
This is for the 'it looks different' case. If it, in addition, actually 'sounds' different, sharing some audio would be awesome.

[Traverser]

If it, in addition, actually 'sounds' different, sharing some audio would be awesome.

Actually sounds different, I started with that, and here is a sample:
https://www.dropbox.com/sh/vmgcw2bnvqly ... 9ePda?dl=0

[Urs]

Sascha is right, from my current study of the issue the so-called warping of filters near Nyquist is the main culprit of the oddities with pre-emphasis. I've spent two days exploring various ways to create better matches. The original code already does that, but it compensates for filter frequency and gain of the shelving filter independently (which is exactly what one would expect). I worked out that in this case compensating the filter frequency in dependence of samplerate *and* gain factor gets me some curves that always *look* (and measure) nearly identical for every setting at any samplerate. I do not yet know if it also *sounds* identical. That's something we'll explore next.

I'm a lot more optimistic than I was a few days ago! I have a much clearer path to tackle this now!

[Urs]

As for the dynamic effects - there's a *visual* difference in the bass response when dialing in a lot of emphasis at higher sample rates. That's because the dirac pulse of the analyser has twice or 4 times as much energy, and all that energy sits in the 20+kHz part of the spectrum. It is greatly emphasised by the emphasize filter (the one I've improved) before it hits the first non-linear stage, after which it is cut off anyway.

I have two options here. I can easily improve the graph for those sample rates. Alternatively I can compensate that frequency content so it doesn't cause trouble if people have crazy hf material in their original audio (which will get lost during the tape recording, due to the fidelity of tape).

[Urs]

I went with both options described before.

The analyzer is now greatly improved to avoid issues with dynamic processes that lead to very different readings at different samplerates. Furthermore I went deep into the realm of DSP trickery to create HF filters for the pre-emphasis which are exact matches to like 1/1000th of a dB in the audible spectrum. These furthermore do not exaggerate crazy high frequencies, such that even if people have crazy hf material, Satin should still sound mostly similar in each sample rate.

While I think I figured it all out, I have to now minimize the solution to a minimum on inference with the original code (which I've tampered with quite a bit).

Nonetheless, anything which applies distortion or dynamic effects will necessarily sound different at different samplerates - if the input material contains spectral content beyond that of the lowest sample rate. So if you ping a compressor with an (inaudible to humans) 32kHz sine wave, it'll pump even if you can't hear why. Satin is no exception.

[Traverser]

Urs, Thank You for all the information and working on this issue.

[Urs]

Finished. I hope.

Passed it on to QA for testing.

[Funkybot's Evil Twin]

Finished. I hope.

Passed it on to QA for testing.

[Checks thread title a second time...nope! Definitely not talking about Zebra3.]

Nah, just kidding! Sorta.

[Urs]

[Checks thread title a second time...nope! Definitely not talking about Zebra3.]

On a positive note, I can go back to my lovely Bezier splines, thus Z3

[pdxindy]

On a positive note, I can go back to my lovely Bezier splines, thus Z3

[Traverser]

Finished. I hope.

Passed it on to QA for testing.

Do you know that the updated Satin approximately when will be released?

[Urs]

I have no idea. There's a lot of testing going on currently.