11 Jun
2005
11 Jun
'05
10:21 a.m.
Dave Chapman:
The most common case will be downsampling 48KHz->44.1KHz, but there are
also users who need upsampling from various lower frequencies (e.g. for
use with audio books).
So we're looking for pointers to any high quality (but fast!) resampling
code that could be used.
I recently did a lot of benchmarking between libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
resampler where a lot faster than the fastest libsamplerate resampler.
I don't have the results available right now, but I remember that mus_src
performance wasn't very far from beating the linear resampler in
libsamplerate.
I did a lot of test with various types of data and compiler-options, so I
don't think it was a coinsidence. However, it might have been because
of some optimalization gcc was doing or something to do with the
cache. The mus_src code is far smaller and easier to read than the one
for libsamplerate.
I did not hear any difference in soundquality, but I guess there might be
a difference.
Sndlib:
http://ccrma.stanford.edu/software/snd/snd/sndlib.html
mus_src is available in the file clm.c .
libsamplerate:
http://www.mega-nerd.com/SRC/
A third program is the original sinc-resampler from Julius Smith:
http://ccrma-www.stanford.edu/~jos/resample/
I don't know how this one performs compaired to the other two though.
--
13 Jun
13 Jun
5 a.m.
Kjetil Svalastog Matheussen wrote:
I recently did a lot of benchmarking between libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
resampler where a lot faster than the fastest libsamplerate resampler.
I think most people would agree that speed is not the most important
aspect when measuring the quality of a sample rate converter.
I don't have the results available right now, but
I remember that mus_src
performance wasn't very far from beating the linear resampler in
libsamplerate.
Did you test anything other than speed?
I did not hear any difference in soundquality, but I
guess there might be
a difference.
If you pick the right kind of source signal and/or chose the right
source and destination sample rate, then even a linear converter can
sound good. However, a converter that sounds good in that example may
not sound good with other real world signals that converters have to
handle.
With libsamplerate, I can state that the three sinc based converters
have the following characteristics:
SNR Bandwidth
SRC_SINC_FASTEST 102.42 dB 80.23 %
SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 %
SRC_SINC_BEST_QUALITY 97.43 dB 96.96%
where SNR is signal to noise ratio and Bandwidth its a percentage of
the theoretical best bandwidth (ie half of the minimum of the source
and desination sample rate).
A third program is the original sinc-resampler from
Julius Smith:
http://ccrma-www.stanford.edu/~jos/resample/
I don't know how this one performs compaired to the other two though.
libsamplerate the same algorithm as this one. I think Julius O. Smith
developed this algorithm.
However, the JOS has a filter that is calculated at run time and is not
optimal while libsamplerate has pre-calculated filters that are near
optimal for a given quality of conversion. When I tested libsamplerate
against the JOS converter and tweaked the JOS converters parameters
to get the same SNR and Bandwidth, then libsamplerate as about 10-20%
quicker.
The bottom line is that doing sample rate conversion well requires
CPU. If you find a converter that is fast, it is unlikely to be good.
Measuring converters is not that difficult. See the test programs
distrubuted with libsamplerate for information on how to test them.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"There are only two things wrong with C++: The initial concept and
the implementation." -- Bertrand Meyer
7:09 a.m.
On Mon, Jun 13, 2005 at 04:59:57PM +1000, Erik de Castro Lopo wrote:
With libsamplerate, I can state that the three sinc
based converters
have the following characteristics:
SNR Bandwidth
SRC_SINC_FASTEST 102.42 dB 80.23 %
SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 %
SRC_SINC_BEST_QUALITY 97.43 dB 96.96%
where SNR is signal to noise ratio and Bandwidth its a percentage of
the theoretical best bandwidth (ie half of the minimum of the source
and desination sample rate).
What do you mean by 'signal to noise ratio' of a resample algo ?
I see no reason why it should produce noise, so it's probably not
what the words suggest.
--
FA
7:42 a.m.
Alfons Adriaensen wrote:
On Mon, Jun 13, 2005 at 04:59:57PM +1000, Erik de
Castro Lopo wrote:
The signal after the resampling is not the same than the original one,
so there is a modification: you can call this modification noise,
distortion, whatever :)
David
With libsamplerate, I can state that the three
sinc based converters
have the following characteristics:
SNR Bandwidth
SRC_SINC_FASTEST 102.42 dB 80.23 %
SRC_SINC_MEDIUM_QUALITY 98.99 dB 90.68 %
SRC_SINC_BEST_QUALITY 97.43 dB 96.96%
where SNR is signal to noise ratio and Bandwidth its a percentage of
the theoretical best bandwidth (ie half of the minimum of the source
and desination sample rate).
What do you mean by 'signal to noise ratio' of a resample algo ?
I see no reason why it should produce noise,
7:47 a.m.
Alfons Adriaensen wrote:
What do you mean by 'signal to noise ratio' of
a resample algo ?
I see no reason why it should produce noise, so it's probably not
what the words suggest.
All sample rate conversion algorithms produce unwanted artifacts.
These artifacts are usually highly correlated with the input signal,
but sometimes do in fact sound like noise.
I gave a handwavey guide to measuring the SNR of a converter in
these slides presented at the Audio Miniconf associated with
LCA 2005. The slides are here:
http://www.mega-nerd.com/tmp/secret_rabbit_code.pdf
The measuring os SNR is on pages 16-19 inclusive.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I consider C++ the most significant technical hazard to the survival
of your project and do so without apologies." -- Alistair Cockburn
7:54 a.m.
Hi Erik,
Erik de Castro Lopo wrote:
Kjetil Svalastog Matheussen wrote:
I believe libsamplerate, as a general purpose sample rate conversion library,
should be able to run very fast if needed. After including your library into
Jackbeat (http://www.xung.org/jackbeat) I was pretty sad to see 40% of my 700Mhz
Duron load dedicated to processing only six tracks with libsamplerate's
SRC_LINEAR converter.
Then, I coded a trivial sample rate conversion routine by myself :
- it sounds good, I can't hear any difference with the SRC_LINEAR converter
- my cpu load droped to 7%
I did not read the SRC_LINEAR source, but if we understand each other on what
linear conversion is, then my trivial converter does the same thing in 10 lines
and more than 5 times faster. If you want to take a look at it, it's located
between lines 274 and 283 in src/sequence.c, in Jackbeat 0.5.1
Maybe there's a design problem in libsamplerate ? Why is the SRC_LINEAR
converter so slow ?
PS: I did not give up support for libsamplerate. The GUI allows the user to
choose between your SRC_SINC_FASTEST converter, and my homemade converter.
--
og
I recently did a lot of benchmarking between
libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src sinc
resampler where a lot faster than the fastest libsamplerate resampler.
I think most people would agree that speed is not the most important
aspect when measuring the quality of a sample rate converter.
8:20 a.m.
Olivier Guilyardi wrote:
Hi Erik,
Erik de Castro Lopo wrote:
I think the issue here is the application, and what you mean by good ?
If the usage is purely sampling rate convertion, as a final stage before
mastering, then linear interpolation sounds really bad, there is no
question about it. Now, if it is used inside a processing effect, it may
be enough (I remember having used a linear interpolation for time
stretching processing, and the linear interpolation was certainly not
the weak point in the processing chain).
David
Kjetil Svalastog Matheussen wrote:
I believe libsamplerate, as a general purpose sample rate conversion
library, should be able to run very fast if needed. After including
your library into Jackbeat (http://www.xung.org/jackbeat) I was pretty
sad to see 40% of my 700Mhz Duron load dedicated to processing only
six tracks with libsamplerate's SRC_LINEAR converter.
Then, I coded a trivial sample rate conversion routine by myself :
- it sounds good, I can't hear any difference with the SRC_LINEAR
converter I recently did a lot of benchmarking between
libsamplerate and mus_src
in clm/sndlib. My result was quite interesting, the fastest mus_src
sinc
resampler where a lot faster than the fastest libsamplerate resampler.
I think most people would agree that speed is not the most important
aspect when measuring the quality of a sample rate converter.
8:53 a.m.
David Cournapeau wrote:
Olivier Guilyardi wrote:
Jackbeat is useful for my composition needs : for example I may need to use 16
samples on 16 tracks. Linear conversion _really_ is good enough to hear what it
sounds like, and my homemade converter is able to process 16 tracks on my 700Mhz
Duron, performing realtime conversion.
Then I save the whole project (the sequence) and when loading it on some faster
computer, I can switch to libsamplerate's SRC_SINC_FASTEST converter in one
click. I would just have liked to think : ok libsamplerate can either do hi-fi
or run very fast, according to the hardware I'm currently using. But that's not
the case.
--
og
Then, I coded a trivial sample rate conversion routine by myself :
- it sounds good, I can't hear any difference with the SRC_LINEAR
converter
I think the issue here is the application, and what you mean by good ?
If the usage is purely sampling rate convertion, as a final stage before
mastering, then linear interpolation sounds really bad, there is no
question about it. Now, if it is used inside a processing effect, it may
be enough (I remember having used a linear interpolation for time
stretching processing, and the linear interpolation was certainly not
the weak point in the processing chain).
9:45 a.m.
Olivier Guilyardi wrote:
Jackbeat is useful for my composition needs
OK, I've had a look at the webpage.
Firstly I see that its basically a drum machine. Drum hits are
relatively we behaved when linear sample rate converison is used.
Secondly, why don't you just do the sample rate conversion on
sample load time and sort the converted version in memory.
This will mean that you do the conversion once for each drum
sound rather than on all tracks all the time?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"If you think C++ is not overly complicated, just what is a
protected abstract virtual base pure virtual private destructor
and when was the last time you needed one?" -- Tom Cargill
4:18 p.m.
Erik de Castro Lopo wrote:
Firstly I see that its basically a drum machine. Drum
hits are
relatively we behaved when linear sample rate converison is used.
It looks like a drummmachine, but that's not the goal of the project. I use
vocal, guitar, bass and drum tracks. I know a Jackbeat user who does similar
things. Samples can be pretty long.
Secondly, why don't you just do the sample rate
conversion on
sample load time and sort the converted version in memory.
This will mean that you do the conversion once for each drum
sound rather than on all tracks all the time?
That's what I did at first, but for several reasons I switched to realtime
conversion. One the most important reason is rate shifting, which is performed
by the sample rate converter according to the following statement :
ratio = jack_framerate / sample_framerate / pow (2, pitch / 12);
The "pitch" is a per track value that the user can change at anytime.
As you can see I use libsamplerate (or my homemade converter) to perform both
sample rate conversion and cheap pitch shifting in a single operation. AFAIK
there just is no difference between a sample rate converter and a so-called
"rate-shifter". Or please tell me what the difference is...
--
og
8:28 a.m.
Olivier Guilyardi wrote:
I believe libsamplerate, as a general purpose sample
rate conversion library,
should be able to run very fast if needed. After including your library into
Jackbeat (http://www.xung.org/jackbeat) I was pretty sad to see 40% of my 700Mhz
Duron load dedicated to processing only six tracks with libsamplerate's
SRC_LINEAR converter.
Because the quality of linear converters is so poor, I have not
even attempted to optimise or even profile it.
I notice that it runs about 5 times faster than SRC_SINC_FASTEST
and on reflection, it should probably be 20 times faster. However,
I really didn't even expect anyone to use SRC_LINEAR. It was added
for completeness, to show how bad linear converters are.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"C++ is history repeated as tragedy. Java is history repeated as farce."
-- Scott McKay
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Java is, in many ways, C++--." -- Michael Feldman
9:10 a.m.
Erik de Castro Lopo wrote:
Because the quality of linear converters is so poor, I
have not
even attempted to optimise or even profile it.
I notice that it runs about 5 times faster than SRC_SINC_FASTEST
and on reflection, it should probably be 20 times faster. However,
I really didn't even expect anyone to use SRC_LINEAR. It was added
for completeness, to show how bad linear converters are.
Well, in Jackbeat, when I included libsamplerate, I added some GUI options to
choose between the 5 converters you made. I then had to give up on this design,
and code a homemade converter, offering users the choice to use SRC_SINC_FASTEST
if they want it. But IMHO libsamplerate was not versatile enough here, and
forced me to code twice the same thing.
The important point is : wether you use SRC_LINEAR at composition time or not
has no consequence on the final sound. This is because once you're happy with
your composition and saved it as a Jackbeat sequence, you can load it on some
faster hardware and switch to SRC_SINC_FASTEST in one click.
And honestly linear conversion performs well enough for my composition needs,
and I don't see why I should forbid users to be able to do lo-fi on old hardware
if they want it.
If you don't want to support linear conversion, then you should state that
libsamplerate is for hi-fi purpose only, and suppress the linear converters. But
IMHO, libsamplerate should be able to :
- either perform _very_ fast
- or do high-quality, and still be reasonnably fast (which it does already)
That's flexibility.
--
og
7138
days inactive
7140
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
5 participants
participants (
participants (5)
)
-
Alfons Adriaensen -
David Cournapeau -
Erik de Castro Lopo -
Kjetil Svalastog Matheussen -
Olivier Guilyardi
-
Alfons Adriaensen
-
David Cournapeau
-
Erik de Castro Lopo
-
Kjetil Svalastog Matheussen
-
Olivier Guilyardi