Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lame3100i, a functional extension (Read 31236 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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.
lame3995o -Q1.7 --lowpass 17

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.

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.
lame3995o -Q1.7 --lowpass 17

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.


 

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

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.
lame3995o -Q1.7 --lowpass 17

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

lame3100i, a functional extension

Reply #32
What is your mod about?
lame3995o -Q1.7 --lowpass 17

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