>
> :: >
> :: > 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.
> ::
> Input is a 57:10.00 WAV file with 34301.0 Hz sample frequency (470 MByte).
>
> What should be IYHO the output?
>
> a) Resample 9:7 and got a 57:10.10 MP3 file with 44.1 kHz with 30 ppm
> pitch error
>
> + faster (factor of 2)
> o little pitch error
> - timing error
> + excellent side slope rejection is no problem
> + you need no fractional fs, because the precission is restricted
> by the maximum possible a:b ratio (for instance a,b <= 441)
> + often rounds rounded values to the correct values (see below)
>
> b) Resample 44100:34301 and got a 57:10.00 MP3 file with 44.1 kHz
> with exact pitch
>
> + slower (nearly doubles the computation time)
> + no pitch error
> + no timing error
>
> - for good side slope rejection (>90 dB) you need something between 128
> and 256 tables
>
> - this routine makes exactly what you are requesting:
> fs_in = 33333, fs_out = 50000:
> This method really resamples by 50000:33333 = 1.500015...:1, not 3:2.
>
> c) Both should be possible.
>
>
> I only need the input: a), b) or c).
b. Right now the maximum number of tables is set to 160.
Resampling in LAME is really so that LAME can lower the samplerate
for low bitrate encoding. It is not in LAME so that we can
handle unusual input files. People with 34301hz input files
should probably resample with sox first, instead of relying on LAME.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
