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.
