CQ=60.00: Difference: 0.862563
CQ=51.75: Difference: 0.974991
CQ=51.75: Difference: 0.974991
...
m1v.Sample-filesize with 51.75-CQ: 2,392,064 Bytes
m1v-filesize with 51.75-CQ: 3,973,120 Bytes

Any idea :?:

@krassi,

I have the same problem starting with a CQ of 60.

I cancelled it in the end. I haven't tried by starting with a different base CQ, I'll do that now.

Fiz.

Got it working with another CQ at start :?:

I'm having the same problem as Krassi and Fiz where after 2 prediction samples, CQMatic keeps sampling at the same CQ! I find that if I cancel and restart with a CQ closer to the "stuck" value, that prediction completes as normal. Very weird bug.

I'm having the same problem also with the resampling of the same cq after 2 tries.


David

Hey! Same problem with repeating CQ here too!

Working on it ....


-kwag

Please download this: www.kvcd.net/cqmatic-test.exe
Try to use the same starting CQ that continued in a loop.
See if this fixes that.

-kwag

The behavior is different :D . The second CQ was 55.88, third was 53.38.

Great :D
sorry :!: :oops: :imstupid:
:x

The condition shouldn't repeat :!:
I'm updating the regular cqmatic.exe to the same version as that test file now ( BETA 2 )

-kwag

I'm sorry to inform you that its still there. It only needed about 10 tries to find the same 51.75-value where it hangs. Sorry. :roll: :oops:

:x :x :x :x :x

Thanks :!:
Priority #1 to fix today
Stay tuned :!:

-kwag

Here it is. www.kvcd.net/cqmatic-1.0b3.exe
Please try it again :!:
I believe that if you start with the CQ that always continued to loop from the start, that's the actual CQ to encode, because it's within the precision boundaries. But :imstupid: was running another iteration, instead of exiting at that point :imstupid:

I can't test it, because I haven't seen that condition in my encodes 8O
So please give us feedback :!:


-kwag

You bet :D
Doing a test right now. Second CQ is 57.24, third 55.86...56.18...final 56.18.
Have a beer, Kwag :drink:
Well, i have to double-check the new CQ. Its a bit higher than before (56.18 instead of 51.01). Maybe its more accurate now 8) .
Thanks Kwag :!:

Thanks :D
I'll post BETA 3 now :)
I think that bug was totally squashed ;)

-kwag

Thats also what i thougth. Man, this bug has a real big armor :lol: .
It was coming back when encoding a long movie (not the one i encoded previously :evil: .
Maybe this has something to do with start-CQ of 60 or with PAL :?:

EDIT: This time Difference in log doesn't stay at the same value with the same CQ, it varies a little bit.

Do this mean you are experiencing the problem again 8O
With BETA 3 :?:

Yep, exactly. With Beta 3 :roll: .

http://www.kvcd.net/cqmatic-1.0b4.exe
Grab it, and let me know :roll:

-kwag

Is it normal that one prediction cycle is taking almost 20 minutes to complete? This with a 140 min. movie. It's going real slooooow....
Using the same script in ToK only takes 3-4 minutes on the first cycle.
This with a XP 2500 Barton. (Just upgraded)

Kwag I'll give Beta 4a a whirl but I was still getting the bug with Beta 3 where it would just keep predicting the same CQ (presumably the correct CQ). I'll do another prediction with the same starting CQ to see if I get the bug again.

hi kwag!

beta4 looks fine, best one yet :) hehe...

prediction is fine, will see the result tomorrow (in form of the filesize *g*), will let you know :)

thx again for this great work! :)

bye

Is that a full screen movie :?:
If it is, and for the length of the movie, probably :!:
But it seems quite a long time :roll:

-kwag

Get BETA 5 ;)

-kwag

Get BETA 5 :!:
That should be gone now.

-kwag

hehe too late :))
i´m encoding now, beta4 needed 4 predictions to find out the cq, looks fine, think it will work fine...

post you the results tomorrow :)
going to bed now ;)

bye :)

That's fine :)
You should get the same CQ as in BETA 4. The changes were only to correct high CQ values on short movies ;)

-kwag

Nope, it's a 576 x 320 AVI file. I let it run for 2.5 hour, and it was still prediciting when I decided to cancel. When predicting time exceeds encoding time, then there must be something wrong. :roll:
Really weird. I'll see tomorrow if the Duron 1300 at work is any faster.

Hello:

I have two issues tha I can not resolve.
1.- I am getting the "illegal stream format" error. Please note that I have ensured that the source range was cleaned, prior to loading the avs file. After setting the kvcd settings @ tmpgenc, and checking the settings, I saved the .tpr as text.
Once Cqmatic started working, it gave me the error message. However, it continued encoding at CQ 90. Which will bring me to my second point:

2.- This is a 4:3 movie, and Tmpgenc was adjusted accordingly, however, the movie appears to be stretched, as viewed in the TMPGenc screen... which more or less is an indication on how it will look in the TV set.
My TMPGenc settings:
Mpeg1
352 X 480
4:3 display23.976 fps (Please note that avi stated that this was a 29.7..fps)
Automatic VBR, CQ 60
max rate: 2000kbps
min rate: 712 kbnos ( 1249X.57).Advance settings:
Interlace
Bottom field first (field b)
4:3 display

It will take 12 hours to complete this kvcd, so......... will check it it again tomorrow a.m. (I may just sto encoding at 9 or 10 a.m. tomorrow)

One thing that I just noticed, while I am very sure that under the video tab, the aspect ratio was 4:3 NCTA, hoewever, after loading the .tpr file is now encoding as 1:1 (VGA). Similarly, in the advanced tab I selected the 4:5 525 lines NTSC, however it is now working under 4:3 display

Thanks Totonho

Hi Totonho,
please try doube-clicking on Source Range and confirm the error messages. Renew start and end frame and leave the window. Then uncheck it again and save your project.

hmm

cqmatic did a fine job on calculating the cq, but the filesize was too short,

instead of being 687 mb for the videostream, the file was 508 mb :(

testing beta 5...

Beta 5 seems to have squashed the bug.
Haven't had the same error with looping :D
I' ll test Beta 5 right now with a short movie.

testing now also :)
hope beta5 is solving my problem here :)
lets pray :P :P :P

I just looked at my result from "K-Pax", done with BETA 5, and the file size was also ~-20MB, perfectly consistent with my previous encode of "Boondock Saints".
I'm doing a long one now (K19), to see if it matches the same final ratio.

-kwag

I can't believe it. The bug seems to exist also in beta 5:
Start-CQ:55, 23 mins movie, 833-2000, Script without filters.

After many predictions CQMatic gave 3 times 51.84, then lowered to 51.83 and now its repeating this value :cry: . Can this be a PAL issue :?:

Another one i've just had:
Because i had problems with the starting CQ of 55 and 60, i lowered it to 50. After one prediction, it encoded directly. Same with starting-CQ of 40 8O .

Sorry Kwag bothering you with so many bugs :roll: :!:

Not at all :!: bother as many times as needeed :!:
That's the way things get fixed :)
Why isn't that I can't reproduce that here :twisted:
So you mean that when you started at 40 and 50, it found the CQ in one try :?:
But it was about the same CQ to encode, but not 40 or 50 right :?:
Let me look again at the source. This can't be a PAL issue. It's a kwag(bug) issue :lol:
This might be a stupid question, but I have to ask: You are sure you are running the BETA 5 executable :?: It does show "Beta 5" when you run CQMatic, because it happened to me the other day, that I was running an older version, thinking it was the latest :roll:

-kwag

:D
PAL-maybe...
Yep.
Not sure what you mean. First time it was 50, second 40. Thats what surprised me. Now i've started from 20 and its around 24 now...
:mrgreen:
Yep. Using Beta 5.

And now its stucked to 23.93 :evil:

8O 8O 8O 8O 8O 8O
Anyone else with this problem :?:
What is your TMPEG version ( not that it should matter, if the program is running :!: )
What Windows version are you using :?:
Sorry to bother ( :lol: ) but I'd like to narrow things down :D

-kwag