Quote:
|
took now a 53 min, wanted it to have it (for tests) on 300mb ;
calculated avg bitrate , with 631. here the log using cq 60 encoder started... encoder end... difference=-5439988.500000 using cq 90 encoder started encoder end differnce=-5439988.500000 cq above watermark , cq set to 90 using cq 90 cqmatic complete hmm strange :) |
Quote:
-kwag |
Quote:
-kwag |
?
don´t know exactly what you mean ? when i hit start he starts encoding ... got another test running now, so can´t do another one... what i wanted to say : cqmatic is getting information on cdsize, nr of cds...about the average bitrate , i think? so why does it take cq 90 , when i like to have the movie on 300mb ? but thats not the most important thing,its more important that it runs stable, finds the cq as fast as possible, so that everybody can use it :) |
Kwag, tigger , please:
i have doubts ... tigger wrote: "took now a 53 min, wanted it to have it (for tests) on 300mb ; calculated avg bitrate , with 631." this size (300mb) is not too low for 53 minutes? and the average is not too low? :? maybe i misunderstand....seems strange for me! :? |
you´re right of course, would never do that :)
but for 1 test, i chose such values... i thougt that cqmatic would calqulate the cq very low...perhaps 20-30 as cq or sth, but it chose 90 and thats strange for me :) |
Quote:
Source was 104 min. 576 x 304 PAL AVI movie. Using the same script for both tests, and destination was MPEG2 - 480 x 576 PAL. One prediction cycle with CQMatic took 16 min 40 sec, with a source range of 1 min 39 sec. One prediction cycle with ToK took 6 min 17 sec, with a source range of 1 min 44 sec. I have checked the project file over and over again, and as far as I can see, everything looks ok. This really puzzles me.... |
Quote:
This WILL be fixed today on BETA 8 :!: as I'm duplicating the problem now. Until later today, no more BETAS :!: -kwag |
If somebody want beta 7 here the right link:
http://www.kvcd.net/cqmatic-1.0b7.exe Kwag forgot the "-" ... |
Quote:
|
|
hope beta8 will be there soon :)
|
Kwag I'm still getting CQ prediction loops with beta 7. It starts at CQ 60, then 50.25, 40.83, 40.66, 40.57, 40.53, 40.51, 40.50, 40.50, 40.49...
And that's where it gets stuck. The value for Difference = also doesn't change. It also SEEMS like prediction samples take a longer time to encode than with ToK, but I haven't done a direct comparison. I'm encoding a widescreen avi, 640x272, 152 min long, avg bitrate 608, into a KVCDx3. |
avg 608 @ KVCDx3???
Is the quality still good at these settings? |
Oh... CQMatic calculated CQ is wrong... I want to encode a 100 min movie... but the CQ is 100MB too big... :cry:
|
Quote:
post big details.... wanted size,CQ found,average,etc. :) |
Quote:
-kwag |
Quote:
Only final prediction accuracy tweaks "might" be needed :cool: Here's the link, in case some of you haven't noticed it: www.kvcd.net/cqmatic-1.0RC1.exe -kwag |
Hello Kwag:
Cqmatic is now working for me. The video stream error message that I was receiving, as well as the strehed screen, were corrected following krassis and your answer to previous posts. On Cqmatic v6 I was seeing up to 2 hours of CQ checking, prior to encoding. I am presently running v RC-1, and so far is in its third pass. It takes about 12 minutes per pass, for an 80 minutes dvd. Will let you know how many passes it takes prior to the actual encoding, which in this oicture is about 13.5 hours..... Question: What is the shortest film, in minutes, that can I test with no problems? On previous versions I have used 4 minutes, but Moviestacker was given me erroneous numbers for the average kbs. ( anywhere from 8,000 to over 240,000- Theshortest the film, the higher the number. Obviously I am doing something wrong here, perhaps I should do this manually no?) Thanks again for your help Totonho03 |
Hi Totonho03,
You should be able to throw any (time) size movie at CQMatic, and it will either encode at a max of 90, or at a min of 1 ( if you like very low quality videos :lol: ) The program should protect MIN,MAX bundaries now :) -kwag |
Quote:
The only gripe I have with cqmatic is the longer sample times than ToK. I guess I'm just used to Tenra's fast predictions, but I could normally zero in on a CQ in 20 min tops. But now it takes me up to 11 min a sample, and if it takes 4-5 samples well that just adds up! (guess I shouldn't look a gift horse in the mouth but.... :wink: ) |
Quote:
Well, If we can get 98% accuracy every time, then I wouldn't mind waiting a ~15% extra overhead for prediction :!: I'd rather wait that extra time, than find out the next morning that it's under 40MB or over 20MB :!: But then again, only if it's a consistent ~2% precision every time :!: -kwag |
Kwag:
Sorry for this, but I am getting a loop with vRC 1. It started at CQ 60, then it went to: 68.19>72.28>73.40>72.31>72.37>72.32>73.34>72.35>73 .31>72.37>73.29>72.38> 72.37> 72.40 and is still going. I have checked and rechecked my numbers, and the only thing that I did wrong was to use 2500 as max number, instead of 2000. Would this create the loop? Each time it encoding takes about 13 minutes, and the prediction is now over 2.5 hours......... Totonho P.s.- Would you loke for me to send you the log? Is a long one...... |
Hi Totonho ,
I'm now too tired to think :!: I quit for today. Tomorrow I'll tackle this. This doesn't make any sense 8O And the test/predict cycle is really boring :!:, so I have to wait a long time too before I get results. And the worse thing is that I don't get a single movie to fail on me, and that makes things worse, because I can't reproduce the problems :roll: To be continued tomorrow ..... Later, -kwag |
Something very odd happened:
I stopped the TMPEGenc, it was still in a loop, printed the log, and surprise, the printed log is longer than the log that the CQmtic was showing win their screen.........No, I only had 4 glasses of Merlot, and am not hic, drunk......... The log even states that CQmatic completed its cycle at CQ 73.054291, (the difference between that one and the previous one is 0.217361, which is less than the .25 tha kwag was talking about............ I will start all over again, but am not sure if I am going to wait a couple of hours for it to finish, so I will report manana por la manana....... Totonho03 |
With RC1, my problem seems to be gone :!:
Here's my log (same source as always): Code:
http://www.kvcd.net Thx Kwag for working so hard on this :!: And thx for the logging feature (very important for me :D ) :drink: |
Well, my doubts where right. With another CQ at start, final CQ is different. I've done the second prediction exactly with the same settings except first CQ. This time i started with 90. Here's the log:
Code:
http://www.kvcd.net |
sorry kwag, but i still have the problem with short movies, its getting me crazy :)
well still have the problem with short movies http://www.kvcd.net CQMatic Version 1.0 RC-1 Copyright Softronex Corporation, 2003. All rights reserved. Ready! Project: C:\--== DVD RIPPING ==--\Band Of Brothers 10 Teile\Teil 4\bob4.tpr Creating: CQMatic.tpr Execute. Movie Time: 57 Average Bitrate: 1785 Prediction Only mode Executing Prediction Phase... Using CQ of 80.00 Encoder started... Encoder end. File size difference = -16550299.000000 Last CQ = 80.000000 Current CQ = 90.000000 CQ difference = 10.000000 Using CQ of 90.00 Encoder started... Encoder end. File size difference = -16550299.000000 CQ ABOVE watermark. CQ set to 90.0 Using CQ of 90.00 CQMatic complete! will try a lower cq as start value...lets see |
Good morning /afternoon gentlemen:
As mentioned, I left the tool running last night, with the max number set at 2,000, and the results were positive: It went through its calculating routine 6 times, and received a final CQ of 78.3089600 and a CQ difference of .218658.4, the CQ values were: Quote:
Kwag, something that perhaps would have answered this without doubts is a clock. Do you think that a clock could be placed at the encoding starting and ending points? Just a question. (I just asked CQmatic to dump the info from my recent test to the clipboard, and I now have 2 sets of the same log, it appears that the command is not clearing the contents of the clipboard, if CQmatic has not been closed.) Total prediction time appears to be around 1 hor and 30 minutes, this for an 80 minutes film and an average bit rate of 1149 Thanks Totonho |
Hi Totonho,
can you try the same prediction with a low starting-CQ :?: I would like to know if it is predicting the same or a similar value. |
Hi Krassi.
Will do that, I will start in about 15 minutes, the result will be there in about 1.5 hours. Totonho03 |
hi krassie...
well started preditcion of 57min with low cq, 30 jumped directly in the 2nd pass to 90 |
Kwag: I notice that CQMatic takes a much longer time to encode the same number of frames in its prediction samples than with tmpgenc on its own. For example, the movie I'm on now takes 12 min to encode 3240 frames. But if I add the line trim(0,3240) to my avs and just load that directly into tmpgenc, it only takes 2 min! Sometimes it takes 5-6 tries to get the right CQ, which would mean 60-72 min, whereas I'd "expect" it to only take 10-12 min. Can you shed some light on what this may be due to?
|
Hello Krassi:
I re-run CQmatic, starting at 70, and this is what I have: Quote:
Quote:
Totonho03 |
And this is my latest log:
Quote:
Thanks Totonho03 |
hmmm wondering :)
set moviestacker to 90mincdr, wanted to have 120min movie on 90min cdr, videostream SHOULD be ca. 780mb, but its 820 mb ?? thought that the filesize woulder NEVER go above the maxiumum? perhaps, next time, i try to configure moviestacker 88mincdr ;) anyone tested running cqmatic for 90min cdr configuration? |
Please get RC-2 :!: ;)
-kwag |
Hello kwag:
I just finished running a test with RC-2. Here is my log ( I have changed its format a bit to save space): Quote:
Quote:
Hope this help some. Totonho03 |
Thanks totonho03 :)
But use RC-2, because it fixes many problems with short (High CQ) encodes that can fail miserably with ;) -kwag |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.