Hey all. Been lurking for a couple of days now, learning all I can and tinkering around with the various templates. What I'm basicly looking for at the moment is an informed opinion about which is better, high CQ/Low resolution, or low CQ/High resolution?

I'm currently making a KVCD for a friend who is not much of a videophile and still watches VHS. Since the movie I'm encoding is 1h 46m, CQTester is coming back with a CQ around 62 (TMPGEnc) using 352x480 resolution. If I lower the res to 352x240, the CQ jumps up to 79. From what I've gathered so far, the CQ rate controls overall picture quality right? So which is the lesser of two evils?

Stay with 352x480 as the picture will look more sharp and you wont recognise the artifacts that much on a TV Set. The lower the resolution, the higher the CQ but on the other hand the image AND the artifacts (even at CQ 79) will be scaled 4times! (2xheigth 2x width).

It's always best to keep the vertical resolution at 480(NTSC) or 576(PAL).

Thanks fellas. I ran it through CQMatic last night and it gave the 352x480 MPEG-2 a CQ of 71, so I either had something set up wrong originally, or CQTester is not nearly as accurate as CQMatic.

Now all it needs is a batch function.......

Thanks again.

CQMatic (v1.4.00) should be quite accurate, or at least as accurate as it can get with TMPGEnc which has its problems concerning the nonlinearity of the CQ curve.

Hi guys ,
I am doing lot's fo tests with Tmpgenc 2.524 and CQMatic 1.4.00 and I gotta tell you, it is pretty accurate.
Only failed me once so far, on more than 10 attempts.
And even then I just had to run it again, as Karl already told us.
Tmpg&CQMatic is a very much appealing package.
Cheers

__________________
Rui

We found a case where CQMatic fails but Karl already fixed it and gave me a (private ) beta to solve that .
I'm currently doing tests to see if this fix for this particular type of source does not screw "normal" predictions. But my PC is slow, and I need more than 6 hours to be sure of the result . Stay tuned.

Note: the problem is on sources with very few camera movement and scene changes. In my case it was a one man show. I guess that with music band show it should be the same.

Scenechange option active in TmpgEnc when encoding via prediction???

I dont know Karls Formula, but it got its reason why slices of sample units in the known predictor apps do got the same value as the GOP like 25, 24 or 15, 18. So the "sizes" of these slices wont change, means less arbitary bitsizes will result (=more "I" Frames in the same time, means a significant rise of encoded bits). But they will do change suddenly if a SC option is set. Thats an issue which makes prediction even more complicated. (nor matter which special formula is used)

Hi Andrej,

The new version of CQMatic takes care of that
The way you set up TMPEG is the way it will encode, and will take many factors into consideration during prediction. So you can have scene detection on. I always do. So it doesn't care what the source is, and it should predict anything you throw at it.
The version Phil is testing now has a quick "calibration" phase before the actual prediction phase. That takes care of linear compressibility vs. random compressibility, and makes some internal factor adjustments

-kwag

God damn
Is this guy amazing, or what
Nevertheless, it has worked fine for me.
Fortunately my system is predicting+encoding in <3,5 hours for a ~2hours movie.
And it just failed once on many attempts so far.
Though my sources are all medium to high action and allways a bit dark.
And unfortunately with Tmpgenc they are getting even more darker
Still need to find out why this is happening.
But I'll do some more testing and I'll post the results.
Cheers

__________________
Rui

Same here
And that's exactly what I'm trying to minimize even more

-kwag