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 3.96 crashes on --vbr-mtrh (Read 12983 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.96 crashes on --vbr-mtrh

Reply #25 –
Quote
would you like to try this one?
lame test compile

Quote
M:\Laufwerke\HD1P1 (Win98)\lame>lame --preset 112 --vbr-new lamecrash.wav lame.mp3
LAME version 3.97 MMX (alpha 1, May 26 2004 23:44:30) (http://www.mp3dev.org/)
warning: alpha versions should be used for testing only
CPU features: MMX (ASM used), SSE
Using polyphase lowpass filter, transition band: 17960 Hz - 18494 Hz
Encoding lamecrash.wav to lame.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=3
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
     3/6      (50%)|    0:00/    0:00|    0:00/    0:00|   1.3061x|    0:00
32 [1] *********************************
40 [0]
48 [0]
56 [0]
64 [0]
80 [0]
96 [0]
112 [1] *********************************
128 [0]
160 [1] *********************************
192 [2] ******************************************************************
224 [1] *********************************
256 [0]
320 [0]
average: 152.0 kbps                    MS: 6 (100.0%)

Writing LAME Tag...done
ReplayGain: +0.9dB


Works.

Lame 3.96 crashes on --vbr-mtrh

Reply #26 –
Quote
lame test compile

Did some testing. With:

--preset 112 -b 80 --vbr-mtrh --athaa-sensitivity 1 -q 1

it averages on ~180 kbps (average of 3 tracks). This is way too high.

Lame 3.96 crashes on --vbr-mtrh

Reply #27 –
your command line is pretty much confusing me.
do you want abr or vbr?

Lame 3.96 crashes on --vbr-mtrh

Reply #28 –
Hmmm. I want abr, I wanted to have control over filesizes. And as abr IS variable bitrate I thought its legitimate to use --vbr-new. Is it not? Does abr + vbr-new in one command line make no sense? I wanted vbr-new for faster calculation.

And btw, does abr make an approximation over the complete file in order to achieve the desired average bitrate?

Lame 3.96 crashes on --vbr-mtrh

Reply #29 –
I am pretty sure that the VBR algorithm is not used in ABR. As I have understood it ABR is pretty much like CBR but without bit reservoir constraints. Can someone confirm this? In that case your commandline makes no sense.

And I am also pretty sure that ABR already is considerably faster than VBR.
EDIT: If you need faster encoding than that, you may consider GoGo.

So why not stick with --preset 112? Chances of doing worse with a homemade commandline is far greater than doing better.

ABR does not go through the entire file to distribute bitrate, it is one-pass only.

Lame 3.96 crashes on --vbr-mtrh

Reply #30 –
Quote
So why not stick with --preset 112? Chances of doing worse with a homemade commandline is far greater than doing better.

ABR does not go through the entire file to distribute bitrate, it is one-pass only.

I'm testing. I try to achieve smallest files and transparancy in sound for my wives car stereo (which hasnt got the best loudspeakers). The main goal is filesize.

ABR is one pass? How can it approximate a desired bitrate then? IMHO it needs to do a quick look on the file at least once.

Lame 3.96 crashes on --vbr-mtrh

Reply #31 –
How about testing different -V settings?
-V 4 --vbr-mtrh should be pretty close to what you want.
"To understand me, you'll have to swallow a world." Or maybe your words.

Lame 3.96 crashes on --vbr-mtrh

Reply #32 –
Quote
Quote
So why not stick with --preset 112? Chances of doing worse with a homemade commandline is far greater than doing better.

ABR does not go through the entire file to distribute bitrate, it is one-pass only.

I'm testing. I try to achieve smallest files and transparancy in sound for my wives car stereo (which hasnt got the best loudspeakers). The main goal is filesize.

ABR is one pass? How can it approximate a desired bitrate then? IMHO it needs to do a quick look on the file at least once.

OK, that's fine. Just want to make sure you read my sentance:
"Chances of doing worse with a homemade commandline is far greater than doing better."
Why? Because Lame has so many switches you can mess with. Many of them were put there for developers to be able to tune Lame without having to recompile. Lots of them shouldn't be touched if you do not understand what they do.

The presets have been tuned and tested very extensively, so chances that you will be able to beat them with your own commandline is very small.

ABR is one pass. Well, here is how I think it works, anyone please confirm or correct me. In CBR there is something called bit reservoir. When a frame is to be encoded to say 128 kbps, the encoder may not match this exactly. In some frames there will be empty space, and in some the data just won't fit. So what the encoder can do when there is to much data, is to move this to a frame where there is empty space. How this works in detail I have no clue, but it is referred to as the bit reservoir.

The problem is that there is not always enough space in the bit reservoir when doing CBR. My guess is that in ABR this is skipped and the frame size is instead adapted to what the encoder wants.

Anyone wanna comfirm this, or correct me?

Lame 3.96 crashes on --vbr-mtrh

Reply #33 –
ABR is the same thing as CBR with an unlimited bit reservoir (emulated by changing frame sizes)

Lame 3.96 crashes on --vbr-mtrh

Reply #34 –
Quote
--preset 112 -b 80 --vbr-mtrh --athaa-sensitivity 1 -q 1

it averages on ~180 kbps (average of 3 tracks). This is way too high.

Just in order to clarify: this command line is VBR, not ABR. To have ABR, you should remove --vbr-mtrh.