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 8)

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. :twisted:

-kwag

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

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 8O

Now, hold on before you scream :lol:
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.

http://www.digitalfaq.com/archives/error.gif

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 8O 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 :mrgreen:

@ 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 :wink:

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 :wink:
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

Current prediction algorithm: Q for 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,

Re: Current prediction algorithm: Q for Kwag
 

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 :!: :x
Finished "The Boondock Saints" with these results:
Wanted file size: 722,779.89KB
Real encoded final file size: :arrow: 645,083KB
So as you can see, prediction is sucking wind :evil: :!:
Back to the drawing board :cry: :cry: :cry: :cry: :cry:

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... :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

8O

and i am
:Drunk:
reading this all..cross-eyed and :oops: 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.
:lol:

@ 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 8O still 8O making MPEG-1 samples 8O 8O 8O

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... :lol:



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

@All,

Well here I go again.
Hopefully we start zeroing in on this inconsistency.
I just finished encoding "The Boondock Saints" with the following changes:

(1) Turned ON Scene change detect on TMPEG. Yes :!:, it seems to be working, and for some "I_DON'T_KNOW_WHY_REASON" the file size is smaller 8O with the option turned on. Don't ask me why! Seems TMPEG is playing tricks on us 8)
Apparently, it optimizes the compression much better with variable GOP, which is the case with this option turned on. Yep, you heard it right: The file size is smaller with scene change detection on. Maybe one reason for the erratic prediction :idea: BTW, I'm using TMPGEnc 2.513.

(2) Changed the GOP back to 24, because 12 was just as unpredictable as 24. So I'll leave it at 24, for a smoother picture, plus now it's variable anyway with the change described above.

(3) Enabled the scene change detection in ToK's "Video.en1" file. Here it is, so you can copy it to your OPT directory: http://www.kvcd.net/video.en1

(4) As posted on the current optimal script page, I removed the line:
conditionalfilter( last, asharp(-1,0), last, "nf", ">", "scd_trigger" )
Read the change log for the explanation.

So here are my "The Boondock Saints" results this time:

Wanted video size: 714,303.19
Final encoded video size: 690.997 :)
For a difrerence of 3.3%, which I can tolerate as long as is negative :!:
The CQ was 63.02, and my manual CQ calculation was 63 :!: So ToK is doing the job correctly. This was using first and second pass as full sampler. Not the fast 10% sampler. That will come later. I'm just trying to get this back on a consistent state.
Now back to encode "K-Pax", and see what comes out, as that was the other extreme yesterday.

-kwag

@ vico1..

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

Well, if we could only just get the "bitrate" accross the time-line, much
like what BV.EXE does, we're in for go, and so much for MA, as we know it.

Yes, I believe that Kwag made mention of these in previous topics
elsewhere's. I've ben wondering about this myself. It's a matter of time
before someone (here or doom9) finds the technique and shares it (we hope) !!

Then, finally we'll be ride of those items that plauged us in past.. some ie's:
* poor quality
* poor predictions
* better CDr/rw - DVDr/rw handling (on a disk per bases)
* anything else to ad here

-vhelp

.
.

And, as for the MA script, I've ben messing around w/ some of the code,
and I've ben playing w/ the:
* scd_trigger = 60, and
* ScriptClip().. w/ asharp( -(fmin((nf/60), 1)) uses

Note the 60 instead of 30.
I think I've had better results, but I'm still debating the above changes I've
ben toying around with.

One thing I noticed still, is the shifting up/dn of the video on the first Bf.
If you remember my Bf/Df/Af analigy in my previous post.

To better analigies it:
CL....FRAME...Fltr.....STRENGTH...Notes
----------------------------------------------------------
Bf - 69379 - blur - 2 - noChange - person sitting
Df - 69380 - blur - 1 - noChange - person sitting
Af - 69381 - clear - 1 - sceneChange - person is walking
...
Bf - 69806 - blur - 2 - noChange - person sitting
Df - 69807 - clear - 1 - sceneChange - person sitting
Af - 69808 - clear - 1 - noChange - person is walking

Note 1,
The blur/blur/clear, and blur/clear/clear (for Bf/Df/Af)

Note 2,
The above is an example of trying to describe the MA process
a little better, I think. A way to visualize in a descriptive manor.
I guess I would catagorize it as a "tool"

Note 3,
The 2 and 1 are the Strength of the filter being applied. ie, I
noticed that on first frame BF, it would be strong hence the 2,
and on the Df frame, it would sometimes be less strength, or 1.

If the above help some, when working out this MA script :wink:
I hope this "tool" can be useful.

-vhelp

@ all..

Can we try a different Filter in place of TemporalSoften(2,7,7,3,2)
I'm not liking all that much in my detais when I run it through vdub on
some items. it's smudging the letters too distortedly like.

And, I'm having difficulty adentifying those filters that will work under
YV12 color space. I'm still getting that noticable color washout look when
I compare two vdub's together, I can see one has richer colors. Anyways..

Can someone throw up a few Filters in place of the above ??
(but that will work w/out error showing up in vdub's screen.. YV12 arrr!!)

Thanks.
-vhelp

Hi Vhelp im currently using the act filter which is a temporal Smoother
n to me it does a pretty good job at smoothing and blending detail, kind of take away the fliks, i use atc(3,6,9,0.5,false) in place of the TemporalSoften(2,7,7,3,2) .

BTW: act is a YV12 filter too

@ ovg64..

Great. I'll look up that filter in my repository hehe..
Ohoh.. looks like I GOT IT. yippy. I'm gonna try. Just finished one of
my test encodes w/ MA script. Looks good too. Hay, now I'll do a test
compar w/ Temporal(2,7,7,3,2) vs. your act(3,6,9,0.5,false)

Thanks.

Any more suggests ?? i'm gain to give them a shot. I'm having fun now :)
-vhelp

Yes Vhelp Convolution works like the old conv. and the new version
of STMedianFilter is 0.1.0.1 :wink: they r also YV12.

BTW: who's osv64 :?: :lol:

Here are the results and analisys on my K-Pax encode:

Wanted video file size: 714,303KB
Encoded video file size: 741,735KB

A difference of ~+3.69%

And this is GOOD :!:
Here's the pattern I see. On action movies, file size will be ~3% smaller MAX.
On low action movies (like K-Pax), file size will be ~3% larger MAX.
So normal "average" films should target ~100% accuracy :!:
There's something I did notice, and that is that just before the end credits, the file size was just at about 714MB, which was the wanted size. So the end credits is REALLY what's throwing off the calculations :)
I was watching TMPEG as it was encoding the end credits, and the file size was soaring high on the vertical scroll of the credits. "THAT'S OUR MAIN PROBLEM" The function "YDifferenceToNext()" reports a VERY LOW value on the end credits (verified with Vdub adding "nf" variable from script as subtitle), even though the scroll is a very high difference to next frame :!: But because it's mainly a black screen with text scrolling vertically, the returned value is very small, and we are loosing A LOT of compression there :!:
So my suggestions are as follow:

(1) Cut off end credits with AviSynth's function "Trim", and encode with a factor of 1.0. OR take into consideration the type of movie you're about to encode. If it's a low action film, subtract 3% (multiply by 0.97) the wanted sampler size.
If it's an action film, add 3% (multiply by 1.03) the wanted sampler size.
If it's an average film, don't add or subtract anything :)
(2) If using ToK, the same applies, BUT:
(a) Use a factor of 0.97 for low action movies.
(b) Use a factor of 1.03 for action movies.
(c) Use a factor of 1.0 for regular (average movies)

*** PAL people, could you please test this please ***
Please use the "Video.en1" file I uploaded earlier ( www.kvcd.net/video.en1 ) and copy it to your ToK OPT directory.
*** PLEASE, let us know your results :!: ***


-kwag

kwag it's funny you mention the end credits messing up the movie. I've been having fairly accurate results using the old style prediction with a high sample length of 48 and prediction factor of 1.00.

Precition was erratic but kind of on target. Well I allways cut the end credits except for this one movie where I wanted to keep them. That movie has given me so much trouble over the last few days. I've encoded it 4 times lowering the CQ tons and it allways over shoots the mark by several MB. Based on what I've seen in my last few encodes it is pretty much consistant with your results.

Well, now we just need some feedback from PAL land, and see how the results match :)

-kwag

I'm currently @work :roll: .. I'll start the encoding this evening. I think i will encode "The Fast and the Furious". What factor should i use, what do you think?
Mabye another PAL-User can give any feedback? Jorel :D :?: .

EDIT: Encoding "The Score" with factor 1.0.

Well the thing i see here is that you already had rich file size
before the end credits, so again that shows the inability of tok
predicting when the AScript is turning on n off (blur), as for the
for the end credits shooting up the bitrate i seen that even before
the adaptive script while using 2.08 so i not sure kwag but to me that just
the way Tmpeg encodes. Maybe by lowing the max bitrate from 2500 to
2300 stabilize prediction :idea: just a tough.

hi Krassi!

in Brasil is pal-m, different from europe pal-g.
then here we encode ntsc-m, the tvs, vk7 and dvds have "dual systems".
ntsc-m is the normal ntsc (like in USA)
the letters "g" and "m" in the final of the system
have a big difference between them,
not only the sizes but all the transmition and reception too.
see, a pal-g tv in Brasil don't work,don't show the image or sound.
the ntsc tv in Brasil stay "black&white" and we need to
make some "transcodifications" as we call,in the color system.
pal and ntsc are the names of the color systems
and "g" and "m" are the "standard" for the remainder signals.
is a big difference.
:wink:

8O
And I always thought PAL=PAL...
Another contribution to my knowledge! Thanks Jorge! :D

As jorel said, pal and ntsc tell how color info is multiplexed into the analog signal. NTSC is one of the first color muxing standards. PAL is more sophisticated and has more stable colors.

the G and M refer to the vertical scanning frequencies, and set the number of lines. As a rule of thumb this is 1/2 the AC power frequency. There are many standards, like M, N, G.

NTSC-M (Japan, USA) is ~30fps. In these countries AC power is 60Hz. You have 480 lines.

In countries where the AC power is 50Hz (most of Europe?) the video standard is 25fps, 576 lines.

In Brazil we have PAL color encoding, but AC power is 60Hz, so we have PAL-M, ~30fps, 480 lines.

So, when you associate PAL=576 lines, NTSC=480 lines, that's not exact.

PS.: It is a hell to find capture cards that support this (since Brazil is the only country that has this standard). The only one I know is ATI AIW, but it works OK with PAL-M broadcast signals but not with prerecorded PAL-M tapes.

PS2: jorel, eu conheci o cara que ajudou a implantar a TV colorida no Brasil, e que definiu o sistema PAL-M. Era o professor Alcione, do IME. MUIIITO fera, mas doidinho :)

Hi Jorel,
sorry, didn't know about that. Seems to be very complicated. Just saw in a list that Brazil has PAL-Standard :oops: .
However, about ~ 3 hours to go...

yes Krassi,
big complicated.

jell and GFR:
the differences are more than vertical and number of the lines.
i try to explain..if my english help me:

frequences of color transmitions
ntsc-m: 3.579.545
pal-n:3.579.545
pal-m:3.575.561.149
pal-g:4.5...?(don't remember the rest)

the sizes of the "channels bands" and the audio band
is different between "m" and "g".

ntsc have in vector:
zero>the burst signal
+90>the red signal
+180>the blue signal

pal have in vector:
zero>the burst signal
+90>the red signal(one phase)
-90>the red signal(another phase)
180>the blue signal

pal-m is the same like pal-g but
in Brasil we have a circuit called
"pal key" that find what is +90 red and what is -90 red
and turn all red in +90 like in ntsc,without invertion of colors
like sometimes the ntsc turn the red to green and the blue to purple.
this circuit find and turn the lines to the original poinr in vector.

the reference for the colors in vector is the "zero" burst.
in ntsc if the +90 turn to -90,the burst see the red
in 90 degrees and "think" that he is correct in the vector but
the red is 180 degress from the original point and show as green.
than we use the "tint" or "hue" to correct this.
the pal system is to correct the original
-90 red automatically to +90 and turn the system stable.
this is the reason of the name "pal":
Phase Alternating Line!

well this is just only for the color...the tuner band,the audio band,
and lots more things are differents between "m" and "g".

i will that my poor english don't turn it all more confused,
i can't explain better than this.
:oops:

GFR:
"Era o professor Alcione, do IME."
já ouvir falar muito bem dele... :wink:

me pareço bastante com ele na parte do "doidin".
:lol:

>>this is the reason of the name "pal":
Phase Alternating Line!

Or as people say "Peace At Last"! against "Never Twice the Same Color". :)

I forgot the funny acronym for SECAM.

Yepp, thats right :lol: ... Here are the results :roll: :
Factor was 1.0, New Prediction Method in ToK and 3 Samples/Minute. Credits were cut off.

3 samples a minute, of how many frames per sample :?:
I'm using one sample per minute of 24 frames each :!:

-kwag