HydrogenAudio

Lame version 3.97 beta 1 is available at rarewares (http://www.rarewares.org/mp3.html), this is good news for all those alphaphobes around here.

Excellent. 
Great work from the LAME devs.
And thanks for the early heads-up skelly831.

Would I be correct in assuming that there is actually no difference in the encoder bewteen 3.97a12 and 3.97b1?

Great! 

Would I be correct in assuming that there is actually no difference in the encoder bewteen 3.97a12 and 3.97b1?
[a href="index.php?act=findpost&pid=326318"][{POST_SNAPBACK}][/a]

I'd like to know too.

Great! 

Quote

Would I be correct in assuming that there is actually no difference in the encoder bewteen 3.97a12 and 3.97b1?
[a href="index.php?act=findpost&pid=326318"][{POST_SNAPBACK}][/a]

I'd like to know too.
[a href="index.php?act=findpost&pid=326321"][{POST_SNAPBACK}][/a]

I see no differences apart from the version tags after comparing the mp3's produced with -apfs

Actually the a12 .exe is 181kb while the b1 .exe is 163kb.

jaybeee

Excellent. Great work from the LAME devs.

(http://forums.overclockers.ru/images/smiles/icon_cool.gif)

Would I be correct in assuming that there is actually no difference in the encoder bewteen 3.97a12 and 3.97b1?

(http://forums.overclockers.ru/images/smiles/icon_haha.gif)

Supposedly, it isn't out yet (or the CVS changelog isn't up to date?)

LAME 3.97 alpha (CVS)

Robert Hegemann:

Fixed and out of array access
Fixed some small rounding problem in vbr-new quantization routines
Updated scalefactors allocation scheme in vbr-new
Fixed mingw32 configure problems
Resolved some compiler warnings

Gabriel Bouvigne:

Changed some FLOAT8 to FLOAT
Reworked -q1 and -q0
Updated presets
Fixed an error in ISO quantization on systems not using the IEEE754 hack
Faster quantization
SSE version of init_xrpow

See the 'history.html' in the download.  In quality terms, I believe there is little, or no, difference between a12 and b1.

BTW, this is a great present for my birthday. Thank you very much, dear developers

BTW, this is a great present for my birthday.[a href="index.php?act=findpost&pid=326330"][{POST_SNAPBACK}][/a]

Can you prove this is a "great" present, do you have ABX results?

JK, Happy Birthday, Leo 69!

BTW, this is a great present for my birthday. Thank you very much, dear developers
[a href="index.php?act=findpost&pid=326330"][{POST_SNAPBACK}][/a]

i was just thinking the same thing!  today is my birthday as well.

edit: btw, shouldn't this be an official announcement?

i didn't feel like starting a new thread for such a simple question, but i was wondering if it made any sense to use -q 0 with -V2 --vbr-new.  I know it will slow down encoding time, but if in some cases it will pinch out some extra quality or cut out some bits, it may be useful to me.

AFAIK they fixed the old bugs in -q0 and -q1 during 3.97's alpha stage so assuming there aren't any more unknown bugs it should be safe.  Now whether or not you should use them is an entirely different matter

Is vbr-new default for "vbr" mode in beta1?

the apelllation beta affords some psychological comfort ;-)
The regression report inclines me to use V0, q remaining the same.

Is vbr-new default for "vbr" mode in beta1?
[a href="index.php?act=findpost&pid=326394"][{POST_SNAPBACK}][/a]

No. Could one of the developers please explain what is planned in this regard?

I see that there is a slight speed drop in vbr_new on my machine:
397a12 --vbr-new: 16.2x
397b1 --vbr-new: 15.5x

The differences down to vbr_old is getting narrower:

397b1 --vbr-old: 11.0x

It varies slightly on different music.


edit: When I ran another sample, I still found the speed drop, but also bigger differences between old and new (which it should be).
397a12 --vbr-new: 17.2x
397b1 --vbr-new: 16.5x

397a12 --vbr-old: 10.2x
397b1 --vbr-old: 10.2x

w00t!

Lets hope for a final soon.

Edit: If --vbr-new is said to produce the same, and in some cases slightly better, results at a faster encoding speed than the standard vbr algorithm, then why is the standard algorithm even included? It makes much more sense to just remove it and set --vbr-new to default, IMO.

Vbr-new will probably NOT be defaulted in 3.97. While this vbr mode itself seems fine, defaulting it is not tested enough and would require differing release.

As it has been a long time since last release, and as 3.97 should bring significant improvements compared to previous release, it is released but featuring the legacy vbr mode as default.

I think --vbr-new should be recommended in the new "Recommended Settings" thread, so people start using it and report failure/problem cases.

Is it now "safe" to use 3.97b1 instead of 3.96.1?

I see that there is a slight speed drop in vbr_new on my machine:
397a12 --vbr-new: 16.2x
397b1 --vbr-new: 15.5x

The differences down to vbr_old is getting narrower:

397b1 --vbr-old: 11.0x

It varies slightly on different music.


edit: When I ran another sample, I still found the speed drop, but also bigger differences between old and new (which it should be).
397a12 --vbr-new: 17.2x
397b1 --vbr-new: 16.5x

397a12 --vbr-old: 10.2x
397b1 --vbr-old: 10.2x
[a href="index.php?act=findpost&pid=326404"][{POST_SNAPBACK}][/a]

the newer vbr code hasn't changed for quite some time, so there should be no speed decrease. what exactly is your commandline at full length?

Sorry, guys, I had compiled using the stock options rather than those that I normally use.  I've recompiled and uploaded again. The speed should now be as before.

What about this issue?
http://www.hydrogenaudio.org/forums/index....topic=37003&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=37003&hl=)

What about this issue?
http://www.hydrogenaudio.org/forums/index....topic=37003&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=37003&hl=)
[a href="index.php?act=findpost&pid=326432"][{POST_SNAPBACK}][/a]

No change.

What about this issue?
http://www.hydrogenaudio.org/forums/index....topic=37003&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=37003&hl=)
[a href="index.php?act=findpost&pid=326432"][{POST_SNAPBACK}][/a]

There will always been samples that certain encoders or encoder switches will not be able to cope with in comparison to other encoders or similar switches.  Whilst it is an interesting sample and one that should be looked at, there seems to have been more positive feedback on --vbr-new than negative.

I believe this issue can be corrected.

when using --vbr-new the -q switch produces exact same results, no matter if i use q0,q1,q2,q3 or q4. is that intended?

-andy-

Should we start thinking about doing large-scale sample/regression testing of 3.97 --vbr-new against 3.90.3, towards making it the recommended encoder? I'm a little leery of just calling it done just yet, given the extremely high standard of testing that is previously established.

based on the tests that have already been conducted, it has already been decided that when 3.97 stable is out, it will become the new recommended version.

http://www.hydrogenaudio.org/forums/index....ndpost&p=289316 (http://www.hydrogenaudio.org/forums/index.php?showtopic=32121&view=findpost&p=289316)

I had a serious issue with the lame ACM from the 3.97b1 compile from RareWares. After installing it EAC, the software with my Bluethoot device and some other programs could no longer be opened. I got "Access violation" messages and such. When reverting to the 3.96.1 Lame ACM, all those issues was resolved. (Using XP sp2, BTW.)

I had the same issue with lameACM. EAC won't start but i got an error message with an "access violation".
But i deinstalled lameACM because i don't need it anymore 
I only used lameACM for filmsoundtrack in the past, but i changed to mp4 or mkv and use other audioformats instead of lame now.
The main-thing is that the lame.exe works great and gives excellent results.

But i have another question:
I didn't followed the hole development of 3.97alphas.
Now i wanted to test all the properties of lame397b1 like i did with 3.96.1.
In 3.96.1 there were ATH-Settings available. Now in the 3.97b1 it doesn't take any effect, when playing with this settings. Are they removed?

Regarding the ACM interface:
Source code did not changed between a12 and beta, but some people are reporting crashes with beta while a12 was working.
Some of those people downloaded the binaries from Rarewares, so the question is:
Is the compiled beta ACM available on Rarewares using the same compiler switches are the previously available a12?

Is it possible, that there will be a Mac-Version of this beta?
Would be very nice 
I've found a Mac-Version of alpha11, very comfortable in combination with iTunes and Synergy (automatic coversearch).

Regarding the ACM interface:
Source code did not changed between a12 and beta, but some people are reporting crashes with beta while a12 was working.
Some of those people downloaded the binaries from Rarewares, so the question is:
Is the compiled beta ACM available on Rarewares using the same compiler switches are the previously available a12?
[a href="index.php?act=findpost&pid=326834"][{POST_SNAPBACK}][/a]

Hmmm, I don't know what happened with the previous build, but I've rebuilt the ACM and I think it's OK now. I've uploaded again to Rarewares and added a note to the narrative indicating that it's only the ACM that's changed.

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?

You may, indeed!!  I'll get right on it.

Thanks a lot john33, now i can finally show my friends, who can't be bothered with commandline settings, how good the new lame 3.97 is

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?
[a href="index.php?act=findpost&pid=327315"][{POST_SNAPBACK}][/a]

Now available at Rarewares. The version I've posted is the one with the revised encoder dialogue interface.

Is it possible, that there will be a Mac-Version of this beta?
Would be very nice 
I've found a Mac-Version of alpha11, very comfortable in combination with iTunes and Synergy (automatic coversearch).
[a href="index.php?act=findpost&pid=326851"][{POST_SNAPBACK}][/a]

The Developer Tools come free with Mac OS X, and can also be downloaded (http://connect.apple.com), and you only need to type 3 simple lines in the Terminal to build and install LAME. A quick reference to this is available with the iTunes-LAME software. It's even easier now with the beta, because there's a source code file download on LAME's sourceforge page, instead of just pulling from cvs.

Quote

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?
[a href="index.php?act=findpost&pid=327315"][{POST_SNAPBACK}][/a]

Now available at Rarewares. The version I've posted is the one with the revised encoder dialogue interface.
[a href="index.php?act=findpost&pid=327329"][{POST_SNAPBACK}][/a]

I'm not sure I understand the scale of 10-100 for the encoder dialogue, how does it correctly correspond to the new presets, such as -V0.  Also, please explain what the encoding engine quality does.  Thanks for the update to LameDrop, always handy.

Quote

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?
[a href="index.php?act=findpost&pid=327315"][{POST_SNAPBACK}][/a]

Now available at Rarewares. The version I've posted is the one with the revised encoder dialogue interface.
[a href="index.php?act=findpost&pid=327329"][{POST_SNAPBACK}][/a]

After encoding using the newly posted LameDrop for 3.97b1, encspot & audio identifier show the lame version as 3.96r.  Not sure what causes this, when I encode using speeks front end I get the proper version tag for 3.97b1.

Quote

Quote

Hey john33, may I suggest making a fresh version of LamedropXPd based on you-know-what?
[a href="index.php?act=findpost&pid=327315"][{POST_SNAPBACK}][/a]

Now available at Rarewares. The version I've posted is the one with the revised encoder dialogue interface.
[a href="index.php?act=findpost&pid=327329"][{POST_SNAPBACK}][/a]

After encoding using the newly posted LameDrop for 3.97b1, encspot & audio identifier show the lame version as 3.96r.  Not sure what causes this, when I encode using speeks front end I get the proper version tag for 3.97b1.
[a href="index.php?act=findpost&pid=327357"][{POST_SNAPBACK}][/a]

Hmmm, I don't quite know how that happened, but I've recompiled and uploaded again and it now reads '3.97b', as it should. Thanks for reporting this, BTW.

I'm not sure I understand the scale of 10-100 for the encoder dialogue, how does it correctly correspond to the new presets, such as -V0. Also, please explain what the encoding engine quality does.

http://lame.sourceforge.net/lame_ui_example.html (http://lame.sourceforge.net/lame_ui_example.html)

Just curious as to why EncSpot report lowpass filter at 18600 for -v 2 --vbr-new?

Just curious as to why EncSpot report lowpass filter at 18600 for -v 2 --vbr-new?
[a href="index.php?act=findpost&pid=327469"][{POST_SNAPBACK}][/a]

This is because for -V 2, the old -preset standard, the vbr quality is set to 2 and this in turn sets a lowpass of 18600. It has been this way for some time.

OK. Thank you john!

Yay, thanks John!

By the way, bitrate corresponding table is a bit, well, misleading in LamedropXPd v.2: while quality 70 is a perfect 176 kbps, quality 60 is more like 144 (150 kbps, to be more precise) and 40 is almost perfect 128 kbps. That is because of -Y switch that gives a massive boost to bitrate starting with -V3, so the progression is non-linear here.
Well, it's not a bug, nor a serious issue… just a minor note.

By the way, bitrate corresponding table is a bit, well, misleading in LamedropXPd v.2: while quality 70 is a perfect 176 kbps, quality 60 is more like 144 (150 kbps, to be more precise) and 40 is almost perfect 128 kbps. That is because of -Y switch that gives a massive boost to bitrate starting with -V3, so the progression is non-linear here.
Well, it's not a bug, nor a serious issue… just a minor note.
[a href="index.php?act=findpost&pid=327588"][{POST_SNAPBACK}][/a]

Always a difficult one, this, as it does very much depend upon the material used. However, if one can generalise, I think that it should be revised as follows:

Quality Setting                   Indicated Bitrate
  10  (V9)                                   64
  20  (V8)                                   92
  30  (V7)                                  112
  40  (V6)                                  128
  50  (V5)                                  140
  60  (V4)                                  160
  70  (V3)                                  176
  80  (V2)                                  200
  90  (V1)                                  224
  100 (V0)                                  240

Anyone else have a view on this?

Did the --athaa-sensitivity switch disapear?
LAME 3.97b1 doesn't start with this switch, whereas the 3.97a12 using the same commandline is working perfectly. Is it intended?

Always a difficult one, this, as it does very much depend upon the material used. However, if one can generalise, I think that it should be revised as follows:

Code: [Select]

Quality Setting                   Indicated Bitrate
  10  (V9)                                   64
  20  (V8)                                   92
  30  (V7)                                  112
  40  (V6)                                  128
  50  (V5)                                  140
  60  (V4)                                  160
  70  (V3)                                  176
  80  (V2)                                  200
  90  (V1)                                  224
  100 (V0)                                  240

Anyone else have a view on this?
[a href="index.php?act=findpost&pid=327625"][{POST_SNAPBACK}][/a]

I'm building a complete table based on a representative [of my own collection] set of 150 classical files (and only classical!). My computer is still busy; I think I will post the result tomorrow.

Did the --athaa-sensitivity switch disapear?
LAME 3.97b1 doesn't start with this switch, whereas the 3.97a12 using the same commandline is working perfectly. Is it intended?
[a href="index.php?act=findpost&pid=328032"][{POST_SNAPBACK}][/a]

the ath switches are available in alpha builds for developing and tuning. If you think you need the sensitivity switch to undo/tune presets, then the presets should be changed.

Experimental switches are also available when binary is compiled in debug mode.

In the past, with v3.96.1, the athaa-sensitivity 1 setting showed a great improvement with certain passages reducing ringing/warblig problems with very limited bitrate increase (at least for certain genres).
I didn't test latest 3.97 alhpa but according to guruboolez intensive testing, those problems are reduced to acceptable levels now. So, i suppose, he himself would not recommend using athaa switches with the new 3.97 version. If not and if 3.97a12 outputs bit identical results with 3.97b1 i can eventually test some samples.

Quote

Did the --athaa-sensitivity switch disapear?
LAME 3.97b1 doesn't start with this switch, whereas the 3.97a12 using the same commandline is working perfectly. Is it intended?
[a href="index.php?act=findpost&pid=328032"][{POST_SNAPBACK}][/a]

the ath switches are available in alpha builds for developing and tuning. If you think you need the sensitivity switch to undo/tune presets, then the presets should be changed.
[a href="index.php?act=findpost&pid=328035"][{POST_SNAPBACK}][/a]

The quality impact of --athaa-sensitivity 1 (with -V5) is variable. I noticed difference in bitrate up to 20 kbps. Difference in quality is very important too - especially after MP3gain process (useful for portable IMO).
For me, it's a pity that this switch isn't available anymore. 

is this switch only useful with -V5 preset, and maybe below?
would you always use it in combination with -V5 (saw some recommendation elsewhere)?

if not always, what kind of samples are affected?

The quality impact of --athaa-sensitivity 1 (with -V5) is variable. I noticed difference in bitrate up to 20 kbps. Difference in quality is very important too - especially after MP3gain process (useful for portable IMO).
For me, it's a pity that this switch isn't available anymore.

I'd suggest --athlower or --scale in such cases.

Please let me repeat AndyMutz's question:

when using --vbr-new the -q switch produces exact same results, no matter if i use q0,q1,q2,q3 or q4. is that intended?

Does anyone know anything about this? Thanks for your help!

is this switch only useful with -V5 preset, and maybe below?
would you always use it in combination with -V5 (saw some recommendation elsewhere)?

if not always, what kind of samples are affected?
[a href="index.php?act=findpost&pid=328052"][{POST_SNAPBACK}][/a]

I haven't tried the effect of the switch with VBR mode below -V5.
I always add this command to all -V5 encodings. On average the bitrate is increased by 6 kbps IIRC.
The impact is really audible on low volume sample/part of the sample. It becomes dramatic after MP3gain with such samples. But the --ahtaa-sensitivity 1 tool can't fully solve the extreme ringing issues occuring with very quiet samples. The quality gain is nevertheless important, and I would rather make --athaa-sensitivity 1 the default mode if you really want to remove this tool from the public version of LAME.



P.S. I recently made some RG statistics with a part of my classical library (11000 files were involved). ~1050 files had a track gain > +10 dB! On such tracks, there's serious ATH issues with LAME VBR with -V5. -V4 is by default much better.

I can speak only for 3.96.1 and early 3.97 alphas, i have to test the lastest version to be sure. --athaa-sensitivity 1 is useful with low/mid bitrate VBR settings. With -V5 the quality impact with some quite tracks in impressive but not resolutive with extreme samples. I remember i did tests even at -V4 and the same switch proved to be useful to reduce ringing. With -V3 and below i believe that the quality gain is trascurable. That said, i never mp3gained my encodings for these tests but i can't exclude that with very high corrections (or high volume listening) artifacts could arise even with others VBR settings.

@robert: if you search for athaa sensitivity in the forums, you'll find some tests and samples affected but i believe that these cases are not so unusual, expecially with certain genres.

@gabriel: --athaa-sensitivity corrects well some issues with limitate bitrate increase. --athlower will certainly help in the same cases but at what "price" ? I admit i never tested it.

As promised, the bitrate table for each VBR -V mode and for both "default" & "new" VBR algorithms.
It's based on 150 classical tracks. Bitrate bloat due to sb21 are not really common; as a consequence, the average bitrate I obtained for the highest profiles is probably lower than what people encoding dynamically compressed music would get.

[span style=\'font-size:21pt;line-height:100%\']VBR [OLD][/b][/u][/span]

V0	V1	V2	V3	V4	V5	V6	V7	V8	V9

239,0	229,8	207,1	195,2	175,8	134,7	112,6	92,4	74,5	52,5
253,4	233,9	206,0	169,4	153,4	133,4	119,4	99,7	83,2	57,8
269,3	252,5	225,0	196,8	176,8	150,4	137,5	122,6	97,6	69,4
262,4	243,8	215,4	177,1	161,4	142,9	130,7	112,5	93,2	68,4
218,9	201,3	177,9	156,4	140,4	108,3	93,5	79,6	67,1	46,4
174,0	166,8	145,5	133,9	115,3	82,1	69,0	55,1	47,2	31,0
224,9	213,3	191,8	182,7	164,9	129,8	109,2	89,8	73,7	52,7
222,0	211,1	190,4	180,2	164,1	131,8	105,7	81,2	63,9	42,9
216,4	205,3	184,0	174,3	153,4	111,7	94,4	76,7	61,7	40,8
228,4	211,4	187,0	158,1	142,2	119,2	95,5	71,2	52,4	31,9
230,5	220,4	199,0	188,4	167,6	130,5	107,8	87,7	72,0	50,6
220,6	211,8	191,1	177,3	153,8	109,5	90,3	71,1	57,7	38,1
244,9	222,2	196,9	180,9	161,4	127,2	109,4	94,2	81,8	61,9
224,5	213,0	192,3	182,9	163,7	127,6	106,5	86,4	70,4	50,2
220,3	200,3	176,7	165,0	146,7	116,2	98,1	80,1	65,2	45,9
244,4	228,8	204,5	182,5	166,5	139,7	120,2	98,7	79,3	49,8
212,4	201,5	179,6	167,7	148,4	110,6	91,9	73,3	58,1	38,1
216,5	201,8	179,9	170,5	154,1	126,6	106,1	85,1	68,9	48,1
225,9	216,7	195,9	185,9	166,8	131,7	110,4	89,7	72,6	50,6
226,8	217,7	195,9	186,2	168,9	131,5	107,7	85,2	68,9	49,0
232,3	221,3	199,2	187,0	170,6	140,2	118,6	98,3	80,7	57,2
239,2	224,7	201,7	184,6	167,1	137,5	114,9	93,0	73,8	50,6
218,7	209,0	186,8	173,4	154,3	117,3	98,8	83,0	68,9	50,0
209,6	198,2	175,1	161,3	140,1	104,5	88,3	71,3	59,1	40,6
212,4	204,4	184,5	171,3	145,1	91,3	72,9	56,1	42,9	23,3
221,2	211,5	190,0	178,7	158,0	115,1	93,9	75,4	61,3	42,1
230,5	217,4	195,5	187,4	172,5	143,8	119,5	97,3	78,4	55,0
226,5	214,9	193,2	179,2	156,6	117,5	98,8	78,6	64,8	44,0
218,6	208,5	186,5	172,7	151,8	111,9	92,5	72,3	57,7	38,8
238,6	225,2	200,9	184,4	167,5	140,8	122,7	103,5	86,9	64,2
237,2	220,0	195,6	181,7	160,4	124,2	103,2	84,3	69,9	50,7
230,0	215,9	193,0	179,2	157,1	117,2	97,9	77,9	63,4	43,4
242,2	227,7	202,7	187,6	169,1	134,4	115,0	97,8	81,6	60,2
232,2	209,3	182,7	164,7	145,8	113,3	96,2	78,3	65,9	45,5
238,8	226,7	204,3	193,3	176,3	141,9	117,4	95,6	76,4	52,9
227,2	213,1	189,2	163,9	150,0	132,2	122,4	106,0	89,5	66,1
228,5	216,7	194,6	184,5	168,2	140,9	121,2	100,7	85,7	63,6
228,1	208,3	184,1	173,7	155,9	128,3	112,6	93,3	81,8	61,0
211,6	202,9	182,0	170,5	153,8	118,9	96,0	76,9	62,2	39,4
214,4	204,4	183,1	172,4	156,0	128,8	114,2	93,6	79,2	53,8
225,9	212,3	188,9	174,7	160,2	140,3	126,9	109,5	92,2	69,5
216,4	207,1	185,6	173,6	154,7	120,5	102,2	81,4	67,6	48,1
220,6	210,9	190,2	180,0	160,4	123,7	103,1	82,5	66,8	46,0
224,8	213,5	191,4	179,1	157,9	118,2	97,9	78,5	63,5	42,6
224,7	208,0	184,5	170,9	150,9	116,9	98,3	80,0	65,9	46,3
209,2	199,5	180,0	173,1	157,6	135,1	113,8	91,9	77,8	56,3
207,9	198,5	179,4	169,4	153,5	126,8	109,7	89,9	76,0	54,6
228,9	216,7	194,0	181,9	164,2	135,2	116,1	96,3	80,9	58,1
222,3	204,5	180,5	167,4	150,1	108,8	84,8	65,0	50,4	28,7
237,3	220,7	195,0	172,5	157,1	138,5	126,2	107,2	90,7	64,8
226,2	214,7	192,3	179,3	161,0	127,4	110,5	91,2	76,5	55,4
229,7	218,8	196,9	187,2	169,5	137,8	117,5	98,6	82,6	61,6
228,8	218,1	196,5	186,7	169,0	138,1	117,9	97,3	80,7	57,9
229,2	215,1	192,1	183,4	166,6	134,8	115,8	97,8	81,4	59,7
259,4	240,7	211,0	184,6	169,3	148,2	135,5	117,6	99,2	73,7
229,4	217,8	196,1	187,9	171,0	142,3	121,7	102,5	85,6	61,3
228,5	215,1	191,8	181,9	166,5	144,5	126,6	107,6	91,4	66,4
236,5	218,3	192,3	176,7	160,3	137,6	121,0	102,5	86,9	63,0
233,3	214,6	190,2	179,2	163,0	139,3	120,4	102,0	86,1	64,4
232,1	220,9	198,9	189,9	173,3	141,7	120,0	99,4	81,4	58,6
233,6	213,8	187,6	169,6	154,1	132,2	117,1	98,5	81,7	57,4
239,5	221,2	195,1	170,5	154,4	131,0	115,7	98,9	82,9	59,2
242,9	229,8	205,0	187,1	171,2	148,2	131,9	114,6	98,6	71,8
220,5	209,1	187,5	178,7	162,9	140,2	124,8	105,7	89,3	63,2
241,3	223,1	196,1	179,0	164,2	142,9	126,3	108,7	92,6	67,2
200,8	170,6	143,3	131,0	116,6	95,2	84,6	66,0	53,5	35,8
219,2	204,1	181,8	170,9	151,2	113,0	94,2	76,6	61,3	41,0
219,5	210,6	189,9	177,9	156,5	116,6	96,8	76,0	60,0	39,6
223,8	208,9	186,3	175,7	156,1	122,8	106,2	85,6	70,9	50,8
212,3	201,1	180,2	171,7	154,9	125,1	105,0	83,2	65,8	43,6
203,1	193,1	173,0	163,2	143,7	104,4	87,3	68,5	56,2	37,7
216,5	206,3	186,0	179,0	163,4	140,0	120,1	97,1	79,4	57,4
226,0	211,3	188,3	177,0	157,5	123,1	102,8	83,1	67,5	48,2
217,4	204,0	182,9	173,9	155,6	116,7	95,7	73,7	58,5	38,4
249,4	218,6	184,9	149,5	133,7	113,1	98,0	79,0	63,6	43,7
225,8	211,6	185,6	161,6	145,7	124,3	110,8	90,4	79,6	57,3
223,6	209,2	183,1	159,4	143,6	125,4	116,3	96,7	83,7	61,3
245,2	226,4	198,2	161,9	146,4	128,3	117,7	97,7	81,3	58,3
255,2	240,0	212,8	168,6	153,8	135,0	125,8	107,5	89,3	65,4
226,4	215,6	192,4	178,5	161,7	136,7	122,3	99,6	81,2	55,1
208,8	197,4	175,0	158,6	144,1	124,0	112,9	91,6	79,3	58,5
237,3	222,0	198,7	189,8	172,9	142,4	122,3	102,0	83,9	60,1
215,6	204,8	184,8	174,1	152,3	117,7	94,8	75,2	60,2	35,1
228,6	218,6	195,8	181,7	161,3	122,2	102,6	80,9	64,5	44,4
260,0	248,1	222,3	206,2	187,0	151,9	123,4	99,7	80,2	57,9
211,1	197,9	177,1	166,7	148,3	117,4	100,9	78,9	63,7	37,7
219,3	208,5	187,3	177,7	160,4	131,0	112,1	91,2	74,6	49,1
237,5	227,4	205,1	193,3	173,2	131,4	107,9	88,1	71,2	50,3
228,2	214,5	189,6	179,7	161,3	113,5	96,8	79,9	67,5	49,9
233,2	211,7	187,0	174,4	155,1	118,1	89,1	66,2	52,7	35,8
194,3	186,9	166,2	154,7	136,5	98,2	82,3	65,2	54,4	37,8
205,3	196,6	174,4	162,0	141,8	96,8	79,8	63,8	53,7	37,1
200,7	192,0	171,0	160,3	145,4	108,2	89,4	71,9	60,1	44,0
221,0	212,1	189,5	174,1	152,5	108,3	87,9	69,4	56,3	38,3
178,9	169,8	149,3	137,6	117,5	81,1	68,7	53,7	45,9	29,1
178,9	169,8	149,3	137,6	117,5	81,1	68,7	53,7	45,9	29,1
208,2	192,8	170,7	158,7	140,9	112,1	96,0	77,9	64,8	45,5
221,4	203,4	180,1	167,4	148,5	112,0	93,6	75,3	59,9	39,2
224,3	214,9	193,9	186,2	169,5	139,1	119,7	96,9	77,5	52,3
229,3	210,5	187,1	178,3	161,7	141,7	127,5	98,3	88,5	68,9
216,1	207,9	187,2	177,3	161,0	123,8	105,6	86,6	70,7	47,8
224,8	206,5	184,1	174,8	158,0	126,1	103,8	83,7	67,7	47,3
241,7	226,2	205,2	195,3	177,6	143,0	116,0	92,6	72,3	52,0
227,8	215,7	192,1	176,9	155,3	111,3	88,8	70,6	57,2	39,4
217,9	207,5	187,0	179,1	164,3	142,6	123,7	100,0	75,3	50,0
220,4	203,4	180,0	167,2	150,4	121,8	95,5	72,5	54,8	34,0
221,3	201,9	178,2	166,5	145,9	111,8	93,0	72,7	57,1	36,3
224,8	211,5	191,2	182,0	161,5	127,1	105,9	85,8	68,5	45,9
193,9	182,1	161,5	155,1	140,6	120,3	105,1	87,6	76,6	55,0
196,4	183,8	162,1	150,5	133,0	94,9	76,2	57,0	44,1	26,2
209,6	198,1	176,9	166,8	148,0	107,6	84,6	64,5	50,2	32,3
215,1	203,7	181,9	170,3	152,5	112,2	88,7	69,3	53,4	33,3
226,6	216,1	193,7	182,5	164,0	127,2	106,0	85,9	69,3	48,9
215,2	202,9	180,4	168,3	148,4	111,3	92,4	72,5	56,4	35,7
218,5	206,7	184,9	175,7	159,3	135,9	120,3	99,3	83,8	57,3
218,6	205,8	184,7	175,4	159,1	131,3	111,5	87,0	66,0	40,7
222,8	210,6	188,9	179,5	163,2	135,7	116,4	96,2	80,2	57,5
184,8	169,7	147,4	135,3	117,7	89,0	75,5	57,8	48,5	32,3
186,9	173,3	150,5	135,9	114,0	75,9	61,9	48,6	40,2	25,0
194,8	184,4	161,3	148,9	130,9	97,5	81,5	63,2	52,0	35,7
227,7	217,7	197,0	187,4	169,6	138,3	116,8	96,2	79,2	54,3
243,6	231,4	208,1	197,0	178,6	142,0	119,8	98,8	79,7	56,5
172,9	166,7	145,0	134,5	113,0	71,5	56,5	41,3	32,9	18,9
249,3	231,4	202,9	176,0	160,4	137,5	126,3	110,6	93,5	69,5
230,7	220,2	198,6	188,4	170,4	135,7	113,7	93,2	74,8	52,2
233,1	221,5	199,7	192,2	177,2	153,0	131,9	113,4	95,5	69,4
247,2	232,5	209,3	198,2	181,9	142,4	119,7	97,6	77,3	54,8
217,4	205,5	183,7	170,2	147,5	101,7	83,3	65,4	52,0	32,5
223,0	204,1	179,6	169,5	153,3	129,0	111,5	91,0	75,1	53,2
221,0	208,1	185,5	176,1	159,7	135,3	114,6	93,7	78,5	55,1
231,8	214,3	190,3	176,3	155,8	119,7	100,4	81,1	66,0	45,7
232,3	221,8	200,3	189,6	171,5	136,6	115,9	92,0	76,0	53,4
235,9	222,0	199,4	188,4	171,9	143,3	123,3	103,6	86,3	62,0
246,5	235,1	211,7	200,4	183,0	146,3	125,0	103,8	84,0	61,7
241,4	228,6	202,0	190,5	170,3	134,3	114,5	95,6	78,8	52,1
231,5	219,9	197,4	183,7	161,2	123,0	103,1	82,3	68,3	47,8
230,8	216,6	193,7	179,2	159,1	109,8	79,8	61,0	48,4	29,7
225,8	215,7	194,7	184,0	166,3	136,2	116,5	95,9	79,4	55,0
226,4	207,7	184,2	173,2	158,0	124,6	102,2	79,7	62,8	42,7
230,7	216,7	193,7	180,5	163,0	131,1	112,0	93,9	77,1	52,9
231,5	209,8	183,5	163,7	148,5	125,6	110,9	93,1	78,3	55,7
219,3	207,8	185,6	176,0	158,5	123,0	100,8	81,4	64,6	42,7
226,2	212,8	190,4	178,7	158,3	121,4	101,4	78,6	63,5	43,8
237,4	220,3	194,2	164,9	148,8	129,9	119,8	101,5	86,3	61,7
222,2	207,8	185,8	173,6	158,7	130,2	104,8	77,8	56,8	34,9
218,8	201,9	179,3	167,6	149,9	113,7	96,2	76,1	62,8	43,2
234,2	216,1	190,7	176,0	159,1	133,4	115,9	97,0	82,0	59,7
228,2	214,6	191,2	177,4	156,1	116,5	96,4	76,9	61,1	40,7
229,7	217,1	194,5	185,1	168,7	142,8	122,2	103,0	87,5	62,9
227,3	216,1	194,5	182,4	163,7	130,4	110,4	89,2	73,4	51,5

[span style=\'font-size:21pt;line-height:100%\']VBR [NEW][/b][/u][/span]

V0	V1	V2	V3	V4	V5	V6	V7	V8	V9

234,3	221,8	194,6	181,7	167,0	129,5	109,0	85,3	69,5	48,6
253,6	240,6	210,8	171,6	160,0	140,5	125,2	103,4	86,0	56,4
266,8	258,7	230,3	200,7	184,4	157,5	143,4	125,7	99,4	67,7
261,3	249,5	217,7	178,0	166,7	148,3	134,6	112,8	94,3	69,2
216,5	202,1	175,7	153,5	140,5	108,6	93,1	77,4	65,9	44,1
190,0	165,1	135,1	119,5	106,2	78,3	66,0	51,8	45,0	26,2
218,3	207,4	181,9	173,1	159,6	127,1	107,4	85,0	70,1	49,4
220,2	211,6	186,9	178,1	166,2	133,2	106,3	76,4	60,6	37,9
218,9	204,1	178,0	167,4	150,9	111,1	93,4	72,6	57,9	36,5
229,2	216,9	188,6	158,9	147,3	123,6	98,4	67,8	49,4	25,6
221,6	213,5	188,7	177,8	161,5	127,8	106,0	83,0	68,5	47,2
215,7	206,1	180,7	165,4	147,2	107,2	89,1	66,9	54,1	33,2
245,4	220,7	191,4	175,1	159,8	127,6	109,9	93,1	81,2	60,1
214,4	205,6	181,2	171,4	156,9	123,9	104,4	81,2	66,6	46,8
213,5	195,3	167,6	156,1	141,9	113,3	96,0	74,9	60,7	42,3
242,8	228,9	201,5	182,8	171,2	144,6	123,7	98,3	76,3	43,2
212,2	196,7	169,5	156,8	142,0	108,2	90,6	68,2	53,9	33,8
216,8	198,5	172,6	164,4	152,8	125,0	104,5	79,9	64,7	44,6
219,0	209,8	184,9	174,8	160,5	128,3	107,9	83,1	67,3	47,2
220,3	206,8	180,3	169,8	157,4	124,9	104,0	77,5	64,1	45,9
225,1	219,0	193,7	182,0	169,8	140,1	118,8	94,7	78,0	54,3
231,5	222,3	195,9	179,2	166,0	137,6	115,2	88,3	70,0	46,1
218,7	201,8	173,7	159,1	145,1	113,4	97,3	78,9	65,7	45,7
214,3	195,8	167,0	150,7	134,2	102,3	87,0	68,0	56,8	36,7
211,9	203,4	178,5	163,6	142,1	91,5	72,4	52,7	38,1	18,3
217,8	207,0	181,3	169,4	152,6	112,6	93,1	71,5	58,6	38,2
225,7	213,2	187,9	181,6	171,1	142,0	117,4	90,8	73,9	52,2
218,7	207,6	182,2	166,3	149,5	115,1	97,3	75,0	61,4	39,9
216,3	202,9	175,8	161,3	145,4	109,2	90,5	67,1	53,5	34,9
234,1	221,9	194,4	178,2	166,2	141,1	123,3	102,4	86,5	63,5
228,0	212,4	184,5	170,2	153,7	120,7	100,9	79,8	66,6	47,1
223,7	211,4	184,9	170,7	153,0	115,9	97,4	74,4	60,4	39,6
236,2	220,2	191,3	175,7	162,1	130,8	113,2	93,9	79,2	57,7
231,5	207,5	176,9	158,6	143,7	112,3	95,4	75,7	64,3	42,7
233,7	223,1	196,9	186,8	174,2	140,3	116,0	90,2	72,7	50,0
223,1	217,7	191,2	166,2	156,4	139,8	129,0	111,5	94,2	67,3
222,5	211,7	186,1	176,7	165,2	139,3	120,6	98,8	85,0	62,7
223,1	204,8	177,0	166,9	154,0	127,7	112,1	91,9	80,6	59,9
214,0	200,8	174,5	162,9	150,6	119,1	96,7	73,0	58,5	32,9
213,5	206,0	181,2	171,3	159,6	134,0	118,2	94,6	78,3	49,3
225,0	213,5	186,6	173,3	163,1	144,1	130,3	111,3	94,4	70,6
212,9	201,3	175,3	163,5	149,4	118,8	101,8	78,0	64,8	44,4
216,6	207,3	182,5	172,2	157,0	123,1	103,1	78,9	63,5	41,7
219,3	209,7	183,7	171,0	154,4	117,8	98,0	75,0	60,2	37,4
218,2	198,5	170,6	156,6	141,5	111,4	94,4	74,0	61,3	43,2
205,6	197,9	174,7	169,8	159,3	137,2	115,1	90,1	75,0	53,8
200,8	196,0	173,1	164,2	152,5	126,4	110,0	88,2	74,1	51,6
224,7	214,0	187,7	176,4	163,4	136,0	117,4	95,3	79,8	56,1
227,3	207,8	179,9	167,7	154,3	111,4	85,8	62,0	46,6	21,7
238,3	224,5	194,6	173,1	162,7	145,0	131,6	109,4	93,0	64,3
225,6	213,5	186,9	173,8	160,1	129,3	112,2	90,0	74,9	51,9
226,0	213,4	187,1	177,6	164,7	136,1	117,3	95,2	79,7	58,5
222,8	212,9	187,6	178,3	165,6	137,0	117,8	93,9	77,7	54,7
220,4	206,4	180,2	171,7	159,7	131,4	113,6	93,6	78,0	56,8
258,9	243,8	210,8	184,5	173,6	153,5	140,7	121,4	102,9	75,7
224,0	213,1	187,9	180,7	168,4	142,1	121,6	99,3	82,8	58,3
224,9	212,8	185,8	177,1	166,6	145,8	127,3	105,4	89,4	65,3
237,6	219,6	189,4	174,4	162,5	141,1	124,0	102,3	86,5	61,2
233,9	212,2	183,4	173,9	162,2	139,3	119,9	98,5	83,4	62,8
225,5	213,6	188,0	179,6	167,9	139,0	117,7	93,9	77,1	56,1
234,7	216,2	186,4	169,1	157,8	136,4	120,5	98,9	81,9	55,5
240,0	225,5	195,3	171,7	159,9	137,0	120,4	101,8	85,2	58,1
238,9	228,5	200,6	182,8	171,4	150,0	133,9	115,2	99,6	72,3
220,8	210,1	184,5	177,0	166,2	144,9	128,7	106,3	88,9	60,7
245,6	224,8	192,9	176,5	166,1	145,8	129,3	108,2	93,0	66,0
200,8	170,5	138,7	128,1	117,1	95,2	84,5	63,3	50,2	31,6
216,2	200,1	173,4	161,6	145,8	110,2	92,2	71,4	56,9	36,2
214,6	205,9	181,0	168,4	151,7	115,0	95,8	71,5	56,1	35,4
216,1	205,8	180,1	169,9	154,5	122,8	106,5	82,9	68,2	46,7
211,2	202,7	178,0	170,8	157,9	128,0	106,7	79,7	62,0	38,8
202,6	191,1	166,6	156,1	140,7	103,6	86,5	65,3	53,5	33,2
210,7	203,3	179,4	174,0	163,0	139,8	118,9	92,4	75,9	55,0
220,9	207,9	180,8	169,8	154,5	121,7	101,7	78,6	64,1	44,5
215,9	202,6	177,7	169,4	154,6	116,7	95,8	69,7	55,1	34,1
254,5	221,4	183,9	149,0	137,3	116,3	100,3	78,0	62,0	39,4
223,8	213,4	185,3	161,9	150,0	128,8	114,5	92,3	80,6	55,0
219,6	212,5	184,9	161,5	149,7	131,3	121,2	100,4	86,5	60,7
237,6	229,8	202,2	164,7	153,3	134,7	122,8	102,4	85,5	59,1
244,3	244,5	215,9	170,4	159,9	142,2	132,2	113,0	94,5	67,6
222,4	217,9	192,6	179,3	166,8	142,1	126,7	100,0	82,4	52,5
204,3	199,2	174,5	158,7	147,7	127,8	116,0	93,1	80,5	57,4
227,2	214,7	188,9	180,8	168,6	140,0	120,0	96,4	79,6	56,0
214,5	208,4	184,1	173,3	154,2	118,8	95,4	71,6	55,6	27,8
223,3	207,8	180,2	164,8	150,5	115,2	97,4	72,9	58,8	40,2
242,3	231,9	204,3	185,5	171,3	138,7	113,6	86,0	71,1	55,2
211,1	200,6	175,3	165,6	150,6	119,6	102,7	76,5	59,9	31,5
213,8	206,1	181,5	173,0	160,4	132,0	112,2	86,8	69,7	44,8
226,0	216,6	190,3	177,7	162,6	126,1	104,0	80,6	65,3	46,6
230,2	201,4	170,4	158,6	145,6	105,2	91,1	72,6	62,9	46,0
227,5	209,6	181,8	169,7	154,8	116,0	86,6	59,5	48,5	32,0
201,6	177,5	150,3	136,6	123,3	91,5	78,1	59,8	50,7	34,0
214,6	189,9	161,4	146,0	130,3	91,4	75,0	58,1	49,9	32,9
208,1	178,7	151,7	140,5	130,3	100,2	84,6	65,1	55,3	40,8
219,6	204,0	175,8	159,1	142,3	103,4	85,1	64,1	52,3	34,2
188,9	168,5	141,7	126,9	110,8	78,9	67,2	51,0	43,8	23,9
188,9	168,5	141,7	126,9	110,8	78,9	67,2	51,0	43,8	23,9
199,4	184,8	159,2	145,6	133,3	108,1	93,3	73,5	61,4	42,0
221,6	201,4	173,7	160,8	145,7	112,0	93,9	71,8	56,4	34,1
215,9	210,0	185,7	178,4	166,6	138,1	119,6	92,2	72,9	47,6
218,1	204,8	178,3	171,2	159,2	139,7	124,5	99,4	90,2	70,0
218,5	202,2	177,0	166,3	154,4	121,9	104,9	82,6	66,5	41,3
217,6	200,6	174,3	165,1	152,6	121,8	99,9	76,9	62,9	44,3
231,1	218,3	192,5	181,1	168,2	136,7	111,7	83,3	66,2	48,5
218,3	206,3	177,2	161,8	144,9	106,5	86,1	64,8	52,9	35,3
217,1	208,3	184,2	178,7	168,9	145,7	124,6	93,6	69,2	45,2
220,2	206,7	179,6	167,6	154,9	125,2	97,9	68,1	51,4	28,1
217,8	202,0	174,7	163,2	145,9	111,9	93,1	68,5	52,7	31,3
218,6	209,8	185,3	175,3	157,9	125,8	105,4	80,7	64,0	40,3
194,4	181,4	157,3	152,5	142,2	122,3	106,2	88,9	74,3	53,5
205,2	184,9	156,9	143,4	129,2	93,0	74,2	52,0	40,1	21,3
208,3	197,7	171,9	161,7	146,7	107,0	83,4	58,9	46,6	27,3
212,4	202,7	176,7	164,8	151,1	111,2	87,8	64,6	49,2	28,2
220,3	206,7	180,2	168,5	154,8	121,7	102,0	78,5	63,8	45,3
213,9	201,5	174,0	161,5	145,9	111,2	92,6	68,1	52,5	31,1
218,1	207,9	182,2	174,1	162,6	140,0	123,4	99,3	82,6	53,8
216,4	207,9	182,9	175,4	163,6	134,5	113,6	82,6	61,1	35,2
220,0	208,2	182,4	173,8	162,1	136,6	117,4	93,8	77,7	54,5
194,1	169,3	140,4	126,4	113,0	86,4	73,4	54,1	45,9	27,5
202,3	176,9	146,4	127,3	109,7	73,9	60,3	45,5	38,3	18,9
206,6	182,3	152,6	138,1	124,9	93,9	78,8	58,5	48,7	31,9
220,1	212,4	188,1	179,1	166,1	137,4	116,2	92,2	75,1	50,5
228,8	220,2	194,7	183,5	169,8	135,8	115,4	91,3	74,2	53,0
192,5	172,1	141,4	124,6	107,4	70,3	55,4	38,1	32,3	12,8
250,2	235,3	202,7	175,2	163,9	142,4	130,6	113,9	96,5	70,1
220,3	212,8	188,7	178,5	164,9	132,0	110,3	86,3	69,5	48,3
228,3	217,3	191,8	185,7	175,5	153,0	131,6	110,0	92,2	67,0
236,0	225,4	199,8	189,7	177,6	137,1	115,7	90,1	71,9	51,5
220,2	204,6	178,6	163,2	144,3	101,0	82,8	61,7	48,8	27,0
219,7	201,5	173,3	164,7	153,0	128,7	111,2	87,3	71,4	49,2
219,7	207,0	180,7	172,9	160,9	137,3	115,9	91,8	75,7	51,9
222,7	206,4	178,6	164,0	147,9	115,0	97,2	75,0	60,9	41,8
224,7	216,7	191,8	180,9	167,3	134,1	114,2	87,7	73,1	49,0
228,3	215,6	189,2	178,7	166,6	139,3	119,6	97,7	82,1	60,1
232,2	223,7	198,4	187,0	174,3	139,0	119,6	94,4	78,4	59,4
236,7	219,7	189,2	176,6	162,2	129,6	111,5	87,9	71,7	47,4
226,0	215,5	189,2	172,8	154,8	120,6	102,6	79,6	65,2	43,5
225,4	214,0	187,0	172,4	157,1	109,3	78,6	55,7	44,5	24,3
222,0	213,0	188,0	177,9	165,0	137,3	117,7	93,4	76,7	51,0
225,3	207,0	180,0	170,5	159,1	125,3	102,6	75,3	59,2	38,3
229,1	217,6	190,8	178,0	164,2	132,6	113,1	91,7	74,7	48,9
227,5	207,8	178,0	158,2	147,0	125,2	109,5	90,7	76,5	54,1
216,1	206,7	180,4	171,0	157,7	123,4	101,0	77,3	60,5	37,7
218,3	207,6	181,4	169,0	153,0	118,9	100,0	73,7	59,3	40,0
236,0	223,9	195,8	166,2	155,0	136,3	124,8	104,6	88,6	60,6
222,2	210,0	184,1	173,2	162,9	133,7	107,1	72,2	51,9	29,7
219,1	199,4	172,5	160,8	147,2	113,2	96,2	73,5	60,4	38,4
231,7	213,9	184,6	170,9	158,4	134,4	117,0	96,0	80,7	57,4
219,2	207,5	180,1	164,9	148,7	112,9	94,1	70,6	55,7	36,3
221,8	212,6	186,9	178,6	166,8	142,5	122,0	100,6	85,1	60,1
221,9	210,4	184,7	172,7	159,0	128,7	109,8	85,5	69,9	48,0

The bitrate curves look like this:

(http://foobar2000.net/divers/LAME/397b1/LAME397VBRold.png)

(http://foobar2000.net/divers/LAME/397b1/LAME397VBRnew.png)

Each curve correspond to a -Vx mode.


To sum up:

VBR NEW			
	AVERAGE		MIN		MAX
V0	221,89		188,90		266,80
V1	208,40		165,10		258,70
V2	181,46		135,10		230,30
V3	167,69		119,50		200,70
V4	154,21		106,20		184,40
V5	124,25		70,30		157,50
V6	105,81		55,40		143,40
V7	83,17		38,10		125,70
V8	68,29		32,30		102,90
V9	46,03		12,80		75,70

VBR OLD			
	AVERAGE		MIN		MAX
V0	224,67		172,90		269,30
V1	211,18		166,70		252,50
V2	188,23		143,30		225,00
V3	174,60		131,00		206,20
V4	156,66		113,00		187,00
V5	124,79		71,50		153,00
V6	106,08		56,50		137,50
V7	80,46		41,30		122,60
V8	71,00		32,90		99,20
V9	49,45		18,90		73,10

To sum up:

Code: [Select]

VBR NEW    
      AVERAGE     MEDIAN        MIN        MAX
V0     221,89     220,30     188,90     266,80
V1     208,40     207,90     165,10     258,70
V2     181,46     182,20     135,10     230,30
V3     167,69     170,60     119,50     200,70
V4     154,21     156,95     106,20     184,40
V5     124,25     127,35      70,30     157,50
V6     105,81     106,90      55,40     143,40
V7      83,17      82,95      38,10     125,70
V8      68,29      66,95      32,30     102,90
V9      46,03      46,35      12,80      75,70

Code: [Select]

VBR OLD  	
      AVERAGE     MEDIAN        MIN        MAX
V0     224,67     225,95     172,90     269,30
V1     211,18     211,95     166,70     252,50
V2     188,23     189,75     143,30     225,00
V3     174,60     176,50     131,00     206,20
V4     156,66     158,00     113,00     187,00
V5     124,79     127,20      71,50     153,00
V6     106,08     107,85      56,50     137,50
V7      80,46      87,65      41,30     122,60
V8      71,00      71,60      32,90      99,20
V9      49,45      50,25      18,90      73,10

[a href=\"index.php?act=findpost&pid=328359\"][{POST_SNAPBACK}][/a]

I prefere the median instead of the average. It's the one in the middle and its value is more resistent against outliers.

But appart from that: great work! Now we only have to find someone who is willing to do the same thing with the other music-styles 

I prefere the median instead of the average. It's the one in the middle and its value is more resistent against outliers.
[a href=\"index.php?act=findpost&pid=328373\"][{POST_SNAPBACK}][/a]

Corrected

VBR OLD					||	VBR NEW				
	AVERAGE	MEDIAN	MIN	MAX	||		AVERAGE	MEDIAN	MIN	MAX
V0	224,7	226,0	172,9	269,3	||	V0	221,9	220,3	188,9	266,8
V1	211,2	211,9	166,7	252,5	||	V1	208,4	207,9	165,1	258,7
V2	188,2	189,7	143,3	225,0	||	V2	181,5	182,2	135,1	230,3
V3	174,6	176,5	131,0	206,2	||	V3	167,7	170,6	119,5	200,7
V4	156,7	158,0	113,0	187,0	||	V4	154,2	157,0	106,2	184,4
V5	124,8	127,2	71,5	153,0	||	V5	124,3	127,3	70,3	157,5
V6	106,1	107,8	56,5	137,5	||	V6	105,8	106,9	55,4	143,4
V7	86,5	87,6	41,3	122,6	||	V7	83,2	82,9	38,1	125,7
V8	71,0	71,6	32,9	99,2	||	V8	68,3	67,0	32,3	102,9
V9	49,5	50,3	18,9	73,1	||	V9	46,0	46,3	12,8	75,7

EDIT: V7 "old" average bitrate: 80.5 -> 86.5 (typo error).

I prefere the median instead of the average. It's the one in the middle and its value is more resistent against outliers.

Mode never gets any love.
Also the phpbb code blocks are annoying just too small for the whole table.


Back to athaa-sensitivity: Its applications are fairly limited, and the bitrate increase is IMHO too much and too unpredictable to justify being incorporated into the presets. And yet it doesn't take up bitrate comparable to moving up one quality level. It's kind of stuck in no-man's-land.

Maybe vbr-new + athaa-sensitivity would equalize out back to the same bitrate as the old presets. But I also would be worried about regressions with it. Frankly the presets are great, but I think it is too much to expect them to be perfect for all music without increasing bitrate demands too much.

So I think it should stay as it is in the alphas, possibly with a note about use. "Setting --athaa-sensitivity to 1 can improve quality with some types of very quiet music at the cost of some bitrate increase."

Back to athaa-sensitivity: Its applications are fairly limited, and the bitrate increase is IMHO too much and too unpredictable to justify being incorporated into the presets.

And? VBR is by itself unpredicatable. Just take a look on the datas I've just posted. On the contrary, the --athaa-sensitivity 1 command is just limiting the amplitude of the variation, by preventing the encoder to use too low bitrate.

Maybe vbr-new + athaa-sensitivity would equalize out back to the same bitrate as the old presets. But I also would be worried about regressions with it. Frankly the presets are great

I'd suggest you to test current presets with and without --athaa-sensitivity 1... They're far to be great.
Most often, there's no difference in bitrate. But when a difference occurs, be sure that the additionnal bits are worth.

So I think it should stay as it is in the alphas, possibly with a note about use. "Setting --athaa-sensitivity to 1 can improve quality with some types of very quiet music at the cost of some bitrate increase."

In other word, you're suggesting that people should use an alpha encoder for safety?!
BTW, I recall that the quality gain is noticeable on quit PASSAGE, and not only with quiet tracks. As long as music still have some dynamic range, the current low/mid bitrate presets are not fully safe to use if compared to ABR/CBR.

In other word, you're suggesting that people should use an alpha encoder for safety?!

I agree. Telling users to use an alpha to make use of a custom switch is the wrong solution. I also agree with the decision of the lame devs to remove --athaa-sensitivity from non-alpha builds. This is the kind of switch about which users should not need to care. If its necessary, then the encoder should automatically use it. If not, then it shouldn't. So, the question is only if and when it should be defaulted, not if the switch should be reimplemented.

The user should not need to "tune" an encoder. This is the job of the encoder. An encoder which needs additional switches for tuning is flawed and needs to be fixed. The exception obviously are developer- and tester-builds which by definition are meant to experiment.

- Lyx

V4  154,2  157,0  106,2  184,4
V5  124,3  127,3   70,3   157,5

This is a very dramatic difference.
Surely something could be done to bridge the gap between this two quality settings?

I'd suggest you to test current presets with and without --athaa-sensitivity 1... They're far to be great.
Most often, there's no difference in bitrate. But when a difference occurs, be sure that the additionnal bits are worth.

I will do so. But I can really only test at trying them out and seeing bitrate results. I am horrible at ABX quality tests. I never make quality opinions that would require TOS8, because I know I can't back it up.

But I have limited material to test on. My classical collection is only about 30 cds, heavily weighted to 18th-19th century. If this is something that is most evident on your harpsichord music, I give up. (I hate the harpsichord ) I'll also throw some other stuff at it to see if I can get it to trigger in other circumstances... Some electronic music might do the trick.

In other word, you're suggesting that people should use an alpha encoder for safety?!
BTW, I recall that the quality gain is noticeable on quit PASSAGE, and not only with quiet tracks.

Not that people should stay with alpha, only that this needs to be looked at in more detail. Until a decision is made, why not keep the switch exposed to keep the people who want to use a-s 1 happy? And yes, I am aware of how the encoder works in general principles.

I agree. Telling users to use an alpha to make use of a custom switch is the wrong solution. I also agree with the decision of the lame devs to remove --athaa-sensitivity from non-alpha builds. This is the kind of switch about which users should not need to care. If its necessary, then the encoder should automatically use it. If not, then it shouldn't. So, the question is only if and when it should be defaulted, not if the switch should be reimplemented.

But if the decision is made not to make it default, what do the people like guru who use and like this switch do?

The user should not need to "tune" an encoder. This is the job of the encoder. An encoder which needs additional switches for tuning is flawed and needs to be fixed. The exception obviously are developer- and tester-builds which by definition are meant to experiment.

- Lyx

Then why is cbr 128 still the default encode? You have to enter at least one option to get a better quality result. But yes, I guess that too many switches exposed in the --longhelp is why we still have people who come in to tell us about their wonderful 20 parameter long encoding string. Still, there's a problem in principle that you can't have transparent quality without a lot of bits. When you need to encode to lower bitrate, something has to get left out.

Quote

The user should not need to "tune" an encoder. This is the job of the encoder. An encoder which needs additional switches for tuning is flawed and needs to be fixed. The exception obviously are developer- and tester-builds which by definition are meant to experiment.

- Lyx

Then why is cbr 128 still the default encode? You have to enter at least one option to get a better quality result...

There are two misunderstandings here:

1. I wasn't implying that with an encoder the user should not need to specify any options at all. What i meant was that the user should only need to tell the encoder *what* he wants, but not "how to achieve it". The latter part is the job of the encoder. In practice, this means that in an optimal world only quality/target bitrate should be *necessary* with bitrate-upper-limit(for streaming), number of channels and samplerate being other optional parameters. Thus, the user should specify what he needs and the encoder shall come up with the best way to deliver it.

2. I am aware that lame still has lots of switches which imho shouldn't be there. Same for some defaults. But that does that mean that you may never "start somewhere" with improving the situation? It's a process, not a 0/1-switch.

Concerning your question what shall happen if --athaa-sensitivity is NOT made the default, although evidence is brought up that it should be: Then the encoder is flawed and should be fixed. Exposing a developer-switch so that the users can fix it is not the solution. In the worst case(which i highly doubt will happen) you will have an official lame release without it being the default, and then a ha.org-modified version which has it by default. This, from a psychological as well as objective point of view(the world does not just consist of ha.org - hardly any outsider will care about the minor difference) would still be better than "letting the users fix it by exposing the switch".

It plain simply comes down to this: if the defaults are wrong, its a bug. You dont fix bugs by requiring users to patch the code.

Here's my little LAME 3.97b1 bitrate test. I gathered some rock/pop/latin/jazz/electronic tracks from my lossless archive. The selection was quite random, but I left out certain tracks that would have probably resulted extremely high or low bitrates. I ended up with 25 diverse sample tracks. I should have included more tracks, but this was about the best I could do this time.

I encoded them using V values from 0 to 9 with and without VBR New. Encoding each set of 25 tracks from the Monkey's Audio source files took about 13-14 minutes with VBR Old and 8-10 minutes with VBR New using a P4/2.8GHz. I didn't bother to measure exact times, because I used the PC for various other things during the encoding.


[!--sizeo:4--][span style=\"font-size:14pt;line-height:100%\"][!--/sizeo--]VBR OLD  (-V 0 ... -V 9)[/size]

[b]	V0	V1	V2	V3	V4	V5	V6	V7	V8	V9[/b]
	252	232	204	172	157	139	127	112	 93	 69
	256	230	199	179	162	139	122	105	 90	 66
	261	235	206	160	143	125	118	103	 86	 64
	255	238	212	197	181	149	129	110	 92	 68
	237	222	195	181	166	146	135	119	101	 75
	241	218	195	150	135	120	112	 97	 83	 62
	262	238	213	154	139	122	114	 98	 82	 62
	250	229	202	169	154	136	123	106	 87	 60
	221	206	184	167	151	127	114	 96	 82	 56
	268	235	203	159	144	128	120	105	 85	 64
	227	203	179	147	133	118	109	 94	 81	 62
	236	211	185	150	135	118	109	 95	 80	 60
	225	209	185	174	158	130	111	 92	 77	 54
	253	240	216	205	188	165	146	128	107	 78
	266	248	226	162	146	128	118	102	 85	 64
	244	228	206	199	182	146	125	106	 88	 65
	246	232	207	187	171	151	136	117	 95	 69
	234	207	176	151	135	118	109	 93	 77	 55
	261	234	206	164	148	131	123	108	 90	 67
	229	204	180	168	154	129	108	 89	 75	 52
	224	198	174	140	126	110	102	 88	 76	 57
	268	239	212	155	140	124	116	103	 87	 68
	245	215	186	148	133	117	110	 94	 80	 61
	248	236	211	184	166	145	136	121	102	 77
	218	206	187	180	164	143	124	108	 91	 67

(http://www.adart.pp.fi/ha/pix/vbrold.png)


[!--sizeo:4--][span style=\"font-size:14pt;line-height:100%\"][!--/sizeo--]VBR NEW (-V 0 --vbr-new ... -V 9 --vbr-new)[/size]

[b]	V0N	V1N	V2N	V3N	V4N	V5N	V6N	V7N	V8N	V9N[/b]
	251	234	203	169	159	141	129	113	 95	 70
	259	229	194	173	160	139	121	103	 89	 66
	255	238	207	161	148	131	122	107	 89	 65
	246	233	205	190	179	147	126	106	 90	 67
	236	223	193	181	169	151	138	122	106	 78
	238	221	195	150	139	124	115	100	 85	 63
	256	241	216	155	143	126	117	102	 85	 63
	249	229	199	166	155	137	123	105	 86	 61
	220	209	183	166	154	132	119	 98	 82	 54
	266	237	203	155	144	128	120	105	 87	 66
	226	205	179	146	136	120	111	 96	 82	 62
	232	213	184	150	138	121	111	 96	 82	 61
	219	204	177	167	155	129	109	 87	 72	 52
	246	238	212	201	189	165	147	126	106	 78
	258	251	228	162	150	132	121	105	 88	 65
	233	222	197	190	178	143	123	101	 85	 62
	247	235	206	188	176	156	140	117	 96	 68
	236	210	176	152	139	122	111	 95	 78	 55
	261	238	207	164	152	135	126	111	 93	 69
	223	202	175	165	154	130	107	 86	 72	 51
	219	200	174	140	129	113	105	 91	 77	 58
	263	243	214	154	143	127	119	106	 90	 70
	244	217	184	147	135	119	111	 95	 82	 62
	244	241	215	188	174	153	143	127	107	 79
	208	201	178	173	162	141	121	103	 87	 66

(http://www.adart.pp.fi/ha/pix/vbrnew.png)


[!--sizeo:4--][span style=\"font-size:14pt;line-height:100%\"][!--/sizeo--]SUMMARY[/size]

[b]OLD	V0	V1	V2	V3	V4	V5	V6	V7	V8	V9[/b]
Min	218	198	174	140	126	110	102	 88	 75	 52
Max	268	248	226	205	188	165	146	128	107	 78
Average	245	224	198	168	152	132	120	104	 87	 64
Median	246	229	202	167	151	129	118	103	 86	 64
[b]NEW	V0N	V1N	V2N	V3N	V4N	V5N	V6N	V7N	V8N	V9N[/b]
Min	208	200	174	140	129	113	105	86	 72	 51
Max	266	251	228	201	189	165	147	127	107	 79
Average	241	225	196	166	154	134	121	104	 88	 64
Median	244	229	197	165	154	132	121	103	 87	 65

All together and a table with track list:

(http://www.adart.pp.fi/ha/pix/bitratetable_thn.png) (http://www.adart.pp.fi/ha/pix/bitratetable.gif)  (http://www.adart.pp.fi/ha/pix/exceltable_thn.gif) (http://www.adart.pp.fi/ha/pix/exceltable.png)

Click the images to enlarge.


[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Edit: fixed the image links. Edit 2: fixed them again.[/size]

This should give a rough estimation of the average bitrate with VBR presets.
Also sfb21 bloat is very noticeable looking at the graphs, starting from -V2 some tracks are bloated (7,10,15). Very interesting 
Thanks to guruboolez and Alex B for these graphs.

Quote

V4  154,2  157,0  106,2  184,4
V5  124,3  127,3   70,3   157,5

This is a very dramatic difference.
Surely something could be done to bridge the gap between this two quality settings?
[a href="index.php?act=findpost&pid=328405"][{POST_SNAPBACK}][/a]

I wouldn't say it's so dramatic. If you use CBR settings, there's also 128kbps and 160kbps and nothing between them.

Quote

Quote

V4  154,2  157,0  106,2  184,4
V5  124,3  127,3   70,3   157,5

This is a very dramatic difference.
Surely something could be done to bridge the gap between this two quality settings?
[a href="index.php?act=findpost&pid=328405"][{POST_SNAPBACK}][/a]

I wouldn't say it's so dramatic. If you use CBR settings, there's also 128kbps and 160kbps and nothing between them.
[a href="index.php?act=findpost&pid=328574"][{POST_SNAPBACK}][/a]

IMHO the problem is not that the gap between V4 and V5, but the neglible difference in terms of average bitrate between V4 and V3. I'd say make V3 the new "medium", but with slightly higher quality than in the past, then lower the quality of V4 bit.

- Lyx

Quote

Quote

Quote

V4  154,2  157,0  106,2  184,4
V5  124,3  127,3   70,3   157,5

This is a very dramatic difference.
Surely something could be done to bridge the gap between this two quality settings?
[a href="index.php?act=findpost&pid=328405"][{POST_SNAPBACK}][/a]

I wouldn't say it's so dramatic. If you use CBR settings, there's also 128kbps and 160kbps and nothing between them.
[a href="index.php?act=findpost&pid=328574"][{POST_SNAPBACK}][/a]

IMHO the problem is not that the gap between V4 and V5, but the neglible difference in terms of average bitrate between V4 and V3. I'd say make V3 the new "medium", but with slightly higher quality than in the past, then lower the quality of V4 bit.

- Lyx
[a href="index.php?act=findpost&pid=328580"][{POST_SNAPBACK}][/a]

Yes, you are right, if you make a linear regression using the median and vbr-new, you get something like bitrate=226.01-19.815*vbr-mode.

In this case, the highest difference is V4 which is 10kbits to high. But only if you want a linear relation between vbr-mode and target-bitrate.

Please let me repeat AndyMutz's question:

Quote

when using --vbr-new the -q switch produces exact same results, no matter if i use q0,q1,q2,q3 or q4. is that intended?

Does anyone know anything about this? Thanks for your help!
[a href=\"index.php?act=findpost&pid=328061\"][{POST_SNAPBACK}][/a]

Here it produces different results. Try putting -q in the middle (after -V and before --vbr-new).

EDIT: I tried -q0 vs -q5. Values from 0 to 4 indeed seem to produce the same results, from 6 to 9 too. So it looks like effectively there are three -q levels with --vbr-new: 0-4, 5, 6-9.

EDIT: I tried -q0 vs -q5. Values from 0 to 4 indeed seem to produce the same results, from 6 to 9 too. So it looks like effectively there are three -q levels with --vbr-new: 0-4, 5, 6-9.

[a href="index.php?act=findpost&pid=331284"][{POST_SNAPBACK}][/a]

i would still like to know if this is intended or if it's just a bug which will be corrected in one of the next versions..

-andy-

i would still like to know if this is intended or if it's just a bug which will be corrected in one of the next versions..

-andy-

You might want to try posting your question again, in this (http://www.hydrogenaudio.org/forums/index.php?showtopic=32288) thread.

Regards,
Madrigal

Intended

I notice that MP2 decoding is still broken in 3.97b1:

D:\tmp>lame
LAME 32bits version 3.97 (beta 1, Sep 29 2005) (http://www.mp3dev.org/)

usage: lame [options] <infile> [outfile]

    <infile> and/or <outfile> can be "-", which means stdin/stdout.

Try:
     "lame --help"           for general usage information
 or:
     "lame --preset help"    for information on suggested predefined settings
 or:
     "lame --longhelp"
  or "lame -?"              for a complete options list

D:\tmp>lame --decode test.mp2
Error reading headers in mp3 input file test.mp2.

D:\tmp>lame --decode --mp2input test.mp2
Error reading headers in mp3 input file test.mp2.

Is this something that could be fixed for the next/final release?

I notice that MP2 decoding is still broken in 3.97b1:

Is this something that could be fixed for the next/final release?
[a href="index.php?act=findpost&pid=332326"][{POST_SNAPBACK}][/a]

I've uploaded an amended .exe only including the corrected get_audio.c source to Rarewares mp3 section.

I have revisited the decoding issue and discovered that decoding has actually been broken since 3.94beta. The 3.94 beta was OK, but 3.95 and onwards is screwed.

The version I uploaded yesterday was fixed for mp2 but this broke mp3 decoding!!

I have just uploaded a new version, with amended get_audio.c source, with mp2 and mp3 decoding working correctly.

Interestingly the version of LAME I have on my linux installation works fine for MP2 decoding even though it says it's 3.96.1. I'm too much of a newbie to compile these things myself so I probably installed it from the livna RPM repository (I am using Fedora Core 3).

MP1/2 decoding are disabled by default because of the poor error resilience of our decoder.
Enabling mp1/2 decoding sometimes break mp3 decoding because the decoder finds mp1/2 sync words inside mp3 files.

Maybe you can replace your decoder with foobar's fixed mpg123?

Or maybe mpadec (http://mpadec.sourceforge.net/), which is also based in mpg123.

Maybe you can replace your decoder

Maybe we can find a brave soul to do it?

Replacing the decoder is planned, but low priority.

Quote

EDIT: I tried -q0 vs -q5. Values from 0 to 4 indeed seem to produce the same results, from 6 to 9 too. So it looks like effectively there are three -q levels with --vbr-new: 0-4, 5, 6-9.

[a href="index.php?act=findpost&pid=331284"][{POST_SNAPBACK}][/a]

i would still like to know if this is intended or if it's just a bug which will be corrected in one of the next versions..

-andy-
[a href="index.php?act=findpost&pid=331823"][{POST_SNAPBACK}][/a]

Intended
[a href="index.php?act=findpost&pid=331835"][{POST_SNAPBACK}][/a]

Hi all, first post here so please go easy on me
I'm curious as to know what the differences are now between the 3 settings and which is the best to choose?  If -V2/--preset standard uses q3 by default and -h changes it to q2, then I would presume the top option out of the 3 should be chosen. However, which of the previous settings have q0-q4 merged to? If it has gone to q2 or q3, does this mean the extra lossless compression in q0 is no longer used? (Forgive me if I've got my facts wrong on the previous version)

Thanks guys and I look forward to being able to contribute to the community 

I noticed some strange behavior using the new 3.97b1 compared to 3.90.3. When I encode using EAC, the bitrate setting dropdown box  adds a -b switch to the -V 2 --vbr-new command line.

For example, if I select 128kbps the base bitrate of the mp3 will be 128. I have confirmed this using different bitrates in the dropdown box. I have read the faq stating the dropdown box in EAC compression options has no effect on the command line except if 320kbps is selected, however, it seems with 3.97b1 this does not apply i.e. the dropdown box does affect base bitrates.

I have tried to select "User Defined Encoder" but under that setting LAME just pops up for a split second and disappears when it tries to encode.

Granted I have only used these two versions of LAME so far so I don't know in which exact version this "bug" popped up. Or am i mistaken and this behavior is intended?

I noticed some strange behavior using the new 3.97b1 compared to 3.90.3. When I encode using EAC, the bitrate setting dropdown box  adds a -b switch to the -V 2 --vbr-new command line.

For example, if I select 128kbps the base bitrate of the mp3 will be 128. I have confirmed this using different bitrates in the dropdown box. I have read the faq stating the dropdown box in EAC compression options has no effect on the command line except if 320kbps is selected, however, it seems with 3.97b1 this does not apply i.e. the dropdown box does affect base bitrates.

I have tried to select "User Defined Encoder" but under that setting LAME just pops up for a split second and disappears when it tries to encode.

Granted I have only used these two versions of LAME so far so I don't know in which exact version this "bug" popped up. Or am i mistaken and this behavior is intended?
[a href="index.php?act=findpost&pid=333119"][{POST_SNAPBACK}][/a]

Maybe when you use "User Defined Encoder", you don't add "%s %d" to the end of your command line.

I was testing out 3.97b1 and I keep getting the following error on all tracks I'm trying to encode...

Command: C:\Apps\RazorLame\Lame.exe -V 2 "C:\Wavs\Johnny Fiasco Feat Dulce Caramelo - Move It (Original Mix).wav" "C:\Wavs\Johnny Fiasco Feat Dulce Caramelo - Move It (Original Mix).mp3"
LAME 3.97 (beta 1, Sep 29 2005) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding C:\Wavs\Johnny Fiasco Feat Dulce Caramelo - Move It (Original Mix).wav
      to C:\Wavs\Johnny Fiasco Feat Dulce Caramelo - Move It (Original Mix).mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=3
RazorLame encountered an unknown message from LAME while trying to encode "C:\Wavs\Johnny Fiasco Feat Dulce Caramelo - Move It (Original Mix).wav"!

Encoded 0 files in 0:00:52
There was an unexpected LAME message for one file, please check log for error messages.

I've also tried using -V 2 --vbr-new and it give the same error

has anyone else had this problem with 3.97b1 ?

I was testing out 3.97b1 and I keep getting the following error on all tracks I'm trying to encode...

Try to do a search and you will find a thread explaining the "error".

Short version: there was no error. It's just razorlame having crappy "problem-detecion": it just treats everything which it doesn't know yet as a problem.

I noticed some strange behavior using the new 3.97b1 compared to 3.90.3. When I encode using EAC, the bitrate setting dropdown box  adds a -b switch to the -V 2 --vbr-new command line.

For example, if I select 128kbps the base bitrate of the mp3 will be 128. I have confirmed this using different bitrates in the dropdown box. I have read the faq stating the dropdown box in EAC compression options has no effect on the command line except if 320kbps is selected, however, it seems with 3.97b1 this does not apply i.e. the dropdown box does affect base bitrates.

I have tried to select "User Defined Encoder" but under that setting LAME just pops up for a split second and disappears when it tries to encode.

Granted I have only used these two versions of LAME so far so I don't know in which exact version this "bug" popped up. Or am i mistaken and this behavior is intended?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=333119")

It's just something EAC does for the "LAME MP3 Encoder" setting. Switch to "User Defined Encoder" and add %s %d like skelly831 suggested.

Quote

I was testing out 3.97b1 and I keep getting the following error on all tracks I'm trying to encode...

Try to do a search and you will find a thread explaining the "error".

Short version: there was no error. It's just razorlame having crappy "problem-detecion": it just treats everything which it doesn't know yet as a problem.
[a href="index.php?act=findpost&pid=333132"][{POST_SNAPBACK}][/a]

Here's the RazorLame fix: [a href="http://www.dors.de/phpbb/viewtopic.php?p=1743#1743]http://www.dors.de/phpbb/viewtopic.php?p=1743#1743[/url]

the fix worked... thanks for the info

I have revisited the decoding issue and discovered that decoding has actually been broken since 3.94beta. The 3.94 beta was OK, but 3.95 and onwards is screwed.

The version I uploaded yesterday was fixed for mp2 but this broke mp3 decoding!!

I have just uploaded a new version, with amended get_audio.c source, with mp2 and mp3 decoding working correctly.
[a href="index.php?act=findpost&pid=332643"][{POST_SNAPBACK}][/a]

I have taken yet a further look at the decoding and have now uploaded another version that now outputs wave files from decoded mp2 and mp3 files that contain the same number of samples as the outputs from foobar2000. Error checking, etc., remains as before. The d/l includes the amended get_audio.c and main.c sources.

Here's the RazorLame fix:

An even better "fix" is to abandon RazorLame in favor of Speek's ALL2LAME (http://members.home.nl/w.speek/all2lame.htm), which never has this problem, and doesn't need to be updated with each new version of LAME.

Regards,
Madrigal

I have taken yet a further look at the decoding and have now uploaded another version that now outputs wave files from decoded mp2 and mp3 files that contain the same number of samples as the outputs from foobar2000. Error checking, etc., remains as before. The d/l includes the amended get_audio.c and main.c sources.
[a href="index.php?act=findpost&pid=333258"][{POST_SNAPBACK}][/a]

And another version is now at Rarewares. I believe this version correctly handles 'enc_padding', decoding to the correct number of output wave samples from mp3 input. The outputs from decoding mp2 and mp3 files are exactly the same size as from foobar2000.

Amended source files are included.

why not just drop decoding in lame until you have a decoder worth including?

Because we need it for the frame analyser.

And another version is now at Rarewares. I believe this version correctly handles 'enc_padding', decoding to the correct number of output wave samples from mp3 input. The outputs from decoding mp2 and mp3 files are exactly the same size as from foobar2000.

Amended source files are included.
[a href="index.php?act=findpost&pid=333732"][{POST_SNAPBACK}][/a]

What I think will be the final version of this is now at Rarewares. Includes exe, amended source files and diff files for the amendments.

What I think will be the final version of this is now at Rarewares. Includes exe, amended source files and diff files for the amendments.

I have the feeling that you are assuming that the mp2 delay is the one of current TooLame version and the mp3 delay the one of current Lame version.
Regarding mp2, this might cut the beginning of files produced with another encoder, and regarding mp3 the situation is the same unless you are reading the encoder delay field of the header.

For the non-technical people, Gabriel: does this affect MP3 encodes? I mean, do I have to do it again with the "fixed" compile?

Sorry if this is a dumb question.

This does not affect encoding, we are just discussing about decoding changes.

Quote

What I think will be the final version of this is now at Rarewares. Includes exe, amended source files and diff files for the amendments.

I have the feeling that you are assuming that the mp2 delay is the one of current TooLame version and the mp3 delay the one of current Lame version.
Regarding mp2, this might cut the beginning of files produced with another encoder, and regarding mp3 the situation is the same unless you are reading the encoder delay field of the header.
[a href="index.php?act=findpost&pid=334080"][{POST_SNAPBACK}][/a]

Yes, the mp2 delay is that for the current tooLAME. Unless I have misunderstood, I believe that foobar uses the same value and I did assume that it should, therefore, be OK. Clearly, that could be a source of contention.

The mp3 delay I've used is the one extracted in 'lame_decode1_headersB_clipchoice' in mpglib_interface.c. Is that OK to use?

I am more than willing to be educated about these subjects!!

MP3: if you extracted the delay from the header, it should be fine.

MP2: we were using the minimum theorical encoder delay, to be sure to not cut usefull samples. Using the tooLame delay hardcoded would cut samples if you are decoding a file produced with an encoder using a smaller delay than tooLame.

MP3: if you extracted the delay from the header, it should be fine.

MP2: we were using the minimum theorical encoder delay, to be sure to not cut usefull samples. Using the tooLame delay hardcoded would cut samples if you are decoding a file produced with an encoder using a smaller delay than tooLame.
[a href="index.php?act=findpost&pid=334095"][{POST_SNAPBACK}][/a]

Thanks Gabriel. I'll put the mp2 delay back as it was and leave the user to add an encoder delay.

OK, the final, final version is now at Rarewares!!  The written decoded mp3 file now contains the correct number of samples and is of the same length as the original wave file. The console display now also indicates the number of samples being skipped at the end of the file. mp2 decoding has been reverted as it was originally.

Has the actual decoding library (MAD, mpglib, whichever) been altered?

Has the actual decoding library (MAD, mpglib, whichever) been altered?
[a href="index.php?act=findpost&pid=334639"][{POST_SNAPBACK}][/a]

It's mpglib, exactly as currently used in the standard compile. My compile simply makes use of information that the standard compile does not.

Okay, thanks for replying. Does it return bit-identical output to fb2k or did you simply mean it returns the same number of samples?

Okay, thanks for replying. Does it return bit-identical output to fb2k or did you simply mean it returns the same number of samples?
[a href="index.php?act=findpost&pid=334785"][{POST_SNAPBACK}][/a]

They appear not to be bit identical, but I suspect that has something to do with fb2k's internal processing of the samples. IIRC, fb2k massages the samples internally at higher resolution.

However, if you compare the decoded wave files with the original wave file, then they both differ from the original in exactly the same numbers and positions of missing/different samples.

Thanks again john33.

Where has the Windows version of Lame 3.97b1 gone from the Rarewares MP3 file library? (http://www.rarewares.org/mp3.html) 

The Hydrogenaudio Knowledgebase page on the recommended LAME version (http://wiki.hydrogenaudio.org/index.php?title=Lame_Compiles) states that v3.97b is what's currently recommended.

Has the recommended LAME complile gone from beta1 to beta2?

The 1st post at the top of this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=37011&hl=3.97++lame++released#) from Sep 11 2005 states that 3.97b1 was the recommended compile at that point.  Has that changed since the last post in this thread on Oct 16 2005?  Or is there just some missing link on the Rarewares page to a Windows v3.97b1 download at this point?

There was a mention of this recently here. (http://www.hydrogenaudio.org/forums/index.php?showtopic=39332&view=findpost&p=347252)  But as yet there doesn't seem to be a definitive answer.

Thx

TS

Has the recommended LAME complile gone from beta1 to beta2?

It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?

Don't hold your breath.

Regards,
Madrigal

It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?

Okay... mia culpa... an admittedly poorly thought out question.  But more to the point again... where did the Rarewares link to download 3.97b1 go... and/or where can it be downloaded now?

TS

Quote

It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?

Okay... mia culpa... an admittedly poorly thought out question.  But more to the point again... where did the Rarewares link to download 3.97b1 go... and/or where can it be downloaded now?

TS
[a href="index.php?act=findpost&pid=347939"][{POST_SNAPBACK}][/a]

There is no reason to use the beta 1 version. By definition, subsequent beta versions are bug fixes rather than new features, as indicated:

LAME 3.97 beta 2  November 26 2005

    * Gabriel Bouvigne:
          o Fixed an initialization error when input is not using a standard sampling frequency
          o Fixed a possible assertion failure in very low bitrate encoding
          o Slight change regarding ATH adjustment with V5
          o Reinstated bit reservoir for 320kbps CBR
          o ReplayGain analysis should now be faster when encountering silent parts
    * Takehiro Tominaga:
          o Fixed a possible link problem of assembly code

IIRC, the ATH change was as an attempt to correct an issue that was apparent using V5, and the remainder are really in the category of bug fixes.

The recommendation should be updated to beta 2 since, otherwise, we'll be in the position of still recommending a beta over the release simply because the release hasn't had 'n' hours of testing!!

well, there are a few quality changes to 3.97b2 that should be tested, and, of course there is always the possibility that something is screwed up unintentionally - so i can see why someone would ask the question...


later

well, there are a few quality changes to 3.97b2 that should be tested, and, of course there is always the possibility that something is screwed up unintentionally

Does that mean that there were, as you said, "quality changes to 3.97b2" that weren't part of 3.97b1?  Or is john33 correct in saying that the only changes were just bug fixes that don't affect the overall quality?

It's still odd that there's no copy of Windows 3.97b1 available on the Rarewares website (http://www.rarewares.org/mp3.html), though there are versions of 3.97b1 available for MacOS X, Linux x86, Solaris SPARC, and HP-UX on PA-RISC.

TS

The Change Log is as quoted above as between beta 1 and beta 2:

red = features and bug fixes which affect quality
blue = features and bug fixes which affect speed
black = usability, portability, other

LAME 3.97 beta 2   November 26 2005

    * Gabriel Bouvigne:
          o Fixed an initialization error when input is not using a standard sampling frequency
          o Fixed a possible assertion failure in very low bitrate encoding
          o Slight change regarding ATH adjustment with V5
          o Reinstated bit reservoir for 320kbps CBR
          o ReplayGain analysis should now be faster when encountering silent parts
    * Takehiro Tominaga:
          o Fixed a possible link problem of assembly code

It's still odd that there's no copy of Windows 3.97b1 available on the Rarewares website (http://www.rarewares.org/mp3.html), though there are versions of 3.97b1 available for MacOS X, Linux x86, Solaris SPARC, and HP-UX on PA-RISC.
[a href="index.php?act=findpost&pid=349035"][{POST_SNAPBACK}][/a]

...that's just because john33 packaged 3.97b2 quickly, while roberto hasn't repackaged for the other arches...

seriously tho, i doubt there will be much (or any) difference unless you are using -V5 or -b 320


later