The Problem with handbrake...

Since you neglected to give either a vertical dimension or actual aspect ration for the original movie in question, it is difficult to determine if your 320x135 or the 320x128 is correct. For instance, does your calculation include a conversion from rectangular pixels to square pixels? (I assume your source here is a DVD and not something square pixel formatted like the "Fantastic Four" trailer's super widescreen format.

However, if your converted file is incorrect, simply correct it in QT and re-save it. Since no further format conversion is involved, the process only requires the amount of time needed to write the self-contained file to HD.

Based on your last statement, I assume the movie is using an aspect ratio on the order of 2.36:1 with ripped rectangular pixel dimensions of 720x272 or square pixel dimensions of 640x272. What I don't understand is, if using a constrained aspect ratio setting produces what you consider "the correct answer," why to you wish to set it manually? BTW: fractional pixels are ignored. (Although it brings up the question as to whether a rounding or concatenation algorithm is applied when someone enters them.) In any case, it points out another weakness. It appears that both you and HandBrake have ignored "The Rule of Fours." It would be better to use a setting of 320x136 here. If you check the setting of one of the medium "superwides" trailers (e.g., "Fantastic Four) on Apple's QT Trailers, you will see this is the preferred size. (I.e., both 320 and 136 are evenly divisible by 4.)

It has been ripped to h264 at 2000kbps for storage on my laptop.

Was wondering if this was a typo. Didn't know if you menat your were storing the file in H.264 at 720x272, 640x272, or 320x135 resolution at 2000kbps. Seems like a waste of effort if at 640x272 (or larger) since it is roughly equivalent to 500kbps for a 320x136 resolution file.

Okay. The light finally dawns. You are doing all of your calculations in rectangular pixels. As such, I assume your output is for TV only (a rectangular pixel device) and will not be used on a "square pixel" monitor like your computer or your iPod. (Anybody know if iPod TV output is re-scaled for TV? Hmmm... This may be why you cannot view both outputs simultaneously.)

If, on the other hand, your output is for your computer or iPod, then you should be using the settings calculated in HandBrake which performs conversion from rectangular pixels to square pixels before calculating the scaled dimensions. In the case of the iPod, the correct settings for H.264 is 320x136 and this setting is a correctly offered option in Handshake for a 2.35:1 widescreen whose original rectangular dimensions are 720x304.

Therefore, unless you are saving the "distorted" files for some heretofore unspecified purpose, you are wasting storage space for them on your computer and wasting your time performing two separate conversions where a single one would do. (You are using the latest v0.7 release and not the beta version, aren't you?)

That's what the crop function is for!

And this has been discussed before:

( iDaze, "HANDBRAKE H.264 PROBLEM SOLVED!! DOWNLOAD HERE!!!" #111, 10:54am Oct 29, 2005 CDT)

In my case the source movie's ratio is 720x404 (this is the true ratio of the
movie, I got this information out of Compressor.) Scaling it down to 320 will
result in vertical ratio of about 176. But we need 240. Scaling up 320x240
to the height of 404 (because we don't want to loose vertical information)
results in a source rate of about 540x404. Well, now 720 minus 540 is 180.
So we need to crop 180 pixels, thus we need to cut 90 pixels of each side.
That is the value I put in the horizontal crop values.

Well now I get it, I believe 🙂 You just want Handbrake to encode a video for the iPod with a preset, just like in QT. Maybe someone implements that feature as an addition for future releases. FourtyTwoDVDVxPlus has a preset. Well, from your point of view, you can call that a limitation of Handbrake. I just love to tune and except for Apple's Compressor, Handbrake is the only application offering that. From MY point of view, other applications have the limitation of not offering tuning functions as in Compressor or Handbrake.

Miklos,

Finally managed to make it back here. Tried to run some additional tests but had problems with HandBrake. Ended up trashing the application files and re-installing.

Simple limitation. Handbrake doesn't ALLOW you to use the correct height when encoding super wide images at 320 I think th ratio is 2.36:1

Have to agree, at least with latest version. Was almost 100% sure I had previously seen/used a 320x136 setting. Have files with settings of 320x128, 136, 138, 144, and 152. All were created from same 2.35:1 source but using different applications and/or versions of the the same application. Unfortunately, I did not document which application created which output.

BECAUSE handbrake is limited in that it's integers for the height and width jump by 16 units on each click and there is no way to fine tune that even down to four units.

Also agree that this was a bit of "overkill" in preserving higher quality re-scales. Would prefer author merely adhered Apple's "rule of four" for unconstrained re-scale option and would have preferred a "calculated" rather than "stepped" approach for constrained re-scaling. (I.e., you enter one dimension and it calculates the other based on current applied crop and/or a stated target aspect ration.) This stepped approach seems even more disturbing when you note that there is actually a built-in 640x272 (2.35:1) but the half size 320x136 setting is skipped using these "saw-toothed" steps.

I hope that explains it otherwise I give up.

Simple proceedure for ripping DVD's on a mac
Use handbrake to rip at max res of 720Xwhatever at a high resolution h264 like 40000kbps for reference.
Use quicktime pro to export your new h264 file to the ipod preset.

Believe this is the long way around to get correct aspect ratio. Prefer to use the HandBrake 320x144 preset here to convert to a file with correct iPod compatible settings and then simply re-scale it to 320x136 in QT using a simple save command. You will note that format, data rate, and new scale is written to the final self-contained file in a fraction of the time it takes to re-convert the file a second time. Posted an example of this approach to my Public DotMac folder (jrwalker4) if you are interested in comparing the results.

Handbrakes automatic "solution" to the height is INCORRECT. It looks wrong and it is wrong mathematically. It should be 135/136 not 128 or 142.

Tend to agree with this also from the standpoint of preserving an "ideal" aspect ratio. Circles are not true circles, squares become rectangles, etc. Don't believe the average person will notice such inconsistency. However, like some individuals with a "perfect" sense of pitch, other individuals with a "perfect" sense of proportion are disturbed by these distortions which are "obvious" to them.

Forgot to mention the following:

Miklos, ran a number tests using single and multi-pass conversions. I too have no problem syncing to iPod using the 2-pass setting and don't understand what is preventing you from doing the same.

Also ran some additional tests on data rate settings. Tried your H.264 video 768kbps and audio 48kHz at 160kbps. Target file ended up with combined data rate of about 930kbps and would not sync. Tried it again using specified audio (44.1kHz at 128kbps) which produced an 898kbps combined rate. Once again it would not sync. Finally reduced video to 600kbps which produced a "syncable" 729kbps target file. While I assume the data rate cutoff may be slightly more than what Apple states as "the official word," am not sure how much headroom they have allowed. (As you may have noticed in the past, Apple does tend to "error on the side of caution" when it comes to specifying specifications.

Feel like I am coming in at the middle of a conversation here. Am a bit confused on what you are trying to say and believe some of what you say just does not make sense.

In my case the source movie's ratio is 720x404 (this is the true ratio of the movie, I got this information out of Compressor.)

Actually 720x404 is the dimensional resolution of the movie as currently displayed. The true aspect ratio is determined by the frame ratio as filmed, cut and distributed (and as stated on the DVD case). Further, you did not state if this was in "square" or "rectangular" pixels (although I feel safe in assuming "square" here).

The dimensions given (720x404) yield an aspect ratio 1.78:1 which would probably indicate a 16:9 movie and not the "widescreen" (2.35:1) mentioned in the original topic unless you made a typo and really meant 720x304 which would then be a 2.35:1 aspect ratio.

Scaling it down to 320 will result in vertical ratio of about 176.

This is only true if the aspect ratio is 16:9 (and in actuality falls exactly at 320x180). A widescreen (2.35:1) aspect ratio movie will be 320x136 pixels. To better see what is going on, set HandBrake for constrained scaling to a width of 640. The algorithm used by HandBrake is, I believe, as exact as can be here -- 4:3, 16:9, and 2.35:1 aspect ratios yield 640x480, 640x360, and 640x272 dimensions respectively. As you can see, simply dividing the width and height by 2 returns the appropriate height for each aspect ratio at a width of 320.

But we need 240. Scaling up 320x240 to the height of 404 (because we don't want to loose vertical information) results in a source rate of about 540x404. Well, now 720 minus 540 is 180. So we need to crop 180 pixels, thus we need to cut 90 pixels of each side. That is the value I put in the horizontal crop values.

This process preserves vertical information at the expense of horizontal information. What you are actually doing is converting one aspect ration to another. (In this case the final product will be a 4:3 aspect 320x240 file. Since much of the action/interest may be contained in the areas you have trimmed, this does not seem to be a viable solution even for the conversion of ratios. (Would be much better to employ a "pan & scan" work flow here.)