What in the case of not anamorphic encoding?

If you do a 16:9->4:3 conversion, there'll be less film pixels of course due to the black borders. However, you cannot say that the complexity will be less than in some other movie without encoding a sample clip of both of them.

Really cq_maxbitrate mode can be selected for the user instead of cq mode.
Only need to disable *cq with a blank space before *, enabling *cq_maxbitrate 1.5 (or 1 as less value better quality) withdrawing the blank space before the *.

Sorry, the program write it but I manage to delete it as the working folder is full of stuff.
Do you think the HC log could be useful in any way?

A test comparing cq and cq_maxbitrate modes.

http://rapidshare.de/files/5228378/P..._cq_.html.html

http://rapidshare.de/files/5228432/P...rate.html.html

HC in cq_maxbitrate mode frequently undersize files. You can see this in first and third file of cq_maxbitrate log. Therefore, second file increase its avg btr as a direct result of ASPA.
I think we should use ProCalc Lite managing HC in cq mode, as in this case the bitrate allocation is the correct (despite the spikes), remember that cq_maxbitrate undersizes.
Then, you need to do the final encoder with an encoder or mode that don't give you those spikes:

For example using CQmatic with the minutes, seconds and avg btr that gives you ProCalc Lite, or using HC Encoder in 2 pass VBR (I never see such precission in a final size) using avg bitrate or file length in KB that gives you ProCalc Lite.
Another option would be AutoQ2, I don't tested it yet but it could be enough good for a CQ encoding with CCE.

Updated:

http://www.kvcd.net/forum/viewtopic....asc&highlight=

I did also a quick and single test and with cq_maxbitrate the bitrate never go above 2300 when I allowed 4500. For sure, this limits the peaks, but a "little" too much

Thanks for your update, I will try it.

CQ_maxbitrate doesn't scale the maximum bitrate down drastically. It only comes into effect when you get a spot where the maximum bitrate would be exceeded - it simply raises the quantizer till the result is below the max bitrate. As I said, I've seen max bitrates of ~50kbps less than the specified maximum with cq_maxbitrate. Try with a high-bitrate matrix and see if it does the same.

My test tells the opposite, but in fact the documentation is not really clear : what means the parameter that you put after the cq_maxbirate ?
In my test I used the value that was in the example file I had, and it was 7.6. So what is the meaning ? Is 7.6 the max Q that will be used in case of peak ?
Before the encoding have been done with "cq 1.5". Do I have to put also '1.5' on the cq_maxbitrate line to encode in the same conditons for both tests ?

Last question, do I have to put the two lines ? I tested but the result was somheow the same.

CQ_maxbitrate 7.6 means that you run a CQ encode with quantizer 7.6 but the maximum bitrate is respected. CQ 7.6 would be exactly the same but the maximum bitrate is not respected and the resulting video file might be non-DVD compliant. You only need either CQ or CQ_maxbitrate in the ini file. Think of the CQ value as the same as Q in CCE.

@Dialhot:
Theoretically, for ProCalc Lite, i think it would be the same using 1.5 or 7.6 or whatelse value, ever that you use same value for all streams.
I did choice 1.5 arbitrarily.

IMO a low value should give a better distribution between high and low bitrate consumption as very dark scenes would consume very few bits and high-motion, bright ones would get near max bitrates. That is, it should be best to keep it as low as possible.

With CCE I always run the samples at Q30 because that's the highest Q value I accept. I can then easily see whether the final encode would be over that limit and do necessary adjustments if needed. With HC it's not that simple as the given value means quantization and there's no telling which one would be the limit. Different matrices have different limits etc.

I did a test and obtained values are differents, so i would use a value between 1 and 2.5.

Quant 2 might be the sweet spot for sampling,it's generally used in compression tests with MPEG4 as the highest point of quality, q1 is used only for avoiding undersized encodes. Quant 1 generally has a huge impact on filesize so that might explain why Phil got those extra large spikes on his test samples.

I'm not saying that any of this rambling is correct and the absolute truth

I understand and my question was more general than that. Actually, ASPA gave me quite the same results whatever the settings I put in HC.ini.
Okay, that explains why my test was so awfull compared to the previous one (with cq 1.5). I thought that 7.6 was the maximum value the quantizer will take to respect the max bitrate.

Updated: SET/18/2005
- You can keep HC Encoder log checking a checkbox.

http://www.kvcd.net/forum/viewtopic....asc&highlight=

Thanks for the update Luis.

__________________
Regards.

Michael.

Updated: OCT/15/2005
- ProCalc Lite 1.3.0.2b
- You can call now PARanoia from within ProCalc Lite.

http://www.kvcd.net/forum/viewtopic.php?p=120280#120280

Changed name to ProCalc ASPA Lite to avoid confussions (and maybe licences issues) as another ProCalc programs can be found in the net.

Updated NOV/27/2005:
- ProCalc ASPA 1.6.0.0b
- Added preview of avs script.
- Added edition and see changes in preview window.
- Added comparation routine (thanks to Diahot) in preview window.
- Help file updated, including how to use these functions. Press F1 to obtain help.

ProCalc ASPA Lite 1.6.0.0b