GXLame - Low-bitrate MP3 encoder., Dedicated thread for discussion. Options

[The Sheep of DEA...]

From yesterday:

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

[lvqcl]

I noticed that gxlame doesn't like quiet samples like bruhns, bibilolo, Chariots of Fire (=sample02 from last mp3 test) etc.

[lvqcl]

Bitrate vs quality settings for LAME 3.98.4, LAME 3.99 alpha 6 (default and vbr-new) and GXLame:
...and alpha7 vbr-new.



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.

This post has been edited by lvqcl: May 3 2010, 17:00

[The Sheep of DEA...]

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?

[lvqcl]

Could you direct me to these sample clips?

http://www.hydrogenaudio.org/forums/index....st&p=509158
http://www.mp3-tech.org/tests/aac_48/samples/ - sample3
http://www.hydrogenaudio.org/forums/index....st&p=689051

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

I doubt it...

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

t3 (Apr 29 2010).

[db1989]

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.

This post has been edited by dv1989: May 1 2010, 21:20

[lvqcl]

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.

[db1989]

Thanks for the answer! I wonder how it'll compare in listening tests.

[lvqcl]

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.

[Aleron Ives]

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?

[Steve Forte Rio]

Sorry, but were I can download LAME 3.99 alpha 6 exe?

[db1989]

Google's first result for "LAME 3.99a6" is 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.

[Steve Forte Rio]

Oh, thank you)

[lvqcl]

current version is alpha 7 vbr-new behavior was tuned again...

[The Sheep of DEA...]

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!

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

CODE

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

This post has been edited by The Sheep of DEATH: May 9 2010, 10:58

[lvqcl]

Killer samples for GXLame-t4 -V 30:

mama_original (Also waste_original from this thread is a problem sample too)
es50
newkid
badvilbel

[The Sheep of DEA...]

Hi. So I see vorbis got another new release recently. Anyway,
GXLame-t4.5

[IgorC]

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.

[The Sheep of DEA...]

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:

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.

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

[The Sheep of DEA...]

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.

[holmus]

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.

This post has been edited by db1989: Aug 20 2011, 17:03

Reason for edit: removing ostentatious formatting; we can read without it

[C.R.Helmrich]

I'm also interested in the performance of the latest MP3 encoders. Given that the public AAC test at ~100kbps 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

[moozooh]

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.

[IgorC]

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.

[moozooh]

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.