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
> :: > 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: > Okay, i'm convinced. Lets put in a chebychev IIR filter for the high pass operator. We can save the debate about not computing psycho acoustics at 80hz until after this is working :-) Mark -- 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
::
::
:: > > 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 B&O. 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
#include
#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 ( i < 200 ) return 1;
if ( i < 500 ) 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
> > 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 B&O. 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. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
> > 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/ )
Re: [MP3 ENCODER] resampling
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/ )
Re: [MP3 ENCODER] resampling
On Sat, Sep 30, 2000 at 10:25:42AM -0600, Mark Taylor wrote: > > 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. > Filters: LTI filters non LTI filters LTI filters: frequency filters polynomial filters ... frequency filters: AR filters <= 2 MA filters ARMA filters non LTI filters: FFT filtering (convolution or circular filter) Windowed FFT filtering (to reduce time variant effects) phase discrimator amplitude discriminator ... MA filters can generated with: FT + Windowing method(fast and bad results) <= 1 Remez Exchange (very slow, but nice results) ... AR filters can be generated with: Z Transform (discrete Laplace Transform) ... ARMA filters can be generated with: This is really Black Magic (elliptic integrals) Or for some examples use ready calcualted tables "AR filters" and "windowed filter" are fully different things. You can't windows AR filters. > 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 B&O. But also normal vented tubes have a relatively sharp cut off at low frequencies, so don't rely on masking. > 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 cut-off or smooth transition band? > My experiences: fs > 36 kHz: uncritical, transition band should not start before 15 kHz f(-6dB) = 0.5 * fs 24 kHz < fs < 36 kHz: sharp cut-off to reduce loss of spectral components below fs/2 add little aliasing artefacts also increases quality f(-6dB) = 12.0 kHz for fs=24 kHz f(-6dB) = 14.0 kHz for fs=28 kHz f(-6dB) = 15.4 kHz for fs=30 kHz f(-6dB) = 15.8 kHz for fs=31 kHz f(-6dB) = 16.2 kHz for fs=32 kHz f(-6dB) = 18.2 kHz for fs=36 kHz fs < 24 kHz: more smooth, otherwise pre-ringing becomes audible f(-6dB) = 0.5 * fs > > Can you explain what you mean by LTI? All the filters in lame are > of course translation (in time) invariant. > Tests later. Cooledit doesn't run under Linux. ... back from Cooledit. PP filters are non LTI. But I don't understand how they are working and why they are non LTI. But the transition is really sharp and I also like the small raise in the frequency response before the transition band. But there should be no signal with medium or high tonality in the transition band. For f>12 kHz no problem, for f>8 kHz acceptable, for f<1 kHz unusable. -- Frank Klemm -- 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
> 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 > 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. Are you saying we should add support to LAME for non-integer sampling frequencies? Is there any application for this? > } > > :: 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". -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] resampling
> From: "Mark Taylor" <[EMAIL PROTECTED]>
>
> 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))
A positively ancient algorithm (by Euclid IIRC :)
/* gcd - greatest common divisor */
int gcd(int i, int j) {
return j ? gcd(j, i % j) : i;
}
or if you'd prefer a non-recursive version
int gcd(int i, int j) {
while (j) {
int t=j;
j=i%j;
i=t;
}
return i;
}
-- Mat.
--
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
:: 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
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? > > > 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/EQing/Analog-vs-digital ripping
Bad idea to use analogue recording through a soundcard. You get added distortion from the digital to analogue (DA) conversion from the CD player and then more distortion going back to digital (AD) through the soundcard. If you want to EQ a song then do it digitally. Rip the song using a CD ripper (eg. CDex). Then use the software Cool Edit or Goldwave or similar to EQ. Then encode to MP3. Ross. Shawn Riley wrote: > Oh, okay... Looks like I got in over my head... Hmm, recording a CD thru the line-in >seems to work fine for me... Oh well :-\ > > About the EQing, I think Greg misunderstood me... I use the EQ in the CD ripping >process, not in the MP3 decoding process. I use Winamp to play MP3s, & I leave its EQ >flat, though sometimes I'll drop it a couple of dB at 630Hz & 1kHz, or drop it at >60Hz when I play it through my parents' stereo. > If I'm wrong, & given that using an EQ plugged into both the CD player & the line-in >is "bad", how else are you supposed to "EQ-to-taste" from a CD recording? (i.e. EQing >during ripping) > > Guess I have a lot to learn. I'm probably halfway between you guys & the average joe >listener. > > If I ever came across the person who decided 44100Hz was the best sampling rate, I'd >shoot them. > > Shawn > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- 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/ )
