:x Read my response to ren above :x

No, wait, thats not what I mean :? ...I meant I ran Sampler at CQ 100, divided Moviestacker average by BitrateCalc average, turned out at 88.85...I then encoded a sample at 88.85, and, according to manual filesize prediction, my file should have been 11.4 MBs, actual file was 13.5.

Oops, didn't see your post kwag......oh dear.... :cry:

Right, that's what I thought. That's exactly the difference I got.
Now wait a minute :!: , coincidence :?: or could this mean we have a constant factor :idea: 11.4/13.5 = 0.84 so 0.84 * (*CQ) in chart for 352x480 resolution :idea: ( Last try :!: )
If that is the case, there is just one constant for different resolutions, and the same chart :idea:
Let me know, so I don't finish digging the hole 8)

-kwag

Does it make any difference if your target is 1 CD or 2 CD's for this chart? My sample size for Ronin is 21.5 Mb, which might be ok for 2 CD's, but what if i want it on 1 CD? I'm using KVCDx3.

hey kwag,

don't feel bad- I can't tell you how long i worked on that cheesy file size predictor thingy and then SansGrip put a nice one out with a gui at the same time (that was funny) :oops: :lol:

The good news is the shape of the curve is the same (i think more testing should be done to confirm this) so maybe if one sample at cq100 is encoded then the range of the curve can be adjusted in the equation based on the resolution :idea:

ren

:mrgreen:I just got a diff of .83 (see my previous post ) on another sampler, also at 352x480 8O.
So I'm running a sampler with the chart value * .83 to see if it hits the same file size that the regular formula wants. Then I'll try another movie to see if the factor is constant on a resolution basis.

-kwag

Hi Kwag..

I was following along Friday at work, and now here at home, (since I've
ben away surfing other areas of the world on a project)

Don't give up too easy. How about just mapping out for each of the major
resolutions and then formulating a Function(res, CDs, CQ) = CQ ??

The data could be stored in a table or DB table and imported into the final
App upon startup. This way, when NEWer data (continues, as it will) flowing
in, those will simply be added in to the calculation factor. Follow me so
far ??

Well, I have some reading up to do, as well as learn a few new things..

-vhelp

Well, it looks like the resolution doesn't really affect the curve to me...but then I could be wrong...anyway I made this to try and make some use of the data we have so far:
CQestimation.xls

I just used kwags results, and divided each filesize by the CQ 100 filesize to get a factor for each one, with CQ 100 as 1.000.

It seems to be able to predict an approximate CQ quite well on only a third sampler...although it sometimes underestimates the CQ quite a bit, but hasn't overestimated it yet, but then I haven't really tested it properly.

In only works in whole CQ numbers which probably affects how accurate it can be...looks to me like it needs a lot of work to be more accurate. Well, let me know if :imstupid: ......

It's a really stupid idea??? :oops:

Or has this project been abandoned and I just haven't realised yet?

Hey Pyromania,

I was not able to download your worksheet before, I got an error screen from geocities but I tried it again and now I'm looking at it in Excel 8)

I'm not giving up on this yet :roll: I've been doing tons of sample encodes and it's very time consuming :wink:

I'm going to check out your worksheet now

Here's the one I've been working on prediction.xls

ren