A very interesting web page dedicated to comparing different resampling engines of various DAWs on the market.
I guess it hasn’t been posted here on forums before, since Renoise is not on the list:)
Wow some of them are shocking bad! Wavosaur 1.0.1.0 especially. Think that was the latest version when I last used it (before purchasing Soundforge Audio Studio.)
May be interesting to see Renoise. But I assume all this is offline Sample Rate Conversion and although this does bring in interpolation, much as playing samples at different pitches does, I’m not sure I’m entirely convinced at how meaningful a test it really is…
PS. Check FinalCD for some that comes pretty much perfect in all tests.
That is conversion of 96kHz to 44.1, meaning they simply load sample and play it at the base note while rendering to the disk, however the principle should be the same.
Yeah, some of the results look scary, but it probably should be remembered that their scale starts from something like -200dB, so in practice that aliasing in many cases would not even cut through the amplifier hum.
-180dB and I think all of them sit below -100dB except the Wavosaur one I mention. Check it out. Peaks of almost -45dB noise from a simple 1kHz sine wave input. Not to mention the nice, colourful display on the Sweep test! 
Any volunteer?
GoldWave outperforms Ableton 7.
GoldWave outperforms WaveBurner.
GoldWave outperforms Sound Forge.
Funny!
No surprises with iZotope, SSRC, and IRCAM. Nice to see a few open source options do it well (SoX, libfsrc, etc).
Renoise does really strange conversions with these files…
I have just done a quick test with the pulse sample…
Here is the original 96Khz sample:
And here is the converted 44Khz (converted in the sample editor, cubic interpolation applies):
Also did a track rendering with Arguru’s sinc, here’s what Arguru’s sinc is making from it (stereo sample out put has been converted back to mono with no effects applied):
The cubic interpolation really has some serious effect on the sample…
Note that the headroom was set to 0.00 DB and all settings in master and track that initiated the note was also set to 0.00 DB, soft-clipping has been turned off.
For cubic rendering, the result was identical as the sample editor conversion process.
vV, what happens when you don’t use interpolation?
I can’t control the internal conversion routines, they always apply Cubic interpolation, even if i set the interpolation level to “no interpolation” for the sample itself, renoise doesn’t offer none-interpolated conversion modes.
(At least the result is the same when setting “no interpolation” before converting)
So only the devs can do that test without interpolation.
To be perfectly honest, I think you’ll see pretty similar results from most other software when using the same type of interpolation. I believe this particular test is designed specifically to expose this strange behaviour. Going from 96000Hz to 44100Hz is of course a non-integer conversion ratio, which will introduce some ‘drift’ (for want of a better term) into the resampling. Since the pulses are exactly 1 sample surrounded by total silence, the effect is that some of the silence gets blended into the pulses with this kind of drifting behaviour over time.
I do agree, though, it looks rather extreme in Cubic mode. Could be worth researching it a bit further.
But when using Wavosaur’s highest quality resampling method, I do get a similar result to Renoise’s Sinc mode, for example:
Try going from 96000Hz to 48000Hz and you’ll get a perfect result, because it’s a perfect 2:1 conversion ratio.
(No point in a screenshot, since it looks identical to the original data)
If you use no interpolation at all, then quite a lot of the original data simply gets thrown away.
Result after rendering in Renoise with the sample interpolation set to None:
Result after resampling with no interpolation in Wavosaur (quite bad!):
If you set the sample interpolation to None, then it will truly be None.
Ah, it didn’t occured to me i should have rerendered the snippet with the song-renderer / render to sample routines, but the setting does not affect the internal sampler converter.
At least these files are great for finetuning the engine.
I was wondering about this long ago. Sample rate conversion is in many cases a time domain operation, not always trivial and that may result in what we have seen in the screen shots above. Wouldn’t it make sense to do a so called “spectral” interpolation instead?
For example, wouldn’t it be way easier to construct the spectrum of a sample in a specific samplerate, and then simply rebuild this sample in time domain at the needed samplerate? In this manner transition should be perfect, apart from dropping the frequencies above 1/2 of the target samplerate (should there be any).
I suspect with a frequency domain approach there would be greater overall distortion (phase, frequency, and amplitude difference) to the signal than a proper phase-linear (or phase-minumum) IIR/FIR time domain filter, especially for program material. Perhaps with a sufficiently large block size, say 4096 to 8192 overlapping ever 64 blocks the accuracy would be a bit better. I’m certainly no expert, but in my experimentation in the frequency domain I’ve always ended up with more procedural artifacts.
i submitted renoise conversions of the test files to http://src.infinitewave.ca/
they have some of the graphs published.
maybe, to avoid artifacts we need to convert high sample rate samples with other software to lower sample rate to match the sample rate we intend to render the project.
or we can render to 96khz from renoise and convert with other software to other sample rates
or maybe to avoid using other software, renoise could have a high quality (better than sinc, slower, it doesnt matter) sample rate convertor in the sample editor.
on the other hand. i am not sure the cubic algorithm that renoise works with in real time (and the render option) should be changed.
i have used this high frequency artifacts creatively many times in songs.
Renoise shows quite good results, only a small part of the residue is around -90dB, which is on par with the quantization noise of a CD. Most of the aliasing happens below -100dB which is really nothing to worry about for most practical applications.
It does not make much sense to upgrade the SRC subsystem of Renoise just for it to produce mathematically perfect as it would produce only a fractional improvement in practical terms. It would be a waste of developers’ resources really for no tangible benefit, since ideal sample rate conversion techniques may be quite complicated.
yes you are right it doesnt make much sense to upgrade the whole src subsystem of renoise, i agree. and actually i wouldnt want that.
but i wouldnt call the cubic results quite good.
i am just thinking that maybe i should do sample rate conversions in adobe audition cs6 until src in renoise sample editor (i am not talking about song rendering) adds at least an option to use sinc.
I am surprised by great results of SoX and disapointed with audacity and openmpt. Surpisingly older versions of Digital Performer were quite bad. Look at the Adobe Audition/CS. Flawless!
I am not sure what you mean. How preconverting samples in a side application would help with the aliasing in Renoise?
I would imagine that you are talking about such a situation where you have a 48kHz sample that you want to downsample to 44.1. You sure could do that, but as soon as you start playing that sample back at different pitches the cubic interpolation will kick in again and all you previous conversion efforts will be useless. But when you are doing song rendering in sinc, it would not really make any difference whether the sample was preconverted in terms of quality.
i was thinking in basic and simple terms. load a sample in sample editor, adjust the sample rate, save the sample.
you have a point. my logic missed the repitching interpolation part and the final rendering in sync that achieves better src.
Looks about the same as the Modplug graphs.