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: CBR/VBR, Joint Stereo, and -q (Read 8363 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CBR/VBR, Joint Stereo, and -q

Hello everyone! This is my first post here on hydrogenaudio.

I have been using lame 256 cbr for a while now without ever questioning - until I found this forum. Now I can see I've clearly been encoding incorrectly.

I've spent much time looking through threads to learn about the differences between CBR and VBR, how Joint Stereo works and the often confusing -q switch.

3 questions have popped up since I've gone through many,many threads. I was hoping for answers from people  that are highly respected on this board (dibrom, gabriel, johnv, user). I believe the answers to these questions will probably make a great addition to the wiki in regards to 'newby' questions.

Note that these questions all deal with (-V0,-V1,and -V2)

1. CBRvsVBR: I'm concerned with loss of quality. For each frame at -V2 'and above', will there be any audible difference in quality between CBR (256). Specifically, CBR 256 will give each frame a bit rate of 256, and I understand that VBR will allow the bitrate to change to the needs of the sample. But, on samples that VBR drops below 256, is there a 'degrade' in quality(audibly compared to C256) - or is the dropping of the bit rate 'transparent'?

2. Joint Stereo: I'm worried about stereo separation. At -V1 many of my songs yield a high percentage of Mid/Side frames. I've read that the JS method is a lossless transform (lossless before encoding), so my main question is on the decode of MS frames, will MS be able to reproduce Left and Right that match the original wave?

3. -q (and --vbr-new): Yikes! throw this one in the mix and I get confused. With lame 3.97, how does --vbr-new stack up to --vbr-old? Is there still some issues with --vbr-new producing lower-quality samples than --vbr-old? And Finally, does -q default to something with -V[2|1|0]? How about with "-V[2|1|0] --vbr-new"?

Thanks so much for any answers - this forum has already helped me quite a bit!
"In the computer.... it's so simple"

CBR/VBR, Joint Stereo, and -q

Reply #1
... 1. CBRvsVBR: ...
2. Joint Stereo: ...

1. When using VBR you let the encoder decide on the appropriate frame bitrate. If it's not necessary it will use a low bitrate, if necessary it will go high in bitrate. The encoder does it intelligently, and that's why most users who are conscious of this feature do it the VBR way. A bit overseen is the fact that even CBR with its constant frame bitrate uses a variable audio data bitrate (though within the restricted framework of bit reservoir).
Audio data bitrate variation with CBR however is technically different from that of VBR. VBR's bitrate variation is based on the psy model, so you get all the adantages resulting from a good psy model. But you also get the (rare) weaknesses. When the psy model is inaedquate (which happens rarely) this weakness is amplified when using VBR. CBR audio data bitrate variation is more primitive and does not have the specific strengths and weaknesses of VBR. Roughly speaking VBR is most welcome in the medium bitrate range giving the encoder the chance to go very high in bitrate if necessary. At very high bitrate ~256 kbps however, VBR cannot play the same rule cause frame bitrate cannot exceed 320 kbps in practice, so VBR is questionable with such a high bitrate. CBR does the job more or less the same and does not suffer from those rare situations where VBR produces an inadequate result.
Moreover there's ABR. ABR uses the same audio data bitrate variation principle as CBR but is not restricted to the technical details of bit reservoir.
Practically speaking with Lame 3.97 there are tonal problems with VBR even with -V0. With CBR or ABR very high bitrate it's at least a minor issue.
With Lame 3.98b5 VBR has considerably improved. There's still a problem left (something like an artificial tremolo on specific tracks) which doesn't exist with CBR/ABR, but compared to the 3.97 issues this is an absolutely minor problem.
Anyway using CBR256 was not at all a bad idea as you do want to use very high bitrate. With 3.98b5 at ~190 kbps I'd prefer -V2.

2. You needn't be afraid of Joint Stereo. From time to time some fear comes up against Joint Stereo, but I haven't seen a single real Joint Stereo issue for Lame since I started to be a member here. Usually you read more or less strange reasoning without real experience.
lame3995o -Q1.7 --lowpass 17

CBR/VBR, Joint Stereo, and -q

Reply #2
The other thing with cbr is that on near-mono or mono signals the bitrate is up to twice what it should be which is kinda retarded for lossy encoding - even lossless is vbr and more efficient in this regard.
wavpack hybrid 256k -hx4

CBR/VBR, Joint Stereo, and -q

Reply #3
My advice is to ignore things like -q and vbrold/new and just go with whatever is defaulted for -V0/1/2 etc. for whichever version you are using. Probably stick with version 3.97 for now, 3.98 when it becomes the recommended version. Anything else that you apply, unless you take the time to really understand all of the issues, has as good a chance of decreasing quality as increasing it.

CBR/VBR, Joint Stereo, and -q

Reply #4
If you've never tested your transparency threshold with a meaningful method like ABX, you should give it a try. Trying to ABX files at V5 will likely give you a heap of confidence in V2...

CBR/VBR, Joint Stereo, and -q

Reply #5
Hi guys!
Thanks for the response.

So... For Lame 3.97: CBR256 vs. -V1 vs. -V0. Any votes? I guess if V1 and CBR256 is equivalent - I'll go with V1.

In regards to Joint Stereo... so will the stereo separation have the same separation as the CD?

With -q/--vbr-new/--vbr-old, If I use VBR, sounds like I'll just stick to "-Vx" and not worry about other settings. For CBR, maybe just "-b 256 -h"?

Thanks - You guys are great!
"In the computer.... it's so simple"

CBR/VBR, Joint Stereo, and -q

Reply #6
Hi guys!
Thanks for the response.

So... For Lame 3.97: CBR256 vs. -V1 vs. -V0. Any votes? I guess if V1 and CBR256 is equivalent - I'll go with V1.

I would because -V1 would be more efficient.  That or use ABR 256 as it will be theoretically more efficient than CBR.  LAME doesn't break that much anymore as IMO it's tuned very well.  I generally can't ABX -V5 on a lot of things.

In regards to Joint Stereo... so will the stereo separation have the same separation as the CD?

Being that the L/R -> M/S transform is lossless nothing will happen to the stereo image unless you find some rare encoder bug which I doubt you will.  LAME's joint stereo is very well tested and that is why it is the default.

With -q/--vbr-new/--vbr-old, If I use VBR, sounds like I'll just stick to "-Vx" and not worry about other settings. For CBR, maybe just "-b 256 -h"?

Thanks - You guys are great!

-q settings don't do anything to --vbr-new.  Generally it's recommended to just leave these alone.  It defaults to -q3 which is the old -q2.  I use --vbr-new but it's up to you what you decide to use.  Both are of high quality.

To be honest with you at the bitrates you're talking about everything is more than likely to be transparent, so no matter which way you should be fine.
Nero AAC 1.5.1.0: -q0.45

CBR/VBR, Joint Stereo, and -q

Reply #7
I would suggest that you read my post "mp3, m4a - how close to the original sound they are".
Here, you can find quantitative evaluations for some results obtained with different encoding parameters.

CBR/VBR, Joint Stereo, and -q

Reply #8
is there ever a situation when joint stereo is not recommended?

 

CBR/VBR, Joint Stereo, and -q

Reply #9
is there ever a situation when joint stereo is not recommended?

I would avoid its use with surround-sound encoded material.

 
SimplePortal 1.0.0 RC1 © 2008-2021