battle of the CBR/VBR/CQ modes

[dvd2svcd]

It is easy to prove which is best x-pass vbr or CQ.

Make a movie using any given CQ value. That will result in a MPG file of a given size. Now calculate the bitrate needed to get that file size. Do it all over again using VBR and the calculated bitrate.

The fixpoint must be the filesize.

The final result will be two MPG files equal in size (no matter what the size). Compare those two and see what looks the best.

I'm not keen on theory and the technical issues. I use my eyes.

[banjazzer]

To tell the truth, I can't think of any better argument regarding the superiority of multi-pass encoding than the fact that CCE costs $2000 to get that feature, and greater than 2-passes is only possible in TMPGEnc with the most expensive version.

I haven't used CCE, but I seem to recall some evidence that not all of its modes are superior to those of much cheaper encoders. What I do know, though, is that price is not always an indicator of quality, specifically with the bloatware from some companies - Roxio springs to mind! 8)

BTW I have the full TMPGEnc Plus, and I cannot see any option for more than 2 passes.

[kinneera]

I haven't used CCE, but I seem to recall some evidence that not all of its modes are superior to those of much cheaper encoders. What I do know, though, is that price is not always an indicator of quality, specifically with the bloatware from some companies - Roxio springs to mind! 8)

CCE is at least honest about what it doesn't do well (MPEG1) - read CCE's documentation. I think it is fair to say that price is some indicator of quality here, though, in regards to MPEG2 and multipass (many will attest to it empirically), although $2000 is clearly a business targeted price.

BTW I have the full TMPGEnc Plus, and I cannot see any option for more than 2 passes.

I'm talking about their server edition. It's on the pricing scheme on the distributor company's website, although I don't know if it has actually been released.

[Peter]

Adam- first off `CHILL WINSTON`

BUT in many cases these distortions(eg lack of sharpness&blocks) are visable, and I have found using CQ in Tmpgenc with Planet of the apes I can fit all 1hr54mins on 3 CDs with a better quality at least to my eyes than a 2passVBR (3CD).

Many times I find the situation reversed and I prefer VBR-Xpass. Again depends on the source.

I was reading the thread, but this I cannot believe.
It almost impossible to fill 3 CD's fully with CQ, you don't want to encode more than 1 time, then you loose the advantage of CQ over VBR multipass. With VBR multipass you can fill CD3 also completely, so your total file will be bigger. And for sure the OVERALL quality will be higher.

Every post where someone says CQ looks better, the CQ file is bigger, so that's why it looks better.

And if you say the size doesn't matter and cd's are cheap, just copy the source file and burn it. Maybe you need 5 or 6 cd's, but no quality loss. What do you do when you use CQ and you can (over)burn 3 cd's and still have 20 MB left?

[banjazzer]

Peter

Hey! - we can all do whatever we like. There is no intent here to get everyone to use the same methods. If having a part of one CD blank bothers you, then by all means go for 2-pass VBR. My main gripe with 2-pass VBR is the time it takes. CQ may or may not be better quality per given filesize, or vice versa. I've not done the tests, nor will I likely get time to do the tests. I am perfectly happy with the quality yielded by both methods, and only really felt the need to persist with this thread because of the vehemence of those evangelising one method at the expense of the other. 8)

[Greyhair]

It only seems obviously intuitive to me. With CQ you inefficiently allocate bitrate. With 2 pass VBR you more efficiently allocate bits. In real terms, I'm not sure most of us can say that "size doesn't matter". It virtually always matters from what I can see. And you can't get away from the most basic premise of digital video, that file size and quality are inextricably linked. So if part of the quality equation for you is file size, and I think it is for most of us, then 2 pass VBR would be superior. If you are a person where, for whatever reason, file size doesn't matter, then hang with CQ.

[injunpana]

So much for not wasting your breath, what with your long discourse.

To say CQ isn't concerned with bitrates is pure idiocy - all encoding is concerned with bitrates

Read my post again. I never said that. I said people insist on sticking CQ with average bitrates and comparing it with VBR. Sure you can use average bitrates as a measuring stick with VBR because that's the parameter it works on. You can't do that with CQ because its working on a different parameter and that's quantisization. If you try to graph quantisization as against bitrates in CQ and exxagerate it, you would see quantization in a more or less straight line while running along side it would be a varying bitrate line with spikes, dips, slopes or maybe even level line. In VBR, it would be the other way around. Exagerated, the graph would show a level bitrate line with the quantization line varying.

Quote:

Your proposal is just like saying, "what if we turn it around and say that you run your 2-pass VBR, then we get the average quantisization and use that quantisization and run it by CQ?"

Well of course this is nonsensical because you would be using 2-pass to achieve higher quality in a limited storage space, not quality at any cost. But to answer your question, the two pass would produce a more efficient bitrate allocation at the specified bitrate, and thus a better average quantization (funny how those extra passes are useful like that) and so the CQ would produce either a somewhat lower quality video or a somewhat larger file if you did that.

I cited 2-pass as an example because do you or anyone really use 1-pass? Okay then, let's get the quantization average of 1-pass or how- many-pass VBR you want and use that in CQ. It is still nonsensical isn't it? So what does that say about what you said of getting the average bitrate of a CQ encode and use that in VBR and compare the two? Nonsense too! That's the whole point of my gripe with what you said, telling people to get the average bitrate of a CQ encode and compare that to VBR using that average. You can't do that just like you can't do what I suggested getting the average quantization of a VBR encode and use that in CQ.

You are so proud of the more efficient allocation of bitrates by VBR. It has to because its working with a limited amount in the first place. But no matter how many pass you let it make, it can only work with what it has. It can only move around the bitrates but it can not add more. You know why? Because you gave it a limit, and your limit is the average bitrate you set and the 800mb capacity of a cdrom.

CQ does not need to be efficient because it can pile on the bitrate that is needed to maintain that quality you set. It's limiting factors are quantization and the 800mb size of the cdrom. Clear?

Anyways, I'm out of this topic. If you really read through the whole thread, everything that can be said has been said many times already, it's just that we don't agree with each other.

[kinneera]

Read my post again. I never said that. I said people insist on sticking CQ with average bitrates and comparing it with VBR.

Because it has an average bitrate! What can't you understand about that? Just because the method of encoding is CQ doesn't mean it somehow has some magical immeasurable bitrate allocation!!! Sorry to yell, but you have to understand this point.

If you try to graph quantisization as against bitrates in CQ and exxagerate it, you would see quantization in a more or less straight line while running along side it would be a varying bitrate line with spikes, dips, slopes or maybe even level line. In VBR, it would be the other way around. Exagerated, the graph would show a level bitrate line with the quantization line varying.

This shows how little you really understand what you are talking about. In a bitrate viewer, if the bitrate line is level and the quantization varies, you are looking at a CBR encode for heaven's sake. A CQ encode, in theory will have a level quantization line, but this will never happen in the bitrate range being discussed (i.e. to fit on CD media). And it still misses the point I'm making which is that if you do multi-pass with the same average, at the very least it will produce the exact same quantization and bitrate lines. We're talking zero-sum here. If you let CQ do whatever the hell it wants, you are going to get a file of a given size. An average can easily be calculated from that file. Then that average can be used to guarantee a file of the exact same size using an x-pass encode. But since the multipass has complete knowledge of the entire video stream after the first pass, there is no question that it is going to allocate the exact same number of bits more efficiently. I don't know how else to put this to get it in your head - Adam and Vitualis both provided excellent detailed explanations of why this is true.

That's the whole point of my gripe with what you said, telling people to get the average bitrate of a CQ encode and compare that to VBR using that average. You can't do that just like you can't do what I suggested getting the average quantization of a VBR encode and use that in CQ.

Of course you can do either of these things. There's nothing nonsensical about getting the average bitrate of a CQ encode, and for the reasons explained above if you use it in a multipass VBR, the multipass will produce the better output albeit at the expense of time. Likewise, you could calculate an average quantization from the multipass VBR encode, and as I said previously, if you used this in CQ (assuming the parameter you're setting in the encoder is actually the target average quantization, which I don't believe it is in TMPGEnc) you would get a file of equal quality but larger size.

You are so proud of the more efficient allocation of bitrates by VBR. It has to because its working with a limited amount in the first place. But no matter how many pass you let it make, it can only work with what it has. It can only move around the bitrates but it can not add more. You know why? Because you gave it a limit, and your limit is the average bitrate you set and the 800mb capacity of a cdrom.

No, I very clearly stated that for the hypothetical comparison the only size limiting factor for the multipass was the size of the CQ output. So if the CQ output a 100 GB file, then for the purposes of the comparison you would use the average that will result in a 100 GB file for the VBR encode. Thus, size requirements being equal, the method that doesn't have to completely guess how complex each scene will be relative to what it might encounter throughout the rest of the movie is going to be more efficient and produce the better quality - thus multipass will perform better at the expense of greater encoding time.

CQ does not need to be efficient because it can pile on the bitrate that is needed to maintain that quality you set. It's limiting factors are quantization and the 800mb size of the cdrom. Clear?

As mentioned previously, if you let multipass VBR pile on the bitrate based on how much CQ felt it needed to pile on the bitrate, the multipass is going to look better, since it has the opportunity to analyze the whole video stream and optimally allocate those bits, no matter how few or many are available. The only case in which CQ is strictly theoretically superior is if you have infinity maximum bitrate, which is nonsensical and logically irrelevant. The difference between the two methods really only boils down to your personal valuation of quality and efficiency relative to time required.

If you really read through the whole thread, everything that can be said has been said many times already, it's just that we don't agree with each other.

I agree. Calmly, dispassionately read the entire thread with an open mind and I don't think it will really be that difficult to understand what myself and so many others who are using multi-pass encodes are saying here.

[pacoreguenga]

Hi Everyone!
I'd like to express my opinion here.

If you want to have the best encoding quality for DVD authoring, you can use CQ_VBR or x pass VBR and a high bitrate limit, as long as you also use high quality branded media, like maxell, apple or pioneer, simply because generic or cheaper media can't cope with high data rates. It will stutter and drop frames. For cheap media stay with CBR encoding at 3 MBs or less to maintain a more stable data flow (video playback).

Now, if you are doing vcd or svcd authoring, keep in mind data rate standards for both formats.

[banjazzer]

[

If you really read through the whole thread, everything that can be said has been said many times already, it's just that we don't agree with each other.

I agree. Calmly, dispassionately read the entire thread with an open mind and I don't think it will really be that difficult to understand what myself and so many others who are using multi-pass encodes are saying here.

The last thing you are demonstrating is an open mind. I'm afraid the poster you quoted has summed up this thread - basically saying we don't agree. You have summed it up by re-stating your entrenched position and passing it off as an open-minded assessment of the thread.

As is common with religion, so we have the same thing thing here. And it's kinda scary. There are those here who can see nothing other than that x-pass VBR is the best possible encoding mode, the overwhelming evidence for this appearing to be that the greater the number of passes, the better it must be, because more of something must equal better. There are those who think CQ is the superior mode, slightly less vociferous, and they seem to be going by the evidence of their eyes, and the fact they are not limiting the bits by stipulating an average bitrate from the outset. And there are the agnostics, amongst whom I count myself.

There is no evidence yet demonstrated here that allocating bits by setting an average and doing multi passes is any way better than choosing a quality setting and letting however many bits necessary be allocated.

And that is not the same thing as saying that CQ is superior to x-pass VBR!

[Peter]

banjazzer, did you allready did a test with same filesize??

[injunpana]

The last thing you are demonstrating is an open mind. I'm afraid the poster you quoted has summed up this thread - basically saying we don't agree. You have summed it up by re-stating your entrenched position and passing it off as an open-minded assessment of the thread.

lol, Banjazzer, so you caught that one too huh?

kinneera, I've read the whole thread several times as I've followed it from its start. I've considered what you VBR advocates said and I just don't agree with you, okay?

I'm not a rabid fan of CQ at all even though I'm defending it. I just want to use the best method and CQ is it for me. I first tried using 2-pass VBR before CQ because I've read it from here that its good. In my several tries of experimenting, I wasn't at all satisfied with the results. I can be convinced yet though. you give me a movie, give me your settings using Tmpgenc and I'll try it then and see if its better than the equivalent CQ product. Who knows, maybe your settings are better than the Tmpgenc default settings I used.

Contrast that with CQ where my first try got a quality that almost looks "dvd-like" but with some blocks in some difficult scenes. With some tweaking with the GOP and Matrix quantization, I've now got to a point where one or two encoding is enough for me to produce an excellent quality that optimizes 2 cds. And CQ is fast that with my computer TmpGenc encodes in almost real time. Even if I encode twice, it will only take me from 4 -6 hours to produce a VCD from ripping a DVD to the burned finished product depending on the length of the movie. Note also that much of the time is taken by the ripping process because my dvd drive can only rip at 2.1 speed.

Damn! I guess I'm still here huh? Okay, I'm truly gone this time.

[int_53185]

Dear friends...been reading ur debate with much interest...decided to do a little experimenting on my own...came to the conclusion: vbr 2 pass is not any better than cbr....uses almost the same file space....takes longer to encode....conclusion....cbr is the best compromise of encoding speed/file size/quality...im sure ull disagree...but thats my conclusion...used vbr 2 pass with max of 2520 min of 2000 avg of 2520.....hey! to each his own! good burning! ...

[wway]

Hey int_53185,

If you set the Max and Average to the same value in a 2-pass, this is the same as a cbr. Ideally, you want your average half-way between the Max and the Min. Try again.

wway

[energy80s]

Why not just stick to CBR and have done with it. You can guarantee up to 40 minutes per disc so you can accurately split the file into useable segments first before encoding it. Movies up to 2 hours will fit onto 3 CD-R's, movies over 2 hours will need 4 CD-R's. If you use CVD rather than SVCD your files will be DVD compatible and you will be able to copy them onto a single DVD R disc in the future.

If your aim is to get every last byte out of a CD-R disc (at 29p) then head over to Kwags site and see some real compression in action![/url]

[Kdiddy]

There are those who think CQ is the superior mode, slightly less vociferous, and they seem to be going by the evidence of their eyes

Im sorry but you and many others have been just as "vociferous" and "religiously fanactical" about the suppose prowess of CQ.

I can be convinced yet though. you give me a movie, give me your settings using Tmpgenc and I'll try it then and see if its better than the equivalent CQ product. Who knows, maybe your settings are better than the Tmpgenc default settings I used.

Again as stated, you basing your beliefs of CQ as whole solely on one product, TMPG. Just because TMPG's CQ is better than its 2pass VBR, does not make CQ better as a whole. That is how TMPG was written, so one should not expect TMPG's 2-pass VBR to be better. I don't because I know it isnt. However, CCE's X-pass VBR will blow TMPG's CQ anyday. Will it take slightly longer, yes, but I leave my machine to encode while I sleep, so 5 hours as oppose to 4 hours is not a deal breaker. If time of encode makes CQ better than VBR, I'll give you that, but the intrinsic encoding process of CQ does not make it "superior" to VBR by any stretch. As I've always asked Kwag "The Great CQ Proponent", if CQ is so "superior", then why do movie studios encode their DVDs with VBR instead of CQ. With the ample space that DVD media provides, the shorter encode time, "guaranteed" quality level, wouldnt it make sense to encode in CQ??, so why dont they? And please, dont give me the "marketing" story that Kwag offers up.

[banjazzer]

Again as stated, you basing your beliefs of CQ as whole solely on one product, TMPG. Just because TMPG's CQ is better than its 2pass VBR, does not make CQ better as a whole. That is how TMPG was written, so one should not expect TMPG's 2-pass VBR to be better. I don't because I know it isnt.

I suppose we could start a whole new thread, talking about software we don't actually use, but personally, I thought it might be wise to restrict my comments to software I do use.

May your god go with you. 8)

[kwag]

There are those who think CQ is the superior mode, slightly less vociferous, and they seem to be going by the evidence of their eyes

Im sorry but you and many others have been just as "vociferous" and "religiously fanactical" about the suppose prowess of CQ.

I can be convinced yet though. you give me a movie, give me your settings using Tmpgenc and I'll try it then and see if its better than the equivalent CQ product. Who knows, maybe your settings are better than the Tmpgenc default settings I used.

Again as stated, you basing your beliefs of CQ as whole solely on one product, TMPG. Just because TMPG's CQ is better than its 2pass VBR, does not make CQ better as a whole. That is how TMPG was written, so one should not expect TMPG's 2-pass VBR to be better. I don't because I know it isnt. However, CCE's X-pass VBR will blow TMPG's CQ anyday. Will it take slightly longer, yes, but I leave my machine to encode while I sleep, so 5 hours as oppose to 4 hours is not a deal breaker. If time of encode makes CQ better than VBR, I'll give you that, but the intrinsic encoding process of CQ does not make it "superior" to VBR by any stretch. As I've always asked Kwag "The Great CQ Proponent", if CQ is so "superior", then why do movie studios encode their DVDs with VBR instead of CQ. With the ample space that DVD media provides, the shorter encode time, "guaranteed" quality level, wouldnt it make sense to encode in CQ??, so why dont they? And please, dont give me the "marketing" story that Kwag offers up.

Sorry to spoil your sunday kdiddy. You should run some more tests again with CCE. I did.
TMPEG 2.5X blows away CCE in CQ mode MPEG-2 vs. CCE's VBR. I'm sorry, but it's the truth. Why does the DVD industry encode VBR? Because they can't waste time re-encoding a movie if it doesn't fit in a DVD-ROM. Not because of quality. I'm sorry again, because you and many others just dont get the point:
X-Pass VBR is designed to FIT X time in X size, without quality consideration.
CQ doesn't care about space, but cares about fixed quality.

Is this so hard for you to understand?

Still think I'm wrong? Then encode a 3 hour movie with CCE's X pass to fit in 2 80 minute CD-R's. Look at the crap you'll get. Do the same with TMPEG CQ=80. Still you'll fit the movie in 2 CD's, but It will look better. For short ( <90 miinute films ) CCE is ok. For longer than 90 minutes, TMPEG shadows CCE with it's CQ mode.

[Nelson37]

I believe the answer is to be found in the ONE person in this thread who posted empirical evidence from a bitrate viewer. In using the ACTUAL values in the CQ file as SETTINGS in TMPGenc 2-pass, the ACTUAL values in the 2-pass file DID NOT MATCH. Specifically, the PEAK values were significantly lower. In order to produce closely matching files, FOR METHOD COMPARISON, you MUST increase the max rate in TMPGenc SETTINGS higher than the ACTUAL value from the CQ file in order to acheive similar peak bitrates, and therefore achieve a valid comparison.

My tests indicated than CQ, Q=80, max=2500 was SUPERIOR to 2-pass, Min=500 Avg=2000 Max 2500, but gave variable quality and filesize on different clips. 2-pass, Min=500 Avg=2200 Max=3000 gave SUPERIOR results, with consistent quality and filesize, slightly smaller than CQ file.

Kwag - I disagree. You are equating Quantization values with visual quality, which may be correct. But how do you achieve a given Quantization level WITHOUT APPLYING BITRATE? CQ sets, or allocates, bitrate according to a Q level, which simply specifies the level of adherence to the MAXIMUM BITRATE YOU SPECIFY. Since you are achieving Quality with bitrate, why not specify it directly rather than indirectly? Put another way, a given Q level WITHOUT A SPECIFIED MAXIMUM BITRATE IS MEANINGLESS. But, a correctly specified bitrate range will give known results EVERY TIME with x-pass. Both methods apply a limited amount of bitrate, CQ just sets the limits FOR you.
To say that 2-pass in not concerned with quality is ludicrous, for what exactly are those Min Max Avg numbers but quality determinations?

[kwag]

I believe the answer is to be found in the ONE person in this thread who posted empirical evidence from a bitrate viewer. In using the ACTUAL values in the CQ file as SETTINGS in TMPGenc 2-pass, the ACTUAL values in the 2-pass file DID NOT MATCH. Specifically, the PEAK values were significantly lower. In order to produce closely matching files, FOR METHOD COMPARISON, you MUST increase the max rate in TMPGenc SETTINGS higher than the ACTUAL value from the CQ file in order to acheive similar peak bitrates, and therefore achieve a valid comparison.

My tests indicated than CQ, Q=80, max=2500 was SUPERIOR to 2-pass, Min=500 Avg=2000 Max 2500, but gave variable quality and filesize on different clips. 2-pass, Min=500 Avg=2200 Max=3000 gave SUPERIOR results, with consistent quality and filesize, slightly smaller than CQ file.

Kwag - I disagree. You are equating Quantization values with visual quality, which may be correct. But how do you achieve a given Quantization level WITHOUT APPLYING BITRATE? CQ sets, or allocates, bitrate according to a Q level, which simply specifies the level of adherence to the MAXIMUM BITRATE YOU SPECIFY. Since you are achieving Quality with bitrate, why not specify it directly rather than indirectly? Put another way, a given Q level WITHOUT A SPECIFIED MAXIMUM BITRATE IS MEANINGLESS. But, a correctly specified bitrate range will give known results EVERY TIME with x-pass. Both methods apply a limited amount of bitrate, CQ just sets the limits FOR you.
To say that 2-pass in not concerned with quality is ludicrous, for what exactly are those Min Max Avg numbers but quality determinations?

No Nelson! No, No, NO!
Let's review this again.
The min, max and avg. are the numbers you calculate to FIT X time in X size media. There is no quality evaluation here!. To give you a drastic example, assume you want to put a movie of 90 minutes in a 80 minute CD-R. Then you also want to put a 180 minute ( exagerate a little here 8) ).
If you put these values in a VBR calculator, the 90 minute will give you reasonable values, but the 180 minute calculation will give you an average bit rate so low that it's worthless to even encode! But it will still fit in the one 80 minute CD-R, because that's what you set the calculations for.
For CQ mode, you specify a CONSTANT quality BUT the bit rate will fluctuate from the value that TMPEG, in this case, chooses for the given CQ and the MIN bitrate you selected if there are less pixels/action/movement on the scene. Any way you want to look at that.
If there is a demand for bit rate, as in the case of high action movement, that's when the bit rate is increased from the CQ point to the MAX bit rate.
So basically CQ will set an average bit rate MAINTAINING a constant quality, while varying the bit rate between MIN and CQ for low/medium action scenes, and between CQ and MAX if the bandwidth is exausted.
Formulated, this is the way CQ would work:

Result CQ Scene bit rate = ( >= MIN AND <= CQ(internal low/high treshold ) OR ( >=CQ(internal low/high treshold) AND <= MAX )

Sorry if someone doesn't understand this, but I am a developer, and can only express the formula this way. This is what any CQ encoder would basically use as software algorithm for CQ mode.

Again:
X-Pass VBR is only worried about BIT DISTRIBUTION for a TARGET media. Nothing else.

kwag

[kinneera]

For the life of me, I just can't understand why you people can't understand a simple concept. Try this - do a CQ encode with a maximum bitrate as high as the encoder will allow, this will get us as close to a true CQ encode as possible. Now use a bitrate viewer to figure out the actual highest bitrate peak that occurred. Now put that value into a multi-pass VBR encode, and use whatever average bitrate will produce the same size file. I can absolutely guarantee you, without a doubt, that the multipass VBR will produce the better output.

There is absolutely nothing "magical" about what CQ does. But given the same total number of bits, multipass VBR can do exactly the same thing. This is so simple. How can you possibly believe that a method that only gets one blind pass through the video can outperform one that has complete a priori knowledge?

Among other benefits, multiple passes allow the encoder to perform more motion searches, and thus encode more efficient motion vectors as well as determine the relative complexity of every scene relative to every other so that the bitrate allocation is optimal for all scenes. CQ can ultimately accomplish a similar result through bitrate at all costs, but this of course is a detriment to both predictability and efficiency - which is not an advantage!!

Anyone who thinks TMPGEnc's CQ can beat CCE 3-pass or more (which would still run faster) doesn't understand how to use CCE or has very bad eyes or TVs. The fundamental basis of CQ encoding is at a technical disadvantage, especially any CQ setting with a maximum parameter.

The only thing that resembles religious fanatacism is when people ignore technical, logical, and pragmatic considerations based on some sort of faith that their position/solution magically does something in a superior fashion. Those who believe that the only purpose of multipass is to "fix x video into x space" clearly have no idea what goes on during the MPEG encoding process. Additionally, there is nothing magical about constant quantization. Those who think it somehow provides a magical solution that cannot even be matched with proper multipass encoding parameters obviously understand nothing about the basis of MPEG encoding. Likewise, those who believe then that it is uniformly superior have a faith grounded in no reality that clearly none of the experienced members of this forum can shake - do what you wish.

[Kdiddy]

I suppose we could start a whole new thread, talking about software we don't actually use, but personally, I thought it might be wise to restrict my comments to software I do use.

We could also start whole another thread about people who don't seem to understand logic, but it would be just as long as this, so might as well continue here. You just back up my original statement, in using only TMPG you have formed an illogically based opinion on the CQ & x-pass VBR encoding schemes. Well heres a newsflash, the programmers of TMPG did not invent the mpeg compression scheme/encoding process.

TMPEG 2.5X blows away CCE in CQ mode MPEG-2 vs. CCE's VBR. I'm sorry, but it's the truth.

No not truth, your opinion, to which you are entitled. Just like Im in the opinion that quite the opposite is true.

Why does the DVD industry encode VBR? Because they can't waste time re-encoding a movie if it doesn't fit in a DVD-ROM.

Well at least that's better than "marketing" BS you posted so many times b4, but it still doesnt hold water. I seen too many 2 disk DVD sets & double sided DVDs to even believe that media limitations is ever problem with DVD manufactuers.

X-Pass VBR is designed to FIT X time in X size, without quality consideration.

Wrong that's CBR

Then encode a 3 hour movie with CCE's X pass to fit in 2 80 minute CD-R's. Look at the crap you'll get.

Of course they both will look like crap because putting a 3 hour flick on 2 CDs is going to require a low average bitrate. Something CCE does not do very well. I said that many times, bitrates below an average of 1400 kbps I would not use CCE. But is not the point...

What you CQ lovers seem to keep missing is that because that scenario does happen, it does not intrinsically make CQ better than X-pass VBR. That is simply a reflection of that particalur encoder. Some people spanish very well, some horribly. To say is spanish is a hard language to understand based on that fact that the one person you know speaks it horribly, is not a true reflection of one's ability to understand spanish, now is it?

Can you get a better flick with TMPG's CQ over it's 2-pass VBR? IMO, probably so, due to flaws within TMPG

Can you get a better flick with CCE X-pass VBR over TMPG's CQ or CCE CQ? IMO, YES

[vitualis]

kineerra has already hit the nail on the head on why the principle logic behind "CQ not limited by an average bitrate" is ridiculous.

Yes, CQ does not work to any specific bitrate limitations (except max and min -- which are actually significant for SVCD) when it is encoding. It tries to maintain a "quality" co-efficient instead.

However, it is still encoding MPEG and at the end, you are still going to get a file of a particular SIZE. Divide that by time and you get an average bitrate. Even though the encoder in CQ didn't know about the average bitrate a priori, IT IS INDISTINGUISHABLE AFTER THE EVENT.

If you encode a multipass VBR encoding instead, and you set the same bitrate settings as above (same measuring stick), you are essentially doing the same thing, i.e., encoding the same video clip to MPEG, except that this time, you know the total number of bits you have to play with AND the complexity of each scene a priori. It is obvious that the multipass VBR clip will do better.

Analogy
Consider the MPEG encoder is a builder and the complexity of each scene is the size of a room.

The "CQ builder" will take each room as it comes, ignoring each other room.

• For room 1, he asks person 1 on how big the room will have to be for him to reach a certain "happiness" factor and then builds it.
• For room 2, he asks person 2 on how big the room will have to be for him to reach a certain "happiness" factor and then builds it.
• and so on until the final person

Now, consider the house build above and calculate the total floor space it takes up.

Now, the "multipass VBR builder" knows the total amount the space allowed (for the "same measuring stick", it must be the same as the above example) AND firstly asks each person in turn how much room they need BEFORE he starts building. Then, he allocates he optimum amount of room for each person when he builds the house.

Obviously, as the "multipass VBR builder" has more information to work with at the beginning and can intellegently allocate room (bitrate) between ALL the people (scenes), the overall happiness (quality) will be higher.

Measuring stick
Someone up the thread actually attacked the validity of the "measuring stick" -- that is, same average bitrate (which means no more than same overall file size) for comparison.

Needless to say, this is rather ridiculous. As a basis of comparison, it is the average bitrate (i.e., total file size) that matters.

For example, when we say "DivX" (i.e., MPEG-4) has better quality than MPEG-1 or 2, what we really mean is that it has better quality at the same bitrate. If you don't have the same bitrate, there is no basis of comparison at all.

Further points

• If you are going to make an arguement, at least back it up with logic. I try to make all my points as logical statements. Go through each and ask yourself, is this "true or false?" and "does this make sense?". If so, why and if not, why.
  
• For TMPGEnc, CQ "may" look better than 2-pass VBR and this is a point that Kdiddy brought up. In fact, it is also alluded to in my list of "caveats". If the encoder screws up multipass VBR (or if much more programming effort was put into CQ), then CQ may well look better than multipass VBR. However, it is important to understand the theory behind this. CQ is not inherently "better" than multipass VBR and indeed, the reverse is true.
  
• I am not entirely sure if this has been covered but someone mentioned about "caveat #7"? The max. bitrate for SVCD (in the specs) only allow for the read spead of the disc to be at no more than 2x CD. This is as the original SVCD players were designed to be able to be read on a 2x CD drive. On modern DVD drives, 1x DVD is equivalent to about 3x CD (in the DVD FAQ). However, some drives will "spin up" when it detects a CD and so the CD read speed may be significantly faster. How fast will depend on the actual drive mechanism.

Regards.

[kwag]

What is it? Some of you can't read industry graphs?
You just don't understand that CQ != VBR
I hope everyone that reads the links provided below, will finally understand why CQ is superior than than plain O'L X-pass VBR. ( As far as quality is concerned ).

Read here:
http://www.tecoltd.com/enctest/concepts.htm
And here ( great info on constant quality quantization ):
http://www.ebu.ch/trev_282-fletcher.pdf ( very relevant )
And here for those who say the long GOP used in KVCD is too long ( which is the basis for KVCD ) ( by Tektronix ):
http://www.grassvalleygroup.com/docs/PDFs/whitepapers/videostorage-generic/Profile-wp-mpeg.pdf

[vitualis]

CQ is VBR. That is obvious. CQ is different from 1-pass VBR in HOW it allocates bits.

In fact: http://www.tecoltd.com/enctest/concepts.htm is very good indeed. It shows why CQ can be better than 1-pass VBR. What the CQ graph doesn't show you is what happens to CQ if you have a limit to the max. bitrate which is pertinent to SVCD encoding. Furthermore, that article (though it doesn't explain it) alludes to the fact that multipass VBR is superior to both CQ and 1-pass VBR.

Regards.

[kwag]

CQ is VBR. That is obvious. CQ is different from 1-pass VBR in HOW it allocates bits.

In fact: http://www.tecoltd.com/enctest/concepts.htm is very good indeed. It shows why CQ can be better than 1-pass VBR. What the CQ graph doesn't show you is what happens to CQ if you have a limit to the max. bitrate which is pertinent to SVCD encoding. Furthermore, that article (though it doesn't explain it) alludes to the fact that multipass VBR is superior to both CQ and 1-pass VBR.

Regards.

vitualis, PLEASE, X-pass VBR is nothing more than a "balanced bit rate allocation". Let's get technical. On the first pass, the encoder creates a "MAP" or a "footprint" ( you choose ) of the material, in order to "preview" or analyze what it's going to have to work with.
The next pass compares the footprint with the required parameters ( min. avg. max ), and starts encoding with this "footprint" as a guideline, together with the parameters, so it doesn't go overboard allocating bits unnecessarily. Further passes perform a more "granular" result, based on result of the previous pass. Now, where is the quality quantization here? Nowhere!. The encoder is not tuned for quality. It's tuned for a target file size. That's all X-Pass VBR is!
If people think that you get higher quality by increasing the number of passes, yes up to a practical point, after that it's a waste of time.
If someone has curly hair, don't expect them to have straight hair by combing their head 20 times

Regards,
kwag

[kinneera]

The next pass compares the footprint with the required parameters ( min. avg. max ), and starts encoding with this "footprint" as a guideline, together with the parameters, so it doesn't go overboard allocating bits unnecessarily.

If those parameters are set to match the output of a CQ encode, the multipass will then produce a better result. Same number of bits, allocated more intelligently. Is that really so incomprehensible?

Now, where is the quality quantization here? Nowhere!. The encoder is not tuned for quality.

Sorry, but I have to call bullshit on this one. "Quality quantization" is your dogmatic holy grail answer even though you don't seem to fully understand it. Every encoder attempts to achieve the highest quality possible within the constraints it is given. This means that multipass VBR will attempt to maintain the best quantization possible with what is has to work with. If what it has to work with is identical to what the CQ had to work with, it will outperform the CQ for all the reasons mentioned so many times before.

[kwag]

kinneera, you obviously don't know peanuts. I just gave a software engineering explanation above, and you completely refuse to accept it.
This is "end of thread" for me. It's a shame that your mind is tighter than a keyhole.
Your advice is a shame to this forum and people. You can't accept facts. I could go on, maybe at a higher technical level, but then you wouldn't understand anyway. Have fun with your VBR ideas. I, and many people, will enjoy higher levels of quality with CQ while you encode multi-passes with "wanabe" quality.

[Wicked_Al]

First of all, I wont pretend to know more about this than any of you. Just thinking about it in practical terms, CQ would seem inherently better because you're maintaining a more Constant Quality (being bitrate). This would be like working on a budget versus...umm..NOT. In VBR, you specify a min/avg/max bitrate, so you'll arrive at a specific file size(budget). Some scenes will be lower quality than others so you can hit your desired file size. CQ is constant, so each frame is guaranteed a specific quality. It can get better than that, but at the very least its going to be within that quality level. The average bitrate in VBR seems misleading when trying to determine quality because more times than not you'll be near the minimum so you can hit the maximum. It would be like hit and miss quality wise. Even if CQ is nothing but single pass VBR than it would always seem to be better than x-VBR, if you're at the same max bitrate, because its always going to be within a range closer to the max bitrate setting. Its assigning bitrate based on quality, not trying to assign a low bitrate for one frame just so it can give another a higher one. With VBR it seems something has to give, and thats quality. Sure its minimized with each pass, but unless that average bitrate is close to the max then the quality will suffer. If CBR, CQ and VBR have a definite max bitrate, I believe most would agree that CBR would yield the best quality. CQ can be closer to CBR because of the quality setting. If set to 100 then its basically CBR. The higher you move the average bitrate in VBR is like upping the quality in CQ, and you're basically doing something like CQ, but then you loose your main advantage of file size prediction, and the time it takes to do it is multiplied by the number of passes. CBR wastes bitrate. CQ wouldn't waste as much. VBR would waste even less. I thought the whole point of having as much bitrate as possible was to improve the quality? The differences are similar to a RAW image, a GIF and a JPEG. Perhaps visually it might not be that easy to tell the difference, but I dont see how system that uses less bitrate is inherently a higher quality system than one that uses more. It may be more efficient , but in general you can't have your cake and eat it too.

BTW, I find this thread very useful. If anything, we're all probably getting a better understanding of CQ and VBR. After reading my post you may disagree, but this is a hobby, so I'm happy to learn.

[Wicked_Al]

Sorry...double post!