Re: [linux-audio-user] Converting sample rate: failed...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Converting sample rate: failed...
From: davidrclark_AT_earthlink.net
Date: Wed Sep 22 2004 - 19:50:59 EEST


Hi Erik,

As you can see, we made it back after chasing Ivan around. Luckily we
saw nothing but a few drops of rain. I'm sure others here or close to
those here must have had bad luck instead of good, and my sympathies
go out to them.

Thanks for your response. I applaud your enthusiasm, but it appears
to me that you are laboring under some misconceptions and
misunderstanding of what I have posted. Among the misconceptions is a
serious one that should cause concern amongst those who use
libsamplerate.

-------------------------

Minor problems:

A good portion of your recent post is aimed at something I never
claimed. It appears to me that you are failing to distinguish
between two cases: 1) Series in general; 2) Series which have been
previously prepared, specifically frequency spectra which are band-
limited and lowpass filtered.

>From my earlier post on the current subject:
 
"The reason is that I assume that the input is band-limited, and this
is usually true for my own work. Not only is it band-limited, but
usually also tapered in the frequency domain, i.e. already effectively
lowpass filtered."

>From your recent post:

"Now I will admit that if the signal is already bandlimited filter
many not be necessary, but that is a different matter all together."

No, it is certainly not a "different matter altogether." Your quote
was nearly all I was saying as you can easily see, except that in
addition signals I use (as well as most that others use) are also
normally effectively lowpass filtered. This is more restrictive than
your assumption, so filtering is even less necessary than you admit it
to be.

Your elementary examples from undergrad engineering courses and
attempt to rephrase what you claim I said don't apply to the situation
I've described; they have nothing to do with what I've said and are
true but irrelevant statements which cause me to wonder what it is
that you are trying to prove; you may want to give some thought to
that: What is it that you are actually trying to prove or demonstrate
to everyone?

As a very minor note, you are also attempting to answer an ontological
question (that something which has no observable effect on the
universe can nonetheless be said to exist) which has plagued
philosophers for millenia by merely declaring your opinion as fact.
Here is what I actually wrote:

"If nothing was removed or even altered, then no filtering has
actually occurred."

Note that I am not so reckless as to claim anything regarding
existence or nonexistence here.

-------------------------

** Serious misconception **:

Two paragraphs from your recent post:

"If you work out the mathematical expression for your frequency domain
converter, you will find that there is a time domain expression that
is mathematically identical and that the time domain expression is in
part a FIR lowpass filter very much like my converter." (You mean
your implementation of Smith's converter, don't you?)

"The difference between the two would be that my version uses linear
interpolation into a very large table to obtain the filter
coefficients while yours are more exact. However mine provides a
*measured* SNR of at least 97dB."

This second paragraph is considerably flawed and reveals a serious
misconception on your part. Although the *starting point for the
derivation* of both methods is the same, the method you are using as
it is actually implemented is a very localized method in which only
few samples are used to construct the new values. This is due to the
*severe* truncation of the series. The horrible effects of this
severe truncation are mitigated through the application of a Kaiser
window which effectively localizes the estimation even further as it
improves the result substantially. The method I'm using remains a
very much more global method in which each new value is constructed
from hundreds of thousands to millions of samples. Given that audio
I process taper off to zero at the beginning and end --- in addition
to being band-limited and effectively lowpass filtered --- I could
have written a global method wherein each sample is the result of
calculations involving ALL other samples rather than one which
contains windows with hundreds of thousands to millions of samples.
  
This is a far cry from what you are doing. This is all BEFORE the
linear interpolation step which you claim is the only difference
between our methods, a step which is totally unnecessary by the way
for most fixed-sample-rate conversions (for example: unnecessary for
96,000 to 44,100, for 48,000 to 44,100, and for 44,100 to either of
the others) and further degrades the sample rate conversion
unnecessarily for the most common use. (This was done by Smith to
permit variable-sample-rate conversions, a useful goal to say the
least.)

Now as I've already said, the sinc-based sample-rate converter you've
constructed from Smith's work seems to work well in the sample I've
listened to. But knowing what I know about sinc-based methods based
on my own implementations, Smith's published work, and the lack of
necessity for such a method for fixed-rate conversions, not to mention
the fact that linear interpolation is being used where it really isn't
necessary, leads me to reject libsamplerate and anything related to it
unless it's forced on me by someone else via a dependency. I rarely
do variable-rate conversions, so I have very little need for sinc-
based sample-rate converters.

-------------------------

For "ordinary" users:

For those of you who have read this far --- hopefully not many: PLEASE
don't be alarmed. As I have repeatedly said, Erik's implementation of
Smith's work seems to work well. The inaccuracies in that method for
fixed rate conversions, including the additional inaccuracy of the
unnecessary linear interpolation, seem to be virtually inaudible.
The main advantage is that a single method can be used for both fixed-
and variable-rate conversions, and this is indeed a *considerable*
advantage for a lib-based implementation. We are all indebted to Erik
for creating libsamplerate, and this includes me.
 
-------------------------

For developers:

Developers, however, should at least be aware of what is going on
there. I would advise anyone who has a *critical* dependence on
sample-rate conversions to carefully read Smith's notes and to make
sure that they understand what is going on. They should also
experiment with Smith's technique, including implentation of different
windows to see how bad it can be if things go wrong. Erik's
"measurements" that I've seen so far aren't very useful for these
worst-case situations. Smith may have had something more useful such
as a bound of some sort, but frankly I don't recall at this moment and
I'm not motivated to check it out at this time (sorry!). I have too
much to do following this trip, and this post has taken all my spare
time.

Sorry for the length, but I wanted to clear up some misconceptions about
what I've posted as well as raise a flag (without causing some sort of
fiasco) for those who may not have had time to study sinc-based methods.

Regards to all,
Dave.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Sep 22 2004 - 19:57:44 EEST