I have been trying to get CQMatic to work but for some reason my final muxed mpeg is always ends up being around 810-825mb. I am using x3 prediction with the average bitrate from CalcuMatic, with 80min CD as target and audio @ 128k. Source material is NTSC fullscreen interlaced video @ 29.97fps, encoded as mpeg-1 @ 29.97fps and deinterlaced in my avs script.

I tried using a lower average bitrate by setting a "custom" target of 775mb in CalcuMatic, but still ended up over. Then I got to thinking, it doesn't really matter what average bitrate to use since filesize is also determined by CQ, right? So lowering average bitrate results in a higher CQ which means I still have a file over 800mb?

Is there a setting I'm missing somewhere? I just read an older post that said to use "motion estimate search". I have been using "high quality (slow)", could this be the problem? Do I lose any quality switching to "motion estimate search"?

Any help is appreciated!

Lowering avg bitrate LOWERS CQ and so the file size.

I guess you problems is more in the nature of the source than in what you do. Avis for instance give more problem with CQMatic then DVD. So perhaps you source (that are capture I guess ?) are also problematic.

Better than taking a smaller target you should use a upper audio. For instance, if you plan to do audio at 128, do the prediction a 160.. It works quite well for avis.

Hmm tried that yesterday and it was an improvement, ended up with a file of 809mb, still a tad too big. Perhaps I should try setting audio prediction at 190?

As DialHot says that CQmatic could give bad results in case of avis, I'm not shure id that is based on problems with the very diff. framerate: 29.97fps ??

Because in the time when I used CQmatic I never had Problems to predict my PAL Captures. ok, but thats a Question to Dialhot.

Another point to you "Danosaurus" is that you could get out more quality of your capt. IF I would know what type of movie it is you captured.

- If its a Hollywood-Movie (Blockbuster) you just perform an inverse telecine which will give you a restored 23.976 NTSC FILM stream ... said restored to the ORIGINAL FPS where the original movie was shot!
Much more quality when encoding! cause of less Pixels per Second.

- If its a real NTSC VIDEO, said a Video shot on original video (not Film!) you also can end up using a Script function from "sharfis_brain" which converts your full interlaced 29.976 capture into a nice smooth-movement 23.976 stream and also here you will get the advantages as explained above.

EDIT: I was just looking for my mini-Guide Posting and by this figured out that you already know about that above mentioned way as it was the Thread started also by yourself.


http://www.kvcd.net/forum/viewtopic....r=asc&start=15

BUT if you already know that Thread, why we are still talking about 29.976 in case of KVCD?

Ok, if you would say "I want to keep the interlaced ordering cause of quality" ... thats a wrong thought in case of KVCD as interlaced encoding sometimes needs a triple of bitrate as in comparison to progressive source encodings ...at least 1500-2000kbit average Bitrate, even when using the Interlaced version of the NOTCH matrix.

What can I answer ? I never do any capture and when I do NTSC I always do it as 23.976 with 3.2 pulldown. So I'm not the one that can give you an answer on 29.97

I also do not handle movies at 29.976 in case of captures the very big advantage if capturing in PAL countries at 25fps

Thanks guys!

Incredible: Yes I learned a lot from that other thread and I think I've got my encoding method down, my only problem now is prediction, that's why I started this thread over here.

So far this is what I've come up with...I tried the script you suggested with "sharfis_brain's" 60i-24p function, and the result seemed a little unnatural to me, motion was not really smooth and my encode time more than doubled, to like 12 hours! My source is video (not a Hollywood movie, real interlaced NTSC video) ripped from DVD. In order to preserve the original smooth motion and "video" look, I have decided to keep it encoded at 29.97 and sacrifice a little CQ.

I do however use TomsMoComp in my script to de-interlace, since as you say encoding interlaced uses a lot more bandwidth. I also tried encoding to mpeg-2 with 3:2 pulldown per Dialhot's advice but to me mpeg-1 looks a little better.

So in the end, my encode method is mpeg-1 @ 29.97 de-interlaced and it looks pretty good to me.

Only problem now is that I can't find a reliable prediction method. CQMatic seems to go a little over, I'm also experimenting with ToK which gos a little under. Maybe it is the framerate that throws things off?