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: Lame Command Line (Read 29477 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame Command Line

Reply #25
Quote
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.)

Lame Command Line

Reply #26
dv1989, I understand all you talking about. But I want find out the causes of this "phenomenon" (bits wasting)
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #27
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?
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #28
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..

Lame Command Line

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

Lame Command Line

Reply #30
[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...
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #31
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...
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #32
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...
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #33
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?
God kills a kitten every time you encode with CBR 320

Lame Command Line

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

Lame Command Line

Reply #35
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...
Sorry for my bad english.

Lame Command Line

Reply #36
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)


Lame Command Line

Reply #37
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: [Select]
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
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #38
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.

Lame Command Line

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

Lame Command Line

Reply #40
-V 0 -b 320 vs -V 0

and

-V 0 vs -V 0 -m s

Do I understand correctly?
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #41
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.

 

Lame Command Line

Reply #42
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


Quote
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
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #43
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.

Lame Command Line

Reply #44
Quote
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.
🇺🇦 Glory to Ukraine!

Lame Command Line

Reply #45
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

Lame Command Line

Reply #46
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).

Lame Command Line

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

Lame Command Line

Reply #48
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:

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

Lame Command Line

Reply #49
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.