On a continuous scale from V 0 (lowest bitrate) to V 100 (highest quality), with V20 as the default:V100: 256kbpsV90: 224kbpsV80: 185kbpsV70: 162kbpsV60: 146kbpsV50: 128kbpsV40: 112kbpsV30: 96kbpsV20: 85kbpsV10: 74kbpsV0: 64kbps (actually 56kbps @ 32KHz; auto resampling to 32Khz takes place at V5 and below)
GXLame 32bits version GXLame-t5 (9 Aug 2011)This version contains debugging options.usage: GXLame [options] <infile> [outfile] <infile> and/or <outfile> can be "-", which means stdin/stdout.RECOMMENDED: GXLame input.wav output.mp3OPTIONS: -b bitrate (Not recommended) set the bitrate, default 85 kbps -h highest quality, but slower (not recommended). -f fast mode, slightly lower quality (but still very good) -V n quality setting for VBR. default n = 20 (near 85 kbps) 100 = highest quality, biggest files. 0 = smallest files --preset type type must be "medium", "standard", "extreme", "insane", or a value for an average desired bitrate and depending on the value specified, appropriate quality settings will be used. "--preset help" gives more info on these --priority type sets the process priority 0,1 = Low priority 2 = normal priority 3,4 = High priority --longhelp full list of options --license print License information
Fascinating. How easily backported are your changes into the main LAME source? Is this a fork? How do your own tests rank the two encoders?
LAME…stands for "Lame Ain't an MP3 Encoder" (I'd say it should be called "LIME" because it is).
LAME originally stood for LAME Ain't an Mp3 Encoder. LAME started life as a GPL'd patch against the dist10 ISO demonstration source, and thus was incapable of producing an mp3 stream or even being compiled by itself. But in May 2000, the last remnants of the ISO source code were replaced, and now LAME is the source code for a fully LGPL'd MP3 encoder
Not no more it doesn't, and not originally it wasn't! QuoteLAME originally stood for LAME Ain't an Mp3 Encoder. LAME started life as a GPL'd patch against the dist10 ISO demonstration source, and thus was incapable of producing an mp3 stream or even being compiled by itself. But in May 2000, the last remnants of the ISO source code were replaced, and now LAME is the source code for a fully LGPL'd MP3 encoder
Are your changes motivated by knowledge instead of by tweaking and listening?
I am not against your work, and I haven't even checked the results of this first test version
The founder of this site can be proud of taking LAME back at 3.89...
From your other thread about getting information, GXLame seems to simply have switched from vbr-new to vbr-old. Can you comment on this, and if your comparison of GXLame -V10 being better than LAME -V9.9 is using vbr-new or vbr-old? Concretely, i am interested in how much of a difference there is right now on truely comparable settings.
Quick impression: Less warbling and distortion than Lame, but more noise.With heavily compressed music it's surprisingly good, but in case of eg. Third World Man by Steely Dan it almost sounds like someone's playing a bicycle pump along to the music.
You could write a genetic algorithm, for example, to tune MP3 without understanding much of what's going on.
Could you upload a 30-second sample of the clip in question?
Ranges from 0-35 are the most interesting to me.
Hopefully it is backward compatible with most hardware/software mp3 decoders...First question: Could you add special switch to disable automatic downsampling (e.g. resampling to 32 kHz for V0) or something like --resample X in original LAME?
There biggest problem will be low volume , solo/jazz/trip-hop vocals, solo instrumental intro etc - expect ringing and lots of ugly distortions made worse by VBR.
Pumping noise, particularly noticeable in the instrumental intro.
Speaking of instrumental intro, I tried your clip, gaekwad2. I'm a bit confused now as to exactly what you mean about the pumping noise you describe. The most apparent artifacts I detect are exemplified from the range 10s-12s in the sample. Just to verify we're referring to the same thing, I hear a metallic, high-pitched squeak accompanying the percussion (I believe these is typically referred to as "ringing artifacts" or perhaps in this case, chirping). Try the original test1 on this clip (the one before the so-called "bugfix"). Does this reduce the issue a bit for you? Also, what quality level did you test at (10, 20...)? Thanks!
GXLame-t2 released!Changelog:- Fixed a nasty bug with channel mapping under V30- Tweaked the dynamic noise floor- Reduced ringing- Significant tuning- Raised lowpassI've tried to address the samples and artifacts people reported most. The result is (hopefully) much better quality across the board. Let me know if there are any regressions. (I still need that bitrate test, people! )
Nice! I'm tempted to try hack-in support for GXLame when I get around to re-adding MP3 support to my Vorbis streaming component.
V 0: 59V 10: 77V 20: 87V 30: 100V 40: 115V 50: 130V 60: 153V 70: 169V 80: 187V 90: 212V 100: 230
The noise is greatly reduced in t2, now the biggest difference when comparing GXLame -V 10 to Lame -V 9.9 --resample 32 --lowpass 16 is that gxlame preserves a lot more high frequencies at the price of a generally dirtier sound (ringing, yes, but not the metallic wma-standard-kind), reminds me of Vorbis before aoTuV in a way.
Why are (expensive to encode) higher frequencies being preserved in a low-bitrate optimized MP3 encoder?