Encoding mp3 VBR instead of ABR

[jordisound]

Hi. My question is about to how encode audio from a DVD movie (AC3) to mp3 in my DVDrips.
I've seen in lots of forums that people encode movies audio using ABR 128kbps, instead of VBR, because they say that the file size is most predictable. But this is not a problem if you encode audio before video!
If mp3VBR gives us better quality than ABR, why not use this method? We can use VBR and configure LAME to have a file size similar than an mp3 ABR 128kbps.
My idea is to use a command-line like this
"-V 5 --vbr-new "
But now, some questions. May I use min and max bitrate (i.e.32-160) to reduce the file size or this isn't a good idea?
What other options can I use to reduce the file size keeping quality? Lowpass filter perhaps?
Thank you for help me with the command line.
Regards!

PS: I'm testing different LAME configurations while I'm writing this. I use besweetGUI with a command line like this "C:\Archivos de programa\GordianKnot\BeSweet\BeSweet.exe" -core( -input "c:\ripeo\VIDEO_TS\inglés.ac3" -output "c:\ripeo\VIDEO_TS\inglés.mp3" -logfilea "C:\Archivos de programa\GordianKnot\BeSweet\BeSweet.log" ) -azid( -n1 -c normal -L -3db ) -ota( -hybridgain ) -lame( -m j -v --vbr-new -V 5 -p )
I will show you my results as soon as possible.

[breez]

Restricting max bitrate is a bad idea because you are losing the benefit of VBR of using higher bitrate for a difficult-to-encode passages.

[tebasuna51]

I think "-V 5 --vbr-new" is a good choice. Is used like high anchor in recent 48kbps AAC public test (http://www.mp3-tech.org/tests/aac_48/results.html)
LAME (MP3)

High anchor. Version 3.97b2, used with "-V5". This is a variable bitrate setting, providing about 130kbps on average (i.e. when encoding a lot of files, bitrate on individual files can vary)

But I agree with breez "Restricting max bitrate is a bad idea...", and for others parameters see the Lame documentation:
-b n bitrate

When used with variable bitrate encoding (VBR), -b specifies the minimum bitrate to be used. However, in order to avoid wasted space, the smallest frame size available will be used during silences.

-B n maximum VBR/ABR bitrate

The use of -B is NOT RECOMMENDED.
A 128kbps CBR bitstream, because of the bit reservoir, can actually have frames which use as many bits as a 320kbps frame. VBR modes minimize the use of the bit reservoir, and thus need to allow 320kbps frames to get the same flexibility as CBR streams.

-m s/j/f/d/m stereo mode

Joint-stereo is the default mode for input files featuring two channels..

-p error protection

Turn on CRC error protection.
It will add a cyclic redundancy check (CRC) code in each frame, allowing to detect transmission errors that could occur on the MP3 stream. However, it takes 16 bits per frame that would otherwise be used for encoding, and then will slightly reduce the sound quality.
The "-p" parameter can be useful for streaming purpose, not for backup.

I don't found documentation about "-v" parameter.

[Gabriel_Bouvigne]

The "-p" parameter can be useful for streaming purpose, not for backup.
It's only usefull when streaming over unreliable medium that can corrupt bits, but it's of no use if your only risk is to loose packets (ie when using internet)

[jordisound]

Well, I will not limit max bitrate and I will turn off error protection.
And what about Lowpass filter.
Regards

[Gabriel_Bouvigne]

Error protection is already off by default.
Lowpass is already internally adjusted according to the -Vx value used. -V5 and --abr 128 will use similar lowpasses.

[Imperial Llama]

Note: Besweet comes with the LAME 3.90 dll, not the lastest 3.97 version. Also it sets the minimum bitrate to 128kbps for all VBR modes, so you'll need to use -b 32 if you want it to behave like the CLI version of LAME.

[jordisound]

Here is the log
+-------- LAME -------
[00:00:00:000] | Bitrate method : VBR (NEW)
[00:00:00:000] | VBR Quality : 5
[00:00:00:000] | MP3 Min bitrate : 128
[00:00:00:000] | MP3 Max bitrate : 320
[00:00:00:000] | Channels Mode : Joint Stereo
Min bitrate is 128, you was right Imperial Llama!!
I may use -b 32

Well, in besweet you can choose the location of lame.exe, I have latest version of LAME 3.97b. But if besweet uses his own lame.dll why this option of location of lame.exe?
Can I replace besweet lame_enc.dll with lame_enc.dll of latest version of lame?

[tebasuna51]

Well, in besweet you can choose the location of lame.exe, I have latest version of LAME 3.97b. But if besweet uses his own lame.dll why this option of location of lame.exe?
Can I replace besweet lame_enc.dll with lame_enc.dll of latest version of lame?
BesweetGUI is discontinued and not recommended for new versions of Lame ( -v parameter is not documented now, ...), aac encoders, ...

Use Belight or command line. Of course you can replace the new lame_enc.dll in BeSweet folder.

[jordisound]

Of course you can replace the new lame_enc.dll in BeSweet folder.
Thanxs. I've done. It works.
-v parameter is not documented now
but without this command VBR doesn't works in besweetGUI.
Use Belight or command line
I've tested in BeLight and it doesn't work
-azid( -n1 -c normal -L -3db --maximize ) -ota( -hybridgain -e 0 ) -lame( -m j -V 5 --vbr-new -q 2 -b 32 )
The result is a mp3CBR32kbps :(
Well, now I know that -v is necessary for besweet. Or i'm doing something wrong.

Since I use lame3.97b dll in besweet, looking mp3 encode for testing propieties appears "mode: DC" instead of "mode: JS" . why?? I command line says -m j
Regards.

[jordisound]

brrr I've just seen this
BeSweet Commandline Reference 2006-03-21 (http://forum.doom9.org/showthread.php?t=91928)
Very interesting...
--vbr-{old|new}
Chooses the VBR mode, with --vbr-old being the older and slower standard
VBR mode and --vbr-new being the faster new mode.
Additionally this parameters requires both -v and -V in the same order as shown
in the syntax above.
-V <Quality>
Sets the quality level for VBR encoding. Possible values as integer numbers from
0 to 8. 0 stands for the highest, 8 for the lowest quality/bitrate.
Additionally this parameters requires both -v and --vbr-old or --vbr-new in
the same order as shown in the syntax above.
-v --vbr-new -V 2

This explain why -v was necessary.
Now, who one explains me why JS turns DC?

[Brother John]

Hi, jordisound.

Try again with a current BeLight (http://corecodec.org/projects/belight/). At least the newest daily build gets the new-style lame commandline right - though you'll have to add "-b 32" manually. (I've addressed the issue in the BeLight thread.)

I don't know about the JS problem. What is DC anyway? Using "-m j" shouldn't be necessary because it's default already. Which software are you using to analyse your MP3s?

Another unrelated thing: Your BeLight commandline above normalises twice (with azid's --maximize and OTA's -hybridgain) but once is enough. Usually you should use OTA. Only 6ch Vorbis or AC3 output require azid normalisation.

[tebasuna51]

@JordiSound
Sorry, you are true about the -v parameter. I mistake Lame CLI docs. with BeSweet-Lame parameters.
For BeSweet is necessary -lame( -v --vbr-new -V x ...)

About the channel mode JS <-> DC.
I make test, and with BeSweet I obtain Join Stereo and Stereo but can't obtain Dual Channel

Using -m s/j/f/d with Lame encoder 3.97b2, and after analysing the headers of output files, work OK:
lame --vbr-new -V 5 or
lame --vbr-new -V 5 -m j or
lame --vbr-new -V 5 -m f
Header field Channel Mode: 1 (Joint Stereo)
Header field Mode extension: 2 (MS)

lame --vbr-new -V 5 -m s
Header field Channel Mode: 0 (Stereo)
Header field Mode extension: 0 (not aplicable)

lame --vbr-new -V 5 -m d
Header field Channel Mode: 2 (Dual channel)
Header field Mode extension: 0 (not aplicable)

With BeSweet-lame:
BeSweet v1.5b31 by DSPguru.
--------------------------
Using lame_enc.dll v1.32 (22/12/2005), Engine 3.97
D:\Programa\Audio\besweet\BeSweet.exe -core( -input ... )
-lame( -v --vbr-new -V 5 -m j ) or
-lame( -v --vbr-new -V 5 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Bitrate method : VBR (NEW)
[00:00:00:000] | VBR Quality : 5
[00:00:00:000] | MP3 Min bitrate : 128
[00:00:00:000] | MP3 Max bitrate : 320
[00:00:00:000] | Channels Mode : Joint Stereo
[00:00:00:000] | Error Protection: No
[00:00:00:000] +---------------------
[00:00:20:000] Conversion Completed !
[00:00:20:000] Actual Avg. Bitrate : 108kbps
Header field Channel Mode: 1 (Joint Stereo)
Header field Mode extension: 2 (MS)

-lame( -v --vbr-new -V 5 -m s )

[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Channels Mode : Stereo
[00:00:00:000] +---------------------
[00:00:20:000] Actual Avg. Bitrate : 110kbps
Header field Channel Mode: 0 (Stereo)
Header field Mode extension: 0 (not aplicable)

-lame( -v --vbr-new -V 5 -m f ) or
-lame( -v --vbr-new -V 5 -m d )

[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Channels Mode : Dual Channel
[00:00:00:000] +---------------------
[00:00:20:000] Actual Avg. Bitrate : 173kbps
Header field Channel Mode: 0 (Stereo)
Header field Mode extension: 2 (? not aplicable)
For me -m j and -m s works OK, but -m f and -m d don't work properly.
Forced joint stereo (f) and Dual Channel (d) give me a stream marked like Stereo but with a bitrate greater than the correct Stereo.

[Gabriel_Bouvigne]

Forced joint stereo (f) and Dual Channel (d) give me a stream marked like Stereo but with a bitrate greater than the correct Stereo.
It's normal that -m f and -m d are producing higher bitrate than joint stereo.
I would advise you to only use the default mode (it should be joint stereo)

[tebasuna51]

It's normal that -m f and -m d are producing higher bitrate than joint stereo.
I would advise you to only use the default mode (it should be joint stereo)
Sure, I only use default mode (Joint stereo) for real jobs.

The test is only to explain the strange behavior of these switches inside BeSweet-lame, and completely opposed to Jordisound results (with -m j he obtain DC, I suppose Dual Channel).

[jordisound]

Besweet log show Joint Stereo
Channels Mode : Joint Stereo
But analysing with Encspot, or mp3InfoExtension says Dual Channel.
Let me try another commandline and i'll show you results.

Another unrelated thing: Your BeLight commandline above normalises twice (with azid's --maximize and OTA's -hybridgain) but once is enough. Usually you should use OTA. Only 6ch Vorbis or AC3 output require azid normalisation.
In OTA options I use Hibridgain, and in azid options I use normalize 100% (--maximize). Both commands do the same? In that case I have to use only hybridgain, have I?

[Brother John]

Sorry, I too can't reproduce your dual channel problem using BeSweet 1.5b31 and Lame 3.97 beta 2 (http://wiki.hydrogenaudio.org/index.php?title=Lame_Compiles).

Lame commandline was:
-lame( -v --vbr-new -V 6 -b32 )

Which results in this:
+------- BeSweet -----
| Input : test.wav
| Output: testBS.mp3
| Floating-Point Process: Yes
| Source Sample-Rate: 44.1KHz
+-------- LAME -------
| Bitrate method : VBR (NEW)
| VBR Quality : 6
| MP3 Min bitrate : 32
| MP3 Max bitrate : 320
| Channels Mode : Joint Stereo
| Error Protection: No
+---------------------
Conversion Completed !
Actual Avg. Bitrate : 110kbps

And examined with foobar and Encspot:
mp3_stereo_mode = joint stereo
Mode joint stereo
Adding "-m j" to the commandline results in bit-identical files. And same results for "--vbr-old".
Try adding "-s stereo" (or "-s dpl" or "-s dplii" if you want dolby surround) to your azid commandline to enforce correct downmix mode.


Both commands do the same? In that case I have to use only hybridgain, have I?
They don't do exactly the same. --maximize is pregain normalisation and hybrid is a mixture of pregain and postgain. Have a look at the reference for all the details.

[jordisound]

I too can't reproduce your dual channel problem using BeSweet 1.5b31 and Lame 3.97 beta 2
I'm using BeSweet 1.5b29.

I have aswers.

First: if JS is default mode, isn't necessary -m j
-azid( -n1 -c normal -L -3db --maximize ) -ota( -hybridgain ) -lame( -q 2 -v --vbr-new -V 5 -b 32 )
bitrate 142kbps
mode DC
But I was wrong!!, mode is DC. Again!!

Second: why use -q 2?
azid( -n1 -c normal -L -3db --maximize ) -ota( -hybridgain ) -lame( -v --vbr-new -V 5 -b 32 )
bitrate 83kbps
mode JS
The key was -q 2. Without this, mode is JS

New test -V4
bitrate 96kbps
mode JS

New test -V3
bitrate 106kbps
mode JS

New test -V2
bitrate 115kbps
mode JS

New test -V1
bitrate 132kbps
mode JS

New test: ABR128(--abr 128 -b 32 )
bitrate 119kbps
mode JS

Well, don't forget the objective of this experiment: get an VBRmp3 near 128kbps to compare to ABR128. In this test, the winner was -V2. I choosed a DVDmovie poor of sound (year 80's, no music, no explosions, etc.) audio was very poor. The next test will be DVDmovie AC35.1 with audio most difficult to encode (year2005, lot of explosoins, lasers, action, etc), and bitrates will be higher, sure!

I'll give you more details and conclusions this weekend. I will open new thread then.
Best regards!


PD: Brother John, I have readed the reference. I should use only -hybridgain, should I?