But I used a one CD target, at 352x240, so that could also be a problem.
I've tested 704x480 NTSC and 704x576 PAL, without any problems.

-kwag

TMPGEnc has always been disappointing in this area.

I would like to see more emphasis on NuEnc, as soon as Peter Cheat can release a stable and bug free version of it.

A combination of CQ Matic + NuEnc would be great.

I don't like to use TMPGEnc at all, because it is simply inaccurate. Predicting the CQ Value with TMPGEnc is always a gamble.

We all should leave the chapter TMPGEnc behind us...

Tmpgenc (MPEG1) gives the best quality whaetever the encoder you try to challenge with it. I have perhaps 1 movie on 20 that gives problem with CQMatic. People having more problems than that never understood that this the the MA script that is the guilty
With a static (linear) script, the accuracy of CQ prediction is very effective.

And the visual quality one ?

TMPEG is still the king, as far as MPEG-1 quality and mpeg (stream) compliance.
NuEnc and all other avcodec based front ends are still very buggy.
Sure I'll add support for NuEnc. But only when it reaches stable useability

-kwag

Hey Phil,

I just re-did Harry Potter, but this time the target was KDVD 704x480.

Wanted size: 1,818,424 KB
Encoded size: 1,808,832 KB

Diff: 0.53%


-kwag

For my part I did not have a closer result with official release than with the RC2. But there were close.

Okay, this has only happened to me once and only once. I set up to do a full encode of a movie -- The Bourne Supremacy (Fullscreen NTSC) if it helps -- and at phase 2 of cycle 3 I was presented with an interesting error. I can't remember the exact text, but it was something along the lines of "Illegal floating point operation." Something like that. It occured halfway through the phase, not at the beginning. Needless to say the next phase was using a significantly higher CQ value, and I had to restart the process.

The bug hasn't happened in this run thus far, so I don't know if it's a major problem. But it's there.


Oh yes, I'd like to request an option to add cycles to the prediction process as a means to increase accuracy(sp?). I usually leave my computer encoding while I sleep or while I'm at school, so if the process takes 6 hours I'm not going to mind.

Hi yukichigai,

The only time I've seen that floating point error was once, and I believe the probem was in my source. I haven't experienced that problem for months. It's not related to CQMatic. It's either the ".avs script/.d2v/source" combination.
As for the increased accuracy, yes I could add an option where the final algorithm that CQMatic uses will try to focus down on a narrower final file size target percentage.
This of course could take 2 to 3 times the current prediction time, but as you say, it's an option for leaving ovenight and forgetting about it
I'll add something for the next version, later this weekend or early Monday.
A "deep-mode" prediction option.

-kwag

This is a well know tmpgenc"s bug that you can solve, when you encode manually, by changing a little the CQ (add or remove 0.1).
If this happens when you use CQMatic, then you are unlucky...

Well, here you have it: http://www.kvcd.net/downloads/CQMatic-1.4.07.exe


Added: Deep prediction option.
If this option is checked, the final size for prediction is 0.5% to wanted file size. That means that samples will target a sample size within 0.5% of wanted file size, per cycle.
If this option is not checked (default), then 2% file size precision is used for prediction.

-kwag

Sweet, thank you very much. This will come in handy.

Also, I found another bug, maybe. After I got a good render of the movie I tried to go back and do an SKVCD (352x480 MPEG-2) render. CQMatic flipped out. The prediction cycle, the ENTIRE cycle, took under a second, and the final CQ value was always 89.something. This produced a file that was too large, so it wasn't an accurate prediction.

So, yeah, you might wanna take a look at that.

Thanks again for the Deep Prediction option. This will make further projects much easier.

What do you mean by "Go back" ?

If you opened tmpgenc, changed some settings, and saved again the project then you forgot to RESET the range editing. This must be done anytime !

I made sure to make a completely new project. I started from scratch. It still flipped out.

There was no range editing involved. If I ever need to edit the range I render I do it with DVD2AVI, so as not to make CQMatic freak out.

I arrives that I neverf close CQMatic for a complete week. Doing encoding after encoding. I can tell you that if you do everything correctly, it works !

So explain better what you call "going back" ???

By "going back" I just meant "went to encode the Bourne Supremacy again".

As far as what I did, I opened the d2v file again, loaded the SKVCD template, made sure it was set to 4:3 display, full screen video arrangement, no source range edits, then saved it as a text project. I did exactly what I did for the KVCD encode, except I loaded up the SKVCD template instead.

And then you load the new project into CQMatic and start the process ?
That's what I'am doing anytime !
Look at your log file, if all size are negative, then you have a range editing problem.

Note: perhaps the problem is when the new project has the same name than the previous. I never did that.

I dunno what the problem was, but after a number of times hitting "new project" it cleared up. Huzzah.

Anyway, I used the new Deep Prediction option on The Village (Fullscreen):

Target filesize: 679520kb (663.59mb)
Actual filesize: 704676kb (688.16mb)

Oddly enough, it didn't seem to take any extra time. Not sure if this is indicative of the overshoot or what.

Once again, I've gotten the odd "Illegal floating point operation" error, and not just once. It only seems to occur with the Deep Prediction option checked.

This is not a CQMatic problem
This is a TMPGEnc problem, with a particular source/script combination

Quick test: Note down the CQ value that was used when the error appeared. Run TMPGEnc at that same CQ value, with the same script, and the error should re-appear.

-kwag

Not necessary because this problem often occurs at a scene change so if you encode the whole film you can have no problem has the scene changes are differetn during prediction (encoding of a sliced sample).

But as you tell, this is not related to CQMatic.