VBR vs Constant Quality

[next]

@ poopy

well.. umm.. i've used 224kbits before, sure, but only very infrequently. mainly for music VCDs where the sound quality has to be foremost, and keeping to standards is prefereable too. My preferred encoder at the moment is almost indistinguishable from CD at 224k except on a few 'problem sounds' (like most encoders have), both perceptually and technically (soundgraph etc). Lower qualities i have little trouble with, if they're filtered right. It does get a bit ropey from 160k down, but if i sacrifice some treble it comes out acceptably. 128k with a bit of care sounds like 224k in old TMPGenc and i even used 112k on a movie encode where the source Mp3 wasn't so hot - and space was tight.

160 (with filtering to a little better than 128k mp3 equivalent) or 192k (without bothering much to filter) usually sound damn good, certainly enough for playing through a TV and/or a modest stereo (when i get something that will make it sound horrid, i'll be able to afford the actual DVDs, and/or a DVD burner). The current state of most mp2 encoders is a little slack, either poor output, really slow, or both, but im sure ive pounded on too much about that already... and im not a programmer or audio/maths graduate so cant rightfully bitch.

------

@ next: word. it's all about your own experiences and comparing them to other peoples, in the end.

Thank you. You get it. No argument here.

[poopyhead]

@next,

invariably given the same source, output will be extremeley variable...

even different versions of the same program...maybe released just months apart can have very different outputs...

not to mention variability between different encoders, frameservers, etc...

thus, it's kinda hard to really talk about the "real-world" because everyone uses different versions of different proggies at different times w/ slightly different settings.

"theory" is just a general statement...just like the guides...they can't be taken word-for-word as there will always be exceptions.

[next]

@next,

invariably given the same source, output will be extremeley variable...

even different versions of the same program...maybe released just months apart can have very different outputs...

not to mention variability between different encoders, frameservers, etc...

thus, it's kinda hard to really talk about the "real-world" because everyone uses different versions of different proggies at different times w/ slightly different settings.

"theory" is just a general statement...just like the guides...they can't be taken word-for-word as there will always be exceptions.

Yes

invariably.

[dwiesel]

I know this topic is for VCD's, but do the CQ / VBR / CBR rules apply to to DVD's as well? I think so, but better to be safe than sorry...thanks.

[Gazorgan]

I used to be a hardcore multi-pass VBR proponent. That was when I had to hit 800/1600/2400 MB file sizes. Now that I do mainly DVD, I use CQ. It's a lot, lot faster, and I can't tell the difference in quality on any TV under 27 inches.

As to file size? Well they pretty much hit what I set them to based on bitrate. Not exactly but within a few % points or so. Since I target my DVD's to 4000 MB, I always have room for the menu and a little over-run

[rhegedus]

Some gas on the fire.....

battle of the CBR/VBR/CQ modes

For VHS conversions to DVD, I tend to use VBR (max and min are 20%+/- average respectively) over CBR unless the bitrate is sufficiently high (over 4000kbps for half D1) not to warrant an extra pass, all with motion search precision set to normal.

For VCD or SVCD disks I always use VBR, irrespective of the bitrate. Even if tere is no difference between the average, max and min bitrates (i.e. they are equal), the extra pass seems to be beneficial.

[adam]

2-pass VBR adjusts the quantization value according to the average bitrate set. It essentially allows "quality" to vary from scene to scene to attempt to allocate bitrate where needed most. I put quality in parenthesis because it is not actually quality we are talking about, we are talking about quantization. Essentially it is the amount of data thrown out, so obviously a lower amount is better.

Constant quality is actually a minomer. A more accurate name would be constant quantization. It just takes your set quant level and applies it to the entire movie and then adjusts the bitrate around this, which is why the bitrate and filesize are unpredictable without running a series of predictive tests.

The ultimate goal is to store our motion vector information as accurately as possible, and to get the most accurate DCT compression as possible. Which of these two methods does these best? I know better than to argue that one. It will actually depend alot on the source and your settings. Neither method is necessarily better or worse than the other and they will both produce nearly indistinguishable results at high bitrate. Generally, the 2-pass vbr will have higher or lower quantization levels on any given scene, but overall the avg should be lower than that of CQ.

Now the more important issue is that CQ operates in 1 pass and 2-pass VBR operates in 2. That is where the real difference is. Multiple passes allow the encoder to recalculate quantization values using past information, and to better recognize motion. So in this sense, 2-pass VBR is superior to CQ, and in my opinion it generally does produce better results. Everyone's mileage will vary.

If you are really a constant quantization fan then you will love CCE. It allows you to do the equivalent of "CQ" in as many passes as you want. Just keep running the 1 pass VBR encode at the same Q value.

The author of TMPGenc never said CQ was higher quality, or anything of the sort. I can only assume you are reading the tooltip which suggests using CQ when quality is of the utmost concern. Obviously this says nothing more than that CQ allows for you to set the desired quality level and let the bitrate fluctuate to achieve it, whereas with other methods you have to choose a correct bitrate value in order to reach this target quality level. If the files are ultimately targeted for the same size media (when aren't they?) then obviously your filesize is going to be a constant factor so you are always shooting for the same result. 2-pass VBR will guarantee that hit your target size, and it should give you about the most efficient Quantization levels to get there. CQ can probably give you about the same results in about half the time, but since it is inherantly only a 1-pass VBR method it has its limitations which you may or may not notice.

So to summarize, CQ and regular VBR are just different algorithms. One uses quant value as the constant and bitrate as the variable, and the other does the opposite. Neither algorithm is necessarily better than the other, however TMPGenc's CQ mode only offers 1 pass which is a disadvantage.

[RabidDog]

And do all these arguments still hold true for encoding to avi (divx).. obviously with bitrates much lower.

[adam]

Sure.

[aamir12345678]

Since I've heard so much about TMPGEnc's CQ method being superior to it's 2-Pass VBR, I just have to ask: Are there settings that can make TMPGEnc's 2-Pass VBR behave more efficiently, or is the notion of TMPGEnc's CQ being better than its 2-Pass VBR just a completely false one? Sorry if this debate was over, just gotta know! Time is not an issue to me. I can set it overnight and let it encode; plus, I have a pretty fast processor and plenty of memory.

[energy80s]

With TMPG CQ encoding offers better quality video than VBR multipass. With CCE its the other way round. The benefit of CQ over VBR in TMPG is that it only takes half the time. The only problem is that you can't accurately predict the final file size of a CQ encode.

[offline]

aamir12345678
Are there settings that can make TMPGEnc's 2-Pass VBR behave more efficiently

Yes, in fact a 30%+ increase in speed but you need a single Intel
P4, Intel Xeon or a dual AMD cpu setup to take advantage of it.

[offline]

aamir12345678
Are there settings that can make TMPGEnc's 2-Pass VBR behave more efficiently

Yes, in fact a 30%+ increase in speed but you need a single Intel
P4, Intel Xeon or a dual AMD cpu setup to take advantage of it.

[aamir12345678]

I wasn't asking about the speed of TMPGEnc. I was asking if there are settings in TMPGEnc that could make its 2-Pass VBR behave more efficiently regarding the quality of the output.

[rhegedus]

With TMPG CQ encoding offers better quality video than VBR multipass. With CCE its the other way round. The benefit of CQ over VBR in TMPG is that it only takes half the time. The only problem is that you can't accurately predict the final file size of a CQ encode.

Out of curiosity, if you calculated the average bitrate of a TMPGEnc CQ encode and then used that bitrate to form the average bitrate of a TMPGEnc 2-pass VBR encode, would CQ still come out better?

[aamir12345678]

I'm actually trying that out right now. I always have TMPGEnc make a log file. It tells at the end what the average bitrate of the video is. I've plugged that into 2-Pass VBR.

[offline]

I was asking if there are settings in TMPGEnc that could make its 2-Pass VBR behave more efficiently regarding the quality of the output.

My error.

If your source is VHS video, you can frameserve it using avisynth
settings and filters to reduce noise, interlacing (if present) and black
level issues which all, if left unchecked, make 2-pass VBR less efficient
by over allocating bitrate (quality errors) in scenes that otherwise can
run closer to average bitrate settings at no quality cost.

[aamir12345678]

Thanks for the tips, Offline, but I figured out my own problem. I failed to mention that my source is a high-quality DIVX file (about 1500 kbit/s). All I wanted to do was maintain the qaulity. I did a CQ 100, set the minimum to 2000, and the maximum to 9600. It did not give me results the same as my DIVX source file. Someone told me it was because you almost always degrade visible quality by reencoding, so it WONT be as good as the orginal. However, just for experimental purposes, I tried the average bitrate my CQ 100 produced and plugged it into 2-Pass VBR. It worked. CQ, at Highest Motion Search Precision, cannot compete with 2-Pass VBR at Highest Motion Search Precision. The results were better at the same exact file size. I gave the minimum bitrate 0 (automatic). I think with TMPGEnc, this is what you have to do unless you can make the minimum and maximum and even amount away from the average. Since I'm using a high average (6700 kbit/s), and DVD Players top out at about 9600-9800 kbit/s for the video, and I really don't want a minimum of about 3700 kbit/s (way too high), a minimum of 0 is best. It produced near flawless results. In some ways, the image looks better than the DIVX file.

[dwiesel]

Aamir12345678, very interesting...I need to try this...I'm sorry, I'm still a little confused...what did you plug into VBR for max and average rates? Where does the 6700 fit in exactly?

Thanks!

[aamir12345678]

When I did my CQ 100 for one of my Divx, it gave me that for the average bitrate. I even did Highest Quality Motion Search Precision. Remember that in CQ mode, the encoder tries to maintain the level of quantization you choose. If you go all the way to CQ 100, set the minimum to 0 and the max to the DVD upper limit (9600-9800), TMPGEnc should give your movie the average bitrate after which everything will truly be "overkill." People suggest that (CQ 100) = (CBR of the Maximum Bitrate). That really just depends on the movie and the max bitrate that you select for the CQ encode, and VERY FEW, if any, movies require the DVD upper bitrate limit as an average bitrate to look good. CQ is a good testing utitlity for those who want to fit maximum quality and runtime onto a CD-r or DVD-r, but 2-Pass is better than 1-Pass any day, so I then look at how much space I have, and calculate what bitrate I can give the movie, and encode with a 2-Pass VBR.

[dwiesel]

Ah…I see what you mean in terms of the overkill. One more quick question though: your average bitrate of 6700 from CQ…when you go to use 2-pass VBR, you mentioned using the default 0 for min bitrate…what bitrates are you setting your max and average to? Both to 6700? Sorry to be a pain, but I want to get the same great results as you.

[aamir12345678]

Hey, no problem. I set the low to 0, the average to 6700 (just replace with whatever CQ 100 value you got), and the max to 9600-9800. I don't know which one is the actual video DVD max, so I just go with 9600 to be safe.

[dwiesel]

Thank you very much!

[DiablosuX102]

mainconcept with 2-pass vbr makes awesome quality for me. fast as hell too.

josh

[DiablosuX102]

Hey, no problem. I set the low to 0, the average to 6700 (just replace with whatever CQ 100 value you got), and the max to 9600-9800. I don't know which one is the actual video DVD max, so I just go with 9600 to be safe.

i think that the max video bitrate depends on the audio bitrate...like if its pcm i think the video bitrate has to go a good bit lower.

[aamir12345678]

One final note. TMPGEnc's 2-Pass VBR, at high bitrates, does not behave like a normal 2-pass VBR. You may need to get familiar with & change accordingly the P & B picture spoilage settings and the like. I think what TMPGEnc does is that it analyzes each scene to determine how much bitrate it needs. Then, BASED ON THE QUALITY TMPGENC THINKS YOU DESIRE FROM YOUR MINIMUM, AVERAGE, & MAX, AND P & B PICTURE SPOILAGE SETTINGS, it will actually - behaving like a CQ - determine an average bitrate. This is precisely why your average bitrate might be different from the one you set. A min of 0, a very high average of around 7000, and a max of 9600-9800 confuses TMPGEnc. There is a lot more difference between the min & average than average & max. You can also try to not have any B pictures at all. This is not an issue with VCD & SVCD bitrates; it only poses a problem with DVD bitrates and only when the minimum & maximum are not an even amount away from the average. Many people mistake this as a weakness of TMPGEnc's 2-pass, but all it means is that TMPGEnc doesn't follow the rules a regular encoder follows. Furthermore, TMPGEnc comes with no manual, just a little help file.

[dwiesel]

I think you said it all: if TMPGenc had a detailed and proven manual on all it’s settings and how they all work together, along with recommendations, there wouldn't be such wide-spread speculation and theorizing (and hours of testing)…because if we're wrong we're just propagating false information. I want a manual!!

[aamir12345678]

me too!