And remember this Fiz: "Never drink beer while doing math" ( as I was last night :oops: :lol: )

-kwag

lol :!: I bet you had a splitting headache after that :drink: + :book: = :cut:

ps. See my previous post, I've got the cq now and am doing a full encode.

Is your movie wide screen 16:9 :?:
Because if it is, and you are using the MA script, it might be the right CQ because that movie is very low action :!:
Also, it's a 102 minute film, so it's not too long.

-kwag

Forgot to mention.

CQ=81.75
Wanted Sample Size = 7,080Kb
Sample with CQ of 81.75 = 6,909Kb
Sample with CQ of 81.5 = 6,807Kb

I'm going with 81.5 for safety but I still think it's too high. Lets wait and see.

The other factor is it's a PAL movie 8O ...

Edit: Just saw your last post. Its wide screen and yes I'm using the MA script. I'll post the results tomorrow (as it's late here in the UK :wink: )

You did take the average bitrate of your source with Vdub, and not with Bitrate Viewer, right :?: :?:

Yup, I took the demuxed m2v and opened in vdub. The file information showed the average bit rate as 4596Kbs.

The clip was very near to 1 minute long (1512 frames) and the sample avs encode I'm doing to get the CQ is being trimmed from 0 to 1512 frames.

Am I doing it correctly :?:

Yes you are correct :D
Let's see how the file comes out. Hope it's not a 1GB file 8O
That would mean this is another "failed" attempt at file prediction :cry:

-kwag

@Fiz,

Look what I found:

"By the way, get this: with Signs I was able to use a CQ of 73 at 528x480 as opposed to Death To Smoochy's CQ of 62 at 352x480. This despite the fact that they are almost exactly the same length and have the same aspect ratio (16:9). "

This was posted back in January by SansGrip, when we were doing experiments on CQ vs. CQ_VBR. At this time, there was no MA scripts :!:
So maybe with all the new stuff, and the current version of TMPEG, your value is right :!:
Just a thought.

-kwag

Thanks kwag, good find! I'm encoding at 528x576 (with 2 overscan blocks). I'm kinda hoping it starts compressing better coz it's done 10 minutes of the encode and it's already at 114Mb :!: :(

Hey Fiz, could it be that the average bitrate displayed with Vdub is incorrect for PAL :?:
Could you do a test. Divide your demuxed .m2v file size by the exact time of the file in seconds, and multiply by 8 :!:
That will give you the average bitrate of the clip. See if it matches the one reported by Vdub.

Edit: I'm currently exactly 25% into the "The Bourne Identity" encode. At 25%, file size is ~178,000, which * 4 is 712,000 and wanted file size is 715,701 :)

-kwag

I get

(34759.502 / 60.480) * 8 = 4597.817

VDub says 4596 so that should be close enough?

Sounds like your prediction is going better than mine! I think mine is thrown off because of the start credits on this movie. The sample clip is compressing too well for TmpegEnc and it's giving me too high a cq to start with.

Edit:

I just noticed something! I was not using the exact file size before for the demuxed .m2v file. I was taking the value in explorer.

With the exact file size I get:

(717784.65/102/947) / (34759.502/4596) = 0.9825 :oops: :oops:

My sample size should therefore have been: 6,913.95Mb

It means the CQ is still the same though, but I should be more careful with the figures 8O

Yes that's right.It shouldn't make a difference :!:, because it's the same ratio on the source to destination :!: Unless I have overlooked something :roll:

-kwag

See my edit on my last post :oops:

What was the size of your sampler with the CQ you are encoding right now :?:

I'm encoding at CQ 81.5 and the size was 6,807kb.

Ok, so there shouldn't be any changes necessary. Weird 8O
Could this be a "PAL/AviSynth/TMPEG" related issue that is also haunting us with inconsistencies in file size prediction it ToK :idea: :?:

-kwag

Fiz,

I think there could be an explanation to the CQ you got :!:
On the two films I've encoded, all are FILM (23.976fps progressive) from the beginning.
I know yours is PAL, but if you press "F5" in DVD2AVI or MPEG2Cut when you load your first VOB, does it show some type of "mixed" mode before the actual movie kicks in :?:
If this is the case, then we can't use the sample cut from frame 0 on the first VOB, because some VOBs have the initial credits in mixed mode, until the actual movie starts. This could be the cause of the weird CQ you got :!:
Could you confirm this :?:
If this is the case, we can start from the first minute of VOB #2, because it's already deep in the movie :idea:

-kwag

Quoting myself, so you don't have to go back and search the post referenced ;)
Final result:
Wanted file size: 715,701.22KB
Encoded file size: 702,662KB

I'll let you guys do the math :mrgreen:
Now on to another encode ;)

-kwag

Ok, checked the result this morning:

Movie Signs:
Wanted File size: 717,784.65Kb
Encoded File size (CQ 81.5): 1,106,992.461Kbs :cry:

I'll try your recommendations tonight kwag as I am at work today :(
If it is mixed mode for the start credits that could explain it. I'll take a one minute cut from VOB2 and compare the results again. Sounds like you are getting very promising results so I won't give up hope yet :!:

Hi Fiz,

Total crash today 8O
I was encoding the movie "Count of Monte Cristo", and I had the same behaviour you had :!:
At 10% it was already around 100MB :!:, so I don't understand what's going on, after having such precise results with a couple of movies.
And this was with the second VOB, to remove any possibilities of mixed mode in the beginning of the movie. Something is not "constant" somewhere, and I'm after it :twisted:
I think we're into something very good here, but more factors need to be found.

-kwag