[MP3 ENCODER] Bug of long block pre-echo control
Hi, I found a bug in the long block pre-echo control code. if (gfc-blocktype_old[chn] == SHORT_TYPE ) thr[b] = ecb; /* Min(ecb, rpelev*gfc-nb_1[chn][b]); */ else thr[b] = Min(ecb, Min(rpelev*gfc-nb_1[chn][b],rpelev2*gfc-nb_2[chn][b]) ); In the loop of chn, chn goes up to 3, but the size of array gfc-blocktype_o ld[] is 2. So, this code works incorrectly in joint stereo mode. This code should be fixed like this. if (gfc-blocktype_old[gfp-mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE ) -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] toolame segmentation fault
Hi ! I'v came across problem in toolame. It segfaults on me on some files. One example is at ftp://mail.slon.net/pub/final.wav.bz2 but it is 8Mb bzip2 file. I looked at the code and it hapens in: psycho_I.c void subsampling in the first loop. While loop checks for i!=LAST, bu it happens that i become -100 (STOP) when tone=125. Then of course, as i is index to array [0..HAN_SIZE] there is no element power[-100]. Now this can be bug in previous tonal_label(power, tone); function, where power[i].next are defined but I wouldn't know. What hapend to help (but mind me I don't know what I'm doing) was replacing all power[i].next = STOP; with power[i].next = LAST; in this file. File gets encoded and I can't hear no quality downgrade from wav file. lp gody __ |Matjaz Godec|Agenda d.o.o.| ISP for business | | Tech. Manager| Gosposvetska 84 | WAN networks| | [EMAIL PROTECTED]| si-2000 Maribor | Internet/Intranet | | tel:+386.2.2340860 | Slovenija | Application servers | | http://www.elgo.si | http://www.slon.net | Caldera OpenLinux | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME file name changes from 3.86 to 3.87?
On Wed, 4 Oct 2000, Stefan Bellon wrote: Am I wrong or has the file quantize-pvt.c changed to quantize_pvt.c (and the header file as well)? Why was this done? As on RISC OS there's no GNU make available yet (but a port will be release hopefully soon!), I can't use the generic Makefile but I have to maintain an own Makefile for RISC OS. And I have to keep track on file name changes. So I wondered why such a change was made. Or am I wrong and the file name got mixed up on my end only? Wait 'til you see v3.88. You've got a big surprise coming to you :) I agree it probably wrong to use GNU make only makefiles. 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] Bug of long block pre-echo control
On Wed, 4 Oct 2000, Naoki Shibata wrote: I found a bug in the long block pre-echo control code. This code should be fixed like this. if (gfc-blocktype_old[gfp-mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE ) Naoki, Did this affect quality? I just folded this change back into my own v3.87, as v3.88 doesn't compile at the moment. It reduced a VBR file from 181.5Kbps down to 177.3Kbps. Is this to be expected? 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] lame 3.87 encode-decode roundtrip
The RAW's are different sizes, too: - original 14,276,640t4.raw - encoded then decoded back (cbr and vbr) 14,275,772t4_b256_ms_h.raw 14,275,772t4_V1_b128_mj_q1_t.raw The original .wav is reported to be 0:00.005 longer (1:20.933 vs. 1:20.928). I don't really mind the 1/200 second off - if that's the difference. Still, I thought I'd bring it up with you in case it's something you feel shouldn't happen. - Original Message - From: "David Balazic" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, October 03, 2000 9:49 AM Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip Convert them to RAW format , thus stripping the headers away. David Liviu wrote: But before I look into this, can you do one more thing: compare the .wav headers? I'd be glad to, only I don't know much about .wav headers, even less about comparing them. One thing, though, doing a .wav compare in EAC reports the original .wav being 0:00:00.004 longer. Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - -- 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)
:: :: 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. :: When you were a physicist, you were a cgs advocate and a SI enemy, right? -- Mit freundlichen Grüßen Frank Klemm background for not involved: cgs (stands for centimeter, gram, second) sets several elemental constants to 1 ( c=1, µ=1, k=1, kb=1) and uses only (floating point) numbers for all physical quantities. You can write all thing shorter and faster, and often you have no idea what you are talk about. 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] Winamp/100hz bug: SOLVED!
:: :: ISO spec says the maximum should be 8191. But as part of huffman :: decoding, you sometimes add 15 to the result, yielding values as large :: as 8206. Right now, LAME (and the ISO dist10 code) will make use of :: the full range: values up to 8206. :: :: The question is, should LAME be modified to limit this range to 8191. :: How likely is it that music triggers this error? When it is very unlikely in music, I would fix it in Lame. Rationale: * unlikely in music means that it is very unlikely to improve music' quality by using factor from 1FFF to 200E. * unlikely in music also means that it is not (urgent) necessary to fic this bug in WinAmp to play correctly older lame encoded files Does it decrease performance to make this command line configurable? -- 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] Parameter setting functions...
Just thought I'd say my thoughts on the different parameter setting function proposals we've had so far... Individual functions for each parameter: Pros: - None. ;) Cons: - Litters the API with "thousands" of functions. - If the parameter's type changes, the API has to change. - If a new parameter is introduced, the API has to change. Giving a parameter structure: Pros: - Hmmm, none. ;) Cons: - You have to be very careful not to disturb the order of the parameters. - You end up with a bunch of duplicates if you have to change parameters. - Different compilers can cause different alignments. Giving tag-pairs on stack to one function which parses them: Pros: - API never has to change. Cons: - Littering with different tags for each type. - It's possible to pass the wrong type. Giving tag-pairs on stack to 3 functions (one for each type): Pros: - API never has to change. - One tag for any type. Cons: - It's still possible to pass the wrong type, but it's much clearer since the function itself states which to pass. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
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. Mathematican: Arbitrary precission is not enough. Physist: Planck time is around 10^-42 s, age of universe is around 10^+18 s, so 60 decimal digits are good enough. non C Programmer: Current CPUs are supporting long double (being 64 or 80 bit) in hardware, so why we aren't use this. Assembler Programmer: How large are the floating point registers? Is there any trick to store two numbers to increase speed? No? Video technican: Films are at most around 4 hours, humans can detect time differences down to 20 ms, so we need something around 6 decimal digits. Markedroid: Reduce precission as long as noone complains. Advanced Markedroid: Reduce precission as long as noone charges you. Professional Markedroid: Reduce precission as long as income increases. C Programmer: Why we are not using a 'int', if we need more precission, then we can store ms or mHz in ints. Also µs, ms, cs and s/HZ are possible (see POSIX API). C++ Programmer: We need a class ... Ada programmers: Don't we have a generic type to store time intervals? COBOL programmer: Sample frequencies are between 0 and 9 Hz, right? FORTRAN programmer: It isn't an index, so I use a REAL. Rivest: Can we assume that all sample frequencies can be exactly described by a/b with a and b being two finite integral numbers with gcm (a,b) := 1 ... Haskell programmer: Do we need numbers? You can describe all by sets. or: There is really no computation until you want to remove the WAV files from hard disk. Perl: What are 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. Current C (C89 + POSIX) has something around 18 integer types. C99 + POSIX something around 90 integer types. May be the ISO committee is stupid, may be they have recognized some problems of the C language. C89 + POSIX ~~~ char signed char unsigned char short unsigned short long unsigned long int unsigned int size_t ssize_t off_t ptrdiff_t wchar_t ptr_t clock_t time_t C99 + POSIX ~~~ char signed char unsigned char short unsigned short long unsigned long int unsigned int size_t ssize_t off_t off64_t fpos_t fpos64_t ptrdiff_t wchar_t wint_t ptr_t clock_t time_t int8_t int16_t int32_t int64_t int128_t uint8_t uint16_t uint32_t uint64_t uint128_t int_least8_t int_least16_t int_least32_t int_least64_t int_least128_t uint_least8_t uint_least16_t uint_least32_t uint_least64_t uint_least128_t int_fast8_t int_fast16_t int_fast32_t int_fast64_t int_fast128_t int_fast16_t int_fast32_t int_fast64_t int_fast128_t uint_fast8_t uint_fast16_t uint_fast32_t uint_fast64_t uint_fast128_t bool ... Also note: float_t and double_t And there are also a lot of Unix types out there (having currently fixed sizes): pid_t, dev_t, ino_t, fsid_t, gid_t, uid_t, mode_t, umode_t, nlink_t, ... -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] wrong prototype
fft routines are wrongly prototyped:
void fft_long ( lame_internal_flags* gfc, FLOAT x_real [BLKSIZE ], int, sample_t
** );
void fft_short ( lame_internal_flags* gfc, FLOAT x_real [3] [BLKSIZE_s], int, sample_t
** );
void init_fft ( lame_internal_flags* gfc );
Right is:
void fft_long ( lame_internal_flags* gfc, FLOAT x_real [BLKSIZE ], int, sample_t
[] [2] );
void fft_short ( lame_internal_flags* gfc, FLOAT x_real [3] [BLKSIZE_s], int, sample_t
[] [2] );
void init_fft ( lame_internal_flags* gfc );
or
void fft_long ( lame_internal_flags* gfc, FLOAT x_real [BLKSIZE ], int,
sample_t* [2] );
void fft_short ( lame_internal_flags* gfc, FLOAT x_real [3] [BLKSIZE_s], int,
sample_t* [2] );
void init_fft ( lame_internal_flags* gfc );
which are different from the above. If gfc is not modified, also
void fft_long ( const lame_internal_flags* gfc, FLOAT x_real [BLKSIZE ], int,
sample_t ** );
void fft_short ( const lame_internal_flags* gfc, FLOAT x_real [3] [BLKSIZE_s], int,
sample_t ** );
void init_fft ( lame_internal_flags* gfc );
is right and fine. Also a last remark for today:
There still strange tabs within the source code.
__
Examples to store 2D in C (comments are in German):
#include stdio.h
#include stdlib.h
#include time.h
#define TYP char
#define XRES128
#define YRES128
/*** 2D-Array **/
/* Eine aufgerufene Funktion */
void foo1 ( TYP (*Array) [XRES], size_t len )
{
size_t i;
size_t j;
int k;
clock_t c = clock ();
for ( k = 0; k 1000; k++ )
for ( i = 0; i XRES; i++ )
for ( j = 1; j len-1; j++ )
Array [j] [i] = Array [j-1] [i] + Array [j+1] [i];
c = clock() - c;
printf ("%.3f µs\n", 1.e6/CLOCKS_PER_SEC/XRES/YRES*c);
}
/* Möglichkeiten, so ein Array zu erzeugen und zu zerstören */
void bar1 ( void )
{
TYP A [YRES] [XRES];
TYP (*B) [XRES] = malloc ( YRES*XRES*sizeof(TYP) );
foo1 (A, YRES);
foo1 (B, YRES);
free (B);
}
/*** Zeiger-Array **/
/* Eine aufgerufene Funktion */
void foo2 ( TYP** Array, size_t len )
{
size_t i;
size_t j;
int k;
clock_t c = clock ();
for ( k = 0; k 1000; k++)
for ( i = 0; i XRES; i++ )
for ( j = 1; j len-1; j++ )
Array [j] [i] = Array [j-1] [i] + Array [j+1] [i];
c = clock() - c;
printf ("%.3f µs\n", 1.e6/CLOCKS_PER_SEC/XRES/YRES*c);
}
/* Möglichkeiten, so ein Array zu erzeugen und zu zerstören */
void bar2 ( void )
{
size_t i;
size_t j;
TYPtmp [YRES] [XRES];
TYP* p;
TYP* A [YRES];
TYP** B;
TYP* C [YRES];
TYP* D [YRES];
TYP** E;
TYP** F;
TYP** G;
for ( i=0; iYRES; i++ )
A [i] = tmp [i];
B = A;
p = malloc (YRES*XRES*sizeof(TYP) );
for ( i = 0; i YRES; i++, p += XRES )
C [i] = p;
for ( i = 0; i YRES; i++ )
D [i] = malloc ( XRES*sizeof(TYP) );
E = malloc ( YRES*sizeof(TYP*) );
for ( i = 0; i YRES; i++ )
E [i] = malloc ( XRES*sizeof(TYP) );
F = malloc ( YRES*sizeof(TYP*) );
p = malloc ( YRES*XRES*sizeof(TYP) );
for ( i = 0; i YRES; i++, p += XRES )
F [i] = p;
j = YRES * sizeof(TYP*) / sizeof(TYP) + 1;
p = malloc ( j*sizeof(TYP) + YRES*XRES*sizeof(TYP) );
G = (TYP**) p;
p += j;
for ( i = 0; i YRES; i++, p += XRES )
G [i] = p;
foo2 (A, YRES);
foo2 (B, YRES);
foo2 (C, YRES);
foo2 (D, YRES);
foo2 (E, YRES);
foo2 (F, YRES);
foo2 (G, YRES);
free (*C);
for ( i = 0; i YRES; i++ )
free ( D[i] );
for ( i = 0; i YRES; i++ )
free ( E[i] );
free (E);
free (*F);
free (F);
free (G);
}
int main (void)
{
bar1 ();
bar2 ();
return 0;
}
/*
* Für Fortgeschrittene:
*- das ganze mit 3 Dimensionen
*- das ganze mit N Dimensionen
*- das ganze mit allen 'const'-Varianten
*- das ganze mit allen 'const'-Varianten mit 3 Dimensionen
*- das ganze mit allen 'const'-Varianten mit N Dimensionen
*/
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
Some remarks about the ATHformula. The result are differing really a lot from my experiments. The difference is 10 dB and more at =12 kHz. For very young people the difference may be larger. Examples: Frequency Formula Experiment Difference [kHz] [dB] [dB][dB] 1 3.362.720.6 2 -0.25 -1.401.1 3 -4.56 -4.640.1 4 -3.38 -5.502.1 5 0.48 -2.272.8 6 2.083.89 -1.9 7 3.168.13 -5.0 8 4.78 11.27 -6.5 9 7.18 13.23 -6.0 10 10.57 14.39 -3.8 11 15.17 12.852.3 12 21.23 11.49 10 13 29.02 13.24 16 14 38.85 18.13 21 15 51.04 23.57 28 16 65.93 35.63 30 17 83.89 51.24 32 18 105.33 60.13 45 Binaural, Sennheiser HD 560, diffuse field. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Bug of long block pre-echo control
Mark Powell schrieb am Mit, 04 Okt 2000: On Wed, 4 Oct 2000, Naoki Shibata wrote: I found a bug in the long block pre-echo control code. This code should be fixed like this. if (gfc-blocktype_old[gfp-mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE ) Naoki, Did this affect quality? I just folded this change back into my own v3.87, as v3.88 doesn't compile at the moment. It reduced a VBR file from 181.5Kbps down to 177.3Kbps. Is this to be expected? Cheers. I would say: YES, it affects quality; it may sometimes result in smaller, somtimes in larger VBR files (I haven't investigated this). Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
Sigbjørn Skjæret schrieb am Mit, 04 Okt 2000: Just thought I'd say my thoughts on the different parameter setting function proposals we've had so far... Individual functions for each parameter: Pros: - None. ;) :-) compiler provides type check :-) direct check for valid ranges :-) small functions everyone can easily understand :-) avoids huge spaghetti code Cons: - Litters the API with "thousands" of functions. is that a cons? this could be a good point to make the use of this parameter clear to every user, just write a short comment for every function - If the parameter's type changes, the API has to change. WOW, IF YOU CHANGE THE MEANING OF A PARAMETER, THIS WOULD BE A CHANGE IN THE API ALREADY AND WOULD BREAK BACKWARD COMPATIBILITY !!! - If a new parameter is introduced, the API has to change. but this is backward compatible, so not a problem Giving a parameter structure: Pros: - Hmmm, none. ;) Cons: - You have to be very careful not to disturb the order of the parameters. - You end up with a bunch of duplicates if you have to change parameters. - Different compilers can cause different alignments. :-( would require to recompile every client if you allow him to access the parameters in your structure Giving tag-pairs on stack to one function which parses them: Pros: - API never has to change. Cons: - Littering with different tags for each type. - It's possible to pass the wrong type. Giving tag-pairs on stack to 3 functions (one for each type): Pros: - API never has to change. - One tag for any type. Cons: - It's still possible to pass the wrong type, but it's much clearer since the function itself states which to pass. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -q1
Mark Powell schrieb am Mon, 02 Okt 2000: 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? I don't know any track where the use of -q1 improves sound quality compared to a same sized -q2. That's why I'm asking you all. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
On Wed, Oct 04, 2000 at 09:42:51PM +0100, Sigbjørn Skjæret wrote: Just thought I'd say my thoughts on the different parameter setting function proposals we've had so far... Individual functions for each parameter: Pros: - None. ;) Cons: - Litters the API with "thousands" of functions. - If the parameter's type changes, the API has to change. This never happens. First you can (mostly) prevent this by avoiding miserliness of bits (Mark! It is easier to pass an boolean through a long double argument than a long double argument through a boolean argument). Secondly I prefer only to add functions. Old functions nevertheless slowly dying if you stop testing them. - If a new parameter is introduced, the API has to change. This is a generic property of an API: The API changes if the API changes. You can't avoid this by reducing the API entry point to one function (otherwise the Linux API has been not changed from Linux 0.01, it is still the sys_call() function, which is an intreq 0x80). Don't mix the two items "number of API entry points" and "complexity of an API". Math libs don't become easier by: math_call ( MATH_SIN_TYPE , MATH_ONE_ARGUMENT, MATH_DOUBLE_ARGUMENT, (double)0.707 ); math_call ( MATH_SQRT_TYPE, MATH_ONE_ARGUMENT, MATH_DOUBLE_ARGUMENT, (double)1.732 ); math_call ( MATH_POWER_TYPE, MATH_TWO_ARGUMENTS, MATH_DOUBLE_ARGUMENT, (double)2.616, (double)1.616 ); Real programmers also merging all other functions (lame_ioctl, math_call, sys_call, X11_ioctl, ...) and use only one function doing all things: void do_stuff ( int do_, ... /* stuff */ ); Then you don't need a linker and can do linking by a hex editor ;-) Also possible are: DoIt (); PerformDataFunction (); HandleStuff (); do_args_method (); snafucate (); do_args_method ( LIB_SELECT_LAME | LIB_LAME_SETUP_FUNC | LIB_LAME_SETUP_SFREQ | LIB_SET_DBL_TYPE, (double)44100 ); do_args_method ( LIB_SELECT_POSIX | LIB_POSIX_IO_FUNC | LIB_POSIX_IO_WRITE | (LIB_SET_INT_TYPE10) | (LIB_SET_VOIDPTR_TYPE5) | (LIB_SET_SIZET_TYPE0), (int)fd, (void*) buff, (size_t) length ); do_args_method ( LIB_SELECT_CLIB | LIB_CLIB_BASE_FUNC | LIB_CLIB_BASE_EXIT | LIB_SET_INT_TYPE, (int)0 ); Giving a parameter structure: Pros: - Hmmm, none. ;) Cons: - You have to be very careful not to disturb the order of the parameters. - You end up with a bunch of duplicates if you have to change parameters. - Different compilers can cause different alignments. - you can't add a translation layer between API and lib. Giving tag-pairs on stack to one function which parses them: Pros: - API never has to change. Cons: - Littering with different tags for each type. - It's possible to pass the wrong type. Giving tag-pairs on stack to 3 functions (one for each type): Why 3 functions? You only need an int ;-) Pros: - API never has to change. - One tag for any type. Cons: - It's still possible to pass the wrong type, but it's much clearer since the function itself states which to pass. Giving tag-pairs on stack to one function which parses them: const char* lame_ioctl ( enum TagItem, const char* TagValue ); returns NULL or the actually set parameter. Note: Both methods (thousands of functions and thousands of tags) are equivalent: * use one function ( lame_ioctl() ) and thousands of constants to tell this function what functionality is actually requested * use thousands of functions (lame_x () ) to execute a functionality The difference is that second possiblity is more type safe, and the first really looks like you never need to change the API, which is only partially true (backward linking is possible, but you have still a runtime error, this is often called error obscuring). -- Frank "C programmers hate readable programs" Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Winamp/100hz bug: SOLVED!
Hello, new alpha winamp plugin was released http://www.landoleet.org/~deadbeef/in_mp3_260_alpha13.zip http://www.chat.ru/~dkutsanov/in_mp3_260_alpha13.zip Changes: * [a13] 8191 bugfix. 8))) Best regards, Dmitry mail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME file name changes from 3.86 to 3.87?
Am I wrong or has the file quantize-pvt.c changed to quantize_pvt.c (and the header file as well)? Why was this done? As Mark said, that is because Borland C could not treat the "-" in filename. Wait 'til you see v3.88. You've got a big surprise coming to you :) I agree it probably wrong to use GNU make only makefiles. and I say I can't make a Makefile for too much architecture. I can check only GNU system. cannot make it for amiga, OS/2, solaris, OpenBSD, BSDI, NetBSD, Windows, MSDOS, OSF/1, and of course RISCOS. so if you want to make the lame on these environment, to maintain an own Makefile for RISC OS. And I have to keep track on file name changes. So I wondered why such a change was made. Or am I wrong and the file name got mixed up on my end you should keep track with filename and command name of CC/MAKE/... that's because this is opensource. no warrantry is here. YOU are the maintainer and developper. another point: I think configure.in and Makefile.am are good thing, but for some people, maybe they are not good. anyone have ideas ? --- [EMAIL PROTECTED] // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Ogg Vorbis encoder
I have looked at the Ogg Vorbis encoder (B2) and I have a couple of points to make : 1] I think it is appalling that there is such little interest in this - it is a viable alternative to MP3 - and doesn't have the patent restrictions that our friends at Franhoffer put on it. Sure, LAME is free, but if you use it (commercially) you still have to pay to use MP3 technology. 2] The encoder is very slow, the quality *comparable* to MP3. I suspect both will improve. 3] Documentation on Ogg Vorbis is very sparse. No info on how it actually works, only technical specs on the bitstream etc. I know there is an Ogg mail list, but I suspect that most LAME mail readers don't look at it. Surely some of the brains in LAME (effectively working for free for the benefit of the Franhoffer group) would feel more satisfaction from developing a real free format? Owen -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Interesting high quality settings and possible bug
Hello... I've been lurking on this list for awhile now and I've really started to become interested in some of the more advanced aspects of lame such as the experimental modes and stuff. Basically what I am trying to get out of lame is the highest possible sound quality short of using 320kbps cbr. For me size isn't such a big issue although the smaller the file the better I just figure if I'm going to be using 320kbps I might as well just go lossless.. Anyway, over the last week or so I have really started experimenting with all the different switches and have been measuring their effects on sound quality via frequency analysis graphs, waveform subtraction, and most importantly listening tests. When I first started encoding my mp3s for archival purposes I was using the switches: -V1 -mj -b128 -q1 (thanks to RoelVdB) and was fairly happy with the results. After performing the aforementioned tests however, I have come up with what I consider significantly better setting! s as far as sound quality is concerned. These new settings are: -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. The main reason I decided to switch to these settings is because they seem to eliminate pretty much all of the artifacts from the different test files I used it on, that the older settings were not able to. In particular, the file where it seemed to make the biggest difference was in fatboy.wav. With the original settings the file had very audible and harsh sounding pre echos... The newer settings seem to almost completely eliminate this problem and the file sounds nearly identical to the original wav. One thing that I am wondering about these settings is whether or not they are the optimum way to acheive what I am trying to do. Basically what I mean is, are some of those settings conflicting with eachother in some way or another? I don't really know the internals of lame well enough to figure out for myself... through my testing they seem to be ! pretty much the best I could get but I know for example that --nspsytune normally enables -X1, but -X3 sounds quite a bit better although it is significantly slower... which isn't too big of a deal to me. Also, I know that from earlier conversations --athlower isn't perhaps the greatest way to control file size (which is what I am using it for)... however without it the files average 270kbps or more usually which is a bit too big... using --athlower they come down to around 230kbps average, although I have had files which reached all the way up to 290kbps. It also seems that these particular settings allow a larger bitrate range (ive seen from ~150 to ~290kbps), while the older settings seemed limited to around ~170 to ~230kbps.. I plan on posting some information about all of the tests and stuff that I have done on a website soon.. I would like to hear some opinions on these settings and my findings. Oh... and about that possible bug... when using these settings, ocassion! aly (about 1 in 10 times or a bit less) while encoding lame will start giving an error saying: ERROR: MAX_HEADER_BUF too small in bitstream.c It repeats this over and over until it crashes. It only seems to happen with these particular settings though. Maybe someone can look into this and see if they find something... it would be nice not to have it crash. Well thats about it for now... if someone would like more information just email me. Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Parameter setting functions...
Note: Both methods (thousands of functions and thousands of tags) are equivalent: * use one function ( lame_ioctl() ) and thousands of constants to tell this function what functionality is actually requested * use thousands of functions (lame_x () ) to execute a functionality The difference is that second possiblity is more type safe, and the first really looks like you never need to change the API, which is only partially true (backward linking is possible, but you have still a runtime error, this is often called error obscuring). -- Frank "C programmers hate readable programs" Klemm I am afraid I actually agree with Frank on this point :-) With the tags, you need to add a line in lame.h for each variable, as well as 3 lines of code in a big 'switch' statement in lame.c With functions, you need to add a line in lame.h for each function, as well as 3 lines of code for the function itself in lame.c So they are about the same amount of code, and same amount of stuff in lame.h. But the functions seems a cleaner approach? Anyway, there is a lot more work cleaning up all this ./configure stuff before we can even think about a new API! By the way, if you have not done a 'cvs update' in a while, be sure to do 'cvs update -d' to get all the new subdirectories. (I learned that from the Vorbis mailing list) Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Hello... I've been lurking on this list for awhile now and I've really started to become interested in some of the more advanced aspects of lame such as the experimental modes and stuff. Basically what I am trying to get out of lame is the highest possible sound quality short of using 320kbps cbr. For me size isn't such a big issue although the smaller the file the better I just figure if I'm going to be using 320kbps I might as well just go lossless.. Anyway, over the last week or so I have really started experimenting with all the different switches and have been measuring their effects on sound quality via frequency analysis graphs, waveform subtraction, and most importantly listening tests. When I first started encoding my mp3s for archival purposes I was using the switches: -V1 -mj -b128 -q1 (thanks to RoelVdB) and was fairly happy with the results. After performing the aforementioned tests however, I have come up with what I consider significantly better setting! ! s as far as sound quality is concerned. These new settings are: -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. The main reason I decided to switch to these settings is because they seem to eliminate pretty much all of the artifacts from the different test files I used it on, that the older settings were not able to. In particular, the file where it seemed to make the biggest difference was in fatboy.wav. With the original settings the file had very audible and harsh sounding pre echos... The newer settings seem to almost completely eliminate this problem and the file sounds nearly identical to the original wav. One thing that I am wondering about these settings is whether or not they are the optimum way to acheive what I am trying to do. Basically what I mean is, are some of those settings conflicting with eachother in some way or another? I don't really know the internals of lame well enough to figure out for myself... through my testing they seem to be ! ! pretty much the best I could get but I know for example that --nspsytune normally enables -X1, but -X3 sounds quite a bit better although it is significantly slower... which isn't too big of a deal to me. Also, I know that from earlier conversations --athlower isn't perhaps the greatest way to control file size (which is what I am using it for)... however without it the files average 270kbps or more usually which is a bit too big... using --athlower they come down to around 230kbps average, although I have had files which reached all the way up to 290kbps. It also seems that these particular settings allow a larger bitrate range (ive seen from ~150 to ~290kbps), while the older settings seemed limited to around ~170 to ~230kbps.. I plan on posting some information about all of the tests and stuff that I have done on a website soon.. I would like to hear some opinions on these settings and my findings. Oh... and about that possible bug... when using these settings, ocassion! ! aly (about 1 in 10 times or a bit less) while encoding lame will start giving an error saying: ERROR: MAX_HEADER_BUF too small in bitstream.c It repeats this over and over until it crashes. It only seems to happen with these particular settings though. Maybe someone can look into this and see if they find something... it would be nice not to have it crash. Well thats about it for now... if someone would like more information just email me. Dibrom Get your FREE Email and Voicemail at Lycos Communications at http://comm.lycos.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
