Part 3 of (probably) 3 If you still don't accept the inadequacies of sinc resamplers for bulk conversions at fixed rates, try this: Download the file abstraction-1_for_piano.ogg which was posted a while ago. (I chose it because it's not that big and isn't my file.) Use oggdec to change it into a WAV file: $ oggdec abstraction-1_for_piano.ogg -o abstraction-1_for_piano.wav OggDec 1.0 Decoding "abstraction-1_for_piano.ogg" to "abstraction- 1_for_piano.wav" [100.0%] Resample it at the *same rate* which should ideally give you the same thing back --- a very complicated "cp" or copy command: $ file abstraction-1_for_piano.wav abstraction-1_for_piano.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, stereo 44100 Hz $ sndfile-resample -to 44100 abstraction-1_for_piano.wav abstraction- 1_for_piano_sndfile.wav Input File : abstraction-1_for_piano.wav Sample Rate : 44100 Input Frames : 6288384 SRC Ratio : 1.000000 Converter : Best Sinc Interpolator <<< Best! Output file : abstraction-1_for_piano_sndfile.wav Sample Rate : 44100 Now diff them: $ diff abstraction-1_for_piano.wav abstraction-1_for_piano_sndfile.wav Binary files abstraction-1_for_piano.wav and abstraction- 1_for_piano_sndfile.wav differ OUCH!! This file, a very gentle audio file, has been corrupted by sndfile- resample at its optimum setting, assuming I invoked it correctly. Audio files which are not so gentle will produce even worse results. With the very little cursory examination I've done on sndfile-resample, I've already measured up to 2.5% errors in resampling to the *same rate*. That's huge. Something that should be at -90 db or so at 16 bit resolution could be at -30 db --- who knows what that might cause with further processing. Ideally, you should get back exactly the same thing. Here is what should have happened: $ resample_simple abstraction-1_for_piano.wav 44100 16 abstraction- 1_for_piano_fft.wav 1.0 1.0 1.0 Using pad size: 176400 $ diff abstraction-1_for_piano.wav abstraction-1_for_piano_fft.wav $ This is not by mere trickery; resampling was done. (The program did not simply check the original and target sampling rates, then quit, but instead spent about 20 seconds processing on my machine in double precision.) ------------------------ When reading about sinc resamplers, you may see some statements about why a file won't be the same if you resample it to the same rate. These statements, none of which appear individually to be false, as a whole misrepresent what can actually be achieved and misrepresent the true origin of inaccuracy, namely the method itself as it is implemented. For bulk conversions to constant rates, sinc resamplers will necessarily be either slow, inaccurate, or both of these because of the way the method works. ------------------------ ********************************************************************* To be very clear : This is NOT about comparing particular programs (specifically, I am not claiming that anything I wrote is of production quality), nor is it about ideal theoretical conditions; this is about comparing implemented methods and about the widespread misuse of Smith's algorithm in Linux audio, and probably elsewhere as well. It is a special-purpose algorithm that is very localized in the time domain. ********************************************************************* This is also about being skeptical. In audio, it pays to be skeptical, even in Linux audio where all the source code is available. A lot of the code is defective, packaged in a way to allow you to install it without problems. (In other words, the installation procedure works great, but the actual application is not really useful or misapplied, etc., my stuff included.) Last, but not least, there is an object lesson here in "rolling your own" rather than expecting other people to do it.