Lame Command Line, Best -v0 one? Options

[db1989]

So, can someone tell me what is a difference between: -b 320 -q 0 and -V 0 -b 320 --lowpass 20.5

One is a legitimate setting and the other is nonsense? (Don't tell the Brilliant Pebbles lot about the latter though.)

This post has been edited by dv1989: Mar 21 2010, 11:30

[Steve Forte Rio]

dv1989, I understand all you talking about. But I want find out the causes of this "phenomenon" (bits wasting)

This post has been edited by Steve Forte Rio: Mar 21 2010, 11:53

[Steve Forte Rio]

Perhaps I should read some description of encoding process and mp3 file structure? Especially about frames, bitreservoir and some other interesting things?

Where I can find it?

[[JAZ]]

You want to know why an unusual setting is not optimized? Doesn't it go a bit against logic?

Try this:

-V9 --resample 44 -b320

It will also encode all frames at 320kbps. But I guess you SHOULD know what will happen.



Edit: you can find some info about the technical aspects of the MP3 format here: http://www.mp3-tech.org/

Not sure if you'll find an explanation of this, though..

This post has been edited by [JAZ]: Mar 21 2010, 11:43

[halb27]

dv1989, I understand all you talking about. But I whant find out the causes of this "phenomenon" (bits wasting)

Bits wasting to a major extent with 320 kbps frames was done by version 3.98.2. It should be gone with 3.98.3.
I guess encoding was done with 3.98.2.

This post has been edited by halb27: Mar 21 2010, 11:50

[Steve Forte Rio]

[JAZ], thank you! I'll start to learn it

About my previous questions:

I want to find where is the difference between VBR and CBR encoding process (except bitrate distribution).
When I see the same bitrate, psy model, the same ATH, noise shaping and other parameters - I don't understand why resultant vbr and cbr files are different...

Maybe causes of it, so to speak, is a bit deeper than I expected...

This post has been edited by Steve Forte Rio: Mar 21 2010, 12:05

[Steve Forte Rio]

halb27, see my previous posts. I was talking about restriction of minimal bitrate in VBR V0 mode. I'm using 3.98.3 of course...

This post has been edited by Steve Forte Rio: Mar 21 2010, 12:10

[Steve Forte Rio]

Thank you! I'll start to learn it

About my previous questions:

I want to find where is the difference between VBR and CBR encoding process (except bitrate distribution).
When I see the same bitrate, psy model, the same ATH, noise shaping and other parameters - I don't understand why resultant vbr and cbr files are different...

Maybe cause of it, so to speak, is a bit deeper than I expected...

[timcupery]

On the file posted by Steve, I would be interested to at how V0-encoded files compare to the 320 (with varying q levels). Steve, can you easily ABX this? Or /mnt?

[halb27]

halb27, see my previous posts. I was talking about restriction of minimal bitrate in VBR V0 mode. I'm using 3.98.3 of course...

Sorry, I didn't read carefully enough.
As for your real question -b 320 together with -Vx isn't meaningful (except for the case you do need a constant bitrate but want to use VBR).

What seems to be a problem in understanding is that frame bitrate is mixed up conceptually with audio data bit rate - quite a common misunderstanding unfortunately.

-Vx -b 320 just means having Lame use frame bitrates of 320 kbps. It doesn't tell about the audio data contents within the 320 kbps frames.
I remember having tried this a couple of years ago, and after mp3repacking -V0 and -V0 -b xxx yielded more or less the same bitrate (maybe it was even exactly the same).
So both -Vx and -Vx -b320 provide (more or less or even exactly) the same audio data stream provided by the VBR mechanism, but with -b 320 added it's put into 320 kbps frames, leaving a lot of space unused.

This post has been edited by halb27: Mar 21 2010, 18:37

[Diow]

as it turned out, in fact LAME didn't use 320 kbps for every frame and I've got 274 kbps (avg) bitrate after using mp3 repacker on VBR file
Repacked CBR file has 317 kbps average bitrate.

I wonder why this happens - encoder don't use all bits for encoding

That's the space reserved to padding of ID3V2...

http://www.hydrogenaudio.org/forums/index....showtopic=52216

And about the switch -q0, if you search here in HA forum you'll find some samples were it apresents lower quality than -q2, lower speed with improvements here but in other hand lower quality (and if I remember considered annoying for some)...
Use recommended settings to have "stable" quality and good speed encoding...

This post has been edited by Diow: Mar 21 2010, 19:33

[[JAZ]]

That's the space reserved to padding of ID3V2...

Sorry... what? I think you've mixed it up. ID3V2 padding is padding *inside* the ID3V2 tag so that additions to it don't cause the file to be rewriten completely.
This is a very different issue than the file having a lower average bitrate after applying mp3packer.



About the issue with -q0 that you mention, it may be outdated information.

I can't remember if it was in 3.97 or what, but the -q 0 setting got changed. Not only that, but a new -q 0 was added, and all the rest shifted by one (i.e. old -q 0 became -q 1, old -q 1 became -q 2.... and the old default -q 2 became the new default -q 3)

[Steve Forte Rio]

On the file posted by Steve, I would be interested to at how V0-encoded files compare to the 320 (with varying q levels). Steve, can you easily ABX this? Or /mnt?

It is very easy... I clearly hear much lower background high-freq noise in V0:

LAME 3.98.3 -b 320 -q 0
vs
LAME 3.98.3 -V 0

CODE

foo_abx 1.3.4 report
foobar2000 v1.0.1
2010/03/22 13:43:05

File A: D:\Samples\Show_Me_Your_Spine__Sample_b320q0.mp3
File B: D:\Samples\Show_Me_Your_Spine__Sample_V0.mp3

13:43:05 : Test started.
13:43:27 : 01/01  50.0%
13:43:31 : 02/02  25.0%
13:43:35 : 03/03  12.5%
13:43:39 : 04/04  6.3%
13:43:44 : 05/05  3.1%
13:43:55 : 06/06  1.6%
13:44:02 : 07/07  0.8%
13:44:07 : 08/08  0.4%
13:44:12 : 09/09  0.2%
13:44:18 : 10/10  0.1%
13:44:23 : 11/11  0.0%
13:44:28 : 12/12  0.0%
13:44:32 : 13/13  0.0%
13:44:35 : 14/14  0.0%
13:44:40 : 15/15  0.0%
13:44:45 : 16/16  0.0%
13:44:46 : Test finished.

----------
Total: 16/16 (0.0%)

Also, it seems like pre-echo is slightly quieter with -b 320 -q 0 (but I'm not 100% sure)

I've got almost the same results for -b 320 -q 3 (default 320 CBR mode) and -b320 -q 2 . In comparing with -V 0 of course.

halb27, see my previous posts. I was talking about restriction of minimal bitrate in VBR V0 mode. I'm using 3.98.3 of course...

Sorry, I didn't read carefully enough.
As for your real question -b 320 together with -Vx isn't meaningful (except for the case you do need a constant bitrate but want to use VBR).

What seems to be a problem in understanding is that frame bitrate is mixed up conceptually with audio data bit rate - quite a common misunderstanding unfortunately.

-Vx -b 320 just means having Lame use frame bitrates of 320 kbps. It doesn't tell about the audio data contents within the 320 kbps frames.
I remember having tried this a couple of years ago, and after mp3repacking -V0 and -V0 -b xxx yielded more or less the same bitrate (maybe it was even exactly the same).
So both -Vx and -Vx -b320 provide (more or less or even exactly) the same audio data stream provided by the VBR mechanism, but with -b 320 added it's put into 320 kbps frames, leaving a lot of space unused.

thank you! Now it's all clear for me

This post has been edited by Steve Forte Rio: Mar 22 2010, 13:04

[onkl]

In light of this thread (Changing minimum bitrate for VBR), could you test "-V 0 -b 320" anyway? I'm curious if the increased bit-reservoir improves the artifacts in comparison to cbr and default vbr.

[Sylph]

And the stereo switch will definitely cause worse results than when it's off?

[Steve Forte Rio]

-V 0 -b 320 vs -V 0

and

-V 0 vs -V 0 -m s

Do I understand correctly?

[pdq]

And the stereo switch will definitely cause worse results than when it's off?

If by stereo switch you are referring to forced stereo vs. joint stereo, then the best setting is the default setting (joint stereo). As far as better or worse, I would say that you would be hard-pressed to find examples that actually show a difference between them, especially at high bitrates, but that for encoding normal stereo material (as opposed to something like surround stereo) when there is a difference it will favor joint stereo.

[Steve Forte Rio]

In light of this thread (Changing minimum bitrate for VBR), could you test "-V 0 -b 320" anyway? I'm curious if the increased bit-reservoir improves the artifacts in comparison to cbr and default vbr.

ready. Both samples sounds very bad for me, but there are some differences between them.

LAME 3.98.3 -V 0 -b 320
vs
LAME 3.98.3 -V 0

foo_abx 1.3.4 report
foobar2000 v1.0.1
2010/03/22 17:04:31

File A: D:\Samples\tyDi-Meet Me in Kyoto_sample_v0-b320.mp3
File B: D:\Samples\tyDi-Meet Me in Kyoto_sample_v0.mp3

17:04:31 : Test started.
17:05:06 : 01/01 50.0%
17:05:13 : 02/02 25.0%
17:05:21 : 03/03 12.5%
17:05:29 : 04/04 6.3%
17:05:37 : 05/05 3.1%
17:05:45 : 06/06 1.6%
17:05:53 : 06/07 6.3%
17:06:05 : 07/08 3.5%
17:06:12 : 08/09 2.0%
17:06:20 : 09/10 1.1%
17:06:30 : 10/11 0.6%
17:06:37 : 10/12 1.9%
17:07:12 : 11/13 1.1%
17:07:25 : 12/14 0.6%
17:07:33 : 13/15 0.4%
17:07:40 : 14/16 0.2%
17:07:42 : Test finished.

----------
Total: 14/16 (0.2%)

So, I hear that first preset (with -b 320 switch) sounds slightly better...
And about *real audio data bitrate*: repacked -V 0 -b 320 has 274 kbps average bitrate while -V 0 gives 264 kbps.


P.S. Here is my new sample for pre-echo effect testing (used in above test):

tyDi-Meet_Me_in_Kyoto_sample.flac

This post has been edited by Steve Forte Rio: Mar 22 2010, 16:26

[onkl]

Thanks Steve for testing. So there is an improvement but you still like cbr320 better for this sample? Then it seems to be a tuning issue of the psy-model that causes worser artifacts for v0.

[Steve Forte Rio]

but you still like cbr320 better for this sample?

Yes, of course. But for me even CBR 320 preset sounds too bad on this sample.

[doccolinni]

as it turned out, in fact LAME didn't use 320 kbps for every frame and I've got 274 kbps (avg) bitrate after using mp3 repacker on VBR file
Repacked CBR file has 317 kbps average bitrate.

I wonder why this happens - encoder don't use all bits for encoding

Command-line flag -F enforces the minimum allowed bitrate set by the -b flag.

So try:
-V 0 -b 320 -F --lowpass 20.5

[doccolinni]

Command-line flag -F enforces the minimum allowed bitrate set by the -b flag.

So try:
-V 0 -b 320 -F --lowpass 20.5

Well since no one else tried it I decided to try it and this does produce a VBR MP3 with only 320 kbps blocks, though its size still ends up being a little bit smaller than CBR MP3 at 320 kbps (the 5:24 long sample I tested ended up being smaller by 11786 bytes as 320 kbps forced VBR than as 320 CBR).

[halb27]

It's not new, but worth considering:
When using -V0 -b 320, the fast and lossless mp3packer procedure applied afterwards can save a significant amount of disk space.
The '-b 320' added to -V0 makes better use of bit reservoir (we had that in another thread), but has the machinery unchanged in all other respects.
As a result there's a lot of plain air in the output file which is removed by mp3packer.

When struggling for high bitrate of real audio data (not just frame data) of -V0 it is necessary to make -V0 more defensive. -b 320 isn't doing this; it doesn't make -V0 want higher audio data bitrates, -b 320 just has less restrictions to achieve those bitrates -V0 wants).
My way of making -V0 more defensive is to add the options '--ns-bass -8 --ns-alto -8 --ns-treble -5 --ns-sfb21 5' apart from '-b 320'. This results in an usually unnecessary increase of signal to noise ratio but improves upon problem samples.
Current 3.99 alpha is about to improve on problem samples, but with a release version above options are the only way I can see to make -V0 more defensive.

This post has been edited by halb27: Jun 9 2010, 20:40

[doccolinni]

It's not new, but worth considering:
When using -V0 -b 320, the fast and lossless mp3packer procedure applied afterwards can save a significant amount of disk space.
The '-b 320' added to -V0 makes better use of bit reservoir (we had that in another thread), but has the machinery unchanged in all other respects.
As a result there's a lot of plain air in the output file which is removed by mp3packer.

When struggling for high bitrate of real audio data (not just frame data) of -V0 it is necessary to make -V0 more defensive. -b 320 isn't doing this; it doesn't make -V0 want higher audio data bitrates, -b 320 just has less restrictions to achieve those bitrates -V0 wants).
My way of making -V0 more defensive is to add the options '--ns-bass -8 --ns-alto -8 --ns-treble -5 --ns-sfb21 5' apart from '-b 320'. This results in an usually unnecessary increase of signal to noise ratio but improves upon problem samples.
Current 3.99 alpha is about to improve on problem samples, but with a release version above options are the only way I can see to make -V0 more defensive.

Honestly, I don't understand why everyone was so confused about -V0 -b 320 producing files with average bitrate below 320. Does anyone here know a thing about Lame command-line parameters? Has no one ever heard of this one:

• -F ― strictly enforce the -b option
  
  This is mainly for use with hardware players that do not support low bitrate mp3.
  
  Without this option, the minimum bitrate will be ignored for passages of analog silence, ie when the music level is below the absolute threshold of human hearing (ATH).

[lvqcl]

LAME (at least 3.98.x) don't use these extra bits so the difference in bitrate between "-V0" and "-V0 -b320 -F + mp3packer" is minimal.

IIRC, the difference between -V0 and -V0 -b320 (-F) is in different bitreservoir handling.

This post has been edited by lvqcl: Jun 10 2010, 00:58