OK, karl, thanx. I was already afraid of that...

Another question: when I run (under XP pro) CQmatic with TMPGenc minimized, if I open later TMPGenc it opens in a vetically stretched window: less than quarter the original height.

Now that's weird. I also run XP Pro (SP2), and I don't see that behaviour.
The only commands I send to the window are to "hide" and "minimize" :roll:

-kwag

I'll try again this option.
Maybe I did something wrong. :roll:

Option ? This is an option ?**LOL**

I didn't see there was a check box :-). That is surely why this does not work on my W2000 system :lol:

CQMatic updated today to 1.4.05

-kwag

Link ??

Hello ? Please ?

http://www.kvcd.net/forum/viewtopic.php?t=5145

Thanks ?

Thanks !! :)

As posted on the main page:

Updated CQMatic to version 1.4.08
Updated CalcuMatic to version 1.1.15

Changes:
Some code optimizations due to new compiler update.
Changed all tooltips to display as "Ballon" help, instead of old style square tooltips.
Minor internal code cleanups.

-kwag

Feature request(s) (still getting size miscalcs)
 

Kwag, you, as always, kick ass. CQMatic has made encoding a lot easier, if for no reason other than giving me a start point in CQ values from which to work with. Which brings me to my first suggestion:

Add final filesize checking to "Deep Prediction" mode. What I mean is have CQMatic check the final filesize to make sure it's within a certain percentage of the target size, and most importantly make sure the filesize isn't larger than the target size. If it is, the program would then adjust the CQ value once more and re-encode with the new settings. Even with Deep Prediction checked a full CQmatic run for me takes only 3 hours; I wouldn't mind if the time doubled, since it runs when I sleep.

The other issue I'm having is with rendering AVI files. CQMatic won't work with them. I don't know why, but the prediction cycle always takes only a few seconds and invariably produces a CQ value of 89.9+. This is a problem for me, as I like to pre-render my video with XviD to convert the credits to greyscale. It seems like it can't accurately gauge the source range, or something. If you can fnd out why it's doing it and fix it, that would rock.


Once again, thanks for the tools, they really do help with encoding.

By the by, I noticed that Wikipedia doesn't have an entry for KVCD. Perhaps someone should add one....

Re: Feature request(s) (still getting size miscalcs)
 

Thanks :D That's a problem :!:
The reason is I don't have any way of looking at TMPEG's time code.
That is, there's no way for me to tell if for example TMPEG is 50% done, so I can measure the current file size.
If I could, I could definitely take a file size snapshot at say 25% of the full encode, and if the file size is larger than what it's supposed to be at that point in time, I could kill the TMPEG process, and restart it with a lower CQ value. Indeed, and it won't work :!:
CQMatic was designed to work with TMPEG "project" files, which can only be saved and produce MPEG-1 or MPEG-2, because that's the only output options available on the main screen of TMPEG.
There's no other option supported on TMPEG's project file, so I can only support what is defined in the project file, for the time being.I just made a submission here ;)
http://en.wiktionary.org/wiki/KVCD

Thanks,
-kwag

Hi,

OT: and why is it in the category "Requests for deletion"?
It seems that Hippietrail delete it...
/OT

salu2
Fabrice

Hi Fabrice,

Where did you see that :?:

-kwag

The 50% or 25% idea had crossed my mind, but there have been movies where the first half took up much less space than the second half, and vice versa. A snapshot like that would only be useful on a "second time around" encode, after plotting a sort of "filesize growth path" with a full encode process. Of course, this is all academic, since you said you can't access TMPGEnc's timecode. But here's a thought: couldn't you just access the MPEG file being written and count how many frames are in it? That would give you a way to tell how much of the file is done.

Anyway, like I said, I was thinking more of having the filesize checked after a full encode is completed. I realize it would take time if the files kept coming in larger than expected, but it would just be doing what the users would have to do manually anyway. Perhaps make it another option, like "Overshoot Protection" or something, with a prompt that lets people know that it could make the total encoding time take a LONG time if the filesizes keep coming in too large.

Also, when I said "rendering AVI files", I meant converting an AVI file to an MPEG-1/2 file, things like fansubbed anime and such. CQMatic just plain freaks out when the video source is an AVI file.

Oh yes, had a bad render just a minute ago:

Source: Baptists at Our Barbecue
Source Length: 85 minutes 18 seconds
Calculated CQ Value: 81.286....
Audio Bitrate: 192 kbps
Target Video Size: 686128 KB
Actual Video Size: 806912 KB

I have no idea what caused it at all, but I thought you might want to know.

Keep up the good work.

CalcuMatic 1.1.16 released!
 

Fixed bug on resulting average bitrate and video size. (Wrong math used :oops: :cluebat: )
Result is now accurate, and using 1024 for Kbps, KB, MB, GB.
Tested against an encoded audio (CBR) and a 2-pass video, to validate final size. Result was perfect!

http://www.kvcd.net/downloads/CalcuMatic.exe

Enjoy!,
-kwag

@Kwag and all: Could you or somebody say me please, how Calcumatic obtains movie time from d2vs, avis, ifos, etc.
Or in a more general way, how can obtain it from anywhere?
I don't mean how can find out it from a program but how can I obtain it from my programmed tool.

Hi Prodater,

For reading .d2v files, take a look at the source code of DVD2AVI.
You can read the sources, and then implement your own routine to decode the data on the project file.
For AVIs, you can use Directshow calls to get the information.
For reading IFOs, that's another story :lol:
Read here: http://dvd.sourceforge.net/

-kwag

@Pro64
And bear in mind that DGIndex is not fully DVD2AVI compliant.
That means that by looking at DVD2AVI sources you might get your tool to properly parse a DVD2AVI-generated-D2V file but it won't work properly for a DGIndex-generated-D2V file.
In such case, probably best to look at DGIndex source code too...
Cheers

Thanks all.

@Kwag: Why you don't put things a little bit more easy for me, you already read that sources, isn't it?
Also I have not idea where to find out those Directshow calls.

Thanks.

Yes, but I don't think the way you do :lol:
What I mean is, the way I code. My algorithms. They will be different to other programmers. Also depends on what language you program.
For example, I program in C for a living (for way too long!) and also in Python (for the last 7 years), and I also program in Purebasic, just for fun.
Purebasic is not "Basic", so my code will not work in your application, if you are using VB. Are you using VB :?:
So you really need to do some pseudo-code, after reading the sources, and apply them to your programming language.Then you need to learn "Windows Programming", because Directshow (DirectX) is build into every Windows OS.
Start by reading here: http://msdn.microsoft.com/library/de...ch_directx.asp

-kwag