The aliasing thread

[tony tony chopper]

Checking Sytrus is pointless, as if I can't load an external sample into it I couldn't know what's the interpolation noise figure.

it's not about the noise, it's about the latency you pretend there is

I understand that the Fruity Waveshaper allows processing an external sample?

no it doesn't

The answer to this is in my previous post: when downsampling, you need to use a low-pass steep filter, generally a fir filter.

again, don't ask, just check that sytrus (or the waveshaper effect plugin, if you want oversampling AND downsampling) don't introduce latency (or maybe 2 samples)

To start, with that method if you were allowing external samples, then you would need n times the storage required by the original sample.

no!
I just resample my original sample, whatever its samplerate is, to the samplerate my plugin is running at. Let's say the host is running at 48khz. I 'oversample' 4x, that makes 192khz. I just resample (realtime) my sample to 192khz, using hermite or whatever, then downsample the result (of all voices to spare some CPU).

[/quote]

[tony tony chopper]

On top of this, EVEN if there was a latency introduced (which is not the case), we're talking about a sampler, so everything is known in advance, you have all the sample material ready, so you could get rid of that latency easily, logically.

[WilliamK]

..

[René]

Quote:
Checking Sytrus is pointless, as if I can't load an external sample into it I couldn't know what's the interpolation noise figure.


it's not about the noise, it's about the latency you pretend there is

Perhaps I've not expressed myself clear. I don't pretend there's any latency in Sytrus. But it could be very simple to just ignore the low-pass filter before downsampling, and then the latency would be zero. But the aliasing/noise wouldn't be. If I can't check both things, then I there's no point in the test.

In other words, it is required to verify that the resampling process is working appropiately, and then check the latency.

no it doesn't

Then it would be another pointless test.

again, don't ask, just check that sytrus (or the waveshaper effect plugin, if you want oversampling AND downsampling) don't introduce latency (or maybe 2 samples)

As said above, it's plain easy to make an audio process with zero latency. That's not the point: to test the quality of a resampler, it's needed to feed a test tone and measure the output in all aspects: noise, aliasing, delay (latency), etc. If I can't feed anything into it, how could one know what the quality of the result is?

The same example again: if you take away the fir filter of any oversampled thing out there, latency goes immedialy to zero. Together with the quality.

no!
I just resample my original sample, whatever its samplerate is, to the samplerate my plugin is running at. Let's say the host is running at 48khz. I 'oversample' 4x, that makes 192khz. I just resample (realtime) my sample to 192khz, using hermite or whatever, then downsample the result (of all voices to spare some CPU).

Let's say we have a small sample, let's say 1Mb, of a single trumpet note at 44.1kHz. How exactly you 'resample' it 4x realtime, to make it 192kHz, and then play it?

On top of this, EVEN if there was a latency introduced (which is not the case), we're talking about a sampler, so everything is known in advance, you have all the sample material ready, so you could get rid of that latency easily, logically

Only if you found a method to detect my intention of pressing a key.

-René

[René]

Thanks for the reply. There are diferences, I just thought we couldn't hear it. But I find one thing a bit odd, is that SFZ sounds "filtered". Indeed. It takes care of aliasing. But I wonder, won't that also remove frequencies we "want" I guess I have to do a test and prove that.

Probably you're right. It removes almost all the aliasing, which some people must really like. Otherwise, there wouldn't be so many people in the biz.

Now if you talk about frequency response, please check the links in my post above, or do the tests yourself.

It is still clear that a good code will result into less aliasing.

Code doesn't help. It's the algorithm what matters.

-René

[WilliamK]

..

[Robert Randolph]

It is still clear that a good code will result into less aliasing.

Code doesn't help. It's the algorithm what matters.
-René

Thanks Rene. One thing I would like to say. I praise your work done with SFZ algo. Very good indeed. I'm not trying to say that SFZ anti-aliasing method is crap or anything like that. What I'm worried is that all those "fancy-graphics" will make users think that some engines are crap, whey they are NOT crap. Get it? This goes to you DiscoDSP guys.

Wk

DiscoDSP's own did pretty "bad"...

[René]

Thanks Rene. One thing I would like to say. I praise your work done with SFZ algo. Very good indeed. I'm not trying to say that SFZ anti-aliasing method is crap or anything like that. What I'm worried is that all those "fancy-graphics" will make users think that some engines are crap, whey they are NOT crap. Get it? This goes to you DiscoDSP guys.

WilliamK, if you check this post and compares it with your previous:

But I find one thing a bit odd, is that SFZ sounds "filtered". Indeed. It takes care of aliasing. But I wonder, won't that also remove frequencies we "want"

You will probably realize that there's no much of 'I'm against fancy graphics' as there's of 'sfz sounds filtered'.

There's other 2934872938 samplers mentioned in the graphic. It would be really better to use your time to reinforce your opinion how those others sound instead of sfz.

As sfz is freeware, everyone can check how it sounds by him/herself.

-René

[tony tony chopper]

But it could be very simple to just ignore the low-pass filter before downsampling

uh? then why would I even oversample if it wasn't to filter the result? or course it is.

Then it would be another pointless test.

no, it's oversampling, filtering/downsampling. And no latency. And filtering. And no latency. And..

Let's say we have a small sample, let's say 1Mb, of a single trumpet note at 44.1kHz. How exactly you 'resample' it 4x realtime, to make it 192kHz, and then play it?

how? using hermite or anything you'd use at a normal samplerate. And I don't resample THEN play it, I do this while I play it.

I don't see why oversampling seems so strange to you. Doesn't your 3D card allow it? How do you think they do?

Only if you found a method to detect my intention of pressing a key

no! were're talking about generators. If there's a latency, you just process ahead to sweep it. There's nothing hard in this. You press a key and there's a 100 samples latency in my stream? big deal, I just process 100 samples more and I don't stream the first 100. There's no unknown here, I already have the samples, it's a sampler.

[arguru]

DiscoDSP's own did pretty "bad"...

Indeed. however, it is the best using the '512-sinc' mode (also analyzed in the graphs) despite is slow as hell.

[René]

Quote:
But it could be very simple to just ignore the low-pass filter before downsampling


uh? then why would I even oversample if it wasn't to filter the result? or course it is.

I don't know, I didn't write the thing. Now, how that oversampling process performs in a test sample? we can't know that right?

no, it's oversampling, filtering/downsampling. And no latency. And filtering. And no latency. And..

And we can't measure how good it is either.

how? using hermite or anything you'd use at a normal samplerate. And I don't resample THEN play it, I do this while I play it.

I don't see why oversampling seems so strange to you. Doesn't your 3D card allow it? How do you think they do?

Oversampling is not really a stranger for me. I've done a few instruments using it for rgc:audio, and several other tube-emulation devices that many users are currently enjoying as OEM. It's actually the oversampling procedure you're describing which is strange for me. However, the whole discussion on Sytrus and the Fruity Waveshaper is pointless, as those devices can't load user samples. If they could, I'd be pleased to test them.

For instance, z3ta+ has also a zero-latency oversampling implementation using something called parallel fir filters. However, it can't load external samples either, so it doesn't count.

no! were're talking about generators. If there's a latency, you just process ahead to sweep it. There's nothing hard in this. You press a key and there's a 100 samples latency in my stream? big deal, I just process 100 samples more and I don't stream the first 100. There's no unknown here, I already have the samples, it's a sampler.

In that way you are losing the first 2 milliseconds of your sample. Drummers won't be happy.

Anyways gol, you seem to be pretty confident of a solution you've found that works for you and that I'm pretty sure it works for many others as well, I'm not positioning against that at all, nor I'd like to enter in any Mr. D--k contest.

What I'm interested in showcasing is that there's no such a case as a 'perfect' solution for a sampler's resampling problem. There's only 'perfect-for-me' solutions.

-René

[george]

What I'm worried is that all those "fancy-graphics" will make users think that some engines are crap, whey they are NOT crap. Get it? This goes to you DiscoDSP guys.

I'm not concerned about any statement in sampler comparison page where it says any of the engines are crap.

Regarding about "what people think", thats a distorted reality comment, completely irrelevant since it's based on the assumption of a single person, hence not true. What I believe this aliasing research _really_ gives is valuable information about _one_ of many features in a sampler, which is, in my opinion, not trivial to consider.

[autloc]

For instance, z3ta+ has also a zero-latency oversampling implementation using something called parallel fir filters. However, it can't load external samples either, so it doesn't count.

Well, I'm not quite sure what this parallel fir thing is (sure it's not a truncated iir or something?), but any filter introduces some delay. (If the present sample is based on the present sample and the past 7 samples, for example, it is clear that a sample 7 cycles old is still influencing the output -> delay). If the algorithm is smart and "looks ahead" to prepare data, I guess you could have 0 latency (and a brief clip as the sound is triggered and immediately offsets into the oversampled output), but the filter itself is still introducing delay. If I'm wrong and seemingly non-causal filters are realizable in real-time applications, please tell me. This technology interests me.

[tony tony chopper]

And we can't measure how good it is either

yes you can, in sytrus, but whatever, I don't need to convince you

In that way you are losing the first 2 milliseconds of your sample

no!

it's a generator. If there was a 10 days latency, you'd be able to process 10 days to finally stream out what comes afterwards. And if there were 10 days lost, you'd then fill the first 10 days with nothing.

[george]

yes you can, in sytrus, but whatever, I don't need to convince you

What's all this fuzz about a synth anyways? This discussion is aimed to samplers and resampling engines which would be better to keep focusing at instead.