Don't do that!
We need you right here!

I looked into that and displaying the info for the Avisynth 2.0 version would be easy, but I'd need to modify some code (someone else's code, to be precise) to make it work with 2.5, so it's still on the to-do list .

You see, I come back here and feel like a :P because my are burned for the day so I'm at my own stupidity.
I really think I should go back to sleep and recharge my neurons
I just keep dragging the old legacy methods around


-kwag

Ah, I couldn't even form a sentence this morning until I'd had at least 3 cups of caffeine .

Well the nice thing about Sampler is that it's not only easier to use but as muaddib pointed out it's also more accurate. When we're talking about sampling not even 2% of the movie, every frame counts.

Oh, and as of 0.2 we don't need to "fix" the Source Range to stop TMPGEnc trying to encode the whole movie .

You're ahead of me by 2 cups
So then instead of Sampler( 120, 24 ), or any other hard coded nubers, we can automate it like this:



-kwag

Hey Kwag,

Don't worry about it, it's just us other enthusiasts. I got your back. With all the hard work you've put in lately combined with the lack of sleep, it's incredible that you got it even close. Keep up the faith.

Racer99

So to make sure I got this right -- when using KVCDP, sample points should equal the length of the movie in minutes and error margin should be 2%?

Hi SansGrip,

Would AutoCrop accomplish the same thing as Tmpgenc's Clip Frame or
FitCD's crop, but do it automatically Here's the link:

http://forum.doom9.org/showthread.ph...light=AutoCrop

What do you think

-black prince

This is just to report that I finished a complete encode (again) of "The Green Mile" that I started last night. On my Celeron 1Ghz it took 10 hours 52 minutes . But here are the results:

Predicted file size with MovieInMinutes:24 (180:24 ) was 659,323KB
Final encoded file size: 650,042KB.

Difference of 9,281KB for a 180 minute film. That is ~1.40% difference.
So I can see that the results with the new method are extremely accurate. This was with a %factor of 1.0, not with 0.98, as it should have been.

-kwag

Hi All,

Tried the new file predictor for Minority Report which I previously
encoded using an old formula and CQ_VBR=12.34. The final movie
(audio+video) = 1,538,867,346. I didn't fill the entire 2 CDs. The new
formula increased my CQ_VBR to 12.903 and guess what
it came out perfect at 1,593,434,274. It's so close to 1.6GB
I was floored Great job Kwag and SansGrip.

My aduio formula is off for calculating mp2 file size. I'm using

((audio bitrate) / 8 ) * Movie time in seconds = audio file size

The results always seem to be a little greater than Headac3he.

-black prince

We could, but personally I find Sampler(minutes, 24) easier to understand and less easy to mistype . However, I could change Sampler so that "samples" defaults to minutes-in-movie and "length" defaults to one second.

When you say SL=Round(Framerate) etc. are you sure you really mean that? I think it should be SL=24, since we're going by GOP length not frame rate. The two just happen to coincide at the moment...

I believe that should work. I'm not 100% confident because KVCDP 0.2 was written with the old prediction formula in mind, but my initial thoughts are that since our new GOP length happens to correspond to the frame rate, it should work regardless.

But yes, you'll definitely need to set the sample points to the length of the movie in minutes. That won't be necessary in the next version.

Theoretically, yes. To be honest I have my doubts about how well an automated process would be able to properly detect borders (it may work 9 times out of 10, but if you have to keep checking each time it runs then you might as well just do it yourself and be sure).

The filter appears still to be in alpha or beta, and my reading of the thread is that it doesn't preserve aspect ratio yet, which makes it interesting but not very useful. With some work, though, it could be an excellent filter -- I see no reason why the whole FitCD process couldn't be automated fairly successfully provided the filter was very careful and "alerted" the user if anything didn't look right. 3-12 hours or so is a long time to wait to find out your autocropper threw a fit .

Yes, you're right. We're going by GOP, and it should be fixed to 24. So that simplifies it to:

I still think this is simpler than having to find out the running time of any movie. Just attach the code to the end of any .avs script, and the sample will always be correct without any human errors

-kwag

I always encode the audio first. That way I know precisely how big it is .

Check here for a new Sampler, this time with very helpful defaults. From now on (at least until we change the formula again) all you'll need to add to your scripts is:

I can't make it much easier without renaming the filter to just "S" .

Re-encoded Resident Evil at 352x480 with 400 min bitrate, slightly more smoothing, slightly less noise, and a slightly higher CQ_VBR (15.63 instead of 15.55). Of course I also used the new GOP and formula.

Target size: 716,523,242
Actual size: 711,603,443
Difference: 0.69%

Not bad, not bad .

Or "SG" For SansGrip

-kwag

@SansGrip,

I have a semi-automated process for file prediction (FitCD is the exception)
which calculates the audio file size and subtracts this from the number
of CD's (1 or 2) to determine the video target file size. It's close enough
now. It's usually only ~2mb larger then than the acutal audio size.

This sounds like another project. This would be especially useful for
automated processes as "acp" on this forum. We have been trying to
find a way to intergrate a "FitCD" a like filter into our avs script.
Until Kwag created "SweetHead" we had to use BeSweet instead of
Headac3he for example. At low audio bitrates Head is da BOMB.


-black prince

It would be useful, but I'm guessing it would be quite hard to determine borders automatically. It sounds easy but I don't think it would be .

I've always had a lot of luck with SCMPX -- it seems to produce really good quality even at low bitrates. I've never tried it lower than 128 though.