Skip to main content

Topic: lame3100i, a functional extension (Read 18224 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • halb27
  • [*][*][*][*][*]
lame3100i, a functional extension
Reply #25
I am about to implement version k on the 3.100.a2 basis. It makes sense for the mere fact that I can do a bitwise comparison test with the 3100j encoding results. I will publish it when it is finished.
After that I will port the k version back to 3.99.5.
lame3995n -Q0.5

  • ShotCaller
  • [*]
lame3100i, a functional extension
Reply #26
Thanks for posting 3100j halb27 and for all your work on this extension.

I was hoping though for an explanation for these --adbr switches... from what I understand, changing the values for these switches can produce less artifacts for certain samples. I really don't have the time to determine the best switches for each encode... so, what would you recommend for a "one size fits all" type command string (very high bitrate being no issue)? Would the --insane_factor switch set to 1.0 help me achieve this? Again, thanks for all you great work. It's comforting to know that my MP3 encodes will always (well, 99.9%) be transparent with the help of LAME developers and your functional extension.

  • halb27
  • [*][*][*][*][*]
lame3100i, a functional extension
Reply #27
You needn't care about the --adbr switches. Maybe I will give them away with version k.
For best quality just use a -Vx+ setting in the range -V0.5+ ... -V0+ according to your likings, but it's not necessary to go straight -V0+ IMO. harp40_1 is the only sample where I can hear tiny differences in this -Vx+ level range (totally negligible to me for -V0.2+ or better). You might try this sample and find out for yourself.
lame3995n -Q0.5

  • Kamedo2
  • [*][*][*][*]
lame3100i, a functional extension
Reply #28
I tested the --brV+ function. A 5min snippet of Pops and Jazz albums was used. It seems the option is properly working, just like the previous version.


  • shadowking
  • [*][*][*][*][*]
lame3100i, a functional extension
Reply #29
It doesn't work for stereo files with near-mono content. It becomes just like CBR/ABR or a lossless mode that doesn't do M/S stereo / inter-channel correlation.

C:\stuff\music\test>lame3100l yaldonet.wav -V2 --cvbr -1
LAME 3.100 (alpha 2, Jul 23 2013 18:58:01) extension:l 32bits (http://lame.sf.net)
warning: alpha versions should be used for testing only
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding yaldonet.wav to yaldonet.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  8921/8921  (100%)|    0:26/    0:26|    0:26/    0:26|  8.6451x|    0:00
32 [  21] *
40 [  0]
48 [  0]
56 [  0]
64 [  9] *
80 [  9] *
96 [ 334] ******
112 [2354] **************************************
128 [4252] ********************************************************************
160 [1627] ***************************
192 [ 249] %***
224 [  54] *
256 [  12] *
320 [  0]
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  130.6        0.0 100.0        94.5  2.9  2.6



C:\stuff\music\test>lame3100l yaldonet.wav -V2
LAME 3.100 (alpha 2, Jul 23 2013 18:58:01) extension:l 32bits (http://lame.sf.net)
warning: alpha versions should be used for testing only
Using polyphase lowpass filter, transition band: 17249 Hz - 17782 Hz
Encoding yaldonet.wav to yaldonet.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  8921/8921  (100%)|    0:48/    0:48|    0:48/    0:48|  4.8021x|    0:00
32 [  19] *
40 [  1] *
48 [  0]
56 [  3] *
64 [  5] *
80 [  9] *
96 [  29] *
112 [  34] *
128 [  41] *
160 [ 218] **
192 [8044] ********************************************************************
224 [  89] %
256 [ 138] **
320 [ 291] ***
-------------------------------------------------------------------------------
  kbps        LR    MS  %    long switch short %
  195.2        0.0 100.0        94.5  2.9  2.6
wavpack -b350hhj0s0.7cc

  • halb27
  • [*][*][*][*][*]
lame3100i, a functional extension
Reply #30
The constrained vbr mode of my variant has a minimun bitrate approach. It doesn't care about the source being ping-pong stereo or near-mono. So yes, for such cases there is a significant bitrate bloat (resp. corresponding security margin) compared to standard Lame.

BTW I am developing a new variant which will work differently. It is based on the fact that usually standard Lame provides an absolutely great quality as well as the fact that for most of the cases where my method has a quality advantage this has only been so when using very high average bitrate.

I looked at the known cases where standard Lame provides an inappropriate quality.

For the first long block after a sequence of short blocks the psy model is lacking information. So some heuristics must do. This doesn't always work as can be seen with the 3.2 second issue of the eig sample. In this case I simply demand for a relatively high minimum bitrate and I have done so in my recent Lame variant versions. This comes virtually for free in terms of additional average bitratre.
Long blocks are made for tonal spots in the music. It can happen however that a long block is used and the music has a low level of tonality. This is the case with the lead-voice sample. In my upcoming version I detect this situation and demand for a pretty high minimum bitrate. This too requires next to no additional average bitrate.

So when using -Vx with the next version these problems will be fixed. Anything else will be absolutely the same as with standard Lame. When using -Vx I will use my minimum bitrate mechanism only to fix these issues, not to have a constrained VBR mode.

There ere other samples where standard Lame's quality is a bit inappropriate for the chosen quality level. Very tonal stuff belongs to this like with the samples herding_calls and trumpet_myPrince. harpsichord music belongs to this group as well (i.e. the harp40_1 sample). The situation isn't too bad though, quality scales with the -V level, but for a fully satisfying quality a high to very high average bitrate setting is necessary.
So there is room for improvement and I will try to do so with my next version. There will be an alternative -Q quality scale. When used my minimum bitrate mechanism will come to work together with a new mechanism which dynamically controls the -Vx level. Other than with my previous variants this is a selective mechanism controlled by the level of tonality. Unfortunately it looks like it can't be made very selective. At extremely high bitrate settings it wil work more or less the way my current variant does. But I expect to improve things at an average bitrate below 200 kbps.
  • Last Edit: 14 December, 2015, 03:44:22 PM by halb27
lame3995n -Q0.5

  • descrates
  • [*]
lame3100i, a functional extension
Reply #31
So when using -Vx with the next version these problems will be fixed. Anything else will be absolutely the same as with standard Lame. When using -Vx I will use my minimum bitrate mechanism only to fix these issues, not to have a constrained VBR mode.


yes, bug in original lame code maybe, in my mod too

http://www.mediafire.com/download/kxxti5bz...15_win32_mod.7z
nothing special, GOGO-no-coda ~256kbps VBR + mp3packer

  • halb27
  • [*][*][*][*][*]
lame3100i, a functional extension
Reply #32
What is your mod about?
lame3995n -Q0.5

  • descrates
  • [*]
lame3100i, a functional extension
Reply #33
What is your mod about?


320kbps tuning (i cannot remember how to build it)
-b 320 -Y -q0
-V0 -Y or -V 0 (my alternative)
nothing special, GOGO-no-coda ~256kbps VBR + mp3packer