Hi,

After encoding the movie, I get a 2% difference between proyected size and real size. That's not too bad, but not good.

Then, I plot Rendalunit datas, and I get this:

The curves are similar, but one can't be obtained from the other by multiplying. So, to get one movie curve, we should encode 2 samples...

@Ren: is your movie PAL o NTSC? I say that, because I get good results with 2 of the 3 movies I have (0,89 and 0,23%).

I'll test that with another PAL movie to see if it's the same things.

Fabrice

hi Fabrice,

my movie's NTSC

ren

Well,

The third movie gives even more diferences: begin higher than the 2 others, but ended 30 % lower than mine (the red one).

So until I had the equation modeling this curve (I'm sure there is one), This thread doesn't have any sense...

Fabrice

Have you seen this thread?
http://www.kvcd.net/forum/viewtopic....r=asc&start=16

GFR had some very good ideas- the math is too advanced for me though and I don't understand 'sigmoidal curves'

ren

HI,

Sigmoidal just means - looks lika a "S"

oh! Well I guess I understand that (I think)

Thanks,
ren

Hi,

@rendalunit: Thanks to point me this thread out. What is strange is that we don't get the same curve type than 5 month ago...

Well, after trying to get a generic equation, I have to say that it's not so simple as I thought, because after 'normalising' the curve base with a polynomial equation (a + b x + c x^2), to get a flat base, the resulting curse is not a symetric sinusoidal curve...

As the first equation has 3 parameters, and they don't seem to be correlated, we need at least 3 samples...

If someone better than me with statistics wants to try getting the equation, I have a xls file with the 3 curves...

Fabrice

That's rignt, and that will always be a problem
Any internal changes to TMPEG's code on every new release, and we'll wind up with a different curve

-kwag

@ Kwag..

Unfortuntely, that is true I hate "incontenance" I mean, "inconsistancy" - rAtZsS

But, although that might be an issue, there STILL is a way around it, easily.
Don't be lazy. Just add in some code, to get response back from user of
what version of TMPG is used. Then, we just branch off to the desired
algo/subroutine to hand the necessary equasions and things.. that's why
I decided to add in the option to select your method of bitrate calculation
in vcalc ie, Bearsons, MStaker, vcdhelp, and of course, my own, vcalc hehe..
and all is happy

Something to think about, guys

-vhelp

@ Rendalunit..

pfew !! ..I'm with you here. I've done this many, many times, when I did
a bunch of Excel work, back in my Beta 12a days

I know how a pain it was then, but I wrote a little app that helped me out
a bit on this back then, using VB 3.0 and then ported what I could, to Delphi
cause I LOVE, LOVE Delphi hehe.. Anyways.. I've done some more touch
up work to it, and included some newer features not in those prev. ones.
I'm still working on it at the moment though.. few things to iron out.

But, if you're interested in a little tool to help you out in this area, PM me, and
I'll send you the tool, and you can test it out for yourlself, if it works for you
or not.. so you can do all your zillions and zillions of test..



-vhelp

Nice pic vhelp

-kwag

@ Kwag..

Thanks pal.. but, I forgot how to do .gif's and I can't remember how to
set those up for "background" images, so you don't have to have TWO
separate images rAtZs !! BTW, I use PainShop Pro hehe.. and originally
was suppose to..

-vhelp

Kwag wrote..

PS, since we're all "cartoon" fans of the past hehe..

Hello all,
I'm a newby who has found this thread to be quite interesting; it confirms my own finding of the nonlinearity of the filesize/CQ curve. Interesting too that different versions of TMPGEnc will yeild different results if an equation derived from one version is used on another. Looking at the points plotted on the graphs I can see that for the type of encoding I'm going to be doing that the 78-80 range is going to be the proverbial tiger-tail that needs to be pulled.