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