Maybe theres a hint/solution. When using CQMatic i've let CQMatic open and only loaded the new project file again (with different project settings).
I've closed CQMatic and reopened it again and the bugs disappeared
Now it seems that its searching the right CQ value also with CQ=40 at start.
I'll keep an eye on this.

EDIT: Dump question, but are you initializing values when a new project file is loaded

TmpgEnc Plus 2.512.52.161, WinXP.

That should be fine. I'm on XP too, but TMPEG 2.520 ( 2.512 should be ok too )
OK, this is on my top priority for today. I just wich I could reproduce the behaviour here, but I havent
Anyway, back to the source, and hopefully find something today

Quick idea
Try setting your initial CQ to 100. I want to know if the problem is related to starting from a low CQ on the first start on a increasing scale, instead of starting very high on a decreasing scale. This means a LOT for my internal algorithm

-kwag

Hi Kwag,

Starting CQ at 100 brings illegal stream format error. With 90 its working.
Well, also with a restart of CQMatic the CQ stucks at 43 when starting with 40, but the error where it is encoding directly after one prediction and taking starting CQ is gone with the restart. Have you read my (edited) post above
I'll post the results with CQ=90 later...

Not a dumb question at all
That's exactly where the problem must be
Every test I've done, has been running CQMatic, and then exiting. So I haven't encoded a second movie without exiting CQMatic. So obviously, it's variables with previous values.
Verifying this, and then BETA 6 will be posted

-kwag

That would explain why it was directly encoding after one prediction

Exactly


-kwag

Here they are :
90, 80.12, 75.18, 72.71, 71.47, 70.86, 70.55, 70.39, 70.32, 70.28, 70.26, 70.25, 70.24, 70.24, 70.24 ....
Right CQ should be about ~60.

excuse me....

prediction results using CQMatic 1.0b5 with small source.
souce 31 minutes,average 1070,wanted size 290mb
one project for each new start CQ and the same source!

starting with CQ100 don't work, "CQ ABOVE watermark"

starting with CQ90 give final CQ62,96

starting with CQ60 give final CQ63,10

starting with CQ50 give final CQ63,15

then like J.Lennon in "good morning" from sgt peppers sung:
"nothing is change,still the same,
i've got nothing to say but it's ok!
good morning, good morning SIR!

CQMatic 1.0 BETA 6 is up
http://www.kvcd.net/cqmatic-1.0b6.exe

Fixed: Cleared some variables that were clobbered when running CQMatic more that once, without exiting.
Added: Exit condition when last CQ = next CQ

Please try it, and report if it does exit now, and doesn't hang in a loop

-kwag

hi guys

well, hope you can answer me this question

cqmatic seems to work properly, tries 4 times to find the right cq, ok...

but then, the file size is much too small , and i think of the following :

i use pal sources, and then, i encode it as 16:9 ; perhaps the black borders are the thing, why the filesize is getting too small ?
anyone had this problem too?

Is your source range cleared
That is, start frame = 0, end frame = -1, and Cut Edit list is cleared

-kwag

yes of coure it is

check it every time!

If BETA 6 still locks in a same CQ value, please let me know immediately, because then the problem is a floating point rounding comparison error, and then I know what to do next

-kwag

Hi tigger,

Is your source a .d2v or avi (MPEG-4, DivX, etc. )

testing it now

Yesterday i had a similar idea:
We already had the same problem once. The OS is localized with , . ; etc. I've just tested this and found no difference. But maybe there is one.
Maybe thats the difference in accruacy we have

EDIT: BTW, Beta 6 is quicker finding right CQ...

Let's see it BETA 6 did fix the error. If not, the problem is clear. The CQ values you see in the log, are actually truncated to 2 precision digits. So you may see a CQ of 62.12, when it's actually 62.1234567 etc. Obviously, I can't compare "Last CQ = Next CQ", because the chances of hitting a 62.1234567 = 62.1234567 are almost endless. And that's the problem with the CQ scaling. It's not linear, and once I get close to the target, CQMatic will start comparing something like 62.12345 and 62.12999 which are different, and never end
So I'm fixing that to take into consideration, if the floating point difference in CQ is < 0.2 (that's just an example), exit with a CQ found flag, and start encoding

-kwag

Well, still have the same error. Repeating CQ value is now 54.76 starting from 60.
I think that floating point issue could solve that, thx

Hold on
I'm finding the correct treshold to break out. I'll post BETA 7 (Hopefully the last BETA for this issue )
Keep an eye here, in the next few minutes.

-kwag