Re: [MP3 ENCODER] resampling
::
::
::I think this should be a seperate utility outside of lame? Most people
::encode from CDs, which usually are already correctly filtered for stuff
::below 20 Hz.
::
:: For pop music this is (mostly) true. I will test several CDs. Next week.
:: The psycho part I would nevertheless filter with a 8rd order Chebychew
:: high pass @80 Hz. Remember active controlled boxes by BO. But also
:: normal vented tubes have a relatively sharp cut off at low frequencies,
:: so don't rely on masking.
::
::
:: The windowed FFT used for the psycho acoustics surely has better
:: frequency responce than an 8th order Chebychev filter,
:: so there will negligable leakage of this 80Hz tone into
:: other frequencies. If you think this is a problem, I would
:: try some experiemnts by removing (from the psycho acoustics)
:: the coefficients up to 80hz.
::
1. Chebychev filters (LTI system) have no leakage at all
2. Chebychev highpass filters (like all IIR filters) have a worse
frequency resolution for high frequencies ( - oo) and a extremly
good for low frequencies ( - 0).
3. You can program a FFT like filterbank with simple 2nd order
lowpass filters. But this filterbank has problems with
detecting high frequencies if there are high level low
frequency signals are present.
Calculate yourself:
#include stdio.h
#include math.h
#define PASS_BAND_RIPPLE0.1 // dB
#define ORDER 8
#define STOP_BAND 84.22 // Hz, note damping is not
// -3 dB, but -PASS_BAND_RIPPLE dB
double cheychev_polynom ( double x, int n )
{
// NOTE: These are really polynoms, but the trigonometric
// represenation is much easier to remember
if ( x = 1 )
return cos ( n*acos (x) );
else
return cosh ( n*acosh (x) ); // would be the same formula for complex numbers
}
int step ( int i )
{
if ( i200 ) return 1;
if ( i500 ) return 2;
if ( i 1000 ) return10;
if ( i 2000 ) return50;
if ( i 5000 ) return 200;
if ( i 1 ) return 1000;
if ( i 25000 ) return 5000;
return i;
}
int main (void)
{
int i;
double poly;
double damp;
double ripple = pow ( 10., 0.1*PASS_BAND_RIPPLE ) - 1.;
for ( i = 1; i = 2; i += step (i) ) {
poly = cheychev_polynom ( (double) STOP_BAND / i, ORDER );
damp = 10. * log10 ( 1. + ripple * poly * poly )
+ ( ORDER 1 ? 0. : -PASS_BAND_RIPPLE );
printf ( "%5u Hz%9.2f dB\n", i, -damp );
}
return 0;
}
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
:: :: 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 = 3, fs_out = 5: This method really resamples by 5:3 = 1.500015...:1, not 3:2. c) Both should be possible. I only need the input: a), b) or c). -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
:: :: 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 = 3, fs_out = 5: This method really resamples by 5:3 = 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/ )
Re: [MP3 ENCODER] resampling
:: As a value of 200 for BLACKSIZE showed an improvement in resampling, why :: does is still got a value as low as 25? :: Low pass, high pass and resampling code should be replaced by artefact-less program code. Which filters have artifacts? low pass code is implemented with a very high quality polyphase filterbank. It is a near-lossless filterbank with a 256 point window and is claimed to have very good frequency resolution. high pass filtering: At frequencies above a few hundred Hz, this can also be implemented with the polyphase filterbank. Below that, any such filter would require a large window size and lots more buffering. I think this should be a seperate utility outside of lame? Most people encode from CDs, which usually are already correctly filtered for stuff below 20hz. Resampling: The resampling code does had some minor problems due to a hack I put in to save CPU time, but this has now been fixed. There are no more artifacts, but it is unclear what type of low pass filtering should be done for the resampling routine: sharp cuttoff or smooth transition band? Can you explain what you mean by LTI? All the filters in lame are of course translation (in time) invariant. All three are currently done by code not being a LTI system, which results in unnecessary distortions. You can see this in the spectral view of CoolEdit Pro. LTI stands for Linear Time Invariant. Non LTI systems are generating additional frequencies instead of only emphasing and deemphasing frequencies. -- Mit freundlichen Grüßen Frank Klemm Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
As a value of 200 for BLACKSIZE showed an improvement in resampling, why does is still got a value as low as 25? Regards, -- Gabriel Bouvigne - France Hi Gabriel, Increasing BLACKSIZE only improves the sharpness of the lowpass cutoff. For resampling, I dont think we need an extremely sharp cutoff, and maybe a more gradual cutoff even sounds better? The problem David discovered (on that mp3.com posting) (aliasing onto lower frequencies) was related to BPC - the number of precomputed convolution functions. LAME was precomputing only 16, but this is now bumped up to 160 in lame 3.87. I hope to add something soon which has it precompute the exact amount needed. Does anyone have code which computes the lcd (largest common denominator) of two ints? 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!) Mark tthink e -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
Mark Taylor schrieb am Don, 28 Sep 2000:
I hope to add something soon which has it precompute the exact amount
needed. Does anyone have code which computes the lcd (largest
common denominator) of two ints? 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!)
int gcd( int u, int v )
{
int t;
while (u 0) {
if (u v) {
t = u;
u = v;
v = t;
}
u = u-v;
}
return v;
}
32000/gcd(44100,32000) = 320
32000/gcd(48000,32000) = 2
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
:: As a value of 200 for BLACKSIZE showed an improvement in resampling, why :: does is still got a value as low as 25? :: Low pass, high pass and resampling code should be replaced by artefact-less program code. All three are currently done by code not being a LTI system, which results in unnecessary distortions. You can see this in the spectral view of CoolEdit Pro. LTI stands for Linear Time Invariant. Non LTI systems are generating additional frequencies instead of only emphasing and deemphasing frequencies. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
::
::
::
:: As a value of 200 for BLACKSIZE showed an improvement in resampling, why
:: does is still got a value as low as 25?
::
::
:: Regards,
::
:: --
::
:: Gabriel Bouvigne - France
::
:: Hi Gabriel,
::
:: Increasing BLACKSIZE only improves the sharpness of the lowpass
:: cutoff. For resampling, I dont think we need an extremely sharp
:: cutoff, and maybe a more gradual cutoff even sounds better?
::
:: The problem David discovered (on that mp3.com posting) (aliasing onto
:: lower frequencies) was related to BPC - the number of precomputed
:: convolution functions. LAME was precomputing only 16, but this is now
:: bumped up to 160 in lame 3.87.
::
:: I hope to add something soon which has it precompute the exact amount
:: needed. Does anyone have code which computes the lcd (largest
:: common denominator) of two ints?
::
Frequencies are real numbers, not integral numbers.
And I don't like code like:
if ( Frequency == 44055 || Frequency == 44056 ) Frequency = 2863636/65.L; // NTSC
PCM
if ( Frequency == 31468 || Frequency == 31469 ) Frequency = 2863636/91.L; // NTSC
Hi8 Digital
if ( Frequency == 22254 || Frequency == 22255 ) Frequency = 244800/11.L; // MAC
HQ
if ( Frequency == 11127 || Frequency == 11128 ) Frequency = 122400/11.L; // MAC
LQ
if ( Frequency == 8012 || Frequency == 8013 ) Frequency = 312500/39.L; //
NeXT/Telco
if ( Frequency == 5512 || Frequency == 5513 ) Frequency = 44100/ 8.L; // 1/8
CD
Table index search is done by:
double Factorize ( const long double f1, const long double f2, int* x1, int* x2 )
{
unsigned i;
long ltmp;
long double ftmp;
double minerror = 1.;
double abserror = 1.;
double error;
assert ( f1 0. );
assert ( f2 0. );
assert ( x1 != NULL );
assert ( x2 != NULL );
for ( i = 1; i = MAX_TABLES; i++) {
ftmp = f2 * i / f1;
ltmp = (long) ( ftmp + 0.5 );
error = fabs ( ltmp/ftmp - 1.);
if ( error minerror ) {
*x1 = i;
*x2 = (int)ltmp;
minerror = error * 0.9;
abserror = ltmp/ftmp - 1.;
}
}
return abserror;
}
:: 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.
You need setup code like:
err = Factorize ( NewFrequency, Frequency, iNew, iOld );
if ( err != 0. )
fprintf ( stderr, "(%.6Lf = %.6Lf Hz, Ratio %u:%u, Error %+.3f ppm) ",
Frequency, NewFrequency, iNew, iOld, 1.e6*err );
else
fprintf ( stderr, "(%.6Lf = %.6Lf Hz, Ratio %u:%u) ", Frequency,
NewFrequency, iNew, iOld );
...
for ( i = 0; i iNew; i++ ) {
k = imuldiv (i, iOld, iNew) - WINDOW_SIZE;
(iNew iOld ? Calc_Coeffs_Down : Calc_Coeffs_Up) ( Coeff [i], iNew, iOld, i,
k );
}
and transforming code like:
for ( ...; i ...; i++ ) {
k = imuldiv (i, iOld, iNew) - WINDOW_SIZE;
ScalarWindow ( Dest.fData [i], Coeff [i%iNew], sData + k );
}
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Resampling at wrong pitch/speed: bug?
Hi Mark, you wrote on Wed, Oct 27 1999: lame -b 128 -X5 -v -V 4 -h -k -d --resample 48 in.wav out48.mp3 The bug is that the error message "Error: resample code not yet written!" was not being printed :-) LOL! Thanks for the clarification. I think the upsample to 48kHz at 320kbs because (IIRC) a 44.1kHz and lower 320kbs frame violates some ISO restrictions on max buffer sizes. Fortunatly most decoders allow for larger buffer sizes. Other than that, is there any reason to upsample? You probably know about that Microsoft/Intel "Standard", the AC97/PC97 according to which all sound-processing has to take place at 48 kHz, regardless of input. So most cards resample everything at 48 kHz. I came to Linux because I was sick and tired of MS/Intel and would want my sound-card to output the digital stream exactly as it is. So I assumed that the resampling to 48 kHz would degrade quality, to confirm my assumption I tried to encode the same wav (from Audio-CD) once with the usual 44.1 kHz and then with 48 kHz. I wanted to compare these outputs (assuming, the soundcard does not do any more "clever" resamplings at 48 kHz). This darn MS/Intel "standard" is very annoying, if you want bit-exact outputs, like e.g. AC-3 or DTS-Streams (DVDs). Kind regardsFrederick -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Resampling at wrong pitch/speed: bug?
Hi all, just gave it a try: lame -b 128 -X5 -v -V 4 -h -k -d --resample 48 in.wav out48.mp3 The .wav file was grabbed from an audio-CD (44.1 kHz). mp3 sounds horrible, way too fast. Is this a feature or should the resampled file sound like the original? The FhG resamples to 48 kHz without any noticeable speed-up. FhG does the resampling even by default, if you choose 320 kBit. Ok, it's lame 3.35, haven't tried out the 3.36 but since this is not mentioned in the history-file, I suppose 3.36 behaves the same. Kind regardsFrederick The bug is that the error message "Error: resample code not yet written!" was not being printed :-) I think the upsample to 48kHz at 320kbs because (IIRC) a 44.1kHz and lower 320kbs frame violates some ISO restrictions on max buffer sizes. Fortunatly most decoders allow for larger buffer sizes. Other than that, is there any reason to upsample? I have been thinking about the downsampling: I think we should just add a simple linear downsampler, with the tapered lowpass sox type filter applied directly to our MDCT coefficients. This would require very little extra work, and my guess is the aliasing from linear downsampling is insignificant compared to what MPEG2 compression does to the high frequencies. Has anyone who uses sox/MPEG2 noticed a difference between the sox 'resample' option and 'polyphase'? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
