Re: [MP3 ENCODER] Some suggestions for LAME - please review
Hi Frank, 1. FFT filters are strictly speaking no filters (they are not a LTI system), so they have some nasty properties, which are more or less audible. The audibility depends on the steepness of the filter. So high passes should never be made by FFT filters. Never ever. Filter flanks modulating the signal, a property LTI systems NEVER have. May be also low pass filter are a bad idea. For high pass filters I'm absolutely sure. Yes, I agree but I've never heard of anyone using an FFT for low pass filtering. The problem is piecing together the results from the different windows. LAME does use an FFT filterbank for the psycho acoustics, where it needs the energies for each frequency. A windowed FFT gives excellent power spectrum estimation, which is why its use is suggested by MPEG for the psycho acoustics in all their codecs. The MDCT is different, it was only invented/discovered in the 1980s to solve the "edge effects" problem. It is a set of overlapped, modified cosine transformations. The windows have to be specially constructed to make the transform (forward then backward) lossless. It is not possible to get a lossless tranform out of any windowed FFT, nor if the windows overlap less then 50% (for a proof of this, see Malvar, "Signal Processing with Lapped Tranforms"). I was going to say Malvar knows what he is doing, except on his web site: http://www.research.microsoft.com/~malvar/ he has the patently absurd comment that WMA at 64kbs beats MP3 at 128kbs :-) The "polyphase filterbank" is similar to the MDCT, but not lossless, and has since been replaced by the MDCT (for example, in AAC and Vorbis). Here's what one of the MPEG papers says about the polyhpase filterbank (maybe this means something to you): "a QMF filter of order 511, with rejection of side lobes better than 96db." They call the MDCT a QMF filter with perfect reconstruction. Using your notation (below), LTI filters are what I've seen called FIR (for when b(i)=0) and IIR (when b(i)0). So now I finally understand what you are talking about :-) I doubt the MDCT can be characterized as a LTI filter. Mark 2. FFT filters approximating non recursive filter (often called FIR filters, which is not correct), but actually they are a mixture of a frequency dependent modulator and a filter. Non recursive filters are only a very special class of filters. All LTI filtering is done by: A B y(n) := Sum a(i) x(n-i) - Sum b(i) y(n-i) i=0 i=1 Every Filter can be characterized by the a(0...A) and b(1...B). For non recursive filters is B=0 and A=0 (also called moving average filters), for absolute phase filters is A=0 and B0 (also called auto regression filter). Filters with B0 and A0 are mixing both base vectors of filters and are also called auto regression moving average filters. You can divide ever (LTI) filter into two filters, a MA and a AR filter: A v(n) := Sum a(i) x(n-i) i=0 B y(n) := v(n) - Sum b(i) y(n-i) i=1 Now you can set b(0):=1 A v(n) := Sum a(i) x(n-i) i=0 B v(n) := Sum b(i) y(n-i) i=0 This gives (x,y,z complex, O is a big omega and omega/fs, j is sqrt(-1) ) A v(w)/x(w) = Sum a(i) exp (jOi/fs) i=0 B v(w)/y(w) = Sum b(i) exp (jOi/fs) i=0 Substituting exp(jO/fs) = z gives Ai v/x = Sum a(i) z i=0 Bi v/y = Sum b(i) z i=0 and Ai Sum a(i) z i=0 y/x = --- Bi Sum b(i) z i=0 So you can see: MA = P_A(z), AR = 1/Q_B(z) and ARMA = P_A(z)/Q_B(z). Example: The easiest AR filter, a integrator (1st order) can only be programmed by a infinite long MA filter. Are polyphase filters LTI systems? FFT filters aren't. And they are comparable with the subset of MA filters. -- 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/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
On Sun, Oct 01, 2000 at 09:10:19PM +0200, Robert Hegemann wrote:
So for backward compatibility we should make a wrapper library
with the old interface (as much as possible) and mark this as
old and outdated, to give clients the possibility for smooth
migration to the new API.
old clientnew clients
||
v|
wrapper lib |
||
++-
| ||
v vv
lame-enc-lib lame-dec-lib lame-hdr-lib
lame-enc-lib:
- lame's encoding engine
- maybe with Xing's VBR header stuff if it must be
lame-dec-lib
- lame's wrapper to the mpg123 library
lame-hdr-lib
- wave header
- Xing header
- ID3 stuff
wrapper lib
- the old libmp3lame and interface
What about the proposal to design and discuss a well designed lame API now
without implementation? AFAICS this takes at least 3 months, if you want to
have a durable and neat API, Mark don't want to change the API until summer
2001. May be should use this time to design all the structures are needed
and the lame.h file needed. This interface should be designed in a way, so
* no arbitrary constants are in it
* also Layer I, Layer II and AAC can added to this interface
* also multiple channels are possible
* feed count be int16, int32, float, double
* Support of huge arrays (open file, memmap, run encoder once, save result)
* solving 'Gap' problem
* solving compatibility problem with LAME 3.xx interface
I propose a file 'NewAPI.h', were all this is written down (prototypes and
rationale). This is better than only discussing and later forgetting the
results.
/*
* All Bitstream Data is stored in a bitbuffer_t structure. So you
* - only have to pass one argument
* - functions have the chance to increase the buffer if necessary
* - you don't need the return value to return the size of the MP3 data,
* so you can return other things (error codes or other stuff)
* - correctness of the bitbuffer parameter can be checked by the C Compiler
* - all functions have the same structure
*
typedef struct {
void* data;// data buffer, allocated via malloc ()
const size_t size;// maximal size of the data buffer
size_tlen; // valid octets stored in this structure
} bitbuffer_t
/*
* The lame API only sees very little of the internal structure of
* _IO_LAME. Only if compiled with BUILD_LAME_LIB all elements are
* visible (and writable).
*/
typedef void (*fnptr) (...);
typedef struct {
#ifdef BUILD_LAME_LIB
const fnptr* virtual_function_table;
int128struct_ID;
int init_state;
...
#else /* BUILD_LAME_LIB */
const fnptr* virtual_function_table;
const int128 struct_ID;
const int init_state;
const char__internal_data__ [32000];
#endif /* BUILD_LAME_LIB */
} _IO_LAME;
typedef int errorcode_t;
bitbuffer_t open_bitbuffer ( size_t size = 16384 );
int close_bitbuffer ( bitbuffer_t* buffer );
int set_FILE_binary ( FILE* fp );
LAME*lame_open ( void );
int lame_close ( LAME* lp );
/* Nice would be if this fucntions returns the exact input frequency. But this is only
possible if
the output frequency is available */
long double lame_set_input_samplefreq ( LAME* lp, long double freq = 44100.l );
long double lame_set_output_samplefreq ( LAME* lp, long double freq = 44100.l );
int lame_set_number_of_channels ( LAME* lp, int front = 2, int rear = 0, int
dual = 0, int docu = 0 );
int lame_set_min_bitrate( LAME* lp, int minbitrate = 112000 );
int lame_set_max_bitrate( LAME* lp, int maxbitrate = 32 );
int lame_set_minmax_bitrate ( LAME* lp, int minbitrate = 112000,
maxbitrate = 32 );
int lame_set_cbr_bitrate( LAME* lp, int minbitrate = 128000 );
real lame_set_cwlimit( LAME* lp, real freq = 8871.68 );
const char* lame_version( LAME* lp );
real lame_set_mask_to_noise_ratio( LAME* lp, real ratio = 0. );
lame_mode_t lame_set_bitrate_mode ( LAME* lp, lame_mode_t mode = lame_cbr );
real lame_set_fullscale_level( LAME* lp, real fullscale = 32768. );
int lame_set_coding_quality ( LAME* lp, int quality = 50 ); // 0 worst,
50 default, 100 best
int64lame_read_coded_pcmsamples ( LAME* lp );
errorcode_t lame_encode_buffer_short (
LAME* lp,
bitbuffer_t* buffer,
size_tpcmdata_len,
const short* channel1,
... );
errorcode_t lame_encode_buffer_interleaved_short (
LAME* lp,
bitbuffer_t* buffer,
[MP3 ENCODER] Winamp/100hz bug: SOLVED!
I was going through my backlog of email that still needs to be answered, and I came upon Rob's Jun 21 message (below) about the maximum value of the big_values range. As I read this message for the third time, still not sure what to think about this issue, it occured to me: This has to be the winamp/100hz bug! If you change IXMAX_VAL to 8191, then the LAME produced "100only.mp3" file plays back correctly in Winamp :-) I always thought the bug was related to the large amounts of ancillary data. But the same thing that causes that (very little bit pressure) also allows for very large amplifications, causing encoded values to be in the range 8192 up to 8206. It is possible to encode values up to 8206, although the ISO docs can be interpreted to say you should not use values greater than 8191. Most decoders can handle values up to 8206, including Fraunhofer, but some decoders (Winamp, Macamp, Sonique) choke on this. This probably shouldn't be called a winamp bug or a LAME bug, but instead a unclear ISO specification. Should we change IXMAX_VAL to 8191? pros: 1. as Rob points out, less false syncwords in the bitstream. (8206 is encoded as 0x1FFF). 2. LAME produced mp3's will no longer trigger Winamp bug. cons: 1. Winamp may not bother to fix their decoder 2. Tiny loss in quality just to pander to Winamp users. (all Linux decoders I've tested do not have this problem) 3. LAME produced mp3's will no longer trigger Winamp bug (so it will look like it was a bug in LAME :-) Mark From: Rob Leslie Date: Wed, 21 Jun 2000 03:06:27 -0400 Hi Mark, I'm pretty sure it is okay as is. Values greater than 8191 would always be encoded with "linbits", meaning the number is written directly into the bitstream after an escape code. linbits allows up to 13 digits, which would give an upper bound of 8191. But with mp3/linbits, 15 is subtracted before the number is written to the bitstream. Thus the actual maximum is 8206. (numbers 15 are encoded with huffman codes) I understand how values up to 8206 can be encoded; my question is whether it should be considered legal to encode values greater than 8191, since a decoder relying on the statement in ISO/IEC 11172-3 that "[t]he maximum absolute value in this [big_values] range is constrained to 8191" might be tempted to allocate a requantization lookup table with only 8192 entries. Such was the case in my own implementation until I discovered LAME could (albeit rarely) create bitstreams with encoded values 8191. It wouldn't be the only ambiguous statement in the standard, but in context it does appear pretty clear. The informative statements in C.1.5.4.4.2 are less clear but, at face value, could also support the conclusion that the maximum absolute value should be constrained by linbits alone, and not 2^linbits + 15. At least one argument I can think of in favor of the limit, other than the assertion in the standard, is to help prevent creating false sync words. It can also serve as minimal error detection. More thoughts? -- Rob Leslie [EMAIL PROTECTED] -- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Fix for Makefile.in
Here's a diff against Makefile.in cvsed this morning. Not every system has GNU make as the default: - *** Makefile.in Sun Oct 1 19:34:33 2000 --- Makefile.in.fixed Mon Oct 2 10:11:54 2000 *** *** 450,462 $(LN_S) $(SHARED_LIB_MAJOR) $(SHARED_LIB) $(PGM): lib ! cd frontend; make mp3x/mp3x: ! cd mp3x; make frontend/mp3rtp: ! cd frontend; make mpglib/mpglib.a: cd mpglib; $(MAKE) --- 450,462 $(LN_S) $(SHARED_LIB_MAJOR) $(SHARED_LIB) $(PGM): lib ! cd frontend; $(MAKE) mp3x/mp3x: ! cd mp3x; $(MAKE) frontend/mp3rtp: ! cd frontend; $(MAKE) mpglib/mpglib.a: cd mpglib; $(MAKE) - Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
Naoki IIRC, bug of winamp is also triggered by FhG encoded mp3 file. This means that nitrane has more than one bug. So, changing IXMAX_VAL to 8191 doesn't solve all problems. I think we should investigate what FhG encoder does, and make lame do what FhG does. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- 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 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] mpglib related routines (Re: modularization)
What about the proposal to design and discuss a well designed lame API now without implementation? AFAICS this takes at least 3 months, if you want to have a durable and neat API, Mark don't want to change the API until summer 2001. May be should use this time to design all the structures are needed and the lame.h file needed. This interface should be designed in a way, so * no arbitrary constants are in it * also Layer I, Layer II and AAC can added to this interface * also multiple channels are possible * feed count be int16, int32, float, double * Support of huge arrays (open file, memmap, run encoder once, save result) * solving 'Gap' problem * solving compatibility problem with LAME 3.xx interface I propose a file 'NewAPI.h', were all this is written down (prototypes and rationale). This is better than only discussing and later forgetting the results. This is a good idea. Some comments (Frank: not all of these are serious:-) 1. file I/O has been removed from the library, so we only have to deal with encoding buffers. 2. I dont think declaring the sample rate as 'long double' is enough. We need to add a portable, object oriented arbritrary precision floating point library to LAME. The sample rate should be a default of 128 digits, but the user can increase this with suitable options. 3. Creating a dozen or so odd types, all synonymous with 'int' is a great idea. But I saw a few 'int's left. I think we need to replace these with more new types. 4. LAME should be converted to C++ or Java. C just is not up to the task of distinguishing between 30 different types of integers. 5. All developers should be required to take 200 hours of UML training before working on any more code. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f Date: Mon, 02 Oct 2000 18:32:58 +0900 From: Naoki Shibata [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] Mark It is possible to encode values up to 8206, although the ISO docs can Mark be interpreted to say you should not use values greater than 8191. Mark Most decoders can handle values up to 8206, including Fraunhofer, but Mark some decoders (Winamp, Macamp, Sonique) choke on this. Mark This probably shouldn't be called a winamp bug or a LAME bug, Mark but instead a unclear ISO specification. Mark Mark Should we change IXMAX_VAL to 8191? IIRC, bug of winamp is also triggered by FhG encoded mp3 file. And, Null soft have already almost completed their new decoder. The 100hz bug is not triggered by FhG produced mp3 files. But winamp does have some other, less audible problems, as shown by David Robinson's web site. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
Should we change IXMAX_VAL to 8191? pros: 1. as Rob points out, less false syncwords in the bitstream. (8206 is encoded as 0x1FFF). 2. LAME produced mp3's will no longer trigger Winamp bug. cons: 1. Winamp may not bother to fix their decoder 2. Tiny loss in quality just to pander to Winamp users. (all Linux decoders I've tested do not have this problem) 3. LAME produced mp3's will no longer trigger Winamp bug (so it will look like it was a bug in LAME :-) I'd vote for limiting it to 8205. The quality loss would be very minimal. It won't solve winamp's problem, but it's easy to fix in the decoder, now that we know exactly what the problem is. The advantage is that 8205 is 0x1FFE, which is not a valid syncword for mpeg1-2. With this, audio resync on corrupted bitstreams would be easier for the decoder Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
This is a good idea. Some comments (Frank: not all of these are serious:-) I am serious :) 5. All developers should be required to take 200 hours of UML training before working on any more code. 6. Learn more about CVS, especially about making your own branch. --- [EMAIL PROTECTED] // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -q1
On Fri, 29 Sep 2000, Robert Hegemann wrote: does someone know any sample where a VBR encoded MP3 with -q1 gives a better sounding MP3 compared to a same sized VBR with -q2 ? From your recent postings I'm detecting that you think -q1 can only rarely give a sonic improvement. In fact it is more likely to degrade the sound over -q2? If so, the Roel recommendation of -q1, seems a little dangerous? You think the extra ~5% file size, that encoding using -q2 requires, usually provides superior sound quality? Cheers. Mark Powell - UNIX System Administrator - The University of Salford Academic Information Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 5936 Fax: +44 161 295 5888 www.pgp.com for PGP key -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Broken MP3s
I know mp3_check can do it... Only keep valid frames from any MP3 files... The problem is that I never released publicly the Win32 build/corrections... And I have no time to do so :( so if you use Linux, you can do it :) - Original Message - From: "Roel VdB" [EMAIL PROTECTED] To: "David Bridson" [EMAIL PROTECTED] Sent: Saturday, September 30, 2000 8:36 PM Subject: Re: [MP3 ENCODER] Broken MP3s | Hello David, | | Saturday, September 30, 2000, 6:25:31 PM, you wrote: | | DB I have a couple of MP3s which I encoded with LAME a long time ago. I made | DB the mistake of putting them on a Zip disk. Now they've got errors in them | DB which they didn't have in the first place, but Nero 4 is refusing to put | DB them on CD. Does anyone know if there's a utility anywhere out there which | DB could possibly fix them? | | 1- find the player that plays them with minimal distortion | 2- write them to wav | 3- burn the wavs with nero | | file://r3mix.net | | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | | | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
I was only wondering about the size of the wav's (not the binary contents). As noted in a parallel reply from Mark, the discrepancy had something to do with the VBR header being decoded into extraneous samples. Thank you, Liviu - Original Message - From: "Zia Mazhar" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, October 01, 2000 11:37 AM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip Hello Liviu, Once you encoded the wave into MP3, the originality is lost forever. The first wave you'll get will have exactly the same quality of the MP3 of "CBR (-b256 -ms -h)" and the second wave will have exactly the same quality of "VBR (-V1 -b128 -mj -q1)". Think about it for some time, and it'll be clear to you why. - Zia Liviu wrote: Please pardon the question if naive but I couldn't find the answer elsewhere... I encode the same .wav to 2 different .mp3's - first one CBR (-b256 -ms -h), second one VBR (-V1 -b128 -mj -q1). Then I decode (--decode) the 2 .mp3's back, and the resulting .wav's have different sizes, both of them different from the original one. Is this expected behaviour? Best Regards, Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
True, it was the -t encode switch. By the way, isn't "lame -?" -t disable writing wav header when using --decode a bit misleading about this? Yes, that is a little misleading: "-t" option is listed twice, since it disables wav headers when decoding, and disables Xing headers when encoding. Thank you, Liviu P.S. The resulting .wav's are slightly _smaller_ than the original, see file listing below - t4.wav is the original wav, t4*.mp3 the encoded mp3's and t4*.wav the decoded wav's. Could easily be a bug in LAME. But before I look into this, can you do one more thing: compare the .wav headers? LAME writes a very spartin .wav header. t4.wav may include some extra "chunks" not in the LAME produced wav headers. 14,276,684t4.wav 2,590,511t4_b256_ms_h.mp3 1,862,685t4_V1_b128_mj_q1.mp3 1,862,268t4_V1_b128_mj_q1_t.mp3 14,275,816t4_b256_ms_h.wav 14,280,424t4_V1_b128_mj_q1.wav 14,275,816t4_V1_b128_mj_q1_t.wav There does seem to be a bug in lame 3.87 - the decoder no longer recognizes the VBR header, and instead encodes it as silence. This is why t4_V1_b128_mj_q1.wav is larger. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
For decoder enthusiasts: 100hz bug fixed versions of Nitrane and their upcoming Nitrane replacement are available at: http://www.sulaco.org/mp3/winamp/winamp.html Nullsoft sent me these .zip files, but I haven't tested them yet. They are probably also available somewhere on www.winamp.com. 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). 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/ )
