Sometimes when you do time-stretchy/pitch-shifty things like in B14.sampler.rockafella.pd, when you return to normal time/pitch you are left indexing in-between samples using tabread4~. That's gotta introduce some fidelity loss, no? Has that bothered you enough to make you write something clever to get the indexing back to integers? If so, please share!

Here's a little test I wrote to see if I could hear the difference: sound quality test.pd . Load whatever sound you think would clearly expose lo-fidelity playback. You can compare integer indexing with fractional indexing and adjust the fraction. I think I hear a difference but I'd have to do a bunch more work before I'd declare I do and I'd rather ask you kind folks first. Plus I think you'll find it fun to try to hear the difference.

@jameslo said:

That's gotta introduce some fidelity loss, no? Has that bothered you enough to make you write something clever to get the indexing back to integers?

A/ maybe? but B/ no.

One way to measure the error is like this:

But this is just measuring the difference between integer-indexed samples and fractionally indexed ones, which doesn't necessarily indicate a perceptible difference in the sound. Basically the [+~ fraction] is a phase shift. You could phase shift a sine wave by 180 degrees and see a large deviation, but both still sound like sine waves (0 perceptible difference).

(I tried listening to the phase shift -- basically a bit HPF-ed result -- nothing disturbing.)

My opinion is: cubic interpolation is a well tested formula. Nothing significant to worry about here.

hjh

just throwing this here since it seems related and is quite an interesting read:
https://github.com/pure-data/pure-data/issues/1305

... although switching algorithms does not address the issue of sampling with a sub-sample offset at the original sample rate. but i admit that i couldn't really identify a difference when listening to a few different wave recordings here. it certainly would become an issue with very high frequencies, where the most obvious case might be a wave at nyquist frequency sampled with an offset of 0.5, resulting in silence.

@ben.wes That's a super-interesting read, thanks. It made me aware of cyclone/wave~, which in turn made me aware that Pd's interpolator is Lagrange, which appears to be not exactly the same as what's called cubic interpolation? 5 minutes with Google suggests that cubic interpolation is differentiable everywhere, whereas I think Pd's interpolator has sharp slope reversals.

cubic interpolation is differentiable everywhere, whereas I think Pd's interpolator has sharp slope reversals.

@jameslo i think so, yes! and that was also the motivation for Cyrille to create tabread4c~. here's a screenshot from its helpfile:

Ohhhh... Thanks for clarification. I had just assumed 4-point interpolation would be cubic.

hjh

@ddw_music said:

[...] I had just assumed 4-point interpolation would be cubic.

... which is correct! both are cubic, but with different curves (and the Pd version might be slightly more efficient):

Pd's [tabread4~]:

actual code:

cminusb = c - b;
*out++ = b + frac * (
    cminusb - one_over_six * ((t_sample)1.0 - frac) * (
        (d - a - (t_sample)3.0 * cminusb) * frac +
        (d + a * (t_sample)2.0 - b * (t_sample)3.0)
    )
);

[tabread4c~]:

actual code:

a1 = 0.5f * (c - a);
a2 = a - 2.5 * b + 2.f * c - 0.5f * d;
a3 = 0.5f * (d - a) + 1.5f * (b - c);

*out++ =  ((a3 * frac + a2) * frac + a1) * frac + b;