battle of the CBR/VBR/CQ modes

[dvd2svcd]

It seems to me that what all the CQ people are forgetting/unwilling to discuss is the importance of the final filesize, why is that. The filesize must be the point of reference.

I can understand why DVD studios would prefer CQ above VBR. They want to maintain the same quality no matter what the movie type and length are, and they don't care about the final filesize. However, when doing SVCD it's another matter.

[dvd2svcd]

Baldrick you gotta do something about this. I am getting an error when submitting a post. Then I retry and voila I've made a double post

[banjazzer]

It seems to me that what all the CQ people are forgetting/unwilling to discuss is the importance of the final filesize, why is that. The filesize must be the point of reference.

The filesize is not important to some of us, but the quality setting is. The idea is not to be concerned about filesize by constraining it with an average bitrate. The 2-pass VBR encoder wants filesize determined at the outset. The CQ encoder wants the quality-setting determined at the outset, and the filesize can be anything.

This point has been made over and over throughout this thread, and it seems the disciples of x-pass VBR cannot comprehend it. I think it's best to say we don't agree. 8)

[injunpana]

Nice explanation Wicked_Al, but sorry it'll fall on deaf ears - the VBR proponents just can't comprehend it. First htere was banjasser, then there was me and kwag telling exactly the same you said, to no avail. Instead , we are accused of being stupid in so many words.

Why is it so hard for them to understand that working with no bit limitations is better than working with a limit. Or in your example, no budget limitations as against a super-super-super-super efficient budget allocation BUT still with a limit. Go figure.

Good luck! Take the cudgel, man!

[injunpana]

It seems to me that what all the CQ people are forgetting/unwilling to discuss is the importance of the final filesize, why is that. The filesize must be the point of reference

I can understand why DVD studios would prefer CQ above VBR. They want to maintain the same quality no matter what the movie type and length are, and they don't care about the final filesize. However, when doing SVCD it's another matter

Of course we care. We care that the final result should fit to one or two 800 mb cds depending on one's preference. That's why we've been saying all along, take a movie and fit it to that 800 mb cd using VBR. Tweak it, use any average you want, do anything and do the same with CQ. Look for a CQ level that would optimize that 800 mb cd, tweak it, then let's compare the final result. That's all we've been asking.

[dvd2svcd]

It seems to me that what all the CQ people are forgetting/unwilling to discuss is the importance of the final filesize, why is that. The filesize must be the point of reference.

The filesize is not important to some of us, but the quality setting is. The idea is not to be concerned about filesize by constraining it with an average bitrate. The 2-pass VBR encoder wants filesize determined at the outset. The CQ encoder wants the quality-setting determined at the outset, and the filesize can be anything.

This point has been made over and over throughout this thread, and it seems the disciples of x-pass VBR cannot comprehend it. I think it's best to say we don't agree. 8)

If quality is such an issue and filesize isn't, then why not always use the highest possible CQ value always?

[injunpana]

If quality is such an issue why not always use the highest possible CQ value always?

Because we want to fit the movie in one or two 800 mb cdrs. That's why we compromise by looking for that CQ level that would make us hit our target.

Because CQ allocates bits from the point of view of maintaining quality, it does it differently from VBR (VBR allocates from maintaining an average bitrate point-of-view) so that's why it is harder to predict the final size for the former. That's the only advantage of VBR over CQ as we've been saying all along.

[banjazzer]

If quality is such an issue why not always use the highest possible CQ value always?

I always do use a pretty high CQ value. I said quality is a more important consideration to me than filesize is. I don't mind having to add an extra CD if necessary, even if some of the last CD is blank. However, i don't want half a dozen CDs used per movie, not because the cost, or waste, bothers me in any way, but because I don't wish to have to change discs that often. 8) Size really is not an important issue issue. Quality is. However, beyond a certain CQ level I would be unable to detect much difference. So there is as little point using a CQ setting of 100 than there is using a CBR encode and choosing the maximum quality setting possible. If I was that hung up about quality, I would buy the DVD.

[offline]

Hey,

If you are after the very best quality for whatever bitrate
just use the manual quality feature under CCE. Just click
on Advanced after doing a single pass and you can
ajust the quality/bitrate yourself to achieve the nearest
to DVD quality PIC available outside a production house.
no lie Only discovered this myself a few months ago.

[dvd2svcd]

If quality is such an issue why not always use the highest possible CQ value always?

Because we want to fit the movie in one or two 800 mb cdrs. That's why we compromise by looking for that CQ level that would make us hit our target.

Because CQ allocates bits from the point of view of maintaining quality, it does it differently from VBR (VBR allocates from maintaining an average bitrate point-of-view) so that's why it is harder to predict the final size for the former. That's the only advantage of VBR over CQ as we've been saying all along.

So you would agree that my test would be a valid test (look further up in this thread)?

I always do use a pretty high CQ value. I said quality is a more important consideration to me than filesize is.

Then I would say that you don't belong in this discussion. That would be the same as I said, "well I'll just use the highest possible bitrate all the time when doing SVCD", c'mon man, that's not an argument you can use.

--

Basically the difference between the CQ folks and the VBR folks is that CQ will settle for constantly shitty or constantly good quality. Whereas the VBR folks want to maintain the best possible bitrate depending on the complexity of each frame and still hit the predefined filesize?

[Greyhair]

Can someone please explain to me why or when file size is irrelevent?

I guess in a situation that you have alot of headroom, i.e. a 30 min video put on a dvd-r or something like that. Otherwise, seems to me that in other than a theoretical sense, file size DOES matter to determining the quality of the final product. Quality isn't some etherial concept, it's exists as real world product.

[injunpana]

So you would agree that my test would be a valid test (look further up in this thread)?

Oh yeah, I most certainly agree.

As I've said earlier, it is too easy to put an average length movie by any method (CQ or VBR) to two 800 mb cdrs and get a good quality and is indistinguishable by the naked eye even if they really are not equal. So let's up the ante and use a very long movie so to magnify the difference in quality if there is any. Let's use the 2 hour and 51 long minutes THE ABYSS.

I've already done this test and I know which looks better. If you want to find out, you coud try it too. Remember though that you have to fit the complete movie in two cdrs or 1600mbs worth of bits.

Do you, dvd2svcd, want to take the encode challenge?

[injunpana]

Forgot to add, you can use any tricks or tweaks you know. Change your bitrates, resolution, GOP settings, or matrix quantization, whatever you want. The only constant should be the end-product fits the 2-cdr capacity limit.

Have fun, I had.

[dvd2svcd]

Sure, except I don't use TMPGEnc anymore I use CCE. Will you accept the challenge that I use CCE and you use TMPGEnc? Let this be a fair fight, one which we both can reproduce both by you and me. And let's keep it clean.

We need to agree on some things:
1. Let's produce just the video (no audio)
2. We have to agree on doing PAL or NTSC.
3. The bordersize (if any) must be equal so to maintain the same aspect ratio.

I don't have The Abyss. And mostly what I have is PAL (some NTSC). How about The Matrix in PAL?

[banjazzer]

Then I would say that you don't belong in this discussion. That would be the same as I said, "well I'll just use the highest possible bitrate all the time when doing SVCD", c'mon man, that's not an argument you can use.

I don't use the highest possible bitrate all the time. I use sufficient quality setting to ensure a high quality result, and I never get caught out. The bits and filesize take care of themselves. If you can't cope with what I say, you don't belong in any discussion.

Basically the difference between the CQ folks and the VBR folks is that CQ will settle for constantly shitty or constantly good quality. Whereas the VBR folks want to maintain the best possible bitrate depending on the complexity of each frame and still hit the predefined filesize?

No, the difference between x-pass VBR folks and CQ folks is that the latter don't get upset if they waste some CDR space, because they are content that they will get the quality, because that's how they approach the encode.

[dvd2svcd]

I don't use the highest possible bitrate all the time. I use sufficient quality setting to ensure a high quality result, and I never get caught out. The bits and filesize take care of themselves. If you can't cope with what I say, you don't belong in any discussion.

Good, then the fact remains. Given the same filesize CCE VBR (3 or 4 pass) always is better than TMPGEnc's CQ. But I am no fanatic if injunpana can come up with settings in TMPGEnc that is better (better=closer to the original source) than CCE's 4-pass vbr, well then I wont have problems admitting I was wrong and I wont have any problem switching back to tmpgenc. I, as you, want the best quality too. And as it stands now, CCE VBR is the better choice imho.

(But if you compare TMPGEnc's CQ with TMPGEncs's 2-pass VBR I too would go with CQ)

[banjazzer]

(But if you compare TMPGEnc's CQ with TMPGEncs's 2-pass VBR I too would go with CQ)

Whoopee!!! A breakthrough. Unlike some people here, I only talk about what I have personal experience of. I only use TMPGEnc. I don't have CCE. So maybe I should now feel bad because I have a grossly inferior encoder? 8) 8)

[dvd2svcd]

Hmm, strange as I have seen many argue for CCE in this thread too so I thought that was valid, sorry. Well, comparing tmpgenc's CQ to tmpgenc's VBR there is no doubt I would go for CQ any day. But that is due to the fact that TMPGEnc sucks at VBR and not because CQ is superior to VBR.

[Wicked_Al]

Well, the reason I'm saying filesize doesnt matter is because the moderators said that VBR will always give you higher quality. They even said it was a fact. Perhaps they meant at the exact same filesize, not within a few percentages, but the exact same file size! Maybe they even said it once, but they repeated essentially the same thing over and over simply saying "VBR wll always give you higher quality...its a fact you idiots!". If my understanding is correct, you use the two methods for achieving different results: size or quality and time.

Filesize is somewhat important, but it seems most people spread their stuff over 2-3 CDs. With CQ you may not use every last bit of a CD, but the quality is going to be consistent, but with VBR it seems that some CDs may have better quality than others. The average bitrate may be the same, but some scenes are going to look good and others not so good.

Using either method seems like its going to take some trial and error when you're attempting to fit things on a fixed number of CDs, so I don't necessarily see how one method is better than the other. In my personal experience, I use CQ like a quick 2 pass VBR. I use King Vipers SVCD template to put an entire movie on one CD. The default quality is 50. I encode about 10-20%, then calculate how big the file is going to be. If I'm going to have extra space I stop the encoding and usually start again with a quality value of 60 to 70, and most time it'll go within 650 to 700 MBs. In general with this template whatever size Divx file you have will be the maximum final size, but often its a lot less, so you can increase the quality. The reason I don't use 2 pass VBR is because of the time it takes. I'm sure that if I did 2 pass VBR the quality would be close, perhaps even better when fitting to exactly one or two CDs, but its still an unknown. If the quality is not what you want then you have to re-encode everything again. I suppose you could do the same 10-20% sample that I use with CQ, but thats turns into 20-40%, which is too much time to encode for a test IMO.

For the record, I'm not "CQ people". I am a "Put it on one CD with acceptable quality because I'm too lazy to switch CDs person."

[Kdiddy]

But if you compare TMPGEnc's CQ with TMPGEncs's 2-pass VBR I too would go with CQ)

Whoopee!!! A breakthrough. Unlike some people here, I only talk about what I have personal experience of. I only use TMPGEnc. I don't have CCE. So maybe I should now feel bad because I have a grossly inferior encoder?

Again thanks for backing up my point that your only experience with mpeg compression is through 1 application. Now everyone nows why you have such an illogically based assumption of CQ.

Hmm, strange as I have seen many argue for CCE in this thread too so I thought that was valid, sorry. Well, comparing tmpgenc's CQ to tmpgenc's VBR there is no doubt I would go for CQ any day. But that is due to the fact that TMPGEnc sucks at VBR and not because CQ is superior to VBR.

Yes indeed DVD2SVCD, I have said it since the beginning that TMPG's 2-pass VBR is piss poor. So one should expect TMPG's CQ to better than its VBR option. But that seems to be a fact that these "CQ bible thumpers" seem to ignore or completely choose not to read.[/b]

For the record, I'm not "CQ people". I am a "Put it on one CD with acceptable quality because I'm too lazy to switch CDs person."

Can't blame a man for his honesty. lmao

[banjazzer]

Thank God I'm an atheist. 8)

[kinneera]

The filesize is not important to some of us, but the quality setting is. The idea is not to be concerned about filesize by constraining it with an average bitrate. The 2-pass VBR encoder wants filesize determined at the outset. The CQ encoder wants the quality-setting determined at the outset, and the filesize can be anything.

This point has been made over and over throughout this thread, and it seems the disciples of x-pass VBR cannot comprehend it.

We comprehend the philosophy behind CQ. But the essential point that has been made over and over and that is so painfully simple is that if both methods of encoding produce a file of the exact same size - and it is possible to accomplish this - the one with multiple passes and thus a priori knowledge of the video is going to look better. Not one of you CQ proponents can give one single, logical, response to this concept:

Same number of bits, allocated more intelligently.

kinneera, you obviously don't know peanuts. I just gave a software engineering explanation above, and you completely refuse to accept it.

You are no more a software engineer than I am the pope. Just because you can write a formula doesn't make you an engineer. Come up with an actual, logically reasoned response to any of the major points made by two moderators and several senior members of the forum rather than petty insults and bogus self-aggrandizing claims and you might regain some sliver of credibility.

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.

You have already well-proven your inability to analyze the credibility of sources, the content when sources are credibile, relevant graphs, or the basic concepts of MPEG encoding. If you actually were capable of any worthwile analysis at a higher technical level, then you would have presented it up front rather than pretending "it's not worth it." The only advice that is a shame is that which tells people to use an encoding method that performs a single blind pass that results in less intelligent, less efficient bitrate allocation and which will inevitably result in wasted space. Make an actual argument, anything with any technical or logical credibility, or shut up!

[kinneera]

P.S. - I honestly don't think there is anything wrong with CQ if you want a quick encode and don't mind wasted space. But given proper parameters and the extra time commitment required, multipass will always be able to outperform the CQ, it is simple logic.

Oh yeah, and wasted space = fewer bits = fewer bits per pixel = lower fidelity = wasted quality potential. Period.

[injunpana]

I just noticed, if you read through the whole thread, why is it that the VBR proponents always have that "hot under the collar" tone in their posts? Starring Kinneera and that moderator, Adam , I think. Hey this is just a discussion people! If you can't take the heat, get out, then come back when you're cool-headed.

Again thanks for backing up my point that your only experience with mpeg compression is through 1 application. Now everyone nows why you have such an illogically based assumption of CQ.

There was an earlier thread sometime back wherein kwag made innumerable tests comparing Tmpgenc and CCE on mpeg1 and mpeg2 and linked the mpg results for everyone to download. you totally disregarded the results and just declared he doesn't know what he was doing.

[Kdiddy]

Quote:
Again thanks for backing up my point that your only experience with mpeg compression is through 1 application. Now everyone nows why you have such an illogically based assumption of CQ.


There was an earlier thread sometime back wherein kwag made innumerable tests comparing Tmpgenc and CCE on mpeg1 and mpeg2 and linked the mpg results for everyone to download. you totally disregarded the results and just declared he doesn't know what he was doing.

First, if you going to quote me, quote me in the correct sense. Kwag did not make the statement I quoted. That was "banjazzer", and that statment was in response to only him. Which leads to me second issue.

We only have an "hot under the collar tone" as you put it simply becuase of the illogic that is presented all the time by "CQers" and those like yourself who misquote people.

Lastly, Kwag has previously demostrated prior to this ridiculous thread his ineptitude at use CCE correctly. This is someone who at first claimed he had "DVD Quality on 1 disk of any movie with 720x480 mpeg1, and that mpeg2 below 3000 kbps was crap". Im sorry, when someone makes outlandish statments such as that, their credibilty goes in the toilet. And then when confronted with facts he has repeatedly his famous "Kwag backpedlle & shuffle", to mean he quickly changes he story. Ask him how many times he blatantly told people "you didn't use my template correctly" when they have stated tha they didnt like the video that his CQ encodes produced.

So for the last time. Likeing CQ over VBR boils to personal taste, you like it, it works for you, fine, that's your opinion, no one can argue or rebuff that. 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.

[injunpana]

Sure, except I don't use TMPGEnc anymore I use CCE. Will you accept the challenge that I use CCE and you use TMPGEnc? Let this be a fair fight, one which we both can reproduce both by you and me. And let's keep it clean.

We need to agree on some things:
1. Let's produce just the video (no audio)
2. We have to agree on doing PAL or NTSC.
3. The bordersize (if any) must be equal so to maintain the same aspect ratio.

I don't have The Abyss. And mostly what I have is PAL (some NTSC). How about The Matrix in PAL?

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.

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.

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

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.

[injunpana]

Quote:
Again thanks for backing up my point that your only experience with mpeg compression is through 1 application. Now everyone nows why you have such an illogically based assumption of CQ.


There was an earlier thread sometime back wherein kwag made innumerable tests comparing Tmpgenc and CCE on mpeg1 and mpeg2 and linked the mpg results for everyone to download. you totally disregarded the results and just declared he doesn't know what he was doing.

I quoted you to spotlight you castigating Banjasser because he was only using one application. My paragraph after it is to comment that someone other than Banjazzer does have a experience with both methods and did make innumerable comparison tests between the two. Only that when he made a conclusion that you did not like, you totally dismissed him and in your own words as simply inept.

Wow! Must be nice to simply wave your hands and simply dismiss a whole group as illogical or inept just because they don't agree with you. To be honest, we also see you VBR advocates as illogical but so far most of us have been calm and didn't throw any tantrums and insults such as that moderator and you.

And by the way, c'mon ......CALM DOWN.

[injunpana]

Again thanks for backing up my point that your only experience with mpeg compression is through 1 application. Now everyone nows why you have such an illogically based assumption of CQ.

Why would it be illogical for him to conclude that CQ is better than VBR when this is what he found out to be true with the application he used? It would be more illogical for him to conclude the opposite. Think about it.

Just nitpicking, nothing to do .....

[Kdiddy]

Only that when he made a conclusion that you did not like, you totally dismissed him and in your own words as simply inept.
Wow! Must be nice to simply wave your hands and simply dismiss a whole group as illogical or inept just because they don't agree with you.

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.

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.

No, because CCE does it correctly is not proof enough. Many others have posted on this thread the basics of mpeg encoding is the reasoning, CCE is just one of several encoders that are proof of that encoding. CCE just happens to be the best. TMPG simply is not at VBR. Again, you can not use a bias encoder as the whole basis of your proof. (Especially when thats the only encoder he admittedly said thats he has used.)

Why would it be illogical for him to conclude that CQ is better than VBR when this is what he found out to be true with the application he used? It would be more illogical for him to conclude the opposite. Think about it.

It would be logical to come to that conclusion with that being only reflective of TMPG encodes. However, he is of the conclusion that because he perceives TMPG as doing CQ encodes better than VBR, that as a whole, no matter what encoder, that CQ is better and x-pass VBR no matter what the scenario. Which follows the same logic as "since the one irishman sheepherder I know, likes have sex with his sheep, all irish sheepherders like having sex with their sheep.

didn't throw any tantrums and insults such as that moderator and you. And by the way, c'mon ......CALM DOWN.

Im so tired of seeing pointless statements like this. Don't mistake passion for anger. If this truly angred me, I would not bother to post here. You don't know me, and I have yet to insult anyone on this thread. If anyone has taken anything I have said as an insult, then they have some self-esteem issues. O by the way, here is what Kwag had to say "kinneera, you obviously don't know peanuts.". It's a 2-way street.

[vitualis]

I think I'm going to give up.

People, please read the long detailed post I made (??page 4) previously. It is a long logical discussion on why multipass VBR will (in theory at least -- read the caveats too!) always do better than CQ.

No one as yet has come up with a logical argument against the principles in that post.

As kineerra stated previously, we all understand the philosophy behind CQ. However, the issue is, how does it actually work especially within the limitations of SVCD.

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.

Regards.