On Sat, Sep 30, 2000 at 10:08:09AM -0600, Mark Taylor wrote:
>
> I dont like code like that either! Good thing stuff like that
> is not in LAME.
>
> MP3 encoding, and WAV input files only support integer sampling
> frequencies.
>
AIFF supports IEEE-854 80 bit floats. AU only support 8 kHz. MP3 only
8/11.025/12/16/22.05/24/32/44.1/48 kHz. CDs only 44.1 kHz. There are also
file formats out there which can only store 1 MHz/(8...263).
This is no reason.
> Are you saying we should add support to LAME for non-integer sampling
> frequencies?
>
It is easier to round a float down to an integer than vice versa.
The code I posted guesses sometimes the wrong, and there is no way to
prevent this. This code is not necessary in the AIFF section.
> Is there any application for this?
>
May be applications where an exact synchronization is necessary (video?
duplex MP3 encoding/decoding?). I don't know. But if it is necessary it is
hardly to fix. Otherwise we need additional 4 or 8 bytes of RAM to store
a double or long double instead of an int (32 bit).
I have bad experiences with the two items "time" and "premature rounding".
Programs seemingly are working, but sometimes there are short errors. Or a
program runs several minutes and then begins to create garbage (circular
buffer overtake). Or a program runs very well, but the technical data (phase
noise) increases with time. We had a function generator (1 mHz...20 MHz, 0.5
mV...5 Veff) which was unusable for long time experiments. Using it for 1 or
2 hours was okay, but we need from 2...4 weeks! It takes nearly 3 months
to circumscribe the cause of our problem.
Question: When fs_in/fs_out is not representable by a:b with little a and b,
what do you like best:
[_] Lame rounds fs_in in a way, so fs_in/fs_out is representable by little a:b
[_] Lame have a function to resample exactly any ratio
[_] both, selectable
> > :: I think the number of windows needed
> > :: is given by: out_samplerate/(lcd(in_samplerate,out_samplerate))
> > ::
> > :: (44.1khz -> 32khz requires 320 windows, but 48khz->32khz only
> > :: requires 4!)
> > ::
> > 48 kHz -> 32 kHz requires 2 sets of coefficients. This coefficients are not
> > the windows. The window function is the same for all sets of coefficients.
>
> This is of course just semantics. The fuction is the same, just
> shifted as you say. Each shifted version of this function has a
> different discrete representation in the computer. You want to call
> this just coefficients, but I refer to them as "windows", this is
> short hand for "sample values of the shifted, windowed convolution
> function".
>
// WINDOW_SIZE is the width of a half of the window,
// so j always steps through an odd number of samples
//
for ( j = 0; j <= 2*WINDOW_SIZE; j++ ) {
tmp1 = ((k+j)*iNew - i*iOld) / (long double)iOld; // overrun and PLOSS save
tmp2 = ((k+j)*iNew - i*iOld) / (long double)iNew;
sum += Coeff [j] = sinc (tmp1) * window (tmp2 * w);
// ^ ^
// sinc interpolator window function
// FT of the desired FR (small footprint of f and FT(f))
}
// Windowing the sinc interpolator changes A(f=0). This effect is
// also not constant for all coefficient sets. So adjust it to avoid DC
// and LF modulation
//
for ( j = 0; j <= 2*WINDOW_SIZE; j++ )
Coeff [j] /= sum;
}
with:
long double sinc ( long double x )
{
if ( x == 0. ) return 1.;
if ( x < 0. ) x = -x;
return sinpi ( x ) / ( M_PIl * x );
}
long double window ( long double x )
{
if ( fabs (x) >= 1) return 0.;
x = cospi (x);
return (0.16 * x + 0.50) * x + 0.34; // using addition theorem of arc
functions
}
--
Frank Klemm
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
