At the end credits? Yes. Did it happen anywhere on the movie? If it didn't, then it's the MIN bit rate at the point where it switches to end credits, and during end credits. There's just too much black there. You might just want to fix your MIN bit rate to 450Kbps. That should keep a steady low bit rate stream that is high enough to kill that effect.

I'm still tweaking prediction. I'm now at 512:6. Running two sample encodes on two machines.

-kwag

It's even more useful than you first thought, isn't it? :)

In fact it doesn't really add sharpening so much as retain existing sharpness. The other resizers (except for "precise bicubic") soften the image. Lanczos is about the most "accurate" resizer there is, but it's bad for us because we want that extra compressibility that softness brings :).

No worries. Glad you got FitCD figured out :).

Yes -- about the last two or three minutes of the movie. It started with a single audio glitch (one of those real loud ones) and progressively got worse as time passed.

I'm still tweaking prediction. I'm now at 512:6. Running two sample encodes on two machines.

I'm testing too, but in the other direction -- 25:96 right now ;).

128:24 seems to be hitting the target very accurately.

When this thing finally stabilizes, we're going to have to write a "Readme.txt" or something, because I think everyone reading this thread must be either asking for some hard liquor or going bananas changing prediction parameters :mrgreen:

-kwag

Sounds logical, too... :)

:lol:

Yes, I hope no-one is trying to track this in real-time :D. Actually I intend to write up a howto while I'm away for Christmas (24th, 25th, 26th). Thank goodness for the laptop... :)

I smell something is burning. 8O Oh, look out, it must be SansGrip's mind running a prediction test loop :mrgreen:

-kwag

Hey! Of course we are tracking it!
Well, at least we are trying... :wink:
Just hope that you guys don't get lost in the middle of all this variation of granularity and window/sample length. :D

Who said that?? 8O :twisted:

What's my name :?: , where am I :?: :roll:

:mrgreen:
-kwag

Come on guys, give us something...
I have a movie here that is willing to be predicted! :D
What should I use?
I made some samples with these strange settings (512:6, 128:24, 25:96) and all came out with very different prediction. 8O

We're minutes away from having a formula that should work for tonight :mrgreen:.

Drums rolling /\/\/\/\/\/\/\/\/\/\ ........

Ok, after hours of testing and (in my case at least) ingesting caffeine, here is the latest file prediction formula...

Count all the chairs in the movie EXCEPT those with arms, then find the square root. Multiply by your favourite cousin's birthday and add 6. Calculate that value to the power of how many eggs you've eaten in the last two years, then divide by 12 and subtract quite a bit. Swap all digits, convert to hex, and simmer for 45 minutes while stirring constantly.

Then throw that value away, because what you really do is...

Let's say your movie is 96 minutes long, and we're using the new GOP structure with a maximum length of 24. This is the line you'd insert into your Avisynth script to get the sample strip:

Sampler(96, 24)

Pretty simple, eh? If your movie is 115 minutes long, it'd be:

Sampler(115, 24)

This will then give you a nice sample strip. You then do the formula as usual, with an error margin of 2% (in KVCDP) or 0.98 if you do it manually.

If I left anything out, kwag'll fix it :mrgreen:.

Have fun and test lots and let us know...

And here's the old ( hard core ) way :lol:
This is what you add to the end of your .avs script:

Or automatic:

And then use the new formula:
Note: For PAL users, use 25 instead of 24 for the value of SL and change the 24 to 25 in the formula. If any NTSC user has to encode at 29.97, then use a value of 30.

And if I screwed up, SansGrip will fix it :mrgreen:

-kwag

By the way, before you ask: yes, it really did take us that long to come up with something that simple ;). However we're now hopefully on surer ground wrt the formula and I'm fairly confident that the error margin is now set correctly.

Of course, kwag suggested all this days ago. We just had to run everything from Sampler(20, 200) to Sampler(1200, 2) in order to discover that he was, as usual, right all along :mrgreen:.

Thank you and goodnight ;).

Thanks for all your time and suggestions SansGrip :D
This was like a roller coaster. Encode, change, encode, reformulate, encode.... :lol:
Now after seeing all the tests you did, I am also very confident that the file prediction is far better than what we had before.

BIG THANK YOU :wink:

Now, I'm going to bed 8O
Good night all.

-kwag

sansgrip wrote:

"In fact it doesn't really add sharpening so much as retain existing sharpness. The other resizers (except for "precise bicubic") soften the image. Lanczos is about the most "accurate" resizer there is, but it's bad for us because we want that extra compressibility that softness brings . "

yes,i'm with you.
in my tests i really see the difference.
i "mix" with Blockbuster.....cool. :wink:

Since this thread is kinda all about everything, and nobody pays attention to any other one at the moment :D maybe someone can help me with this one...

with the new GOP I encoded frequency again, at 704x576 PAL, and result was really watchable... Usually I only encode in MPEG2 and mux with BBMPEG. I did the same thing with this movie, after encoding the audio with Headache. I muxed it as VCD VBR, forced mux rate 0, write program endcode checked.
The video and audio are fine in sync on my PC, but viewed on my standalone (which plays all KVCDs fine, when i muxed them together with BBMPEG) the audio is slightly too early from the beginning... that never happened before...

any suggestions?

Wow, that's weird... Total frames/MovieTimeInMinutes? Can you explain it a little bit?

It's ok... I got it. :D
It would be easier to understand if it was:
Or even easier (just for my understanding):
Anyway, I just needed to understand it to not get crazy... the formula is as good as always!
Nice work!

Are you sure? Does the GOP size change?

So what should be added to the AVISynth script to implement the function Sampler(int movielength, int gop)?

I tried
and it didn't seem to work.. said that SelectRangeEvery was being fed invalid arguments :?:

I tried adding
to my test script, and when opened in TMPGEnc, it wants to encode a 23-minute sample (from a 128 minute movie)...is this correct?

Would I just change the Error Margin in KVCDP to 2% and go from there?

maybe u'll try this :
Total frames/Framerate/MovieTimeInMinutes = 60
so formula going to be :
60 * 0.98 * sample file size
or
file size = Sample file size * 58.8
Very simple , Right ?!!!
bman

Sampler?
 

Hi Kwag,

I believe that it's not right.
Remember... IL = Interval Length, not the quantity of samples.
If you want the number of samples to be equal the movie time in minutes, you have to do this:

Re: Sampler?
 

:lol: We posted at the same time Racer99.

Try this and you'll get what you want:
MI = (Framecount/Framerate)/60
IL = round(Framecount/MI)
SL = round(Framerate)
SelectRangeEvery(IL,SL)

Sorry, forgot to mention where to get Sampler ;). Try here. It really is much easier than the old SelectRangeEvery method.

Nice, got it.

Another quick question -- I realize this probably isn't the thread to post it in, but this thread is hot and I'd like this answered immediately so I can get on with my encoding =)

When using
for BlockBuster, do I want BB_Resolution to be the resolution that the movie WILL be encoded at (ie: 352x480), or the resolution that AviSynth is feeding to TMPGEnc after AviSynth cropping and before TMPGEnc resizing (ie: 480x279 or whatnot)..?

No, I'm not, but it was too late for me too think :lol:

Good morning :D
-kwag

It's exactly the same :)
If we have:
Then IL=107 ( rounded time for Red Planet in my example )
SL=24 ( rounded frame rate )

And if done like this:

Then my total frames are 153233 / 23.976 / 60 = 106.51832 which will round to 107.
And the SL will be 24 ( round 23.976 )

Edit: I see where the confususion is. IL was wrongly labled. It's not "Interval Length". It's really "Every Interval"

So IL is really the "every" field, and in the example above, every is 107 which is what we want. 107 samples of 24 "length" frames each :)

-kwag

And more accurate to! :wink:

For my test I'm using an 86min film, so I'm using an 86:24 sample.
The sample with Sampler has 2063 frames, and the sample with avs has 2087. The exact value should be 2064 frames (86x24). I don't know why Sampler always produce 1 frame less then the total, but it's much more accurate than avs.

Now the strange part: after encoding the sample, TMPG is producing 1243 frames, instead of 2063! I don’t know if I made my self clear, but what I mean is at TMPG Source Range the sample has 2063 frames, but after the encode it end up with 1243 frames. I can’t understand… is that supposed to be happening?

Yep... they are both the same, and are both wrong. :wink: :D

If you use IL=107 (your red planet example) and SL=24, them you are getting 24 frames of every 107!! This would result in an HUGE total sample!
If you want 107 samples, then you have to do Framecount/107 !!

But I think that we should start to use the Sampler from SansGrip.
It IS more accurate.

......i need a "resume" to understand it all. "i'm flying" :?

:oops: I must go back to sleep 8O
You are correct. Maybe I should step away from the computer for a couple of hours :lol:

Edit:
And the correct lines are what you posted:

MI = (Framecount/Framerate)/60
IL = round(Framecount/MI)
SL = round(Framerate)
SelectRangeEvery(IL,SL)

Thanks,
-kwag

Sampler always produces samples * length frames. You might be looking at the "end point" figure in the TMPGEnc Source Range dialog, which is the last frame rather than the total frames. Since they start from 0, this will be one less than the total.

If you look at how many frames TMPGEnc sees when it's actually doing the encode, it should be right on the money.

There's a new Sampler out. I posted details here. No more monkeying about with Source Range now :).

8O

Also correct is:

Sampler(minutes, 24)

:mrgreen:

Yep! Right on target! :D

And I just thought that this "supposed" missing frame would be the "information" frame that we talk on the other thread. :mrgreen: