The aliasing thread

[arguru]

Ah yes stefan, sorry, got read too fast and didnt get the picture. Yeah, seemed reasonable so I implemented it,

Some audio:

http://psycle.free.fr/Arguru/stefans_in ... _(lit).wav

1st part: plain Hermite (no above nyquist antialiasing filter)

2nd part: integrate/average stefan's sampling method.

Quite impressive stef!, i thought the box filter may attenuate above nyquist a bit, but not that good. (and I used linear interpolation to sample the integrated wave vector).

A mixture besides both methods (average/integrate for uppitch ratios and maybe just spline for downpitch ratio [agh, with the drawback of twice memory usage]) looks pretty good for realtime performance.

pD: The audio render shows also a good perceptual example of how irritant aliasing could be.

[stefancrs]

That actually _was_ quite impressive. I didn't know it'd work that good Look at the spectra of the last note in both versions, the fundamental frequency is almost completely raped by noise in the first one. Yay! I rock!

[Scr1pt3r]

That actually _was_ quite impressive. I didn't know it'd work that good Look at the spectra of the last note in both versions, the fundamental frequency is almost completely raped by noise in the first one. Yay! I rock!

You realy rock
I've just heard the example...
So instead of a hermite we gonna see stefan interpolations now implemented in products ?
Anyway, how does this compare CPU wise to other methods ? As I understand according to what you say it is faster and suitable for real time.

[stefancrs]

That actually _was_ quite impressive. I didn't know it'd work that good Look at the spectra of the last note in both versions, the fundamental frequency is almost completely raped by noise in the first one. Yay! I rock!

You realy rock
I've just heard the example...
So instead of a hermite we gonna see stefan interpolations now implemented in products ?
Anyway, how does this compare CPU wise to other methods ? As I understand according to what you say it is faster and suitable for real time.

Hermite, as far as I've understood it, is for interpolation, hence good for reducing interpolation noise. In that regard, hermite might very well be good to use together with this "oversampling" method or whatever it should be called The method I described has nothing to do with interpolation, but one should still use as good interpolation methods as needed. When playing back a sample below its sampling frequency, my methods result should be very similar to using interpolation only, it only gives you an advantage when playing back the sample at a higher speed than its sampling rate. But the advantage seemed quite huge when checking out argurus stuff

I'd say that it is cheap on the cpu, but I, as usual, haven't tested this algorithm at all so I really wouldn't know. It does ofcourse involve a division per sample...

[mauseoleum]

stefancrs, I might be wrong but I think i've seen similar method (done in python) in a script used to bake gi to vertex colors in blender.

i mean there's got to be some universaly simple solution to it.

[arguru]

I'd say that it is cheap on the cpu, but I, as usual, haven't tested this algorithm at all so I really wouldn't know. It does ofcourse involve a division per sample...

Is the (s-s[last_i])/(i-last_i) division?

Iirc, this division can be skipped (along the sub), in most practical cases step rate is not modulated at sampling rate, but control rate (each 32 samples or so) or just each time pitch is varied, so '(i-last_i)' doesnt vary also, compute the inverse and change the sampling code with:

pitch control:
inv_dif=1.0/(step_rate);

loop:
(s-s[last_i])*inv_dif;

[stefancrs]

I'd say that it is cheap on the cpu, but I, as usual, haven't tested this algorithm at all so I really wouldn't know. It does ofcourse involve a division per sample...

Is the (s-s[last_i])/(i-last_i) division?

Iirc, this division can be skipped (along the sub), in most practical cases step rate is not modulated at sampling rate, but control rate (each 32 samples or so) or just each time pitch is varied, so '(i-last_i)' doesnt vary also, compute the inverse and change the sampling code with:

pitch control:
inv_dif=1.0/(step_rate);

loop:
(s-s[last_i])*inv_dif;

Ah. Well. In that special case it would be very effective indeed. But if pitch is interpolated per sample (that's what I usually do, but it might only be of interest in synths, not samplers) it'd be worse. So, for sampler usage, this might be rock fast.

[Big Tick]

Stephan,
This algo seems like the next best thing since FFT was invented ! I believe it can be implemented in a very fast way, even with the division. The SSE RCCPS instruction does just that, it computes the inverse of 4 values simultaneously, and is hyper fast with low latency.

I'm more concerned about what happens when i=last_i. This never happens in a regular sample playback engine (as this would be equivalent to playing a 0Hz note), but this may happen (infrequently) in a FM engine.

PS. Please, let some admin move this post into the development forum, where it will be more relevant.

'Tick

[Scr1pt3r]

Stephan,
This algo seems like the next best thing since FFT was invented ! I believe it can be implemented in a very fast way, even with the division. The SSE RCCPS instruction does just that, it computes the inverse of 4 values simultaneously, and is hyper fast with low latency.

Sounds good

[george]

PS. Please, let some admin move this post into the development forum, where it will be more relevant.

I don't think a single post can be moved. It should be better to start a new thread at DSP dev forum instead. May stefancrs do that?

[stefancrs]

Will do. With some quoting specific to this algorithm (not the other stuff that's been going on in this thread).

[george]

Will do. With some quoting specific to this algorithm (not the other stuff that's been going on in this thread).

That's great stefancrs, I will be following any progress about it too.

[mark4man]

People,

Didn't have a chance to read all 39 pages yet (wow!)...so I'm sure someone must have touched on this, but...

If you take one note & resample it at subsequent frequencies up the scale...the farther from the original pitch we go, the more the aliasing and distortion occurs, correct?

So...wouldn't that mean that this sampler shootout is basically a non-starter...as most modern sample libraries now sample every note?

This is basically a malady of ROM-based hardware, with the issue being incremental sampling across an octave; & then tweaking the pitch & velocity to accommodate the capacity of the ROM, right?

mark4man

[tony tony chopper]

So...wouldn't that mean that this sampler shootout is basically a non-starter...as most modern sample libraries now sample every note?

This was my point. Although I wouldn't say every note, I'd say at least every octave.

Considering that a 2x oversampling gives you 1 alias-free (talking about the moirage aliasing here) octave, that it's great for filters, distortion, etc, my ideal resampler would be a 2x oversampled (for moirage) 6-point interpolator (for staircases). Would eat MUCH less than a sinc for a near-perfect (no moirage and rather good resampling) sampler.

[stefancrs]

Again; not everybody uses sample libraries just because they use samples. And some people like to repitch stuff that is hard to multi-sample as well (a cymbal sampled once or twice each octave is quite unheard of, unless _resampled_ with a good algo that is).