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

[The Sheep of DEA...]

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

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

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

This post has been edited by The Sheep of DEATH: Sep 1 2011, 03:41

Attached File(s)

 GXLame_t5.3.zip ( 180.48K ) Number of downloads: 354

 

[IgorC]

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

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.

[The Sheep of DEA...]

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

[IgorC]

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$