It doesn't work very well with CQ. That was done back when we were using CQ_VBR.

-kwag

@ Kwag..

As for my earlier issue w/ sampler.dll/sampler-2.5.dll, I changed back to
* sampler.dll

..and right after, my system went by-by..

When I got it back up and running, restarted ToK, all worked !!

I think I know what hapened.., my .d2v source was a small test file I was
using in my tests. I think it was like a 3 minutes in total. So, that may
have ben the "division by zero" error.

I used my favorite movie, "Dogma" @ 128 minutes for my very first test.

But ToK gave me these results below, and I'm a little confused, but I did
notice that the quality in TMPG's window was not so good w/ those low CQ
values. I used the defaults for my first try w/ ToK.. I'm sure I'll get it right,
But, for now, I'm just curious.., did I do it correctly, after viewing below ??

I cancelled for obivious reasons, i think.

@ Kwag..
Oh, about how many more minutes to go for that test of yours ??

Thanks for the help.
-vhelp

Ha Ha that is good to know, it was easier using the calculator anyway
Thax dude.

Hi vhelp,

You're trying to fit 567,396,720 bytes of video at 720x480 on one CD
I think that's the problem right there

Edit: I mean, you're trying to crunch down your video to that size. Your audio is WAY too big

Time left on my encode: 2 hours, 7 minutes.

-kwag

Hey Vhelp you doing audio at about 192 kbps that audio size is toooo big

I get that decreasing curve error on one of my DVDs too. Every time it happens and I've tried 5 times. The movie is 120 minutes and I tried 112, 128, 160, and 192 all on 2 CDs and everytime I get the decreasing curve error. I don't know what that means, but for some reason ToK barfs on these Vobs.

And my CQ is in the 70s so I don't know why it does that.

Ok guys, here are the results
Remember this was an encode with a new shorter GOP (which should generate more accurate prediction results)

Wanted final file size: 718,644KB
Actual encoded file size: 764,711

Now, hold on before you scream
I didn't use any "factor" at all. Just the plain formula, to see the result on the final file size. The difference is basically 6% larger on final file size, compared to the wanted. Now I must do one more test, but with another movie. I now that if I correct the CQ on this one by lowering the wanted CQ to target my sampler file size 6% lower, the result wil be exact.
So now I need to encode some other movie, an action movie, but apply the same formula and take into consideration the new 6% introduced with the GOP change.
That's the only way we're going to know if we have a constant prediction
So now I'm going to encode "Boondock Saints" to see what the final size will be, but with the 6% factor. It the target is on the nose, then we know we're accurate again. K-Pax is a very low action movie, and "Boondock Saints" has a lot of action. So they are movies on extremes.
We'll see what happens.
If anyone wants to try this, the current formula is this:
Predicted MPEG size = ( ((Total frames/MovieTimeInMinutes) / 24 ) * MPEG sample file size ) * 0.94

Which is the same as taking the value that MovieStacker suggests for video stream, divide it by 60, and subtract 6% ( or multiply by 0.94 )
In my K-Pax movie, the final video size required is 718,644KB. So that divided by 60 is 11,977.4KB and then applying the 6% would be 11258.756 and that's the sampler size we need to find CQ for.
I'll keep you posted, probably tomorrow when the encode is done.

-kwag

@ Kwag..

Right now, I'm having my own version of FUN

I'm reading KVCD Predictor (by sansGrip 11.18.02) to better understand
"predictions" and calculations and whatnots. Its hard reading for me at
this hour, and I'm currently at page 7 now.

Here's the FUN part. I'm building a predicter app as I go. This way, I am
sure to learn it all. Well, it may turn out to be a nothing app, or not. That
will be up to me, and how much I can take. I should've done this a long time
ago.. oh well.., live and learn. But, this brings back some old memories of
LONG nights of programming, and two pots of COFFEE. Part of this app is derived
from rendalunit's C++ code on page 4. So, it could be off. It's a start.
Hehe.. the funny thing was, in thinking up a name.. vpreck hehe.. but, I stuck
to predict.1 instead. Mind you, this is all manual. But, if I have to
scratch this app.. so bit it. Heck, maybe I'll spark others to play too.



But, before i continue, should I be reading this thread, or another one ??
So far, I seem to be reading about CQ_VBR, but not CQ. So, I'm a little
worried that I've read the wrong thread all-to-gether I hope not. Please
tell I'm not hehe..

Currently, I'm at page 7 and counting. But, I'm taking it REAL slowoww.
I wanna make sure I understand this "prediction" stuff, but I must admit,
I'm sort of confused on a few points..
* scale factor - where am I getting this from ??
* target MPEG file size - 6MB is my target ? where exactly derived from ??
* Sample size ie,
* Well, the list goes on, but I'm learning as I go.

-vhelp

If you're on the CQ vs CQ_VBR thread, you're on the right track

@ Kwag..

Ok, I'm not quite there, but being that I'm almost finished w/
KVCD Predictor (by sansGrip 11.18.02), I'll finish it up
and move on to that thread you mentioned.. CQ vs CQ_VBR

Would this thread happen to be this LONG 41 pager:
* CQ vs. CQ_VBR ... VERY INTERESTING...
[ Goto page: 1 ... 39, 40, 41 ]

...you bast..xx'rd you. hehe..

Ok.., give me a little time, and I'll be ready ta read.

What's the countdown for your latest encoding test ??
-vhelp

I don't know I'm in bed browsing with mi iBook, so we'll see the results in the morning
I could connect to my PC via VNC client, but I rather not touch the machine that is doing the encode, which is about 100 feet from where I am in another room.

-kwag

Hi Kwag,

I don't know, guys, seems that everytime I have a thought and come to this forum with a new idea, some of you are already working on it or have discarded the idea alltogether after serious work.

However, this time I am sort of confused, and I still would like to help. Would you please post the algorithm currently used in ToK to do the prediction?

I don't want to look stupid by coming up with some logical supposedly new idea just to confirm you already gave it 75 posts.

You know, it is better to remain silent and look stupid than to speak up and definitely clear the doubt

Regards,

Hi r6d2,

These are the lines ToK uses at the end of a script to predict:
Your code will be different, depending on the length of the movie and your source frame rate

-kwag

Well, I need a vacation, because prediction is now a total disaster
Finished "The Boondock Saints" with these results:
Wanted file size: 722,779.89KB
Real encoded final file size: 645,083KB
So as you can see, prediction is sucking wind
Back to the drawing board

Note: Anyone interested in accurate prediction, move back to AviSynth 2.08 and the current 2.0x script.

For the time being, I consider prediction with the MA script with AviSynth 2.52 marked as "BROKEN" until we can come back to +-2% accuracy and consistent results

-kwag

@ Kwag..

Well, after an hour 1/2, I finally "captured" all those pages for later DETAILED
reading (though I skimmed through some that took loke to D/L 'imgaes")

But, I think most of the "predictor" formulas started around:
* KVCD Predictor (by sansGrip 11.18.02)

And, then:
* CQ vs. CQ_VBR ... VERY INTERESTING...
[ Goto page: 1 ... 39, 40, 41 ]

..took off further from there, w/ Matrix/GOP tuning, and so on and so forth.

I'll print out all, later.
-vhelp

@ Kwag..

I feel for ya. Anyways..

Now, don't get mad at me.. Colm down.. and hear me out

Here's a brilliant idea...
If you can contact Hedix and ask him if revise ToK to make a copy
of the .M1V and .M2V files, you can run a quick test to see if they are
the same (size/quality etc)
.
.
..If you run the:
------------------------------------- FIG. A -- -- --
* AVIsynth v2.08 script w/ ToK and same script and filters, same movie
* AVIsynth v2.52 script w/ ToK and same script and filters, same movie

Note, they should be the same "size and quality" (according to you)
Forget about color space and whatnots. Just use the EXACT same Filters
that you used in v2.08 scripts w/ the same YUY2 only (I'm assuming that
at the time, YUY2 was all you was using then) and make sure you DON'T
use YV12 filters for v2.52's script filters (unless you used one in a given
predict, back in v2.08 predicitons) <-- follow ?
------------------------------------- FIG. A -- -- --

That'll help you narrow down what's exactly causing the faul-ups.
These two files (above) have to be different !! Otherwise, if they are the
same, your predicts should be the same.

I have the sneaky suspician that these two files will not match, even when
useing the same Scripts and their respects Filters

Also, I noticed you used MPEG2dec3.dll in your tests. Wasn't there some
changes made to it ??

And, are you SURE you are using the exact same script, same Filters, same
everything ??

However, if you still are insistant, that I'm in error (as I am at times)
you can do the following then. Assuming that it's not the color space or
YUY2 vs. YV12, then perform the same senario as above (Fig A) BUT, this
time, take out the MA script functions, and only use the script filters
in v2.08 and see what you get in those two file sizes (.m2v / .m1v)
Again, assuming your're correct, you should two files that are:

* same size
* same quality
* or, same whatever

But, first we need to keep the file (or files) that ToK creates during
the predict process. I think that all he (or you) have to do is revise
the .tpr file to no delete the .m1v or .m2v files it creates. I know it's
only ONE file that it creats, but if it could STOP deleting them, and in
stead, use index numbers for each file, that'll help us w/ our (your)
analisis/comparison of v2.08's based predicts vs. v2.52's !!

What do you think. And, remember, be nice.. I'm ONLY trying to help !!

-vhelp

@ Kwag..

Ok, wait a minute.. maybe I need to re-read your post(s)

At first, I thought you were not getting the same results based on
the same movie you ran ToK (prediction) on in a preivous AVIsynth
v2.08 and that your final numbers were way off, but that you felt
v2.52 should have matched v2.08 - - Am I understanding you now ??

Now, I'm thinking that you went past that stage, and am not now
at the stage where you are not getting an "accurate" predict, using
the latest AVIsynth v2.52 version (IOW, you're not comparying
AVIsynth v2.08 against v2.52, but rather, you are comparing the
"predictability" rate or accuracy when using w/ v2.52 vs. v2.08
<-- follow me ??

I think I now follow you. If that is what you are saying, then
I appoligize for my insistive behavior, and rambling on. But,
I still feel the above posts hold truth in another perfective

So, based on my newly found realization, have you done other tests
like:
* again, take out the MA script functions, and just run the test
that way and see how close you get. As, Joz or ovs64 said, it
may be the MA script functions that needs to be fine-tuned.

I don't know.. I'm just trying to help narrow down the causes.

-vhelp

and i am

reading this all..cross-eyed and too cos
i'm lost.
i see the last changes in the script,was removed:
conditionalfilter( last, asharp(-1,0), last, "nf", ">", "scd_trigger" )
and
scd_trigger=30

this will change the velocity and the final prediction too.

then someone would help me to use the prediction or
is better wait a little more for your results to
put my feet in the earth?
i'm out of space.

@ Kwag..

I just had a thought (made sense to me) w/ ToK's output. When I cancelled
the first pass, and wait a little for it to finish, I stopped TMPG.

Next, I examined the .m1v file (which by the way seems to be a bug in ToK)
I selected SVCD, but it's still making MPEG-1 samples

Anyways..
And I examined the .m1v (which was suppose to be MPEG-2) and I observed
how it scene-changed through those Samples. I noticed that there were
far too many abruptness when TMPG encoded those scene changes w/ the
MA script's MA functions. There were soo many bad encoding around
these, and as far as I can tell, that leaves to increased filesize.

Ok, so given the above, I think that the MA functions have to really
looked at.

W/ respect to above, I've done a few of my own encoding w/ MA script and
I can say, that I STILL find it is not encoding these scene-changes
smoothely.

If we setup some sort of analigy tool like this, caues I don't know
any other way to demonstrate that you would understand:

* Bf,Df,Af represents the SCENE Changing.. beforeFrame/duringFRAME/afterFrame

An example:

When doing "Deuce Bigalow", during a low motion scene change:
* Bf would blur, then
* Df would be clear (normal)
* Af would be blur again
-- -- -- (Fig A) -- -- --
.
.....OR,
.
* Bf would blur, then
* Df would blur, then
* Af would be blur again
-- -- -- (Fig B) -- -- --

Note, that Bf,Df,Af would alternate in these anamilies in various order.

Now, since this caught my eye, I decided to follow the test encode I did
w/ MA script. I found Fig A and Fig B through my test clips, and that the
effect (dramatic or not) would depend on the scenes low motion or hi motion
would refect the MA's function's effectiveness, hence Fig A, and Fig B.

Some how, this has to be fine-tuned some more, because there is obvious
issues w/ the scene detection algorithm, which is probably what's causing
the predict to be thrown off

I'll play around w/ this some more.

That's my theory so far. Unless you can come up w/ a better one.
-vhelp

Finding a way around the sheer "unpredictibility" of scene changes, movie to movie, that are
"super compressed " with the "Adaptive" script, is both our blessing and curse.
This "unpredictibility" also only increases (theoreticly) as a movie`s timeline gets longer to boot.

What we aren`t sampling is what`s skewing the math, I believe.
Someone correct me if I`m wrong here.

Kwag once joked to me "what we need is a scene change counter"....more truth than jest.

To bad we can`t use some kinda` "transcode" technology with it...



*******************************
The Devil`s always.....in the Details!