Quntal Interpolation (Next to Cubic)

[chackl]

Hello!

I just did a Quintal Interpolation.
It uses 6 Poits to interpolate between the 2st and 3rd point.
I know it is not needed but verry interesting if you do not need a Realtime DSP Process.

It is sounding verry interesting by converting wave files from 44100Hz/16Bit to Remasterlevel at leas 96Hz/24Bit.
But it needs heavy CPU!!!
It is just an Example

Best Regards
C.Hackl

[TheAudiophileDutchman]

This is an excellent example, thanks.

Being the proud new owner of a Focusrite Forte USB interface, I would be interested in using these kind of interpolation techniques for upsampling and streaming CD-tracks to 192kHz/24bit, instead of resorting to a proprietary solution like XXHighEnd audio player (or sample conversion with e.g. r8brain PRO).

Question: how does one have to interpret the last point in the draw wave graph compared to the interpolated graph, i.e. they seem to be far off, while the second last point is still positioned 'exactly right'? The stock cubic interpolation resampler shows similar behaviour (not sure about Smoothing on/off).

[trogluddite]

Nice work, Chakl - a very smooth looking output, I look forward to trying this on some 'real world' data.

Question: how does one have to interpret the last point in the draw wave graph compared to the interpolated graph, i.e. they seem to be far off, while the second last point is still positioned 'exactly right'? The stock cubic interpolation resampler shows similar behaviour (not sure about Smoothing on/off).

This is common to any form of interpolation that uses more than the two point either side of the interpolation point - at the start and end, there is always a small section where the interpolation requires points beyond the ends of the original data. The results depend on what strategy you use to 'pad' the array with extra points to avoid 'out-of-range' errors - either just zero's, or trying to 'guess' the continuation of the data. In this case of a looped sample, you don't have to worry about this, as you can 'wrap around' points from the opposite end of the array.

[chackl]

well i will explain it like this:

y1=array[i-2];
y2=array[i-1];
y3=array[i];
y4=array[i+1];
y5=array[i+2];
y6=array[i+3];

On Smoothed Ends = False
if i = 0 then
y1 = y2 = y3 =array[i];
If i = Maximum i
y3 = y4 = y5 = y6 =array[i-max];

And if ens sommth is on
if i = 0 then
y1, y2 will get the last 2 Point of the array
If i = Maximum i
y4,y5,y6 will get the first 3 Points of the array

[TheAudiophileDutchman]

Allright then, being back in town and still chasing the idea of efficient realtime upsampling of CD tracks.

Focussing on upsampling speed and 32-bit accuracy (for now), let's discard array calculations as much as possible (and forget about looping, but retain smooth ends), vastly reduce the number of mul (div!) & add operations and CPU-hungry sample read components (in case of streaming code).

Here's an early prototype 44.1 -> 192 kHz mono upsampler. The main algorithm has also been transferred to streaming code (which appears to be quite easy to do from Ruby, albeit untested):

Fast 6p 5o Upsampling Interpolation - TAD 2012.fsm

(8.23 KiB) Downloaded 1606 times

[trogluddite]

Looking nice - and I like the 'Ruby Algorithm Prototyping' idea too, much easier to de-bug than code/assembly - I might just have to steal that trick!

That Ruby version might be well worth hanging on to as well - unlike code, Ruby uses all double-precision floats, for more accurate results. Don't have the kit to tell how audible the difference would be, but if going up to those high sample rates, might as well keep as much resolution as possible (only for cases where the slower off-line processing time is not a problem, of course). With Ruby's array iterating and file handling capabilities it could turn into quite a handy little batch processor for wave files maybe?

[TheAudiophileDutchman]

Looking nice - and I like the 'Ruby Algorithm Prototyping' idea too, much easier to de-bug than code/assembly - I might just have to steal that trick!

Thanks, I take that as a compliment: "Good Ruby artists copy, great Ruby artists steal."

...unlike code, Ruby uses all double-precision floats, for more accurate results...

Actually, I'm already anticipating on Malc's promise of better 64-bit streaming support in FS 3.