battle of the CBR/VBR/CQ modes

[dvd2svcd]

I don't think I agree with you, CQ and VBR should be tested on the same encoder to establish a common ground. As I've told you, I've already done the test comparison, although I grant you, it was solely done in Tempgenc. Now that you guys agree that VBR is beat by CQ in tmpgenc, then I guess I'm done.

Well, that kind of takes me out of this as it will be impossible to make tmpgenc VBR better than CQ.

Now, all I need is to test CQ and VBR in CCE of which is better. If VBR turns out better than CQ in CCE, does that make the conclusion that VBR is better than CQ? WHat makes CCE rather than Tempgenc be the deciding factor on which method is better. Still going along the thought, if CQ beats VBR again in CCE, it'll just prove that CQ is better than VBR in CCE and Tempgenc. Hmmmm, this is getting complicated.

When I did my tests I used all kinds of methods in 3 different encoders (tmpg, lsx and cce) and basicly I didn't go for any theories or math. I went with what my eyes said. And the end was CCE 4 pass VBR was what looked the best (and the closest to the source).

Anyone who can suggest a really good method to prove which methos is better?

I know a lot of dvd2svcd users are using 1 pass VBR (I guess what you'd call CQ in CCE) and are getting good results, but their main reason is always because it is faster to encode that way, not because it's better than 4-pass VBR.

A comment to your conditions though, especially on the first. Why leave out the audio part? You can't watch a movie without the sound, it's the other half of the total experience. An audio bitrate should be specified and what channel mode to use. Conditions 2 and 3 are okay. If any of the CQ advocates could take up the challenge, it would be appreciated not just by me but by evryone. I'm hoping this will stop this debate once and for all.

Ok, specifying the bitrate would yield the same result. Only reason I suggested to leave the audio out was to focus on the video only.


--

So basicly, whenever I have seen a CQ versus VBR battle, I have read it as "Which encoder+method is the best", and always without looking at the theory behind the various methods.

[banjazzer]

That problem in this thread lies in the attempts to proclaim CQ as the supreme encoding method, based upon your personal taste (and for 1, lack of experience) and not facts.

No, the problem in this thread, if you actually read it from the beginning, is exactly the opposite. It is the adherents of multi-pass VBR proclaiming that as the supreme encoding method, and attempting to rubbish CQ. What's more, it's the multi-pass VBR adherents who are becoming the most ill-tempered, which is always the way with religious folk when their faith is challenged.

I notice I have been attacked because I have the temerity to contribute when I only use the recently-rubbished TMPGEnc. Evidently, you must use more than one encoder to give you the right to pontificate, and one should preferably be CCE. However, if you re-read the thread, the discussion was largely about TMPGEnc. The multipass people started harping on about CCE when it seemed they were losing the argument with TMPGEnc. Which is always a good ploy - if you cannot win fairly, move the goalposts. 8)

[Kdiddy]

What's more, it's the multi-pass VBR adherents who are becoming the most ill-tempered, which is always the way with religious folk when their faith is challenged.
I notice I have been attacked because I have the temerity to contribute when I only use the recently-rubbished TMPGEnc.

O please come with something better than this. Again, assuming people are "attacking" you personally is reflection of how you feel about yourself. No one is "attacking" you, people are simply pointing out the mistruths in your statements, simple as that. Stop trying to shift to subject to that, if you feel attacked, then why continue to post and open yourself up to more of these supposed "attacks"? ahhh but that would require logic

However, if you re-read the thread, the discussion was largely about TMPGEnc.

Please, quote where in the orginal poster's statements where he/she specifically states anything to do with TMPG. Its only after the "TMPG CQers" come in does it only get spinned that way. Yet another issue I have with "TMPG CQers". Always entering a thread, not answering the original question, and throwing "CQ" out like people at golf tournament yelling "get in the hole" after every shot.

The multipass people started harping on about CCE when it seemed they were losing the argument with TMPGEnc. Which is always a good ploy - if you cannot win fairly, move the goalposts.

Its funny how you see this as a win/lose situation, which it is not. Again, simply pointing out the errors in your statements. If you don't like people doing that, don't post. CCE was brought up as counterpoint/example to show TMPG's fallacies. Had you said, "I prefer TMPG's CQ over that of TMPG's VBR", then no one can have issue with your statement. As I've stated several times, people only have issue with your statements when you take that preference and try to apply it as being the general rule of mpeg encoding which it is not. What makes your stance even weaker is that you have admitted to only having experience with TMPG.

[banjazzer]

I'm not the first to notice the ill-tempered responses. Look, I don't care how ill-tempered people get. They can have tantrums for all I care. I was pointing out where the heat was coming from. I have been told I don't belong in the thread because I do not use CCE. This does not bother me in the least. I will post when and where I please. And I don't get upset, heated or angry.

Please, quote where in the orginal poster's statements where he/she specifically states anything to do with TMPG.

I actually said "the discussion was largely about TMPGEnc". I never mentioned the original poster. The discussion took on a life of its own after the first post, which mentioned no specific encoder. Late in the day CCE came into the discussion.

Its funny how you see this as a win/lose situation, which it is not. Again, simply pointing out the errors in your statements. If you don't like people doing that, don't post.

I don't see it as a win/lose situation. I use both encoding methods. I only take issue with those who try to rubbish CQ. I have never said multi-pass VBR is rubbish. I have said that approaching an encode with a filesize/average bitrate in mind can lead to problems. In experienced hands it won't. And if I don't want to post, I won't. 8)

Read through the discussion, pick out my posts and find one where I have been angry, or rattled. All I am pointing out is that some of the proponents of multi-pass VBR have been ill-tempered, starting, if I recall correctly, with adam. Pick out the angry posts, and correlate them with their preferred encoding method.

I have no qualms whatsoever about what people use. As I said, I am not a religious person.

[Kdiddy]

Look, I don't care how ill-tempered people get. They can have tantrums for all I care. I was pointing out where the heat was coming from. This does not bother me in the least.

Sooooo lame, if you truly did not care about the temperment of some posts, then why even bring it up as an issue?? Because there comes a time when one lacks any credible information to provide, so they try to shift the topic of conversation.

Pick out the angry posts, and correlate them with their preferred encoding method.

kinneera, you obviously don't know peanuts.

Hey ADAM ,pull your head out of the sand for a moment,

Now which side of the fence did they fall again??

I have said that approaching an encode with a filesize/average bitrate in mind can lead to problems.

There is big difference between can and will.

Read through the discussion, pick out my posts

Im glad you said that because in doing so, because I found this.

I have done no tests on this. I am only going by what others have written,

"The proof is in the pudding". Had I caught this statement, I would have simply ignored anything you had to say on this subject. Let me get this straight, you have not done any of your own tests, you go by word of mouth (hand), you've used only one encoding software application, and yet you expect us to not only listen, but believe you possess in depth knwoledge of mpeg compression? Yeah right. No point in continuing to beat this dead horse, everything has said ten times over, and whatever has been missed will surely be discussed again in the next big post about CQ.

[banjazzer]

The proof is in the pudding". Had I caught this statement, I would have simply ignored anything you had to say on this subject. Let me get this straight, you have not done any of your own tests, you go by word of mouth (hand), you've used only one encoding software application, and yet you expect us to not only listen, but believe you possess in depth knwoledge of mpeg compression? Yeah right. No point in continuing to beat this dead horse, everything has said ten times over, and whatever has been missed will surely be discussed again in the next big post about CQ.

You have no need to rationalise your inability to follow a discussion. You can ignore whoever you want if it is inconvenient to your position.

Each contributer here does not need to run all the same tests as a pre-requisite for posting, whether you want to think so or not. Enough have done that already. Nor do they have to use certain software in order to belong to the club. I talk well within my own experience, and I am quite good at detecting bullshit and illogic, of which plenty has been posted by the x-pass VBR advocates. 8) You can ignore whoever and whatever you want - that is your prerogative.

[banjazzer]

And as a rider, you do not need to do any tests personally to realise the basic premise of my argument. I will repeat this, because no matter how many tests you do, no matter how many passes you do, no matter how much your software costs, no matter how many encoders you possess, if you approach an encode having limited the encode by stipulating an average bitrate/filesize at the outset, under certain circumstances you will have a poor result. To get a poor result with CQ you have to set a silly quality setting from the outset, because the average bitrate/filesize is not fixed at the outset.

Nobody here has refuted that statement, although many have conveniently ignored it.

[injunpana]

I see where problem lies with you, your inability to comprehend. I just stated that "Kwag has previously demostrated prior to this ridiculous thread his ineptitude at use CCE correctly." Simplified for you, it means well before the original poster even thought up this thread. Kwag has shown the inability to properly use CCE, period. For several outlandish posts he has made in the past, is my reasoning for simply dismissing him, not for anything the just said in this thread, got that? Banjazzer has simply discounted himself lack of experience, get some experience at something, then come blab about what you think you know.

NOW THERE YOU GO AGAIN. That of Kwag "demonstrating his ineptitude at use of CCE" is simply your opinion, and you expect everybody to take it and everything you're saying as gospel? If we don't, then we too simply couldn't comprehend, right? Okay, got that.

You know, I simply haven't yet met somebody who has the conceit that he has the absolute truth always. I guess there's always a first.

[injunpana]

Damn! Double post. Sorry

[injunpana]

O by the way, here is what Kwag had to say "kinneera, you obviously don't know peanuts.". It's a 2-way street

Yeah, that damned KWAG, ruining the CQ advocates' rep. What the hell are you doing??? And you've been such a paragon of level-headedness. lol

[wway]

And as a rider, you do not need to do any tests personally to realise the basic premise of my argument. I will repeat this, because no matter how many tests you do, no matter how many passes you do, no matter how much your software costs, no matter how many encoders you possess, if you approach an encode having limited the encode by stipulating an average bitrate/filesize at the outset, under certain circumstances you will have a poor result. To get a poor result with CQ you have to set a silly quality setting from the outset, because the average bitrate/filesize is not fixed at the outset.

Nobody here has refuted that statement, although many have conveniently ignored it.

banjazzer,

If you intend to burn your encoded file to a cd, YOU ARE LIMITED BY THE SIZE OF THE CD. So, the average bitrate/filesize is fixed at the outset. Does not matter if you intend to use 1, 2, or 3 cd's. There is a limit.

wway

[banjazzer]

banjazzer,
If you intend to burn your encoded file to a cd, YOU ARE LIMITED BY THE SIZE OF THE CD. So, the average bitrate/filesize is fixed at the outset. Does not matter if you intend to use 1, 2, or 3 cd's. There is a limit.

Currently, scattered about the house I must have a thousand blank CDs. So I am not limited in any meaningful sense of the word. 8) I create a file which is X MB, and use Y CDR to accomodate the X MB.

[wway]

banjazzer,
If you intend to burn your encoded file to a cd, YOU ARE LIMITED BY THE SIZE OF THE CD. So, the average bitrate/filesize is fixed at the outset. Does not matter if you intend to use 1, 2, or 3 cd's. There is a limit.

Currently, scattered about the house I must have a thousand blank CDs. So I am not limited in any meaningful sense of the word. 8) I create a file which is X MB, and use Y CDR to accomodate the X MB.

OK...somebody please close this thread and turn off the lights. The multi-pass people have won.

I'm outta here.

[Kdiddy]

Since it has nothing to do with the actual CQ-VBR idea, I'll respond

I talk well within my own experience, and I am quite good at detecting bullshit and illogic,

As well you should be, for the amounts of which you displayed throughout this thread.

NOW THERE YOU GO AGAIN. That of Kwag "demonstrating his ineptitude at use of CCE" is simply your opinion, and you expect everybody to take it and everything you're saying as gospel?

Dude, for the last time, in the past he has said, he doest know how to use CCE, he posted his settings his attempts in using CCE. Please read what I said, NOT IN THIS THREAD, but in previous posts these events have taken place. Do a search through his previous posts and you will see for yourself.

What the hell are you doing??? And you've been such a paragon of level-headedness.

Again, don't mistake passion for anger. I also not the one harping on the idea that I feel "the other side of this ideal is attacking/illtempered/mad" because my the logic has been proven to have fallacies. You want provide solid proof via mpeg compression specs, we can talk. But as for this debate of who is acting this or that way, its silly and so way off topic.

[banjazzer]

You can insult as much as you like - I really do not care. If you do not have an answer, then perhaps the only option for you is possibly to insult people.

Nobody has yet offered one single shred of evidence as to how approaching an encode by specifying the filesize, or average bitrate, is in any way superior to choosing a quality setting, and letting the filesizetake care of itself.

You can throw in as many red herrings as you like. You can mock, you can insult. You may even impress a few newbies. But you will still be wrong, and you will still be unable to provide a refutation of my statement.

[vitualis]

if you approach an encode having limited the encode by stipulating an average bitrate/filesize at the outset, under certain circumstances you will have a poor result. To get a poor result with CQ you have to set a silly quality setting from the outset, because the average bitrate/filesize is not fixed at the outset.

Nobody here has refuted that statement, although many have conveniently ignored it.

I refuted that statement in my long post, as did adam before me.

That statement is inherently pointless and you state it implicitly yourself in that quotation.

"to get a poor result with CQ, you have to set a silly quality setting from the outset"

The same is true for multipass VBR. If you set stupid bitrate settings, you are going to get poor results.

In either method, poor initial settings --> poor results. It is not particularly profound.

As for not a shred of evidence??? Open your eyes. What you and the other CQ proponents have continually ignored is what I wrote in my last post:

Same number of bits, allocated more intelligently.

This sums it all up between multipass VBR and CQ. If you use the same size file (i.e., same average bitrate as the basis of comparison which is the ONLY fair way or comparison), multipass VBR will allocate those bits more intellegently than CQ --> better overall quality.

Please, before you ramble on again on how CQ sticks to quality rather than bitrate, etc., consider the above point. It is obviously true and the conclusion should be blantantly obvious.

Remember, both CQ and multipass VBR are just encoding MPEG-2 frames. CQ doesn't do something magical. It just allocates bitrate differently to multipass VBR.

The ways to compare "quality" between different encoding schemes for the same application is to firstly have a basis of comparison -- that is, equal filesize which implicitly means same average bitrate.

If a CQ and multipass VBR encoded clip are the same size then the encoder would have distributed those bits more intellegently for the multipass VBR clip (it worked harder and longer and knew a priori the complexity of each clip before it starts giving bits).

What is the obvious conclusion??

Regards.

Regards.

Virtualis ,Kdiddy, injumana,wway...........etc etc



Wrong Wrong WRONG!! you dont get it do you!

What is Mpeg2? its a description of the source, its not only compressed, we are droping info we think is unimportant, which hopefully we dont notice to much in the output.
When I say its a description of the source, another way to think of it is you can not reverse the process, you can not re-create the original source from the output.

Ok so far dudes??

What is VBRXpass & CQ-VBR? 2 different methods of encoding, each one has its advantages & dissadvantages, niether of these methods will give you the best result for the desired number of CDR`s(Mb`s) every time.

This is probably where I lose you guys as you have already decided the X-pass VBR is the best form of encodeing known to man.?? Anyway you are probably also the sort of xpass VBR people that will use 100 pass VBR when computers are fast enough in a few years and say you can see a differance between 3pass and 100 pass...yeah??

Please anyone new to ecoding video ignore most of what you are reading in this thread try different methods of encoding for yourself & decide for yourself and there is so much bullshit in this thread.

[dvd2svcd]

True there's too much BS is in this thread so I suggest that all you newbies try this for comparing and decide for yourself:

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 CCE's X-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.

Now remember I am not advocating for tmpgenc's VBR. I am using CCE, which does encode VBR properly.

So CQ and VBR folks I suggest that you stop now, and let those who actully try the above test get a say in this.

[banjazzer]

I refuted that statement in my long post, as did adam before me.

That statement is inherently pointless and you state it implicitly yourself in that quotation.

No. You think you have refuted that statement. I, and several others do not. You do not refute a statement by labelling it utterly pointless, and then refusing to address it.

Quote:
"to get a poor result with CQ, you have to set a silly quality setting from the outset"

The same is true for multipass VBR. If you set stupid bitrate settings, you are going to get poor results.

You would have to set a silly setting to get a poor result with CQ. You could get a poor result with 2-pass VBR purely because of the compressibility of the source material, and because you have a filesize, or number of discs, in mind from the outset. This is inherent in approaching encoding from a constrained average bitrate/filesize. And please note I said could, not will. This possibility of error does not arise with CQ, because difficult material will just mean a much larger file. You can waffle away forever, but you will not alter the fact that multipass VBR limits the bits available from the outset. CQ does not.
A point I have made over and over: It does not matter how well multipass VBR distributes the bits, if it is working with an insufficient number of bits for the source material then it will produce an inferior result. Notice the emphasis on the word "if".

Banjazzer wrote.......

This possibility of error does not arise with CQ, because difficult material will just mean a much larger file. You can waffle away forever, but you will not alter the fact that multipass VBR limits the bits available from the outset. CQ does not.
A point I have made over and over: It does not matter how well multipass VBR distributes the bits, if it is working with an insufficient number of bits for the source material then it will produce an inferior result. Notice the emphasis on the word

I agree, but I am afraid many people in this thread, either cant understand this point or dont want to.....

[dvd2svcd]

I give up. The CQ guys are unwilling/unable to prove their statements in real life. In practice CCE X-VBR does produce better result than TMPGEnc's CQ. That is not theory that is fact. I don't give a rats ass what is supposed to be the best of the two in theory, basicly I can't use theory for anything if it can't be applied practically. As banjazzer clearly have stated, he's conviction comes from hearsay and nothing more, and he is quite unwillling to do any tests to prove his statements. Weird.

Basicly the CQ folks wants others to believe blindly that CQ is better than VBR.

And to prove you otherwise I will make the tests for you to download and prove to you beyond any doubt that given the same filesize CCE X-VBR will be better than TMPGEnc's CQ!

[banjazzer]

As banjazzer clearly have stated, he's conviction comes from hearsay and nothing more,

banjazzer did not clearly state that, or anything like that, even though it might be convenient for your argument. banjazzer says that if you take your super duper encoder costing thousands of dollars, set it up for umpteen passes until the cows come home, and set it off with an insufficient average bitrate because you are working to a filesize, you will get an inferior result to weedy TMPGEnc costing $50 using CQ mode on a reasonable quality setting.

Now, if you want to run a full CQ encode first at a decent quality setting, take the resultant filesize and input it into CCE and set up the maximum number of passes and do a second encode with lots of passes, I will accept that you may get better quality. However I would not be surprised if it was undetectable to human eyes. Note, I did not say it would not be undetectable - I said I would not be surprised if it was undetectable. So please do not misrepresent me.

Now, all you multipass encoders, you always do your encoding like that, don't you? 8)

Basicly the CQ folks wants others to believe blindly that CQ is better than VBR.

No we do not. And you will not find anywhere in any post where we say this. This is what you think we are saying because of poor comprehension skills and a paucity of logic. We do not want others to believe that CQ is rubbish because a few of you who cannot follow a reasoned discussion think it must be so. We do not want others to believe you must use CCE with multi-pass in order to get excellent results. It is the multipass zealots who consistently have attempted to rubbish CQ, and in some cases TMPGEnc - not the other way round.

[banjazzer]

I do not seem to be able to edit my previous post. The second paragraph should read:

Now, if you want to run a full CQ encode first at a decent quality setting, take the resultant filesize and input it into CCE and set up the maximum number of passes and do a second encode with lots of passes, I will accept that you may get better quality. However I would not be surprised if it was undetectable to human eyes. Note, I did not say it would be undetectable - I said I would not be surprised if it was undetectable. So please do not misrepresent me.

[Kdiddy]

Well now that you are actually back on the subject, I will give it one last shot since you claim that throughout these whole 7 pages, no one has shown you proof otherwise. So lets try this..

Considering you have already posted

I would say x-pass VBR may be theoretically best if you know how many bits you are going to use

Media does impose a limiting factor in the size of our file, which forces us to know how many bits we plan on using. If one was truly concerned about maintaining the best quality at all cost no matter how many CDRs(filesize) are used, then that person would be using CBR or CQ 100% in all scenarios. The max bitrate will always give you the best possible Q value. So doing a CBR encode at max bitrate will cure any worries that one might have on whether or not you chose the right CQ setting for a particular movie and use however many CDRs it takes. The reason to use a CQ less that %100, is to have the encoding speed of CBR,but have a reduced filesize by raising the your Q value. (remember, the higher your Q value becomes, the worse the quality). You want a reduce filesize because you feel that some scenes dont require the full max bitrate in order to have a "good" Q value and therefore not used as much media. Why used 3000 bps to get a Q value of 8, if 2500 bps will give the same value right? Kwag's first big statement was that by using CQ you fit 120+ mins of SVCD video on 1 CDR. So in subscribing to Kwag's theory and say you had a movie you knew a CQ would take 2 disks, then yes you, me, and everyone knows that the max number of bits that could be use for either a CQ or VBR encode would be 1.6 GB (=12.8 Gb). The only difference is that VBR would gaurantee that I would use all of the potential number of bits whether I needed them or not. Therefore media is a worry & limiting factor.

So in any scenario whether theorectical or practical, filesize in and of itself no longer becomes an issue, and therefore is moot point. The only point from here on how is the encoder/encoding process.

Lets start here first, in one of your posts,

Although you seem to think the reference I gave http://tangentsoft.net/video/mpeg/enc-modes.html
not worthy of consideration, I am not quite sure why.
I certainly agree with the conclusion.

It will be considered worthy, just as worthy as what can be found elsewhere on that very same website. Something that routinely gets ignored when "CQers" quote this as a source.
"In CQ mode, CCE SP has no significant quality advantage over over its closest competitors.......Because for some people, CCE SP's one remaining advantage--multi-pass VBR--is worth it. This mode gets you the quality of CQ mode, while still giving you complete control over the bit rate. If you must have the highest quality but can't tolerate unpredictable bit rates, and you are willing to spend some time and money to get that high quality, this is the only encoder that will do. This explains the high cost: CCE SP's potential market must be small indeed, yet it must have taken a lot of engineering effort to make the encoder this good."
http://tangentsoft.net/video/mpeg/reviews/cce-sp.html
Yes I know the temptation now is to say, well who can afford CCE? Trust me, Im sure the author of this site did not pay for it or all the other encoders he used. CCE is out there, you just have to turn over every rock & stone on the net to find it. But again, the value of CCE is not what is in question here.

But back to the subject, remember, the filesize is the same from our example because we plan on using the same bitrate...Your stance is that CQ looks at the video, says it needs this bitrate to attain set Q level, true. In using CCE, the first pass gathers all of the exact same info that CQ does and creates a .vaf file. CCE lets you set a quality option before this pass allows you to dictate Q values. Not supper accurately but as accurate as TMPG CQ sliderule setting. Where the added advantage comes in that once this pass is complete, you can open the vaf file in advanced, and adjust the desire q levels all way down to frame by frame if you choose. The graph also shows you where distortion begins & ends. Once you have this set, then you can run your other passes. Which allows to encoder efficiently distribute the bits as needed, more passes more efficiency. Yes, as with anything you reach a point of diminishing returns, which is about after 3-4 passes.
Now Im lost as to how you dont understand that say TMPG's CQ looks at a scene says to have this Q, it need 2453 bits, and is done thats it. CCE says it first pass that hey this scene might need 2453. Well on its subsequent passes, CCE learns that hey it can get away with 2450 bits and have the same Q, and redistribute those 3 bits to other scenes in the future/past that might require more bits that originally thought. The only thing I can think is that your logic is telling you that TMPG is so perfect that it gets the Q level exactly right for each scene all the time on the first pass.
To me thats like assuming one one can type a long post such as this without any errors and get your meaning across the first time through. When the reality is that it is better to go back and reread it a few times, find where one might have left stuff out/mispelled/or need more info. Do they need to reread it a 100 times, no, but 2-3 times would make it definitely better than the just 1 time through on the first try.

Im not surely really how explain the theory to you more than that. But since you have said before, you have already agree to the theory that x-pass VBR is better, so Im not sure why you were even debating this to begin with. The only next step would be actually to do encodes and compare Q levels & bitrates. Which could basically pointless because we are talking about SVCD encodes and subjective viewing preferences. A lot of of factors such has DVD players & TVs get thrown into mix in determining that subjective preference as well. Yes what may be undetectable to you might not be to someone else, again that is a preference, not a fact. My personal determining factor is that I would rather know that I have my desire filesize and quality, even if I have to wait longer for it to be done.

So again..
TMPG CQ better than TMPG 2-pass VBR: Most likely
TMPG CQ better than CCE x-pass VBR: No
CCE x-pass for SVCD/DVD mpeg2 video: thumbs up
CCE x-pass for VCD mpeg1 video: thumbs down
TMPG for mpeg1: thumbs up
TMPG for mpeg2: Could be better, could be worse.

[Dave B]

I always like to look at things from a practical point of view - even though I understand the basic concepts and theories behind the two encoding techniques.

Both CQ and xpass VBR are fantastic algorithms (compared with CBR and 1 pass VBR) and I use them both extensively. I think one of the reasons this stupid thread has gone on for so long is that the algorithms are very difficult to compare as they have been designed for completely different purposes.

Consider these two scenarios:

Scenario 1
I often spend weekends away in dark, dingy corners of England with my friends and we take a video camera to record some of the "hilarious" drunken moments. When I return home I encode some of the embarassment to MPEG and email the video to my friends at work.

I don't care if the resulting file is 1MB or if it is 5MB, I just care that the video is watchable from start to finish. In this case CQ mode is the perfect algorithm to use. It won't waste bitrate like CBR and I know that high motion scenes won't break up under a swarm of macroblocks as the encoder has been given a free reign to use as much bitrate as necessary to maintain the quality I specified.

If I had used 2 pass VBR, I would have to predetermine an adequate average bitrate for the length and complexity of the clip. I would also have to wait for the encoder to make two passes. After all that, the 2 pass VBR video could still have been unacceptable if I had misjudged the average bitrate value.

Scenario 2
I was recently asked to produce a SVCD of my friend's wedding from his camcorder footage. The video was about an hour long and I wanted to put it on one CD. Now as much as I like the CQ algorithm I wanted to fill the whole CD to maximise the quality of the video. In this case I used the 2-pass VBR algorithm as it gave me the best quality when constrained to a filesize.

If I had used CQ then I would have been damn lucky to hit the 1 CD target size. If the CQ algorithm had produced a filesize less than 800MB then I would have wasted potential bitrate. If the filesize was greater than 800MB then it would have had to spill over to two CDs (in which case I would want to fill the second CD) or I would have to crop of the disco at the end (maybe not a bad idea )

Conclusion
I don't give a damn which of the two algorithms gives the best results with the same average bitrate and final filesize. Each algorithm has been designed for a specific purpose and they each do it very well.

I can't see a situation where I would have to choose between them.

[banjazzer]

Media does impose a limiting factor in the size of our file, which forces us to know how many bits we plan on using.

Yes, the size of the media is fixed. But the number of media is not. I would suggest that arguably most multi-pass exponents have a fixed idea of how many discs they intend using from the outset.

TMPG CQ better than TMPG 2-pass VBR: Most likely
TMPG CQ better than CCE x-pass VBR: No
CCE x-pass for SVCD/DVD mpeg2 video: thumbs up
CCE x-pass for VCD mpeg1 video: thumbs down
TMPG for mpeg1: thumbs up
TMPG for mpeg2: Could be better, could be worse.

I don't disagree with any of this, although it will be interesting to see if you have common ground here with your fellow multi-pass enthusiasts. 8)

My main point throughout is that if the average bitrate is chosen too low, the result will be poor, no matter how many passes, no matter what software. Now, if I understand you right, you are saying that with CCE the average bitrate will never be too low using its x-pass encoding mode. Fair enough. As I do not use CCE I can only go by what you say. Most of my argument applied to TMPGEnc's multi-pass mode, because that is what I am familiar with, and that is possibly what most mult-pass encoders actually use. I seem to recall that multipass VBR was held as superior to CQ independent of encoder by some, and later if I have time I will check the thread to see.

[dvd2svcd]

TMPG CQ better than TMPG 2-pass VBR: Most likely
TMPG CQ better than CCE x-pass VBR: No
CCE x-pass for SVCD/DVD mpeg2 video: thumbs up
CCE x-pass for VCD mpeg1 video: thumbs down
TMPG for mpeg1: thumbs up
TMPG for mpeg2: Could be better, could be worse.

I don't disagree with any of this, although it will be interesting to see if you have common ground here with your fellow multi-pass enthusiasts.

I agree 100% with kdiddy on this as this is what my test indicate too!

[injunpana]

Now, if I understand you right, you are saying that with CCE the average bitrate will never be too low using its x-pass encoding mode.

So what's your answer to this kdiddy and company? Your answer is most important because this has been our main point of contention against your sweeping statement of multipass VBR superior to CQ.

Thinking about it without your answer yet I don't think you should say yes. Okay, supposing you could fit a 140 minute movie in twp cdrs and have an excellent quality. How about if the movie has a director's cut and this made it longer to 170, will CCE still be able to maintain that average without running out of bits?

Supposing the average bitrate you set was just about right and worked perfectly on a 140 minute movie you encoded of mostly black and stationary scenes. Will this average bitrate be enough to provide bits for a same length movie but with high action scenes?

If you say yes, then this CCE is the mother of all encoders and I'll download it right away and swear off CQ.

[dudulho]

A Discursion like this needs some Guides to explain all scenarios.

Because many users of this forum are beginners (including me), I sugest that anyone whith experience in both scenarios make a guide to show us.

I think too only with discursing, the defensors of each side will say: "My method is better than yours!", and the discursion will never ends...

Sorry about my english, because i'm a brazilian, and write in a very poor english.

But I think I had said what I want it.

Well, who will make which guide? And then show the best method? Or the best method for each scenario?

The Challenge Starts!

PS.
BRAZILIAN SOCCER TEAM IS IN THE WORLD CUP FINAL NEXT SUNDAY!
Oh, my! My heart closely stops!

[Daagar]

Okay, supposing you could fit a 140 minute movie in twp cdrs and have an excellent quality. How about if the movie has a director's cut and this made it longer to 170, will CCE still be able to maintain that average without running out of bits?

Supposing the average bitrate you set was just about right and worked perfectly on a 140 minute movie you encoded of mostly black and stationary scenes. Will this average bitrate be enough to provide bits for a same length movie but with high action scenes?

But the same thing is true with CQ in this case! If I encode a 140min movie in two cdrs at CQ 78, chances are I'm going to have to drop the CQ to fit 170min in the same amount of space. Same with example 2, if I encode a movie at CQ 78 that is mostly black and stationary scenes and it fits exactly 1.6GB, chances are a high-action movie wouldn't, without reducing the CQ value. In both cases, x-pass VBR or TMPGEnc CQ, you _must_ trade some amount of quality for filesize.

Sure, you could keep CQ 78 and just let it spill onto 3 cdrs. But for x-pass VBR users, they could just allocate more bits and spill onto 3 cdrs as well.

That seems to be the problem with most of this thread. One camp values quality above all else, another camp values minimizing the number of CDRs used while maintaining decent quality. As others have said, there is nothing to argue about until tests are done with a _fixed file size_.

The question you must ask yourself up-front, is do you value quality first or reliability first.
Quality first: Pick a CQ level acceptable to you. Encode your file. It may fit on one CD, it may fit on 2 CDs. You don't know up front. If it bugs you, you can always try again at a lower CQ value to make it fit.
Reliability first: Pick an x-pass method and appropriate bitrates to fit x CDRs. Let it run. You are _guaranteed_ to have it fit _perfectly_ on x CDRs. However, the quality may not be enough. You can either recalculate for x+1 CDRs, tweak other parameters, or suffer with the quality you have.

Either way, you run the risk of not getting the quality you want in the size you want. CQ vs. VBR seems to let you pick your priority. In either case, you may _still_ have to go back and try again before being happy with the result. [/quote]