@nicksteel,

use this version of FitCD which is modified to encode a 100 second sample (check the file prediction box- it adds three lines to your .AVS file)

encode the sample, check the size, compare it to the predicted sample size of KVCD Predictor and adjust the CQ in TMPGEnc so that your encoded sample is close to the sample size predicted. Then when it's close, comment the prediction lines that were added with a # like this:

LoadPlugin("C:\encoding\MPEG2DEC2.dll")
AviSource("D:\encoding\MOVIES\movie.avi")
BicubicResize(512,250,1/3,1/3,0,0,639,352)
#TemporalSmoother(2,2)
AddBorders(8,115,8,115)

###--------------------- Start Of File Size Prediction ----------------------###

#IL = Framecount / 100 # interval length in frames
#SL = round(Framerate) # sample length in frames
#SelectRangeEvery(IL,SL)
## MPEG size = ((Total frames/Framerate)/100) * (MPEG sample file size * .95) ##

###------------------------End File Size Prediction--------------------------###

or delete the file prediction lines from the .AVS and save.

Then do the final encode, encode the audio file (.MP2), mux, burn, done!

I must say that I'm very happy with the KVCD Predator. I just encoded Cast Away, which was very hard to encode with DVD2SVCD because it used only 650MB of the second disc and I decided to encode it manually. The result: 10MB short of a full second disc, very good!

The thingie is the only reason why I would download Microsoft.NO..I mean .NET

Hi all,
I got a problem with the Predictor. I suspect it has something to do with the audio file size. Anyway, I entered in the movie length, the number of frames, the frames per second, the media type, and a scale factor of .98. I took the .ac3 file from the movie and it was 219 MB when the Predictor got the size from the .ac3 file. So I got the sample sizes right and ran the movie in TMPGEnc and the final movie size came out to be 643 MB instead of 797 MB. So my question is, where do I get the audio size from? Do I encode it into MP2 and then load it into the predictor? Thanks for the help.

Hi Bigswaffo,

I always do my audio at 128Kbps, or 112Kbps for high action movies. This way I leave more bit rate available to the video on action movies
So just calculate your audio bit rate with predictor as constant bit rate. One you open the .d2v or .avs with predictor, it already knows the size of the movie, so it will correctly calculate the audio size depending on the bit rate you set.

-kwag

@kwag
Thanks. I just entered in the bit rate under "Calculate size from CBR bitrate..." tab to get the audio size. So I'll try it again.

I'm glad people are finding KVCDP works out for them. I had a strange result yesterday while encoding a full-screen 1h20m movie with KVCDx3 -- final size was over 100mb too small .

I've been away for a couple of weeks and I know how quickly things move. Are there any changes to the file size prediction formula I should be aware of, or any new software that renders KVCDP obsolete?

It'd be nice to hear suggestions for the next version. I've noticed a bug when obtaining running length from AVI files, so I'll take a look at that in the meantime.

Once I get everything working satisfactorily (and assuming there's still demand for it) I will rewrite in non-.NET. Seems a number of Win98/ME people have had problems with it.

Let me know .

Welcome back SansGrip,

Kwag has developed a process to greatly reduce video file size and
you're knowledge of DCTFilter or other filters could be useful.
See Link below:

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

So far I am playing with encoding KVCDx3 (528x480) on 1 CD.
See what you think and please add any suggestions that come to
mind.

-black prince

Ok, if possible I'd like everyone using KVCDP (those that read this thread, that is ) to let me know how accurate you're finding it. For me, it's often out by 50-100mb using an error margin of 0% .

Any suggestions why this might be?

Hi SansGrip,

I'll let you know in about an hour, when I finish a test encode. If I get the same result you did, then probably the % factor will have to be adjusted. At least with the 1-12-2-1-24 GOP.

Later,
-kwag

@SansGrip,

I believe I found the error % adjustment in Predictor to correct for the new 1-12-2-1-24 GOP. Try 19 instead of 5.

Edit:
For the original manual calculation, it would be:
MPEG size = ((Total frames/Framerate)/100) * (MPEG sample file size * .81)

-kwag

It's inaccurate for me with any GOP structure. I'm wondering if I changed something in the development version I'm using...

Hi Kwag,

For the original manual calculation, it would be:
MPEG size = ((Total frames/Framerate)/100) * (MPEG sample file size * .81)

Is this the new test formula for MPEG size. Everyone's using .95

-black prince

For me, this would make it far worse. American Pie was ~50mb smaller than KVCDP predicted with an error margin of 0%.

That's about the same I got on "Red Planet". So I calculated a new offset adjustment, and wound up with 0.81. ( Would be 100 - 81 = 19 in KVCD Predictor ). This is based on manual prediction with the formula, and after running a new sample with the new adjustment and GOP.

So your error % in KVCD Predictor would be 19, instead of 5 which is the default.

@black prince,
The 0.81 factor is ONLY for the GOP 1-12-2-1-24.
0.95 is for the 1-36-3-1-36.

Take this 0.81 with a grain of salt , I'm re-encoding again "Red Planet" with a higher CQ_VBR value based on this formula, because with the original formula, my file size was approx. ~78MB lower than predicted

Please try this and let me know if the prediction is still constant after applying this offset for this GOP.

Edit: And the great thing about this is that my original CQ_VBR values was 8.4 and my new calculated value is 11.1 And that's a HELL of a difference in quality from the sample I posted

-kwag

kwag -- should this one go in the new file prediction forum?

Beam me up scottie
Weeeeeeep! We're here

Thanks, ( Many more to go! )
-kwag

how can the predictor work properly when there are different mb per minuter for the templates

Because it doesn't really care which template is being used, it just compares the size of the sample strips you encode with the size it has calculated as being correct, and suggests new CQ_VBR values based on the result of the comparison (i.e. if bigger than target, lower CQ_VBR, otherwise raise it).

cheers for clearing that up for me.