ARDFTSRC - Real Discrete Fourier Transform Sample Rate Conversion

[juha_p]

Have you tried Real Discrete Fourier Transform Sample Rate Conversion in your plug-in/software implementation(s) ?

[signalsmith]

Just read through the Python and C ports. It looks like a 50%-overlap STFT, with the block size chosen so that you can add/remove bins in the frequency-domain to get the appropriate-sized output spectrum.

That approach depends heavily on being able to use arbitrary FFT sizes, which means that porting it to some FFT libraries can end up slow - much slower than one might expect when comparing the fast sizes of each implementation. The author seems pretty dismissive of this, and I'm not sure that's fair. While FFTW is not the only implementation which can do fast arbitrary-sizes, it really narrows your options.

The exact block size, latency (and probably performance) depend on the common factors between integer input/output rates. I don't think I've encountered non-integer sample-rates in real-life, but still - the whole thing adds up to being awkward enough that I'm personally not motivated enough to give it a whirl.

[mystran]

Just read through the Python and C ports. It looks like a 50%-overlap STFT, with the block size chosen so that you can add/remove bins in the frequency-domain to get the appropriate-sized output spectrum.

Doesn't this result in awful time aliasing?

[signalsmith]

Doesn't this result in awful time aliasing?

Yeah. As well as a control labelled "quality" which enforces a minimum block size (-> closer-spaced bins -> aliasing stays in the ultrasonics), you can also set a cutoff which is below Nyquist. I haven't checked whether they use this extra room do any tapering/folding/etc. which would reduce aliasing, but I hope so.

[quikquak]

Doesn't this result in awful time aliasing?

Yeah. As well as a control labelled "quality" which enforces a minimum block size (-> closer-spaced bins -> aliasing stays in the ultrasonics), you can also set a cutoff which is below Nyquist. I haven't checked whether they use this extra room do any tapering/folding/etc. which would reduce aliasing, but I hope so.

You do need a sloped cut-off, or was that what you meant by tapering?

[signalsmith]

You do need a sloped cut-off, or was that what you meant by tapering?

Yeah, that's what I meant - you ideally want a nice curve which keeps the effective impulse response of your filter focused (kinda the time-frequency-swapped counterpart to designing window functions with focused frequency response).

And by "folding", I meant that the curve of the cutoff could extend beyond Nyquist, if you read/add the reflected bins as complex conjugates. You'd accept a bit of aliasing, strongly limited to the (inaudible) high end, in exchange for the cutoff being higher, which might be a reasonable trade-off for some situations.

[juha_p]

I don't have best tools for plotting the "src quality" nor I can't say what's probably wrong in plot but, with Audacity spectogram -tool, https://src.infinitewave.ca/ 's test file "Swept_float.wav" (original file is 96kHz mono file so I duplicated the audio data and converted it to a stereo file) converted to 44.1kHz audio using default settings given in python listing resulted this spectrum (range 0-22050Hz, window size 4096, Hann):

srcspectrum.png

Result looks quite similar as what Audacity's internal resampler (SoX:libsoxr) outputs.

EDIT: ARDFTSRC developer added support for single channel files so here's plot (0-22050, window size 1024 (blackman-harris)):

spectogram_src_96000_20_44100.png

[juha_p]

Hydrogenaudio launched recently Sample Rate Conversion Testing site. Here are some results linked for SRC method in question and for some others tested ATM.