[MP3 ENCODER] free MP1 or MP2 encoders - give me please url
Hi Jaroslav! You wrote, that you use mp1 or mp2 encoders for best quality results. Are they free or not? Give me please - where did you take it? Give please some url. Alexander Russia - Original Message - From: Jaroslav Lukesh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 06, 2000 5:17 PM Subject: Re: [MP3 ENCODER] mpglib compiles once again... | Is there a simple Layer I coder out there to test Layer I decoding? | I've never have seen a Layer I file. | | Isn't there some ISO Layer I test bitstreams? In the negative case, Layer I If you want to send some short sample to test decoder, send me mail. layer 1 is absolutely BEST lossy audio (by me). If you want to use very high bitrates such as 320, 384 kb, use layer1. If you want to use 192..320kb bitrates, use layer 2 and at low bitrates up to 160k use layer3. All encoders have different characteristic of unwanted effects, but layer1 is my favourite for audio archival. Regards Jaroslav Lukesh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] very lowand very high-quality settings
Thank you Mark, for your suggestions and explanations! I will test the different hints from various persons on a DDD recording and then I can pass to my old mono sound files. Regarding the second question (CBR 256 versus VBR) I finally understood what is going on. For now I will stick to the cbr 256 basically because it appears that the bitreservoir stores the extra info for "difficult frames" beyond the 256-mark. And last but not least I will do an "-mm -b128" on all my pre-1960 recordings optaining the same quality as with "-ms -b256" on those mono files. 50% is an amazing save in space...:-) Bye, Heribert. Mark Taylor writes: -V4 -mm -h -b24 -q1 --resample 22.05 Before you settle on this, do some comparisons with CBR. I would reccomend: % lame -h -b 32 --resample 22.05 And then try playing with --lowpass X, with x ranging from 3 to 10. (the CBR default filterlevel may not be correct for low bitrate encodings). Once you get the best CBR results with the target bitrate, then compare with the VBR stuff and other exotic options to see if they are any better. Second question: is it possible to obtain better quality then "-h -ms -b256" with some vbr-mode. Maybe I am far off, but if I encode with vbr and there are 320kbps-frames these parts should be encoded better than in cbr-256-mode. Am I wrong? No, at those bitrates there is no reason to use VBR. CBR, because of the bitreservoir, is also really a limited form of VBR which small fluctations in bitrate and the occastional large jump. cbr-256 will fluctuate between using the same number of bits as in a 220-320kbs just as effectively as VBR. I tweaked a little but usually it is almost impossible with vbr to get an abr200kbps. (Nonsense-settings as vbr -b 256 apart. They result often in a cbr 256) Why? I would prefer an abr 256-file if it sounds better then the cbr 256-file, of course. Can VBR and/or ABR get 256kbs results at a lower bitrate? I wish I knew :-) Mark -- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: MP3 Format
Presets: There are three blocks which can be selected via conditional compiling. Block 2: use low fs Block 3: do not use fsb21 if possible. Differences are: Block 2 Block phon+ (0...4 kHz) fs=8 kHzfs=11 kHz 700 KB 610 KB voice (0...12 kHz) fs=24 kHz fs=32 kHz 1.8 MB 2.0 MB So I suggest to use block 1, which uses the fs with the lowest bitrate. -- 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] VBR / CBR / ABR
CBR VBR ABR Can use different frame sizes no yes yes File size depends also on complexity of source no yes no Can adapted bit demand by * different frame sizes no yes yes * use of bits from the pool yes ? no Size of the bit pool (bit) * MPEG-1: 4088 ? ? * MPEG-2: 2040 ? ? frame size for 320 kbps/ 32 kHz (bit)11520 11520 11520 44.1 kHz (bit) 836083608360 48 kHz (bit) 768076807680 effective framesize regarding the usage of the bitpool (bit) * ISO:61440 ? ? * common usage: 131072 ? ? Size of the original PCM data (2*16 bit) 36864 36864 36864 What would be done in VBR/ABR if the needed frame size is between two allowed sizes? Emitting frames with wobbling effective frame size or also using a (small) bit pool and a more constant effective frame size? -- 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] very lowand very high-quality settings
Frank Klemm schrieb am Son, 10 Sep 2000: :: :: Second question: is it possible to obtain better quality then :: "-h -ms -b256" with some vbr-mode. Maybe I am far off, but if I :: encode with vbr and there are 320kbps-frames these parts should be :: encoded better than in cbr-256-mode. Am I wrong? :: :: No, at those bitrates there is no reason to use VBR. CBR, :: because of the bitreservoir, is also really a limited form of VBR :: which small fluctations in bitrate and the occastional large jump. :: cbr-256 will fluctuate between using the same number of bits :: as in a 220-320kbs just as effectively as VBR. :: What are the differences between: -h -ms -b256 -h -ms -b256 -V0 -F or more often used: -h -ms -b192 -h -ms -b192 -V0 -F I thought the "-V0" versions are better. The coder has the ability to increase bit rate on demand. There are only problems with the so called silence detection which generates switching artefacts, so I added the -F option. I thought we already had a -F option It strictly enforces to use the minimum bitrate in VBR mode. For very low audio levels I would prefer a adaptive low pass filter and adaptive data rate. May be this will be added if sample_t becomes float. Level (1...5 kHz) Lowpass (kHz) Channel Datarate separation -30 dB 24 kHz1.0 min (b, 320) -40 dB 20 kHz1.0 min (b, 256) -50 dB 18 kHz1.0 min (b, 192) -60 dB 16 kHz1.0 min (b, 128) -70 dB 12 kHz0.99 min (b, 112) -80 dB7 kHz0.9 min (b, 96) -90 dB4 kHz0.5 min (b, 48) -100 dB3 kHz0.1 32 -110 dB2 kHz0.01 32 -- 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 Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR / CBR / ABR
Frank Klemm schrieb am Son, 10 Sep 2000: CBR VBR ABR Can use different frame sizes no yes yes File size depends also on complexity of sourceno yes no Can adapted bit demand by * different frame sizes no yes yes * use of bits from the pool yes ? no yes yes yes Size of the bit pool (bit) * MPEG-1:4088 ? ? * MPEG-2:2040 ? ? 4088 4088 4088 2040 2040 2040 frame size for 320 kbps/ 32 kHz (bit) 11520 11520 11520 44.1 kHz (bit) 836083608360 48 kHz (bit) 768076807680 another constraint: each granule has to be less than 4096 bits effective framesize regarding the usage of the bitpool (bit) * ISO: 61440 ? ? * common usage:131072 ? ? Size of the original PCM data (2*16 bit) 36864 36864 36864 What would be done in VBR/ABR if the needed frame size is between two allowed sizes? Emitting frames with wobbling effective frame size or also using a (small) bit pool and a more constant effective frame size? could lead to wasted bits -- 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 Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MS switching
Currently there are the following options to control channel frame coding: -ms only LR frames allowed -mf only MS frames allowed -mj both are allowed But there are no controls to affect the switching more sensitively. So, for instance, a switch can be added to set a penalty bitrate for the MS coding theme: -mS 10 use MS coding if it saves 10 kbps -mS 20 use MS coding if it saves 20 kbps -mS 200 use always LR coding scheme Also the threshold can be adjusted due to the average bitrate. -q1-q2-q5-q7 96 uses -mS 3 uses -mS 3 uses -mS 3 uses -mS 3 112 uses -mS 6 uses -mS 6 uses -mS 6 uses -mS 6 128 uses -mS 10 uses -mS 10 uses -mS 10 uses -mS 10 144 uses -mS 15 uses -mS 15 uses -mS 15 uses -mS 200 160 uses -mS 20 uses -mS 20 uses -mS 200 uses -mS 200 192 uses -mS 30 uses -mS 200 uses -mS 200 uses -mS 200 224 uses -mS 40 uses -mS 200 uses -mS 200 uses -mS 200 256 uses -mS 50 uses -mS 200 uses -mS 200 uses -mS 200 320 uses -mS 200 uses -mS 200 uses -mS 200 uses -mS 200 So the usage of the MS frames becomes more and more unlikely for high bitrates. This is better than a sharp break. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Extending report
Is it possible to extend the report at the end? 128.0 kbps frames: 1 total, 571 short, 8917 Mid/Side "%5.1f kbps\tframes: %5lu total, %4lu short, %5lu Mid/Side\n" -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] libmp3lame shared library?
Hi! This may be semi-offtopic because its more like a general Unix/Linux question... How can I compile libmp3lame as a shared library (libmp3lame.so) ?? Can this be added as an alternative target in the Makefile perhaps? Or even made the default for Linux? Is there a reason for *not* using shared libs? /cyr -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] changes to version.c
#include "sndfile.h" should be added to version.c on or around line 25, sf_get_lib_version is undefined otherwise. Of course it only makes a difference if you use libsndfile, but it caused me a problem. Joshua Bahnsen -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MS switching
Hello Frank, Sunday, September 10, 2000, 6:39:22 PM, you wrote: FK But there are no controls to affect the switching more sensitively. FK So, for instance, a switch can be added to set a penalty bitrate for FK the MS coding theme: FK -mS 10 use MS coding if it saves 10 kbps FK -mS 20 use MS coding if it saves 20 kbps FK -mS 200 use always LR coding scheme this is just what I was afraid of: fighting symptoms instead of a fundamental change. (-mx thread) what is the use of sacrificing kbits in trade for assumed quality gains? There will always be pieces where even -mS 100 will not be enough, and you loose a lot of the use of JS. An algorhytm needs to be adaptive: you put in music, and what comes out should be the best possible: M/S or LR. If it takes encoding all double and measuring distortion or so, it takes encoding all double. I'd still prefer it than a patched-up fundamentally inept model. With all these settings, won't you loose a great deal of universality? Why not look more at JS (-mx) as a sort of variable switching algorhytm , like vbr-old iirc, rather than a, becoming increasingly complex, condition to switch to MS. Adding -mS xx will weaken the benefits of JS (saving space), and what is there to gain? A hack for some music pieces, while you're even further off shore since you're left a less powerfull algo with still no form of assuring quality. just my 2c, not trying to stop a creative process, but simply giving my reflection on this. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] changes to version.c
#include "sndfile.h" should be added to version.c on or around line 25, sf_get_lib_version is undefined otherwise. Of course it only makes a difference if you use libsndfile, but it caused me a problem. Actually, I just fixed that, and the correct solution is to include get_audio.h which in turn includes sndfile.h .. the reason for this is that there's a special alignment for WIN32 apparently. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] very lowand very high-quality settings
:: :: I thought the "-V0" versions are better. The coder has the ability to :: increase bit rate on demand. There are only problems with the so called :: silence detection which generates switching artefacts, so I added the -F :: option. :: :: Using -V0 the ATH is lowered (by 16 dB I think), so there are a lot less :: analog silences than in cbr mode. :: But could you explain why analog silence (and then switching to low bitrate :: frames) could lead to switching artefacts? And did you ever encountered such :: an artefact cause by analog silence processing? :: A) Take a EBU test CD for low voltage converter linearity (for instance used by "Stiftung Warentest" to test CD players). It contains some music attenuated by 60 dB. Or take some WAV files with fade ins and fade outs and attenuated this by 60 dB (Dire Straits: Brothers in Arms, Private Investigations). B) Code this files by lame with lame -V0 -b160 -q1 input-60.wav output.0.mp3 lame -V4 -b160 -q1 input-60.wav output.4.mp3 lame -b160 -q1 input-60.wav output.c.mp3 lame -b160 -q1 -mm input-60.wav output.m.mp3 C) Enforce input.wav, output.0.mp3, output.4.mp3, output.c.mp3 and output.m.mp3 by 54 dB. D) Listen to this 5 enforced sound files. output.+54.wav: noisy, no artefacts output.c.+54.mp3: noisy, no artefacts output.m.+54.mp3: much more noisy, no artefacts output.4.+54.mp3: heaviest MP3 artefacts, combined with a lot of random muting bitrate: 0:00-0:04 32 kbps (muted) 0:02-6:36 160 kbps (with some mutes) 6:36-7:00 32 kbps (muted) output.0.+54.mp3: heavy MP3 artefacts, combined with random muting bitrate: 0:00-0:01 32 kbps (muted) 0:02-6:36 160 kbps 6:57-7:00 32 kbps (muted) Okay, this is not normal operation. But it's a test to show weakness of the coder. Tools available to HQ-attenuate WAV files and enforce MP3 files. :: For very low audio levels I would prefer a adaptive low pass filter :: and adaptive data rate. May be this will be added if sample_t becomes :: float. :: :: Level (1...5 kHz) Lowpass (kHz) Channel Datarate :: separation ::-30 dB 24 kHz 1.0 min (b, 320) ::-40 dB 20 kHz 1.0 min (b, 256) ::-50 dB 18 kHz 1.0 min (b, 192) ::-60 dB 16 kHz 1.0 min (b, 128) ::-70 dB 12 kHz 0.99 min (b, 112) ::-80 dB 7 kHz 0.9 min (b, 96) ::-90 dB 4 kHz 0.5 min (b, 48) :: -100 dB 3 kHz0.1 32 :: -110 dB 2 kHz 0.01 32 :: :: Wouldn't this lead to some artefacts due to the change of available :: frequencies? :: It will sounds a little bit muffled. But recodings without lots of distortions in this level region will have a lot of shaping noise in this range, so the Encoder is confused by this noise. :: And if it's not the case, why only lowpassing and not bandpassing? :: Bandpassing is better, indeed. If available. -- 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] LAME style guide, rule #1
I'm not too fond of your new naming-scheme for defines to check if a include has already been included (__VERSION_H__ f.ex.)... Generally this scheme is only for internal compiler defines and system includes, and normal projects should not use pre- and postceding underscores in defines (esp. not two). The old scheme is the more publically excepted method (VERSION_H_INCLUDED). - CISC I dont know what is the "correct" convention, and I put these types of changes under the catagory of cosmetic. I personally do not care what is used, but I do care if they are changed for no good reason! Changing them makes life very difficult for people (like myself) who try to keep up with *important* changes. When the MP3 output has changed, it is usefull to track down why it has changed, and thus code changes (which do not represent bug fixes or additional functionality) should be kept to a minimum. Yes it is true that LAME does not have a good coding style. This is because it has evolved from dist10.tar.gz, and many developers work on it. LAME is not a computer science project: it is a production code for which mp3 quality is the number 1 concern, and tracking changes which effect quality is my number 1 concern. Thus, here is a first draft of the the first rule for the official LAME Sytle guide: 1. COSMETIC CHANGES If you didn't write a routine, dont change the style, indentation, tabs, variable names, function names, #ifdef names, capitalization, spacing between lines, spacing between commas, spacing between operaters, etc etc etc, unless you have a good reason. Here are some examples: good reasons: 1. Mac cant handle local arrays 32kb. 2. The variable named 'stereo' is used in a confusing way. 3. Adding or elaborating on comments bad reasons: 1. code does not compile under g++ 2. code not in your prefered style. LAME compiles on all modern OS's, and under dozens of C compilers. This fact alone means that LAME is effectively complient C code. No additional "complience" work is needed or wanted. If you disagree, start a discussion in mp3encoder and try to convience other developers. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] include-defines
:: I'm not too fond of your new naming-scheme for defines to check if a include :: has already been included (__VERSION_H__ f.ex.)... :: :: Generally this scheme is only for internal compiler defines and system :: includes, and normal projects should not use pre- and postceding underscores :: in defines (esp. not two). :: :: The old scheme is the more publically excepted method (VERSION_H_INCLUDED). :: These tokens should be similar. A file has the name: path/name.extention Currently in usage: 1 __name_extention__ 2 name_extention 3 name_extention_INCLUDED 4 name_extention_INCLUDE 5 name_DOT_extention 6 somethingelse_H Select one and apply it to ALL files. 3) seems to be a good joice. Someone against this? -- 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] LAME style guide, rule #1
On Sun, Sep 10, 2000 at 05:23:32PM -0600, Mark Taylor wrote: LAME compiles on all modern OS's, and under dozens of C compilers. This fact alone means that LAME is effectively complient C code. No additional "complience" work is needed or wanted. If you disagree, start a discussion in mp3encoder and try to convience other developers. I've tested serveral DSP boards (32 bit, lame has several 16 bit flaws, so 16 bit will never work) and the code doesn't works on any of them. You can compile the code without any problem, the program also runs, but the output have nothing to do with MP3. Okay, C is a language "guarantee for nothing, compile everything", so it's very difficult to write something which is "complient C code". Yesterday I compiled "The old man and the sea", got only 3 warnings, but the program does not run. Strange ;-) -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] libmp3lame shared library?
same shared library. Is this libmp3lame library really of use to any program other than lame? Most definitely! I've got a perl program called "DJ In A Box" that does on-the-fly shoutcast streaming using the lame command line, and we're in the process of trying to make a perl module using libmp3lame. Unfortunately, there's a lot of stuff right now that's kind of funky to have in a library (printing status info to stderr). The guy doing it is running into some problems with one of the libmp3lame functions closing filehandles it didn't open (I believe in the encode wrapper function, I'm not much of a C guy so I can't elaborate), but other than that and the cosmetic stuff, it looks like it will work just fine. I just thought I'd chime in with a "yes"! :) -- Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED]) http://defiance.dyndns.org/ / http://radio.scenespot.org/ Now playing on Defiance Radio: Spacefunk by Digital -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MS switching
Have someone measured the coding delay for FhG and lame ??? How many PCM samples must be feeded to achieve the first MP3 frame? May be FhG have a longer delay to see more of it's "future"? mp3enc3.1 high quality (default): encoding delay 1160 For other modes it is slightly different. LAME: 576 (but you can set this to any value = 48 in encoder.h) Note that most decoders have an additional delay of 573, so be sure to add that. lame --decode will remove the first 576+573 samples when decoding. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR / CBR / ABR
CBR VBR ABR Can use different frame sizes no yes yes File size depends also on complexity of sourceno yes no CBR and ABR adjust bits based on the PE. VBR adjusts the bits based on the quantization noise. So both depend on the complexity of the source material. Can adapted bit demand by * different frame sizes no yes yes * use of bits from the pool yes ? no VBR and ABR use bits from the bit reservoir, but the reservoir is intentionally kept as small as possible. With VBR and ABR, there is no reason to try to build up a large reservoir. What would be done in VBR/ABR if the needed frame size is between two allowed sizes? Emitting frames with wobbling effective frame size or also using a (small) bit pool and a more constant effective frame size? VBR/ABR would have to use the larger size. The unused bits are added to the reservoir, so for the next frame it may use the smaller frame size + reservoir, and so the bitrate will wobble as you suggest. VBR/ABR only uses the reservoir to avoid wasting bits, since the number of bits needed is never exactly equal to the number available. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
