ardftsrc - the new resampling algorithm

[1231rq32r1qw32r]

I’ve just been made aware of a new resampling algorithm called “ardftsrc”. It’s available here under the MiT licence and I believe is also integrated in FFmpeg

GitHub - mrspoonsi/ARDFTSRC: ARDFTSRC Audio Resampler, by mycroft, port to C and Windows by dBpoweramp.com

ARDFTSRC Audio Resampler, by mycroft, port to C and Windows by dBpoweramp.com - mrspoonsi/ARDFTSRC

github.com

It looks to be the highest quality conversion so far, according to the results found at https://src.hydrogenaudio.org/

I’ve not seen a mention of it in this forum yet, so thought it would be worth posting. Any improvements in resampling quality are welcome (I guess regardless of how audible that may be)

 

[daftcombo]

That algorithm is integrated in Foobar2000 v2.26 released today.

Resampler technology updates

• New resamplers: ARDFTSRC and Speex, replacing SSRC and libretro from previous versions. New resamplers provide better quality at comparable speeds / better speeds at comparable quality.

I don't know Speex.

 

[kemmler3D]

This is cool, but what's more interesting to me as a non-developer / user is the low quality of some of the resampling algorithms lower in the list linked at Hydrogenaudio!

How the hell is Windows using resampling with so much detectable foldover in 2026???

Also really suprised at how bad SINC 512 is, given that I have used it a lot in the past thinking it was great quality...

 

[danadam]

How the hell is Windows using resampling with so much detectable foldover in 2026???

The sweep that is used there is normalized to 0 dBFS and that engages the audio limiter in Windows. If I reduce the volume to 95% or use a sweep that is normalized to -0.2 dBFS, then I get something like this:

or with a different color scheme and the scale reduced to -160 dBFS:

The aliases are at and below -130 dBFS. The one that creates a triangle with the sweep signal is maybe at -120 dBFS.

Also really suprised at how bad SINC 512

What is it? I don't see it there.

 

[kemmler3D]

The sweep that is used there is normalized to 0 dBFS and that engages the audio limiter in Windows. If I reduce the volume to 95% or use a sweep that is normalized to -0.2 dBFS, then I get something like this:
View attachment 562172
or with a different color scheme and the scale reduced to -160 dBFS:
View attachment 562173
The aliases are at and below -130 dBFS. The one that creates a triangle with the sweep signal is maybe at -120 dBFS.


What is it? I don't see it there.

This is presented as one of the higher quality resampling algorithms when you render a project in FL Studio.

 

[cobby]

I went down this rabbit hole after seeing the HydrogenAudio results and did some measurements on Linux.

One interesting finding: simply turning up PipeWire’s resampler quality is not necessarily a good trade-off.

On an Intel N150, 96 → 44.1 kHz:

SRC	Balanced	CPU for 60 s audio
PipeWire q4	56.59	0.157 s
PipeWire q8	64.04	0.313 s
PipeWire q14	65.80	2.234 s
SoXR VHQ	70.04	0.081 s
SoX Vulkan 16.2.1, CPU path	99.61	0.276 s

The last result surprised me most. Despite the name, SoX Vulkan also has a CPU path, and with the high-quality settings it gets into the 99.x range while still being very light.

I also tested 12 channels at 48 → 192 kHz on the N150 and the SoX CPU path was still about 18× realtime, using roughly 32 MB RAM.

So the interesting result for me isn’t really whether 99.61 vs 99.9 is meaningful audibly, but that 99.x-class resampling can apparently be practical even on a low-power mini-PC CPU.

ARDFTSRC can score slightly higher, but the high-end configurations I tested became dramatically more expensive in CPU/RAM, so for realtime use the SoX result currently looks much more attractive.