> > 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
>
>
LAME is going to only work with integer samplerates. MP3 output must
always be an integer samplerate. If you want to encode
from non-integer samplerate source, resample first.
>
> // 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
> }
>
Thanks for the code, but it is basically the same as what
is already in LAME. Originally I tested the window coefficients
to make sure they did sum to 1. The error was small enough
that I ignored it. But I took your advice and added the
normalization step. (but in all my resample test cases, the
new window coefficients did not change the mp3 output in any way).
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
