Hydrogenaudio Forums

Lossy Audio Compression => MP3 => MP3 - General => Topic started by: The Sheep of DEATH on 2010-04-23 20:06:42

Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-23 20:06:42
This is a snapshot of my work on "GXLame." GXLame is an MP3 encoder based off of LAME v3.98.4 and v3.99b0 which has been heavily optimized for high-quality, low-bitrate VBR encoding. It is similar in concept to other popular encoders at these bitrates such as some AAC codecs, Vorbis mods, and so forth at bitrates down to 56kbps. This codec does not rely on aggressive lowpassing or resampling to acheive these low bitrates, and the quality aims to be acceptable at much lower bitrates than have come to be expected of the standard. Here's a rough idea of what to expect:

Code: [Select]
On a continuous scale from V 0 (lowest bitrate) to V 100 (highest quality), with V20 as the default:
V100: 256kbps
V90: 224kbps
V80: 185kbps
V70: 162kbps
V60: 146kbps
V50: 128kbps
V40: 112kbps
V30: 96kbps
V20: 85kbps
V10: 74kbps
V0: 64kbps (actually 56kbps @ 32KHz; auto resampling to 32Khz takes place at V5 and below)

The range 0-35 is where the most tuning took place. The codec accepts input from stdin and can be used in foobar2000 (and many other audio rippers/managers/converters) by following any of the guides for LAME, but with a different commandline. For instance, one can easily import CD audio into foobar2000 and convert the tracks with the simple commandline: GXLame-t5.3 -S - %d
For greatly increased encoding speed, add "-f". To target a different quality level, add "-Vx" ('x' here means a number like 30, which would produce average bitrates somewhat close to 96kbps according to the above table).
Code: [Select]
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.mp3

OPTIONS:
    -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

This is an early test release. Although some great progress is being made, it is not completely tuned, stable, or optimized. Then again, codecs never are and probably never will be. I want to gather user feedback, so use this puppy to compress whatever audio you will. Please note that lossy transcoding is an especially bad idea with GXLame. It relies so heavily on the psymodel and noise shaping that any artifacts present in the original--even inaudible ones in a transparent encode--may rebound here with a great vengeance. Particular culprits are transient smearing and additional high frequency distortion. If you must transcode, at least resample to a different frequency first (for instance, add "--resample 48" to the commandline when re-compressing/transcoding standard CD audio).

Grab a look at the changelog and older versions in the uploads thread here (http://www.hydrogenaudio.org/forums/index.php?showtopic=80509). Be sure to provide your opinions, discussions, impressions, test results, and whatever other witty banter you might deem applicable in this thread!

Right now, go forth and test it on your music, soundtracks, speech tracks (for speech, I recommend GXLame -V0 -mm --resample 16) -- I'm looking for tests for any regressions that might have been introduced in t5.3 since t5.2.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: ExUser on 2010-04-23 20:29:36
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?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-23 20:57:22
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?


I started knowing little about LAME's VBR code only a few days ago, but I've worked very rapidly since then, and the results should clearly speak for themselves. It is a fork with some pretty significant differences, but the changes probably wouldn't be terribly difficult to backport at all.

As to how I'd rank the two against each other, I'd rank GXLame well above LAME at these quality modes/bitrates, but it's actually very hard to say anything about comparable commandlines. You see, stock LAME even with lowpass set to some arbitrarily high value like 16 (just as long as band 21 is discarded, so -Y is your friend), and/or resampled to 32khz, simply can't approximate, for instance, GXLame's V10's bitrates in VBR mode. The closest LAME comes (ironically, LAME -V 9.9 with lowpass 16 resampled to 32khz) produces significantly worse results from my testing.

But the results of one guy's tests (okay, me and a few others) on a certain subset of music doesn't say enough on its own.

If you'd like to compare this to LAME, it's best to figure out the closest commandline in 3.98 and go from there. I think you'll be very pleasantly surprised, however. 
Title: GXLame - Low-bitrate MP3 encoder.
Post by: db1989 on 2010-04-23 23:28:06
LAME…stands for "Lame Ain't an MP3 Encoder" (I'd say it should be called "LIME" because it is).

Not no more it doesn't, and not originally it wasn't!

Quote
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
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-24 07:29:36
Not no more it doesn't, and not originally it wasn't!

Quote
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


Haha, you sure know your codec history! Well done. So the name is just a remnant from when it was a patch.

Anyway, I found a bug that causes a lot of the wonderful "underwater" artifact (and smearing distortion) in certain samples. I will re-upload soon with a quickfix. Yeah, sort of glad nobody jumped on it yet--things like this could be a huge turn-off.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: gaekwad2 on 2010-04-24 15:33:36
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. 
Title: GXLame - Low-bitrate MP3 encoder.
Post by: [JAZ] on 2010-04-24 16:24:17
I don't pretend to be rude but...

Do you have knowledge on psychoacoustics and on Mpeg layer III as a format?
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, but if the answer to those questions is "no", I would advise you to slow down.

The problem with lossy codecs is that they are not just an algorithm. They are the result of knowledge and empirical studies that are not trivial and which are sometimes interrelated.


The founder of this site can be proud of taking LAME back at 3.89 and doing such changes in the code that led to the --alt-presets (which nowadays are still alive in the -V settings). Your goals are similar to the ones he had then (best quality/ratio at high bitrate vs best quality/ratio at low bitrate).

As such it's something that would be nice to happen, but only achievable with the proper knowledge.



And one more thing:

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.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: ExUser on 2010-04-24 19:31:07
I have to disagree [JAZ]. The results speak for themselves. The goal of an MP3 encoder is to produce good-sounding MP3s. You need little (to no!) comprehension of the underlying mechanisms, necessarily, to be able to discern which of two files you prefer, after you've identified that you are indeed hearing a difference.

You could write a genetic algorithm, for example, to tune MP3 without understanding much of what's going on.

In short: knowledge is not a pre-requisite, knowledge is simply beneficial.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-24 22:53:21
[quote author=[JAZ] link=msg=702516 date=1272122657]
Are your changes motivated by knowledge instead of by tweaking and listening?[/quote]
Both, to varying degrees. 

Quote
I am not against your work, and I haven't even checked the results of this first test version

That's fine, thanks for being honest. If you do find the time, I'd certainly appreciate you giving it a shot, though. Thanks!

Quote
The founder of this site can be proud of taking LAME back at 3.89...

Speaking of knowledge, everyone here seems to know their codec history! I'm really proud. I know, I know, geeky of me to say...but still.

Quote
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.

Certainly! In that thread, I was just trying to get basic information about what I thought to be a bug with the VBR-old code, which I decided was the most solid base for GXLame's VBR. Once I identified and fixed this issue, I proceeded to make my changes. For this reason, GXLame doesn't touch VBR-new, and little of the work applies to it. Also, the VBR scale in GXLame is from 0 (low quality) to 100 (large, high quality). As for my comparison of quality, you'll have to see for yourself. Sometimes it's hard to know what a program or codec can do without trying it.  The point I was trying to make about comparable settings is that there really aren't any. V9.9 in LAME with the strange commandline I suggested (including vbr-old) comes close in bitrate to GXLame's V10, though.

Quote
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. 

Haha, glad the overall impression is good! Yes, there is a bit of added noise. You might consider that a leaf from lossyWAV and AoTuV's book-- at heavy settings there's a bit of added noise, but with the hope that the difference isn't "too annoying." That said, bicycle pumps aren't exactly the most innocuous sources of noise.    Could you upload a 30-second sample of the clip in question?  Thanks for testing!!

Quote
You could write a genetic algorithm, for example, to tune MP3 without understanding much of what's going on.

What an interesting idea! Acovea genetically evaluates compiler flags; a speed test of the result would determine the next round of flags. I wonder if it isn't possible to "genetically" run loads against LAME's psymodel until you get the "best" possible combination of internal settings values... The problem here is, unlike speed tests which are relatively unequivocal, there is no infallible "audio quality" model to run these different tunings against, unless you have a group of 100 dedicated audio testers who'd be willing to test 5 times a day for years to come. The same happens to be true of video encoding, as x264's default "best looking" options have long since deviated away from what simply produces the highest PSNR or SSIM values (these are the mathematical "video quality metrics"). Quality, especially at low bitrates where even individual ABX tests fall apart (where every sample is distinguishable from the original), is a much more intangible construct to tune for genetically. Saying "these artifacts are more/less annoying than these" is of course an existing model, but still...you need people's opinions on "annoyance levels." Haha, sorry for getting off topic and raising the "annoyance level" of this thread.

Thanks to all who've done tests so far! Remember to grab the latest binary (with bugfix). Tests I'm currently looking for:
1. Bitrate. Do the bitrates in the table (first post) match the bitrates GXLame is providing you on [larger] sets of your music?
2. What kind of artifact should I tune against? "Artifacts" here means perceived ringing, warbling, added noise, etc. So in other words, which of these artifacts stands out most to you in low-bitrate GXLame MP3's? Thanks again!
Title: GXLame - Low-bitrate MP3 encoder.
Post by: gaekwad2 on 2010-04-25 01:26:42
Could you upload a 30-second sample of the clip in question?

Here. (http://www.hydrogenaudio.org/forums/index.php?showtopic=80525)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: shadowking on 2010-04-25 02:48:12
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.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: stereotype on 2010-04-25 02:54:39
Ranges from 0-35 are the most interesting to me.

Why don't you focus your work exclusively on lower bitrates?
I'm sure transparency-focused users are happy with the way lame is now...
And why not explore bitrates lower than 64Kbps? Even if just for fun / technical merit...

Anyway, whatever happens, it is indeed beautiful to see that the MP3 format can apparently be still "stretched-forward"...
Title: GXLame - Low-bitrate MP3 encoder.
Post by: [JAZ] on 2010-04-25 12:28:49
@Stereotype: in GXLame, 0..35 is the low bitrate range. The scale is inverted in comparison to LAME, (i.e. it is like in other codecs: nero, vorbis...)


@Canar: If i take something made by someone else, not really well documented, and i don't have knowledge of the limitations and tradeoffs involved, the work of improving it can easily create a scenario where changes either: make a positive difference on the items tried, while making a negative one on other items, or not make a difference on the items tried but making a negative one on other items.

By definition of tuning, the case of making worse the items tried is discarded, and the possibility of making better something not tried just by chance is small.

And just like The sheep has said, a genetic algorithm can be just as good as the psychoacoustic model that it uses to decide what's good and what's bad which sort of defeats the idea.


Again, i respect the intention and procedure. I was just trying to avoid a situation where we would need different LAME versions for different targets and/or files. This is especially accentuated by the fact that GXLame uses --vbr-old, while the development on LAME in the last two/three years has been in -vbr-new, and is the default mode nowadays.

If it ever gets to get merged, -V6~V9 could use -vbr-old while the rest use vbr-new, but this will depend on how much the changes affect the rest of the encoder.


If this is the next Aotuv, it would be great. Does it have the chance to be?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Steve Forte Rio on 2010-04-25 19:57:00
very interesting project. Hopefully it is backward compatible with most hardware/software mp3 decoders...
thank you

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?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-25 21:22:01
[quote author=Steve Forte Rio link=msg=702724 date=]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?[/quote]
The files should be compatible with all compliant MP3 players...
As for resample, there is a --resample X option. Usage is like in LAME or Venc. X is in Khz (so 44.1 would be good).

Let me know of any issues, particularly if the bitrate map is correct and any annoying artifacts you might hear. Join the main discussion here (http://www.hydrogenaudio.org/forums/index.php?showtopic=80510&st=0&gopid=702578&#entry702578), too.

Thanks for testing!
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-25 22:14:11
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.


Is the artifact that most bothers you the ringing on these types of tracks? Thanks for the report.

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!
Title: GXLame - Low-bitrate MP3 encoder.
Post by: gaekwad2 on 2010-04-26 02:04:40
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!

I mean an audible noise floor which rises and falls along with the music. It's most obvious at quality levels below V30 (though still audible at 40, at 50 I don't notice it anymore at least at normal listening level (based on the whole track which has a replaygain of ~0dB)) and when the guitar is playing on the left since the noise appears in both channels.

The original version doesn't help here, it just adds that underwater effect to both the music and the noise.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: nycjv321 on 2010-04-26 20:46:57
Cool project, I need to do further testing before I can say anything about quality for my ears...
I changed my mind about the last post (#6) how can I delete it?....
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-27 14:18:39
In response to the samples I received so far!

Quote
GXLame-t2 released!

Changelog:
- Fixed a nasty bug with channel mapping under V30
- Tweaked the dynamic noise floor
- Reduced ringing
- Significant tuning
- Raised lowpass

I'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!  )


Have at it. Perceptual quality (should be) improved on many samples.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: ExUser on 2010-04-27 15:24:48
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.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-29 02:11:27
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.


Excellent! Perhaps I should get to work on the ABR mode--or try to improve capped VBR. Otherwise, it would be awkward to stream even an 85kbps file if it had some bursts of 224+kbps. Then again, vorbis suffers from this theoretical streaming problem unless it is similarly constrained, but I've yet to encounter any real-world problems in streaming true VBR vorbis with adequate decoder-side buffer. So yeah, go for it!

@all: Work is still underway. I may release a t3 (test 3) soon with the improvements. I'm focusing on the underwater effect and general distortions this time around, and will issue the release once even a small (but concrete and universal) quality improvement is made. Then I will try to project some of my work into the framework of the vbr-new mode (or, failing that, make a hybrid vbr or other simpler forms of speed increase/compromise). Finally, I will try to work a bit on the ABR quality (maybe). It's interesting how LAME has such different tunings for each of the modes of operation, but I certainly see the rationale behind it.

Any reports yet about the bitrate matching? (i.e. Is V10 really 84kbps for your music?) Make sure to mention the genre and other features of the test sample(s) if you choose to make a report. Thanks!
Title: GXLame - Low-bitrate MP3 encoder.
Post by: gaekwad2 on 2010-04-30 13:03:12
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.

Bitrates:
I used 46 tracks that are representative of my cd collection (mixed genres) with lossless codecs, so mp3 bitrates may be a bit off.
Code: [Select]
V 0:    59
V 10:   77
V 20:   87
V 30:  100
V 40:  115
V 50:  130
V 60:  153
V 70:  169
V 80:  187
V 90:  212
V 100: 230
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Soap on 2010-04-30 13:06:52
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.

(emphasis mine)
I'll admit to having performed no listening tests, but I noticed this behavior discussed earlier on, and was curious.
Why are (expensive to encode) higher frequencies being preserved in a low-bitrate optimized MP3 encoder?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: ExUser on 2010-04-30 16:26:12
I do intend to do a bit of listening testing on this when I get back home sometime next week. I haven't yet due to work.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: [JAZ] on 2010-04-30 19:41:12
Why are (expensive to encode) higher frequencies being preserved in a low-bitrate optimized MP3 encoder?


--resample 32 --lowpass 16 should ring a bell to you.  It does not try to preserve the whole bandwidth, but a lowpass of less than 12Khz can be more annoying that an artifact at -30dBs.

That's what he is trying to do, redefine the "annoyability" of artifacts.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-04-30 21:44:32
From yesterday:
Quote
GXLame-t3.
Changelog:
- Slight tuning (some artifacts addressed)
- Improved high frequency handling (helps stabilize cases of fading backbeat, etc)
- Slight speedup


Grab it to go™ (http://www.hydrogenaudio.org/forums/index.php?showtopic=80509&view=findpost&p=703384).
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-01 11:09:25
I noticed that gxlame doesn't like quiet samples like bruhns, bibilolo, Chariots of Fire (=sample02 from last mp3 test) etc.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-01 18:50:00
Bitrate vs quality settings for LAME 3.98.4, LAME 3.99 alpha 6 (default and vbr-new) and GXLame:
...and alpha7 vbr-new.

(http://img710.imageshack.us/img710/577/clipboard01xh.png)

quality scale for GXLame was reverted to coincide with LAME (gxlame -V0 <=> lame -V9.999, gxlame -V20 <=> lame -V8, etc.)
Test set: modern pop and rock music.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-05-01 19:40:01
I noticed that gxlame doesn't like quiet samples like bruhns, bibilolo, Chariots of Fire (=sample02 from last mp3 test) etc.

Thanks for the bitrate curve and the report!
Could you direct me to these sample clips? A quick search turns up a bunch of threads referring to them but deleting all attachments thereafter. Surely there's a central location for these killer samples?
Thanks again!

PS: What version of GXLame did you use for the bitrate curve test?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-01 20:05:31
Quote
Could you direct me to these sample clips?

http://www.hydrogenaudio.org/forums/index....st&p=509158 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56129&view=findpost&p=509158)
http://www.mp3-tech.org/tests/aac_48/samples/ (http://www.mp3-tech.org/tests/aac_48/samples/)  - sample3
http://www.hydrogenaudio.org/forums/index....st&p=689051 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=77584&view=findpost&p=689051)

Quote
Surely there's a central location for these killer samples?

I doubt it...

Quote
PS: What version of GXLame did you use for the bitrate curve test?

t3 (Apr 29 2010).
Title: GXLame - Low-bitrate MP3 encoder.
Post by: db1989 on 2010-05-01 21:16:58
LAME 3.99 alpha 6 (default and vbr-new)

Does this version have a different default VBR mode? The changelog only covers a2, and most of the listed updates are bug fixes and input format support.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-02 08:26:52
Quote
Does this version have a different default VBR mode?


No, the default mode in 3.99a6 is the same as the default mode in 3.98.
--vbr-new in 3.99a6 is yet another (new!) VBR mode.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: db1989 on 2010-05-02 11:55:15
 Thanks for the answer! I wonder how it'll compare in listening tests.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-02 20:36:20
Quote
I wonder how it'll compare in listening tests.

Well... I compared 3.99a6 -V6.5 and -V7 --vbr-new. Default VBR mode is better IMHO.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Aleron Ives on 2010-05-03 01:24:51
Forgive my ignorance, but if the VBR new in 3.98 has been under development for such a long time and finally as of 3.98 has become the default mode, why is 3.99 introducing yet another VBR mode?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Steve Forte Rio on 2010-05-03 11:56:19
Sorry, but were I can download LAME 3.99 alpha 6 exe?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: db1989 on 2010-05-03 12:15:00
Google's first result for "LAME 3.99a6"  is lame.bakerweb.biz (http://lame.bakerweb.biz/), which automatically compiles and uploads on Mondays, Wednesdays and Fridays. I believe that this is quite a 'famous' site for LAME compiles, albeit one that is not mentioned in Hydrogenaudio's pinned topic or Knowledgebase.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Steve Forte Rio on 2010-05-03 12:20:24
Oh, thank you)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-03 13:21:37
current version is alpha 7  vbr-new behavior was tuned again...
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2010-05-09 10:57:49
current version is alpha 7  vbr-new behavior was tuned again...


GXLame is based on the stable version, not the alpha, so none of these changes made it in. But that's okay, since GXLame uses another strategy. Here you go!

Quote
GXLame-t4:
- Reworked ath system
- Lowpass raised (again) also at high bitrates (20.5Khz at V100)
- Tuning
- Changes in bitrate mapping as follows:

Code: [Select]
V0:   64kbps (resampling to 32Khz takes place at V5)
V10:  79kbps
V20:  85kbps
V30:  96kbps
V40:  112kbps
V50:  128kbps
V60:  146kbps
V70:  162kbps
V80:  185kbps
V90:  224kbps
V100: 256kbps


I addressed some problem samples (some more than others, for various reasons), but in general I think you'll find perceptual quality has increased tremendously with this release. Special attention was given to "cleaning" up the sound and reducing ringing in certain situations. V20 (85kbps) is now perfectly usable on my player while on the go. (Of course, a deafeningly noisy bus commute with my rather strange collection of music blaring through cheap headphones doesn't vouch for everyone).

This marks my first "alpha" release. Note that there is much left to be done. The new ath system has yet to mature and isn't yet used to its full potential. Also, abr (still) isn't tuned yet. Speed and stability have yet to be evaluated in the long haul. I recommend you use -f if things are moving too slowly for you, but speed tweaking isn't a priority now--the focus is on quality at very low bitrates (V10-V30 in particular).

Let me know of any regressions, no matter how obvious or obscure.

Cheers!

Link (http://www.hydrogenaudio.org/forums/index.php?showtopic=80509&view=findpost&p=704488)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2010-05-21 18:43:40
Killer samples for GXLame-t4 -V 30:

mama_original (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55372&view=findpost&p=497935) (Also waste_original from this thread is a problem sample too)
es50 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=34329&view=findpost&p=300969)
newkid (http://www.ff123.net/samples.html)
badvilbel (http://www.ff123.net/samples.html)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-05-05 06:22:51
Hi. So I see vorbis got another new release recently. Anyway,
GXLame-t4.5 (http://www.hydrogenaudio.org/forums/index.php?showtopic=80509&view=findpost&p=754700)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-05-06 07:40:56
Thank You,
Nice to see new version.  It looks good at first sight. It really has less warbling but maybe  at cost of some noise.
Will get a try to it in these days.
It is particularly interesting for me bitrate  96 kbps (V30) .
Don't know if it is worth to compare to some of the  LAME versions (settings) or other MP3 encoders which are tuned for low bitrates.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-05-07 09:11:01
Thank You,
Nice to see new version.  It looks good at first sight. It really has less warbling but maybe  at cost of some noise.
Will get a try to it in these days.
It is particularly interesting for me bitrate  96 kbps (V30) .
Don't know if it is worth to compare to some of the  LAME versions (settings) or other MP3 encoders which are tuned for low bitrates.


Great news! A comparison would certainly be useful. I've compared to LAME a lot, but no other MP3 codecs at these rates.

Anyway, let me sneak through an early-stage t5.
GXLame-t5:
- Synced (selectively) with LAME 3.99b0
- Small ath minval bugfix (introduced in t4)
- Better normalization of quality between quiet and "noisy" audio (needs testing!)
- Fast mode (-f) is much faster (now on par with aotuv venc builds) with better quality approaching that of default mode
- Changes in low bitrate mapping to be more geometrically consistent and to take advantage of new quality normalization at even lower bitrates:
Quote
V100: 256kbps
V90:  224kbps
V80:  185kbps
V70:  162kbps
V60:  146kbps
V50:  128kbps
V40:  112kbps
V30:  96kbps
V20:  85kbps
V10:  75kbps
V0:    64kbps (actually 56kbps @ 32KHz
; auto resampling to 32Khz takes place at V5 and below)


GXLame-t4.5 is still the recommended version for actual use, while t5 is a new branch. Although t5 it is less mature than t4.5, it may produce better overall quality in some (few? most? 'all?') cases, but more testing is needed. It would be very helpful if you could compare it to t4.5 (or the popular t3, for that matter) on normal music. A comparison of average bitrates (at V20, for instance) between these versions would also be welcome, as would a comparison of normal and fast mode. As usual, grab it in the release post (http://www.hydrogenaudio.org/forums/index.php?showtopic=80509&view=findpost&p=754931).

Again, let me be clear...
GXLame-t4.5 is the recommended version. It is 'r1' for GXLame. GXLame-t5 hasn't been tuned to the extent that t4.5 has been. (However, if you can, please do test it and compare the quality of t5 vs t4.5 on a variety of music).
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-08-15 20:10:23
Just for the record (in case I'm not around for a test announcement like before), GXLame-t5.2 (or 5.3) can be used in any upcoming listening tests. In fact, I strongly encourage it and hereby enter it in any and all such tests.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: holmus on 2011-08-19 15:44:17
Just for the record (in case I'm not around for a test announcement like before), GXLame-t5.2 (or 5.3) can be used in any upcoming listening tests. In fact, I strongly encourage it and hereby enter it in any and all such tests.

I second that motion.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: C.R.Helmrich on 2011-08-20 13:55:33
I'm also interested in the performance of the latest MP3 encoders. Given that the public AAC test at ~100kbps (http://www.hydrogenaudio.org/forums/index.php?showtopic=89785) will finish today (if you want to participate, now is the last chance!), it would be nice to set up the same test with only MP3 codecs during the next few months.

Any volunteers? I probably can't since I work for one of the codec providers...

Chris
Title: GXLame - Low-bitrate MP3 encoder.
Post by: moozooh on 2011-08-20 18:14:09
Any volunteers? I probably can't since I work for one of the codec providers...


A bit off-topic, but working for a codec developer shouldn't make a difference since the tests conducted are double-blind. Unless you can specifically pick up the codec you favor (which, mind you, isn't too hard in many cases, as most codecs have unique and identifiable artifact signatures at low bitrates), and give it higher marks on purpose, you're on equal ground with any other volunteer.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-08-21 23:23:04
After conducting the last public test I've understood why all previous organizators of public tests weren't the developers of competitor codecs. It's for a really good reason.  Even if the person is well known.

I won't go into details for an obvious reason.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: moozooh on 2011-08-23 13:46:22
Ah, I erroneously assumed C.R.Helmrich was asking for volunteers to participate in an existing upcoming test, not organize a new one. In that case it makes sense.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-01 05:50:57
Short test.

10 first samples from last public test.
100 kbps test.

Codecs:
GXLAME 5.3 V35
GXLAME 4.5 V35
Apple AAC Constrained VBR 96 kbps high quality.

Both GXLAME 5.2 and 5.3 produce the same output for V35.


Code: [Select]
GXLAME 5.3   GXLAME 4.5     Apple AAC
3.00    2.50    4.50
1.50    1.50    3.00
3.70    3.00    3.50
2.50    1.70    4.50
1.70    1.60    3.30
1.90    2.00    5.00
2.00    2.20    4.00
1.60    1.50    4.60
1.30    1.40    4.50
2.40    2.20    4.60

% Codec averages:
% 2.16    1.96    4.15


Scoring:
GXLAME 5.3 - 2.16
GXLAME 4.5 - 1.96
Apple AAC  - 4.15

Not sure about the difference in quality between 5.3 and 4.5.

Final conclusion:
GXLAME has low quality at 96 kpbs.
It's not really news. The quality for MP3 begins from 128 kbps, not less.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-09-01 20:49:34
Excellent, this is what I was looking for! Thanks for doing some of your tests. I also find Apple AAC (one of the best AAC codecs at this bitrate) somewhat superior to gxlame, but I'm curious as to what particular sort of artifacts are most offensive to you.

Also, a test between GXLame and other encoders may be useful (such as GXLame V20 vs he-aac at 64kbps, or GXLame vs LAME at these or any bitrates).

I'm also curious about untrained listener response to bitrates as low as V20. This curiosity stems from the fact that GXLame "gets" the fact that it can't eliminate all artifacts, but tries to mask their severity as much as possible while preserving the full spectrum (up to 16KHz).

My own tests have shown GXLame produces tolerable quality down to V20 (85kbps) on most mainstream music samples. (And of course, killer samples will chip away at such a notion, but all the same.)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-02 02:44:32
This curiosity stems from the fact that GXLame "gets" the fact that it can't eliminate all artifacts, but tries to mask their severity as much as possible while preserving the full spectrum (up to 16KHz).

I'm not a developer but here is my opinion based on personal observations.

The preservation of the bandwidth is a good thing but  good encoder should have an optimal balance between the lowpass and amount of distortion in high frequencies.
LC-AAC can preserve the frequency up to 15.5-16 kHz at 100 kbps because it's more advanced.
LAME can reasonbly afford around 14.5 kHz at such bitrate.
GXLAME tries to handle 16-16.5 kHz while is running out of the bits.    That explain a lot of noise in high frequencies that I can hear with GXLAME (but not so much with LAME)
The good example of it is castanets sample (also pre-echo handling of GXLAME is very week).  I bet the the quality will be better if the lowpass will be set at 15 kHz (that could be already at high side though) and appropriate optimizations will be done. 

My 0.02$
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2011-09-03 09:13:41
My own tests have shown GXLame produces tolerable quality down to V20 (85kbps) on most mainstream music samples.


It seems that "Sabbath Bloody Sabbath" by Cardigans doesn't fall into this category: obvious artefacts at the beginning... 
Sample: http://www.hydrogenaudio.org/forums/index....ost&id=6664 (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6664)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-03 09:50:48
Another short test.
10 samples from the last public test (Samples 11-20)

Bitrate ~96 kbps.
GXLAME 5.3 -V 35
LAME 3.97 -V 7  (I prefer 3.97 for low bitrates.)


Link for audio files and results:
www.mediafire.com/?1nu52fvzego6plf

Code: [Select]
GXLAME_53    LAME_397
1.80    3.00
2.00    3.00
3.00    5.00
2.00    2.50
2.50    4.00
1.00    2.70
2.00    3.00
2.00    3.80
4.00    3.00
1.00    2.00

% Codec averages:
% 2.13    3.20


Bootstrap:
Code: [Select]
bootstrap.py --blocked --compare-all -p 100000 -s 100000 TOTAL_RESULTS.txt
bootstrap.py v1.0 2011-02-03
Copyright (C) 2011 Gian-Carlo Pascutto <gcp@sjeng.org>
License Affero GPL version 3 or later <http://www.gnu.org/licenses/agpl.html>

Reading from: TOTAL_RESULTS.txt
Read 2 treatments, 10 samples => 1 comparisons
Means:
GXLAME_53  LAME_397
   2.130     3.200

Unadjusted p-values:
          LAME_397
GXLAME_53  0.012*

LAME_397 is better than GXLAME_53 (p=0.012)

p-values adjusted for multiple comparison:
          LAME_397
GXLAME_53  0.011*

LAME_397 is better than GXLAME_53 (p=0.011)
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2011-09-03 10:45:12
I thought that ABR is still preferrable for LAME at low bitrates...

"For very low bitrates, up to 100kbps, ABR is most often the best solution. Use --abr <bitrate> (e.g. --abr 80)" -- HA wiki.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-03 11:20:04
You're right.
ABR is recommended for LAME at low bitrates (wiki article)

I was just listening some samples encoded at V 5/6/7 and eventually  perfomed the test with V7. Even this way I think the results  are clear (GXLAME and LAME).
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-09-03 21:55:12
You're right.
ABR is recommended for LAME at low bitrates (wiki article)

I was just listening some samples encoded at V 5/6/7 and eventually  perfomed the test with V7. Even this way I think the results  are clear (GXLAME and LAME).


Now that's certainly interesting. My results were almost the exact opposite. This means I certainly (highly) prefer subtle high frequency distortions over over aggressive lowpass and ringing. GXLame, to me, wins against LAME in almost every sample. Now things are certainly getting interesting. Do you happen to find tremendous lowpass preferable to slight high frequency distortion?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2011-09-03 22:39:45
This means I certainly (highly) prefer subtle high frequency distortions over over aggressive lowpass and ringing. GXLame, to me, wins against LAME in almost every sample.


What do you think about this sample - http://www.hydrogenaudio.org/forums/index....ost&id=6665 (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6665) ?
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-03 22:53:54
Do you happen to find tremendous lowpass preferable to slight high frequency distortion?

14.5 kHz is hardly can be named as tremendous lowpass.  LAME was tuned during several years and here a lot of good listeners  have helped to do it.
Even AAC can't preserve 16 kHz at 96 kbps.

It's not slight HF distortion of GXLAME. It's a severe distortion.  The difference is so big that GXLAME has no chance against LAME. (see the difference between scores).
I know GXLAME is your baby and I just try to help.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-09-04 04:40:19
Ahaha, thanks. I was thinking of V20, in the middle of GXLame's range of interest. LAME's lowpass is quite severe at these rates, for instance. (I do also consider 14.5KHz fairly brutal, but that's a preference). I also took a bit of a leaf out of HE-AAC's HF methodology (well, not really, but the metaphor is somewhat relevant) -- higher frequencies are least important to the ear, so more distortions can be present; in HE-AAC's case, frequencies above 11 or 12KHz are essentially discarded and/or 'guessed' (SBR). I did a very quick and dirty double-blind test today with some volunteers in my living complex pitting GXLame V20 and similar-bitrate LAME 3.98 V9.9 (upsampled appropriately) against the originals. With a few laptops and their cheap headphones, all 3 listeners couldn't easily distinguish between the original and GXLame (they're certainly not audiophiles, apparently, nor do they have 'golden ears'), but they easily could hear LAME's lowpass. When I later tried to point out a few artifacts in GXLame, the 1 person who could hear them said he "didn't care" and probably wouldn't notice during casual listening. I didn't tell him which codec was which at that time, either. This was almost exactly the result I'd hypothesized (and hoped for) based on the premise of my tunings. I know it doesn't count as a full-blown scientific survey, but perhaps it suffices as a sort of 'sanity test' to make sure I wasn't completely crazy. But it's certainly likely enough (low n value) that we actually are kind of crazy. Or the samples were too easy (it was some of their music), or some other confounding factors.

So again, this is quite curious. I will try to produce a slightly tweaked version with reevaluated lowpasses to see if it will suit your tastes better (perhaps in the meantime you can manually specify a lower lowpass -- the tunings probably won't be thrown off too terribly for a couple of KHz difference). Perhaps everyone will win in the end. Thanks for your continued interest!
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2011-09-04 06:27:23
GXLame V20 and similar-bitrate LAME 3.98 V9.9


That's strange. According to my tests, the average bitrate for GXLame -V20 is 85 kbps, and for LAME 3.98.4 -V9.9 it is close to 36 kbps (with lowpass=4.4 kHz).

I can get ~85 kbps from LAME using the following settings:
-V 8.4: resamples to 32 kHz, lowpass=11.3 kHz
-V 8.5: resamples to 24 kHz, lowpass=11.0 kHz
--abr 85: resamples to 32 kHz, lowpass=13.5 kHz
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2011-09-04 07:49:24
GXLame V20 and similar-bitrate LAME 3.98 V9.9


That's strange. According to my tests, the average bitrate for GXLame -V20 is 85 kbps, and for LAME 3.98.4 -V9.9 it is close to 36 kbps (with lowpass=4.4 kHz).

I can get ~85 kbps from LAME using the following settings:
-V 8.4: resamples to 32 kHz, lowpass=11.3 kHz
-V 8.5: resamples to 24 kHz, lowpass=11.0 kHz
--abr 85: resamples to 32 kHz, lowpass=13.5 kHz


They were both at 44.1KHz for consistency. I suppose I can re-do the LAME tests at V8.5 at 32KHz, but the music was a mix of metal, pop, and hip-hop, and LAME claimed a full 83kbps there -- very, very close to GXLame at V20.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: IgorC on 2011-09-04 08:04:41
I suppose I can re-do the LAME tests at V8.5 at 32KHz

ABR is recommended for LAME at bitrates lower than 100 kbps.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: darkbyte on 2011-10-02 14:58:22
Nice encoder. I'm waiting for the lame_enc.dll version so i can test it out with streaming.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Yuri on 2012-01-21 03:16:16
This encoder is great. 
Sounds really good with high compression, it tames the most annoying artifacts. I simply couldn't do without it. Thank you very much.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Freya on 2012-03-15 09:36:56
Firstly respect to you for coming out with such a thing, obviously it's the kind of thing some people might be a bit hostile to but I think it's great to have diversity and different approaches to things.

It makes me a bit more comfortable to say the following. I'm trying to encode at extremely low bit rates. Presently I'm doing 16kbps at 22khz in mono! I'd like to achieve something like FM radio quality only in mono. Sometimes I get very close. Obviously at such low rates anything that can give me the edge is very welcome!

I've just been trying ABR in lame, as that is supposed to be recommended for lower bitrates but I'm questioning if I wasn't getting better results with VBR and max_bitrate?

I'm wondering if GXLame might help? I notice that you are more looking at bitrates around 96kbps and 85kbps but I am working with mono and at only 22khz which might make things closer?

I'd love to hear if you have tried anything like this in GXLame and what the results were.

Also is GXLame only a windows thing? I'm doing Linux with gstreamer here...

Thanks for your help!

love

Freya
Title: GXLame - Low-bitrate MP3 encoder.
Post by: LithosZA on 2012-03-15 10:45:53
Are you restricted to 16Kbps? MP3 will blow up at this bitrate.
Opus and HE-AAC might work okish at 16Kbps.

Edit: HE-AAC at 24Kbps is very much possible. Some online radio stations stream at that rate.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: Freya on 2012-03-15 11:36:20
Are you restricted to 16Kbps? MP3 will blow up at this bitrate.
Opus and HE-AAC might work okish at 16Kbps.

Edit: HE-AAC at 24Kbps is very much possible. Some online radio stations stream at that rate.


16kbps yes, 24 sometimes at a push.

I'm getting okish results now but a bit too much swirly on some things.
I just want to improve on things a little.
Don't forget this is mono and 22khz.

I think I was getting better results with vbr before but it might have been an older version of lame and all kinds of stuff.

It has to be .mp3 format I'm afraid, otherwise I might play with .ogg

Just wondering how to improve my encodings. Looks like adding a lowpass switch might help for instance.

Any suggestions for things I might try?

love

Freya
Title: GXLame - Low-bitrate MP3 encoder.
Post by: LithosZA on 2012-03-15 13:07:19
Quote
It has to be .mp3 format I'm afraid, otherwise I might play with .ogg

You should be able to get better results with Ogg Vorbis. You might need to use the '--managed' switch to make sure it doesn't go above 16Kbit/s

Quote
Just wondering how to improve my encodings. Looks like adding a lowpass switch might help for instance.

Yes, you could try that. It might worsen or improve.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: The Sheep of DEATH on 2012-03-26 06:23:11
Firstly respect to you for coming out with such a thing, obviously it's the kind of thing some people might be a bit hostile to but I think it's great to have diversity and different approaches to things.

It makes me a bit more comfortable to say the following. I'm trying to encode at extremely low bit rates. Presently I'm doing 16kbps at 22khz in mono! I'd like to achieve something like FM radio quality only in mono. Sometimes I get very close. Obviously at such low rates anything that can give me the edge is very welcome!

I've just been trying ABR in lame, as that is supposed to be recommended for lower bitrates but I'm questioning if I wasn't getting better results with VBR and max_bitrate?

I'm wondering if GXLame might help? I notice that you are more looking at bitrates around 96kbps and 85kbps but I am working with mono and at only 22khz which might make things closer?

I'd love to hear if you have tried anything like this in GXLame and what the results were.

Also is GXLame only a windows thing? I'm doing Linux with gstreamer here...

Thanks for your help!

love

Freya


For audiobooks, using --resample 16 -mm -V10 proved close to 16kbps. It's mono and around 16kbps, sounds great, but its at 16khz. You can try -V5 at 22KHz if you like, too -- results should be similar. Vorbis has actually not been very good with speech content, historically. Even if it is comparable at this rate, it is nowhere near as ubiquitous and can't be nearly as easily played/transfered/etc.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: njsain on 2012-10-31 16:52:38
Is the source available for GXLame? I would like to compile it for use on my computer running the Ubuntu 12.04 OS.
Title: GXLame - Low-bitrate MP3 encoder.
Post by: darkbyte on 2016-01-04 08:59:08
Downloaded gxlame.exe from the first post's attachment is identified by avast! as infected with Win32:Evo-gen [Susp]. Is this a false positive or..
Title: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2016-01-04 11:07:01
[Susp] probably means "suspicious".  GXLame is compressed/encrypted by PECompact, maybe Avast doesn't like it.
Title: Thank you! This is a really good replacement for nero mp3!
Post by: Max9000 on 2020-09-08 19:10:34
I need music at extremely low bit-rates without the treble reduction of LAME codec.  So, I had been using alternatives that didn't actually make much smaller files (just slightly smaller). 

GXLame was really a shock to my system, and I've signed (first post) to thank you for it.  :D

First experiment with the foobar2000 example and .exe from post#1, I set to -V0 and tried "Beautiful Briny Sea" from the movie Bedknobs and Broomsticks.  Male voice was fine, but female voice blurred/overmod slightly. 

So, in foobar2000's processing, I added ResamplerPPHS set to 22050 ultra.  And the blurs were gone! 
Also the quality was easily as good as tape/fm.  Probably better than cassette tape set too hot.  Bitrate 25k to 46k and 22050 bit depth. 

The 25k bitrate  was a problem, so:  GXLame-t5.3.exe -S -b32 -F -V0 - %d
Now the bitrate ranges from 32k to 46k.  There are file sizes from 680k to 1 megabyte. 
Epic bandwidth savings.

At these small bitrates, hearing the '3d ambient cues' or sound-stage environment is really unexpected (and awesome).  Usually an advanced codec would flatten that or most mp3 would have treble cut and noise.  I had no such problems with GXLame. 
There was a cost--The file is louder with audio compression.  

Certainly, the file size vs quality was well beyond expectations.  So, I tried V1, similar, V2, similar, V3 slightly less severe loudness boost (v0 33k; v3 40k). . . V4 similar to V3, V5 similar, V6 similar, V10 similar, etc... no escaping the loudness boost.  But some settings are less severe on that peculiar cost.
Increasing too-quiet sounds for low bitrate may be necessary to get enough bits to represent them; however, it is Not necessary nor pleasant to increase the loudness of already-loud sounds (that is blare).

V6 does ~42k bitrate stereo @ 22k bitdepth in very good quality (maybe better than FM), except for loud sounds get louder (a little smashed and blare).  Can we have a switch/flag to regulate/reduce the loudness-compressor-booster function?    

Meanwhile, I will search for a foobar2000 gain-cut plugin...  The unwanted boost is linear and it shouldn't be linear (quiet sounds louder is pleasant, already-loud sounds louder isn't).  Halp?

P.S./Edit:  As usual for today, an audio thing doesn't have a gain control, but I stacked the equalizer plugin and cut every band by 2 notches (no mention of decibels).  That has halfway resolved the unnecessary volume boost.  It only dawned on me to try that after I found out that the boost was linear.  Without overmod distortion, bandwidth consumption fell to 40k bitrate for stereo, which is probably better quality than FM.  I still hear a rather clever audio compressor boost, just less often (but when it hits, still bracing).  Perhaps it would be good to have a switch/flag to set how much less loudness boost is desired, and perhaps nonlinear ratio of quiet verses loud (because already-loud sounds shouldn't be much louder)?  
I'd love this if you can cancel the air raid. 
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-08 21:09:27
Just a little more gentle on the audio compressor/expander gig (especially not make loud sounds louder) and then perhaps most internet radio stations will want it. 

I experimented with cutting the input gain further to compensate, resulting in unheard-of 39kbps bitrate @ 22k bitdepth resolving rather similar to CD quality. 

Had I bought a CD that sounded like that, I'd be satisfied.  But as this is a codec, I'd like an adjustment/flag so that the loudest of sounds don't get boosted so much. 

Otherwise, ridiculously high quality for 40kb-ish bitrate mp3's. 
I just can't figure out how to prevent loudest of sounds getting louder. 
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: fabiorug on 2020-09-09 20:59:45
I'm interested how to encode mp3 at 128 kbps vbr or mp3 320 kbps with your encoder in foobar2000 can you send the screenshots, please?
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-10 11:24:51
I'm interested how to encode mp3 at 128 kbps vbr...
Foobar2000
r-click song(s)
convert
output format
add new
encoder=custom
GXLame-t5.3.exe -S -b32 -F --noreplaygain -V50 - %d
Highest BPS mode 16 (like a CD)

*see post#1 for alternatives to -V50, such as -V20 for 85kbps (the default setting).
...or mp3 320 kbps with...
GXlame is for very small size files, so 320 is opposite of purpose.  Consider WavPack lossy quality-max @ 460kbps (slow but excellent), or FLAC for your archive purposes.
Higher quality original is more successful for later transcode to fit more into portable devices (especially don't use same codec for both). 
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: fabiorug on 2020-09-10 20:43:30
https://imgur.com/a/TqTkLUL
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters)
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: adamjk on 2020-09-11 08:27:11
"-s" is not equal to "-S".
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: lvqcl on 2020-09-12 09:52:56
Also, there should be no encoder name ("GXLame-t5.3.exe") in parameters.
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-17 07:48:34
For successful mp3 bit-rates below 80kbps, you'd need to use the Foobar2000 converter with
advanced limiter + Resampler PPHS (click ultra too)

With the bitdepth resampler, a setting of 32000 opens up bitrates under 80kbps, or
With the bitdepth resampler, a setting of 22050 opens up bitrates under 48kbps
That is true of most codecs; with the major difference that GXLame doesn't cut-off the treble. 

The default -V20 is problematic.  Lowest useful is -V26 (in my opinion).  At -V26 or higher, my dynamics problem evaporated. 

GXLame makes possible bitrates under 48kbps still similar to tape/FM quality.  So, it is possible to put so many hours/days/weeks/years of audio into your phone that it would not be able to index the contents.  I have not seen AAC/M4A make such an achievement.
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-17 18:32:53
The inbuilt old-style resampler is harmful; so it needs replaced with a more modern albeit slower PPHSultra/fast-fourier type. 
And then,
Default to -V30. . . and then achieve expectations like so:
Automatic shift to 32000bitdepth at -V28
Automatic shift to 24000bitdepth at -V16
Automatic shift to 22050bitdepth at -V8
Automatic shift to 16000bitdepth at -V4
Automatic shift to 16000bitdepth Mono at -V0

This would work for quality smaller files if there was an especially high quality resampler included, inside the codec.  Is that possible? 

Currently, it is possible to supplant the bad/outmode internal resampler by pre-processing with an external high quality resampler. What can be done to better-automate that? 
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-28 06:39:24
I may have made some poorly worded comments (my fault).  But, there's a few nice facts available:  I haven't used another encoder since I got it.  The loud sounds get louder psychoacoustic translation problem can be dealt with attenuation/fb2k's hard-6 limiter prior to encoding.  Environmental ear-perking cues for room, etc... are preserved at any bit-rate (unlike aac/m4a/wma if used for smaller-size files).   I have no idea if it works better than Nero MP3Pro (with pro shut off), but it does make smaller files that are similar.  Preprocessing with a higher quality resampler (especially downsampling) makes smaller files more successful (that is probably important). 
I think that GXLame is excellent for Ebooks, micro-power FM, micro-power AM, and internet radio stations. 

P.S.
It could also be used to stuff double the number of files on to MP3 CD (or car) or your favorite elder MP3 player, thus restoring it to service.  And GXLame probably will work better than all previous compatible file shrinking that you tried earlier. . . so long as you mind the sample rate.  I assume that is the case and am using it daily.  

Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-09-29 23:07:04
This, I think, is on the verge of legal, because educational purpose and that most people have no use for < 39kbit monophonic mp3 files of less than 1 megabyte. 

Well, attached is evidence of how important GXLame may be for ebooks and old time radio, including micropower FM, micropower AM, and internet radio stations. 

A duophonic or stereo variant would involve ceiling to 80 kbits and 'V' adjusted for some odd 60 kibts average.  But, these examples are in mono for efficiency, because micropower stations can't lock stereo, and because old time radio originals were in mono anyway, thus ~39kbits is good.  Judge that for yourself. 

Also, there are no parachutes aboard a Lancaster.  Those come in shot full of holes sliding sideways through the air, probably with one motor, everyone alive and usually coming in on a wing and a prayer.  Not even the most modern fighter could survive a fight against the Lancaster bomber.  It got shot full of holes and most stuff failed, but the airplane and guns still worked, and most of the time it came home, with everyone alive.  . . . as illustrated by old time radio. 
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: binaryhermit on 2020-09-30 00:54:59
The thing is for nearly mono source material anything resembling a modern mp3 encoder can do mid-side frames and use like no bits on the side channel.
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-10-09 17:59:23
The slightly older version GXlame_t5.2 (https://hydrogenaud.io/index.php?action=dlattach;topic=80509.0;attach=6500) seems easier to use for making tiny mp3's.  For example (in foobar2000 converter):
-S --resample 24 -mj -b16 -F -B96 --highpass 40 --noreplaygain -V26 -h - %d

just one step to make 60-ish kbit stereo mp3's
Title: Re: GXLame - Low-bitrate MP3 encoder.
Post by: Max9000 on 2020-10-11 08:06:45
For fb2k converter (and GXlame 5.2): 
This is tiny MP3 mono -S --resample 24 -mm -b16 -F -B48 --highpass 40 --noreplaygain -V26 -h - %d
This is larger MP3 stereo -S --resample 32 -mj -b16 -F --highpass 40 --noreplaygain -V30 -h - %d

I'd like to offer some opinion; but, you'd be better served by deciding for yourself.  Try it.
SimplePortal 1.0.0 RC1 © 2008-2020