Then we can just use 3% as error margin on a ES stream, and 5% for system video stream on KVCDP :idea: .

-kwag

Just make your samples as ES (Video only). That's the way I've always done my test strips. You can use TMPEG 2.59, and set the error margin to 3%. That should still provide a final file size just a tad lower (for insurance ;) ) than final predicted size.

-kwag

Step by steps for newbies?
 

I'm really exicted about the predictor, but slight problem, I don't know what the hell to do .... Maybe I'm the only one who hasn't a clue, but could someone post a step by step on what to do to use this? So far I've got this:

Use FitCD to get avs script (if you use 1.05 enable the prediction?)
Read the avs script into Tmpgenc (urm then what?, make a few short samples?)
Make sure whatever sample you have is smaller than the answer from the prediction program?

Any layman help would be great please :)
I know I'm slow and stuff, all I ask is be patient with us and don't forget us newbies when charging ahead with this awesome development...

spyglass.

Why do that, if we are getting acurate results with ES only with 5% as error?

Well, I'm getting between -2% to -3% accuracy almost every time. So 3% should bring the prediction almost to 0% offset from predicted to actual file size. This should be verified by others too.

-kwag

will there be a none .net version?

Given that a couple of people have had problems with it, I've decided that once I've got this version working satisfactorily I will port it to regular Win32 code. .NET seems to work fine for 2K and XP but it seems to be not quite stable yet for lesser versions :(.

@kwag:

I'm interested in finding out why the formula is always out by some percent. I think we can knock 1.5% off that because you encode the sample strips with no system stream, but where does the rest of the difference come from? Ideally one would want to get rid of the scale factor, since it's a bit of a kludge.

There are two culprits: the number of sample points taken, and the length of each sample.

As far as the number of samples goes, I would guess that the formula gets more accurate as you take more samples. However, one reaches a point of diminishing returns, in that it would take too long to encode each sample strip. Maybe 100 is too few?

Instead of each point being a second long, wouldn't it be better to use some multiple of the max frames per GOP, say 36 or 54? Of course, scene-change detection would mess this up. Does scene-change detection really make much of a quality difference since it almost certainly increases file size?

Perhaps if we took, say, 200 samples, each one composed of 2 or 3 whole GOPs, we'd be able to get a more representative sample.

Just some thoughts, probably misguided ;).

Hi SansGrip,

The main reason I selected a one second "window" snapshot, was because of the size of the GOP. If you look at 24 NTSC FILM frames on a mpeg created with KVCD's or even standard VCD templates, you'll have two I frames, several B and P frames. So the worse case scenario should always be on a very high action movie with many scene changes, where the GOP is constantly being replenished with new I frames. So on a average movie, the actual file size will always be below the real final file size because of the compression given by the B and P frames. That's our ~2% insurance. It's better to have a -2% accuracy, than have it so tight, that one day we might get a movie that goes over the predicted file size, and then we either have to re-encode the audio at a lower bit rate or overburn the CD-R. At least, that's the way I see it.
As for the 100 samples, I agree that more samples will give a higher accuracy, because we're increasing granularity of the formula. The more, the better. But then also the longer it will take. I have found that with 100 samples, even on a extremely long movie, like "The Green Mile" which is 3 hours long, the prediction still came out within the ~2% of final size. So on average 2 hour films, I think 100 is more than enough.
But hey, any improvements are always welcome :D .

-kwag

Been noticing the moves to get accurate results. Has anyone picked up that the 100 x 1 sec sample when viewed after Tmpgenc has finished encoding shows it as 2525 frames and 1:41 (101 sec)? If it has already been mentioned sorry i missed it.

I'm using PAL of course.

Yep. It's a little bit off, but the sample will always be the same size for each frame rate. With 29.97 fps sources the sample strip should be around 3,146 frames.

Yep... I think that's because we have to round the framerate in order to use it as an argument of the SelectRangeEvery function.

The good o'l "Off-By-One" bug :wink:

-kwag

hmmm

I was just gonna ask if there will be a .net runtime independent version of kvcd predictor... i have windows xp, but i'm not willing to download that 20.4 megs runtime library... would have benn great though...

So how are people finding it? Is it as accurate as doing it manually? Does the helper work okay?

I can't make it better if you don't tell me how ;).

Hi SansGrip,

So far, so good :D
I've done a couple of movies, and the calculation are correct.

-kwag

Until now I have used a spreadsheet to do prediction calculations. The predictor is 'spot on' thanks!

deleted

Hi SansGrip,

SansGrip wrote:
I can only speak for myself when I say .NET and avisynth 2.5 beta
problems pretty much stop me from testing KVCD Predictor. Also
discovering that Blockbuster noise causes file size to change with the same
settings, I am wondering how KVCD Predictor can be accurate or is
this being compensated for? I am sure it's works for some who have
solved the setup to use it, but re-installing my operating system just
to get rid of the .NET (add/remove still doesn't work) and install it
again is something I just don't time to do. :)

-black prince

@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 :wink:

:mrgreen:

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. :wink:

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 :wink:
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. :D

Time for a new release?
 

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 8O.

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% 8O.

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. :wink:

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 8O

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 8O And that's a HELL of a difference in quality from the sample I posted :D

-kwag

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

Beam me up scottie :lol:
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.