Kwag can you help explain this to me.

I used the same movie and .avs file.

On the first encode I used a max and min in my TMPGEnc project file of 300 and 2500. It picked a CQ of about 63 and the final video size was 635,563

On the second I used a max of 2500 and min of .57*Avg which was about 650kb for the min. It picked a CQ of 57 and the final video size was 649,798

So the CQ went down, but the final video size went up?? How can that be

hi audio2honda,

I've experienced this too, in other encoding projects and things.

I've not ben able to come up w/ an 100% explanaa, but I have theorised
that..

when you encode w/ your scenerio as in your example:
* max2500 and min300

.. the quality at that given scale, macro block for macro block had reached
an equalized bitrate distribution (or equlibrium)

when you upped the min to:
* max2500 and min650

.. in effect, changed the scale (or threshold) and all of the sudden, the
macro blocks had some more time to deal w/ those pixels, and did a better
job at giving smoother blocks, hence in short, lesser bitrate was needed.

Thats the only theory I have come up with in my past encodes with type
of expeirence (phenominon) and I've had plenty of those, using a few of
my SuperBit DVD's.

I hope all that made some sense out of it.. as it does to me w/ my encodes

I'm sorry I can't exactly express in better, clearer words, but perhaps
Kwag can

-vhelp

Because when you increase the MIN, you increase the CQ curve. The CQ value is just a reference for CQ calculations. It wil give you a complete different value if you change MIN or MAX.
That's the reason for the (avg. * 0.57). To push the CQ curve into a more predictable range. The problem is related to the low average we use on KVCDs. If you were predicting for 2 CDs or for a DVDs, where the average is high up in the ~1,500Kbps+, then TMPEG has a better linear range for bitrate allocation. When we use a MAX of 2,500, MIN of 300 and average down around 800Kbps, the MIN and MAX are to far apart and not centered, in reference to the average bitrate.
This problem is also clearly seen with the MainConcept encoder, when trying to use low averages, and high MAX bitrates.

Edit: I'm currently running some tests, related to MIN, Avg. and MAX suggestions for higher file size preciction accuracy. I'll post results later today.

-kwag

Ok makes sense. So is it safe to say that in this case the lower CQ, but higher file size will look better?

I just feel like I'm losing out on quality when I use 2000 as a max although that prolly does give the most accurate file size.

Yes. That could be case, if you are not using the MA script. I'm using 2,000 MAX all the time with the MA script. But if I wasn't, then a MAX of 2,000 might be a problem
That now brings me to think of a new addition to our procedures, and that is to do some kind of analysis on the material to be encoded, and if it is a low action material, we can increase the MIN bitrate much closer to the average and if it's a very high action material, we can drop the MIN further apart from MIN
This would guarantee that if it's an action movie, more bitrate would be allocated on high speed scenes without wasting it on dark and low motion scenes with a MIN above the real needed MIN bitrate. So maybe some formula could be derived, that would give us an optimal MIN/MAX/Average ratio depending on the movie activity

Looks like this week is going to be another fun week

-kwag

Yes it does.

.
.
But, Kwag.. how would we know for sure, or, HOW MUCH action
is considered a change in algo ??

That's always ben my issue. I have to see the movie, and notice what makes
it action vs very action, vs calm vs. whatever else. Maybe a scale could
be derived, based on a table of some sort for this.. must like what I have
for the (0.57 * ave) in vcalc though

But, still, it would be rather difficult to conjure up such a receipe
-vhelp

.
.
Yeah, much like a lever switch:

* Very High -- -- (Arnold, water, fences, rain etc)
* High -- -- -- --- (some Arnold, water fences and rain drops)
* Low -- -- -- --- (ie, k-pax)
* Boring -- -- -- -(talk shows ie)



-vhelp

It's soooo easy
Ratio = Movie Source (DVD) Video Stream Size in MB / Movie Time in Minutes
The larger the Ratio, the more active the movie is

-kwag

hi Kwag..

Actually, I don't get it, but I'll massuage it around a bit in my spreadsheet and my head

But, basiclaly, you're saying then, that whatever the final file size would be
ie, say MStaker reports Wanted Filesize: 695mb, that THAT becomes my
Ratio ?? or else, how to obtain my "Movie Source..." size ??

..otherwise, the above analygy would be something like:

Ratio = Movie Source (DVD) Video Stream Size in MB / Movie Time in Minutes..

... or ...,

Ratio = (695mb / 123min) = 4 --> compare to scale(1,2,3,4,5)

So, given the Scale below w/ values:
1 = 820mb - Very High action
2 = 790mb - Very High action
3 = 770mb - High actoin
4 = 720mb - Mid action
5 = 650mb - low action

I don't know what you would concider the scale to be w/ just the right values
and all, but you would prob be the best one to revise the above scale w/
more accurate values

EDIT: - - then, based on 4 value, go to algo to handle the
bitrate calc for that given encode ??

Those above are just random thought

What are your comments regarding the above ??
-vhelp

No. I clearly said: Movie Source (DVD) Video Stream
That means Stripped MPEG-2 video stream. You can see that size with DVD Shrink. It let's you "see" the video stream file size, wthout overhead of the other streams. So just divide the true video size by the time of the movie, and that will give you a ratio. Obviousy, the larger the file/movie time ratio, means more film activity.

-kwag

Hi Kwag..

I got it. I realized, after seeing the "DVD" inside that formula, that you
ment for the Actual DVD source size, not our calculated size

But, I was still able to play around w/ this in my spreadsheet
Anyways..

Thanks for all your helpful pointer and explanations,
-vhelp

PS: After a second run on "Get Karter" s/ CQM v1.1.07, I went from an
previous CQ value of 39 to a CQ of 56.021 now. Quality was way much
better than the first, but I'll have to double check that score to be sure the
previous value was 39. In any event, latest CQM showed much better
results for my MPEG-2 tests, though based off a 21 minute test VOB.
I'll do a full "Get Karter" test, later on, if I have the opportunity and post
the results. Hope it's not weird though.