This point is also known and was already discussed on the forum. CQ_VBR is not good for hig action scene BUT it is far better in VCD res than CQ for evry other scene (I am talking about MPEG1 as I never do MPEG2).

So the choice as to be done according to the "actioness" of the movie.

I know that it was discuss. But did you see the pic's above?
They say another and there are more blocks at a resolution of 352x288 with CQ_VBR.

CQ vs. CQ_VBR

I did see the pics. Please re-read my previous post, and maybe look at OUR PICS in this thread, which contain HOW the samples were done WITH data to prove the points.

-kwag

And I would add something : I do not use CQ_VBR for VCD resolution because someone (even if he was kwag) told me to do like this . I use it because I tested it and compared to CQ. And I trust the one and only tool I ever use : my eyes.

Do not follow foreign advices, test it by yourself and take the one you prefer.

I use MPEG1 where others prefer MPEG2.
I do not use the MA script when others say it rocks.
I never encode the audio in dual chanel mode.
And I use tmpgenc for muxing.

You aren't a number, you are a free man .

What do you think I've made with this screens and you have to admit that the CQ pic's are sharper and less of blocks then CQ_VBR.


I know!

I didn't notice these snapshots were yours.

So we are still at the point we were in my first post : the choice must be done according to what is in the movie.

And I agree with you that in the present case, CQ is better than CQ_VBR.

Well CQ or CQ_VBR......

in these samples above I see a total horizontal distortion/frequency cutting! Thats the one which would make me think about it, the CQ or CQ_VBR is not the problem in these pics.
It seems like a very overdone cutting using DCTFilter or the right colums of the DCT matrix.


Inc.

pfew.. another long thread.

Listen, I remember following this very long thread (when it was short, way
back when SansGrip was adding his research knowledge etc to it)
and even then, it was considered long. Anways..

I remember following it while at work (every day) and it was fun and very
interesting indeed. This was the kind of thread/topic etc that I always looked
forward to while at work. Anyways..

I think what was kwag was saying is that you need to first read through the whole
thread (not just the tail end) because you miss so many key points, of which
led many of those that did the painstaking research (and testers) a great
deal of time and effert to conclude to. And, many of those key points were at the
beginning and then some. There are many key factors that led one here, to there
and so on and so forth.

So, w/ the above in mind, all those sample pics that you see (afer reading) should
be followed (to the letter) those settings used in TMPG (that includes the proper
bitrate settings, and those w/in the scope of the CQ vs. CQ_VBR analysis) and the
various Filters that were used during the testing (and debating) plus the various
.AVS scripts that were used, and the source type (Resident Evel, for instance)
(yes, like I said, I read it) and some ofthe tools used to compare the pics as
well as the encodes etc :P

.. .. .. getting some coffee .. .. ..

-vhelp

Sorry, I had technicle issues w/ my pc..

As I was saying..

I remember those that contributed, rendalunit, jorel, maudib, jellygoose, kwag
el_mero_zooter, black prince, GFR and others.. the list goes on.

Check page 8, for intance. And, notice the CQ vs. CQVBR pics.

Did you use the same source files as those in the test threads here ?
Did you use the same .AVS scripts; filters; settings; bitrates etc etc etc ?
Again, all within the same params as those in the thread, and matching the
same sources etc etc.

Course, TMPG has evolved since that time, two years ago. So, the CQ/CQVBR mode
may have improved. Which in actuallity, my cause your argument to become
null'n void :P

That's about it,
-vhelp