Re: [MP3 ENCODER] Please stop breaking LAME... ;)
C can't cast from type A to type B. There is only the possibility to cast every shit to type B. And this is dangerous. So you write a int ifreq; double dfreq; ifreq = (int) ( dfreq ); and now dfreq changes the type to 'struct bla*'. C converts this without batting an eyelid. ...but doing anything different from address arithmetic won't compile. So if you do anything useful with dfreq, the compiler will catch the error; if you don't do anything useful with it, then a) you don't do _anything_ with it, so no worries, mate or b) it is only part of an API interface, so it's types should be well defined and documented. The example of the X11 problem you give, is typical of X11, and not so much of C typecasts, IMHO. The example X11 implementation is full of evil ineteger - pointer conversions. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
On Mon, 4 Sep 2000, Frank Klemm wrote: :: :: I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on :: :: warnings, and still much more forgiving on "errors")... :: Can you add g++ for testing? :: Or also some other C++ compiler? G++ 2.95.2 has the -fpermissive switch that makes most of these errors turn into simple warnings. mailto:[EMAIL PROTECTED] -= Alberto García =- http://www.cryogen.com/berto Clave pública PGP disponible Fidonet: 2:348/105.108 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the -mx mode - different philosophy
-md is not documented. What is it ? Does anyone made a dual channel mode? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] RazorLame 1.1.0 released
perhaps it is time for someone who fully understands all the options/switches to settle down and write a comprehensive 'Help' file for Lame, - I doubt many who use Lame with a front-end or ripping utility bother to read the 'Usage' file that accompanies the exe file and I don't think users of the dll file even see it. I'm trying to do it in the html doc. I plan to add to it a page about the basic options because there are now too much ones in the full switches page. If you've got any suggestion about the html doc, please share them. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Some of the test signals
I've improved the correlation calculator a little bit, so not only the correlation of the pure signal is calculated, but also the correlation of the (in time) differentiated signal. Normally the correlation of differentiated signal is a little bit lower than the of the original signal. But a lot of the test signals on the Web-Server are really strange (The first line is the origin, the second the diff'). Correlations differs AC x AC y r 32.637% 33.327% 88.061% technik/Castanets.wav 23.530% 23.429% 65.664% technik/Castanets.wav Am I the only one wich doesn't understand what Frank is telling? Can anyone explain a little? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
:: Hi Everyone, :: :: I haven't been keeping up with things for the last week, because :: my wife and I just had our first baby :-) (baby's requisite website: :: www.wildpuppy.com/baby) :: :: Anyway, now LAME CVS fails all my test cases. This is normal since :: small changes in just the order of operations will show up in these :: tests. I normally then track down exactly what is responsible and :: make sure I understand what is going on. But in this case it looks like :: this will not be possible: There are massive differences in every :: single file. Most of them may be long overdue, but for the most part :: they are related to coding style and/or cosmetic. :: what CODING style? Sorry, it is very laborious to only read (not understand) the source code. Currently the first action in the editor is the auto-format features of xjed. It only takes 1 or 2 seconds, but the code can't be checked in anymore. Transmitting the changes from the local copy to the 'commit'-able version is sinewy, especially line by line. It begins with the simpliest things like tabulators '\t' with different sizes (3, 4 and 8 are used in lame), continues with circle references in header files (try to change the type of internal_flags from 'void*' to 'lame_internal_flags*') and ends with dangerous variable names like gfc-stereo and incorrect code due to provoked misunderstandings. It uses some features still tolerated by the ANSI C3.159-1989 standard and strictly forbidden in C99 and C++. A lot of things I've not seen for 3 or 4 years. May be features should be stopped for 2 or 3 days and only these things should be solved. The simpliest way to get a coding style is to use /usr/src/linux/Documentation/CodingStyle . May be there are better coding styles (note that coding styles are also a question of personal taste), but this coding style is the coding style of one of the most successful projects and it is much better than every tohuwabohu. :: It is not approrpriate for new developers to make so many changes so :: quickly without consulting the rest of us. :: Waiting for more than 2 or 3 days makes it nearly impossible to check in changes. That are the results of the usage of SourceSafe at work. -- 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] Typo in --help
Not a biggie, but the --help and --longhelp displays the line: RECOMMENDED : lame -h input.mp3 output.wav shouldn't that be: RECOMMENDED : lame -h input.wav output.mp3 Chris Wise -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR, distortion, and CBR
Hello, If I've well undertood what the VBR quality setting means (-V x), it is the allowed number of bands where distortion (in the psycho-model sense) occurs . I'd like now to take the problem from the other side: in CBR, is there a way to have statistics about the number of distorded bands (in the same way that in VBR we have statistics about the bitrates) ? Pierre -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame/CODING_STYLE
Frank Klemm wrote: :: :: programmers don't document, you know ;-) :: OK, your point is clear and I'll try to add more comments :: (hopefully useful remarks..) :: :: * Don't use single 'short' variables to save storage. :: Short variables are especially on Pentium Class Computer much slower than :: int's. DEC alpha also hates short variables. :: :: Example: float bla [1024]; ::short i; ::for ( i = 0; i 1024; i++ ) :: bla [i] = i; :: :: I'm not so sure about shorts. Documents on the Intel compiler suggest :: for example to put the index variables of nested loops in a struct :: to improve cache performance, this way they would be in the same cache line. :: May be this plays a role, but only if you have more than 8 loops. And if you have more than 8 loops, the performance of the outer loops becomes very unimportant. In 32 bit mode the pentium supports 8 bit and 32 bit. 16 bit need the operand size prefix. This is slow. DEC Alpha cannot handle 16 bit int's at all. The compiler generates a lot of bit shifting and masking stuff. IIRC the "int" type is the fastest on all ( most ) compilers. I.E. : On 16 bit systems is int16 On 32 bit systems it is int32 On 64 bit systems ( alpha ) it is int64 ( unless tweaked to 32 bit for bugward compatibility ) So for loop counters and like, "int" should be used. David Balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
Pierre Hugonnet schrieb am Mon, 04 Sep 2000: Hello, If I've well undertood what the VBR quality setting means (-V x), it is the allowed number of bands where distortion (in the psycho-model sense) occurs . hmm, this was the meaning of -V in the very first beginning of LAME's VBR code. Actually you influence the absolute threshold of hearing aka ATH and the masking thresholds computed by GPSYCHO. VBR tries to avoid distorted bands, but sometimes, when there are not enough bits, they will survive. I'd like now to take the problem from the other side: in CBR, is there a way to have statistics about the number of distorded bands (in the same way that in VBR we have statistics about the bitrates) ? This is a little bit problematic, because the number of distorted bands does not tell you the weight of distortions you will get. What do you think sounds uglier: 20 distorted bands, each 0.1 dB or 1 distorted band by 2 dB ??? Pierre Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Congradulations Mark (Off Topic)
We are expecting our second in November. From my experience, I suspect we will be hearing less from you in the next few months. You will most likely be sleeping in your spare time! Cheers, Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Please stop breaking LAME... ;)
From: Frank Klemm [mailto:[EMAIL PROTECTED]] Good C Code should be compilable with (nearly) all C(89/95/99) Agreed. (Although there is some perfectly good C89/95 code that is broken by changes in C99 - see endless arguments in news:comp.std.c) and C++ compilers. Good C code compilable as C++ tends to be *bad* C++ code, so why bother? Let the two languages concentrate on what they're good at... But if you're intent on compiling C with a C++ compiler, an automated translator is probably the best approach: you don't need to break/weaken/obfuscate your C code that way. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
Robert Hegemann wrote: hmm, this was the meaning of -V in the very first beginning of LAME's VBR code. Actually you influence the absolute threshold of hearing aka ATH and the masking thresholds computed by GPSYCHO. VBR tries to avoid distorted bands, but sometimes, when there are not enough bits, they will survive. Not enough bits ? Then VBR should select a higher bitrate ? This is a little bit problematic, because the number of distorted bands does not tell you the weight of distortions you will get. What do you think sounds uglier: 20 distorted bands, each 0.1 dB or 1 distorted band by 2 dB ??? I would say that 20 distorted bands at 0.1dB is preferable, and assume that this is the choice of lame's algorithms. Is this assumption wrong ? Pierre -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
What do you think sounds uglier: 20 distorted bands, each 0.1 dB or 1 distorted band by 2 dB ??? I would say that 20 distorted bands at 0.1dB is preferable, and assume that this is the choice of lame's algorithms. Is this assumption wrong ? Depends. If it is maximum distortion, you're right (don't think you would notice 2dB, though), but if it is mean (or total) distortion, it would depend. Max distortion is what gets _really_ annoying artifacts (blips). More or less noise just changes the "ambience" of the music a bit; artifacts is a much worse problem, IMHO. Ciao, Segher -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame/CODING_STYLE
David Balazic ([EMAIL PROTECTED]) wrote: IIRC the "int" type is the fastest on all ( most ) compilers. I.E. : On 16 bit systems is int16 On 32 bit systems it is int32 On 64 bit systems ( alpha ) it is int64 ( unless tweaked to 32 bit for bugward compatibility ) Actually, "int" is 32 bits on the Alpha; "long int" is 64 bits. (At least that's true with the versions of OSF/1 and Digital Unix that I've worked with. I haven't worked with Tru64 or Linux/Alpha yet.) So for loop counters and like, "int" should be used. That's correct. -- Greg Wooledge| "Truth belongs to everybody." [EMAIL PROTECTED] | Red Hot Chili Peppers http://www.kellnet.com/wooledge/ | PGP signature
Re: [MP3 ENCODER] VBR, distortion, and CBR
Pierre Hugonnet schrieb am Mon, 04 Sep 2000: Robert Hegemann wrote: hmm, this was the meaning of -V in the very first beginning of LAME's VBR code. Actually you influence the absolute threshold of hearing aka ATH and the masking thresholds computed by GPSYCHO. VBR tries to avoid distorted bands, but sometimes, when there are not enough bits, they will survive. Not enough bits ? Then VBR should select a higher bitrate ? Well, even the highest bitrate is finite ;-) This is a little bit problematic, because the number of distorted bands does not tell you the weight of distortions you will get. What do you think sounds uglier: 20 distorted bands, each 0.1 dB or 1 distorted band by 2 dB ??? I would say that 20 distorted bands at 0.1dB is preferable, and assume that this is the choice of lame's algorithms. Is this assumption wrong ? The default quant_compare routine in LAME -X0 would say one distorted band is better than 20. But there are another seven different quantization comparing possibilities you can select from. Maybe we should document them, but you can dig in the mail archive, early this year I described most of them. Pierre Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] ABR 320?
would it be possible to encode an mp3 at ABR 320 using frames larger than 320 kbps? e.g. 440kbps , 560kbps -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] normalization
I want to implement a normalizing routine in one of my programs, can anybody recommend one? It would be for 16 bit CD audio. Would simply multiplying by a constant factor and rounding be good enough or would the rounding errors cause some problems sorry for the offtopic Francois
Re: [MP3 ENCODER] ABR 320?
MoiN On Tue, Sep 05, 2000 at 01:03:14AM +0100, Estrunfus Maleficus wrote: would it be possible to encode an mp3 at ABR 320 using frames larger than 320 kbps? e.g. 440kbps , 560kbps There are no audio frames larger than 320kbps in MPEG standard. The only way to create larger frames is to use freeformat. Ingo -- I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] newbie question
On www.r3mix.net, the following command line is recommended as the best option (size, speed, quality-wise): -V1 -h -mj -b128 -q1 I was looking over the documentation that came with the zip file of LAME 3.86b, and I couldn't find any mention of the "- q" command. Can someone here explain? Does it apply only for VBR, or can it be used with CBR as well? Thanks. One last question, for the best quality at the expense of file size, is "-b 320 -h -k -m s" the best option? How much of a difference would there be compared to one recommended on r3mix.net (-V1 -h -mj -b128 -q1). Thanks a bunch. Jerry -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
