Transcode in 0.10.0.6534 results in 3GB larger file

[ieatsoop]

I've been using Handbrake for several years and couldn't do without it. I'm not a power user, but have been able to figure out settings that worked for my devices. After upgrading to 0.10.0.6534 from, I believe, 0.9.8 in Windows 7, the same movie with similar settings results in a file that's 3GB larger. I re-ran encodes again because a recent transcode of Life of Pi (blu-ray) came out at 9.3GB. I normally see file sizes at between 3-6GB at RF22.

I used the same blu-ray rip of Django Unchained (36GB) for both transcodes below.

In the older version, these are my settings as far as I can recall:
MKV, High Profile, Loose mod.16, Decomb Default, x.264 same as source, RF22. First audio track mixed down to Dolby PL II with 6db gain at 160 bitrate, secondary audio using the hi-res track with auto-passthru. 1 subtitle track. File output was approximately 4.4GB when done last September.

In 0.10.0.6534, these are my settings:
MKV, High Profile, Loose mod.16, Filters Off, x.264 same as source, RF22. x264 Preset: Med, Tune: Film, Profile/Level: High/4.1. First audio track mixed down to Dolby PL II with 4db gain at 160 bitrate, secondary audio using the hi-res track with auto-passthru, 1 subtitle track. File output was about 7.35GB. Here's the activity log: Django Activity Log

I tried several other encodes with slightly different settings for Life of Pi such as x264 Preset at Slower and Profile/Level at Auto with very little difference in file size, 9.1 - 9.3GB.

I have not found any threads in the forum or on the web regarding the cause for this change. Are there any settings that I may have used that caused the big bump in file size? RF22 or 21 works very well on a 60 inch plasma, so I'd like to keep this setting at the minimum. If this is just the way it is with 0.10.0.x, then I'm going to have to get used to it. However, I'd like to know if it's my screw up that's causing the much larger file sizes.

Thanks in advance for your input.

[mduell]

Would need the 0.9.x activity log to tell you what you changed. No crystal balls here.

[ieatsoop]

I can no longer find them on my PC, probably overwritten by the newer logs. Is there anything in the 0.10.0. logs that would explain the larger file sizes based on settings? I've tried to provide the previous and current settings in the hope they might be of some use. I have not tinkered with the more advanced settings in either versions, just the basics. Without any references to older versions, are the larger file sizes expected in 0.10.0.x? Or can they be tweaked further for more manageable files in the 3-6GB range? Thanks.

[mduell]

Code: Select all

[12:40:04] mux: track 0, 237911 frames, 3818092530 bytes, 3078.22 kbps, fifo 1024
[12:40:04] mux: track 1, 465073 frames, 198431262 bytes, 159.98 kbps, fifo 2048
[12:40:04] mux: track 2, 930147 frames, 3451034768 bytes, 2782.29 kbps, fifo 4096
[12:40:04] mux: track 3, 4209 frames, 50511619 bytes, 40.72 kbps, fifo 32

Well you've got 3.4GB of audio in that 2nd audio track. Your 0.9.x may have been so old it wasn't passing through DTS-HD. Or you picked a container that didn't support DTS-HD. Or any of 18 other things we can speculate about since you can't produce the logs and we can't trust users to accurately report their settings.

[ieatsoop]

mduell, thanks for pointing out the size of the 2nd track. I didn't realize it would be that large. And maybe the older version did not pass the HD track through as you mentioned. I've always used MKV as the container so that's a constant. I'll dig up the logs from backups when I have time. I can check for the size of the 2nd track, now that I have an idea of what to look for. Sometimes speculation can point you in the right direction, so I appreciate that you've taken the time to look at my logs.

[mduell]

Wait, your encode log here has a 7.5GB (or 7.0 GiB) output. Where's the 9+GB encode you're talking about?

[ieatsoop]

9+GB was for Life of Pi, not for Django Unchained.

[mduell]

Are you trying to be as confusing as possible?

[ieatsoop]

With all due respect, I noted in my post that Life of Pi resulted in larger files than I was used to:

- I re-ran encodes again because a recent transcode of Life of Pi (blu-ray) came out at 9.3GB. I normally see file sizes at between 3-6GB at RF22.

- I tried several other encodes with slightly different settings for Life of Pi such as x264 Preset at Slower and Profile/Level at Auto with very little difference in file size, 9.1 - 9.3GB.
***

If this caused confusion, then my apologies. LIfe of Pi was a new encode using a new version of Handbrake (0.10.0.6534) that resulted in a large file. Since I had no baseline to work with, I needed something I already transcoded before to compare the results of an older vs a newer version of HB. I had done Django Unchained several months ago and still had the rip. So I used the rip with 0.10.0.6534 and it did result in a larger file than the one done months ago using an older version. Since I was able to confirm that the newer version of HB created larger files than I am used to getting, I wanted to get an opinion from more experienced folks on the forum.

The included reference to Life of Pi above was to illustrate that I had tried different settings that did not result in a significant change in file size.

[mduell]

You don't have the old encode log anyway, so why not... augh, nevermind. This is why people without logs don't get help.

[ieatsoop]

Actually, several posts above, I thanked you for helping me out with deciphering the logs on the new encode. That's already more than I expected without the old logs. If I had known this would happen, I would have kept copies of the old logs. Unfortunately, HB had already overwritten them. So please accept my thanks.

[mduell]

Unfortunately, HB had already overwritten them.

Handbrake does not overwrite old logs.

[Smithcraft]

The exciting part about using CRF is that you are encoding for a quality level and not a file size. Some files will come out larger, and some will come out smaller. It's the nature of the beast.

SC