25 :!: And GOP also 25.

8O
I just though about something. Could it be the on/off "switching" of the filters :?:
The way the filter works now is that if there's very low motion, only TemporalSoften is applied and ZERO blur with asharp. Then if there's some motion after a treshold, blur is applied and ZERO TemporalSoften :!:
So if we change the script to this:

ScriptClip("nf = YDifferenceToNext()"+chr(13)+ "nf > 2.5 ? asharp( -(fmin((nf/30), 1)), 0 ).TemporalSoften(0,0,0,0,2) : \
TemporalSoften(2,7,7,3,2).asharp(0, 0) ")

This will keep both filters active, no matter what the scene is :idea:
Just something to try :roll:

-kwag

does that mean the filters become static instead of dynamic again?

Hey :D . Thats a good idea. I've already done an encode without filters and it was matching near 1%. I've done this a long time ago but i will test your change of the script right now.

They become static, but with NULL values :)
Look at the script how I set the values to 0 ;)

Edit:
Meaning that the filters are present or active at all times, but operational depending on motion. So the motion adaptive filtering is still dynamic, with the difference that the filters are always one during the complete encode.

-kwag

Hmm :? . CQ remains exactly the same with

@kwag

Is this really correct?

Shouldn't this value read "0" instead of "2"?
Just wondering...

No, it's either 1 or 2. That's a "mode" value.

-kwag

Okay kwag, sorry to bother you :oops: . It's just that I haven't exactly figured out what the parameters stand for in TemporalSoften.
With this new (changed) line will we be able to use 1,00 for prediction factor in ToK? I mean, that is what we hope, right?
On to another thing... Since I live in Sweden (PAL country) I will try to predict and encode a couple of movies so we can compare them to each others encodes. I'm starting right away with "Enough" (J-Lo!) :wink: .

I'm seeing two things posted here one with

TemporalSoften(2,0,0,0,0)

and another with TemporalSoften(0,0,0,0,2)

Which is correct?

Great! I'm currently encoding K-Pax again, to see if the final size is lower than my previous >3%. I got exactly the same CQ with ToK, (67.33) with the changes to the script above, so we'll see if the file is smaller when the movie finishes.
I have a strong feeling that the problem throwing off the prediction was the on/off switching of the filters.
We'll see what happens in ~5 hours :!:
If the file is still the same as my previous encode, I'll dig a hole in the yard and crawl in it for some time :roll: :!:

-kwag

TemporalSoften(0,0,0,0,2)
The first line will give you an error.

-kwag

Exactly :!:, but if I'm correct and the on/off switching was throwing of compression, then the final encode should be close to the target.
BTW, the line should read: TemporalSoften(0,0,0,0,2)

-kwag

I've just started my encode of "Enough". In ~5 hours we'll see if there is any change in the prediction reliability with the new line kwag posted :) ! Hopefully it will be closer to target now... Anyway, I'll let you know how it turned out in the morning. Bedtime now. I'm dead tired. My band just got a record deal (at last!) so we're at our regular jobs at day and we're recording at night. If anyone was wondering... :roll: And in between I'm here at this EXCELLENT forum :D !!!
Good night to you all!

Hey guys. I'm getting the same CQ value also with the new script and video.en1 file. I"ll let my encode finish though and see what the final size turns out to be. I'm curious though if the CQ is the same how can the file size turn out bigger?

If the filter switching was throwing off prediction how would that have an effect on the file size after TMPGEnc gets done encoding? It seems that it is still predicting the same CQ thus TMPGEnc will still encode it the same and produce the wrong results.

make sense?

Actually I was thinking that the prediction was not thrown off, but it was the actual encode. But I just stopped my encode to do a quick test by encoding two 2 minute clips, one with the new line and one with the prior script line. The result :!: Same size :x
So that proves that it's definitely the prediction that is being thrown off. This also means that the on/off switching behaves correctly, and doesn't produce any glitches which is what I had suspected was happening. So back to prediction debugging :roll:

-kwag

Here are the final results:

Hi Krassi,

Your CQ was calculated with ToK 0.0.5.3 with the "SelectRangeEvery()" function right :?:

-kwag

Yes.
I'm @work now again but i've started one more encoding without any filters.

Did you read my other post about the use of "Sampler()" instead of "SelectRangeEvery()" :?: :!: :!:

-kwag