Handbrake an Error Occurred While Extracting the Archive Please Try Again Later

So Handbrake 0.10 has been out for a while now (and 0.nine.ix for even longer), and if you've looked through my previous multi-folio guide that explained all the advanced settings in 0.nine.half dozen, I've got some practiced news:

Getting something that amounts to the "all-time settings" is a whole lot easier in v0.nine.9 and v0.10.

(yay!)

The "x264 presets" are at present in Handbrake, and 99% of the fourth dimension, that should mean that you don't have to dabble in the "x264 Advanced Options Panel". Though if you want/need to for any reason, the former rundown of Handbrake settings (0.9.6) guide should help explain all those options for you in great detail (note that in v0.10 you lot may demand to enable the x264 advanced options panel in the Handbrake settings/preferences located in the drop-down menu).

Note that since v0.10 is very like to v0.9.9, I've but updated this guide with v0.ten-specific additions in orangish (like this!) .

I'll use some images this time around to help make things quick & easy. We'll offset at the more than complicated part, and work backwards.

Just first…

-Encodes fast
-Loftier quality
-Smallest file size possible

Pick two.

The decisions you lot make during these sections will largely depend on which 2 you lot choose.

Anyway, allow'south start at the highlighted area below.

Constant Quality (RF) vs Average Bitrate (kbps)

1. These accept the largest impact on quality & file size. Move the Constant Quality RF slider far enough to the correct (or utilise a high plenty Boilerplate Bitrate) and the video will be large, and look indistinguishable from your source. Moving the slider to the extreme left (or using a low enough Average Bitrate), and you can get really small file sizes, but something looking pretty ugly. Most people aim for something in between.
2. Generally speaking, one isn't going to get you a "nicer" video than the other.
3. I'm really going to be simplifying the remainder beneath (information technology won't exist 100% technically accurate, only authentic enough to give you lot an agreement).

Kickoff, a quick epitome to give you an idea every bit to what Constant Quality entails…. (click for a larger epitome)

Abiding Quality – Commonly this is the preferred method. This targets a sure level of quality throughout your video(s). The reward to Constant Quality is that your videos all tend to look consistent. The downside is that you don't know how big each video volition exist until the end.

RF – Sliding to the right (lower numbers) lead to better quality. Sliding to the left (college numbers) result in lower quality, simply lower filesizes as well. If y'all've never used Constant Quality before, normally RF:20 is considered as a starting point for DVD encodes (and RF:22 for BluRay). Nearly people experiment to find an RF value that looks good plenty to them at a file size they tin can handle, and use that RF value most of the fourth dimension, deviating slightly when need exist.

RF examples – Here are a couple screenshots taken at dissimilar RF settings (one at 20, and i at xxx) to give you a very rough starting bespeak (click for a larger view):

For a more in-depth wait at RF values, cheque out Comparing x264 "RF" settings in Handbrake (examples) for the full write-up.

And an image to give you lot an idea equally to what Boilerplate Bitrate entails… (click for a larger prototype)

Average Bitrate – Using this and a calculator, you can aim for a specific file size given a certain video length. Helpful if you wanted each of your movies to be exactly 700MB for case. Advantage to Boilerplate Bitrate is that you tin can finer pre-determine your file size. The downside is that after you cease encoding, you might detect out that the filesize yous chose wasn't loftier enough, and your video looks like junk. Or maybe the file size was college than it needed to be. 2 pass encoding when using this selection used to exist strongly recommended, but information technology'southward more often than not not thought to exist as of import anymore unless you lot demand a precise file size ("turbo" first pass is okay if you lot don't heed losing a little precision in size).

kbps – The higher this is, the larger the file will be (and thus, the college the quality). Online bitrate calculators are the easiest fashion to practice this.

Looking at Constant Quality vs Average Bitrate from another perspective…:

Allow's pretend we're encoding a one hour Television serial from DVD with constant quality and accept determined that RF:22 looks only-good-enough to united states. Here's how it might plough out:

• Episode 1: RF22 – 278MB (avg video bitrate of 686kbps)
• Episode 2: RF22 – 349MB (avg video bitrate of 915kbps)
• Episode three: RF22 – 363MB (avg video bitrate of 948kbps)
• Episode iv: RF22 – 304MB (avg video bitrate of 792kbps)
• TOTAL SIZE: 1294MB

All episodes should look consequent. Clearly, Episodes 1 & 4 didn't demand as much bitrate as the others, so they ended up being smaller.

Now what if we'd tried using an "boilerplate bitrate" instead, targeting exactly 323.5MB per episode?

• Episode 1: 798kbps (avg video bitrate) – 323.5MB
• Episode 2: 798kbps (avg video bitrate) – 323.5MB
• Episode 3: 798kbps (avg video bitrate) – 323.5MB
• Episode 4: 798kbps (avg video bitrate) – 323.5MB
• Full SIZE: 1294MB

The TOTAL SIZE is the same. The problem is that this time, Episode 1 got more than bitrate than it needed. Episodes ii & 3 probably didn't get enough. Episode 4 got close to the ideal amount for our "RF:22 looked good to us" standards and probably looks identical to the RF:22 version from before. Either way, we're now in a situation where Episode 1 looks stellar, but in Episodes ii & three, things are below our standards, looking notably worse.

That doesn't mean that average bitrate is *bad*. It's just not consistent when information technology comes to visual quality – it's simply consistent when it comes to file size. And then if you use average bitrate, you may have to "pad" your numbers a bit just in instance some of your videos need the extra bitrate to look okay. If I were encoding the rest of the season via "average bitrate", I'd probably be encoding everything at 1000kbps to exist on the safe side. Unfortunately, that means my full filesize for 4 more episodes similar to the above would now be 1622MB instead of just 1294MB. And at that point, I'd have been better off using Constant Quality with a better RF value.

Brusque version: Unless you desperately need your file to come out at an verbal size, use Constant Quality. Play with RF values until you find values where the video looks proficient enough to you on the devices yous play back from, at file sizes yous find acceptable.

—

x264 Preset

As mentioned above, this has a different effect depending on whether you went with Constant Quality, or Average Bitrate.

If yous went with Abiding Quality, your quality has already been "decided". Changing this won't substantially bear on the quality whatever further (if you wanted higher quality, motility the RF slider more to the correct). Using the seven slowest settings will find ways to fit that quality into a lower file size. Using the 2 fastest settings will result in a larger file size. Either way, it should look about the same. Note that the 3rd setting (very fast) behaves very oddly with Constant Quality and I advise yous avert using information technology. If you want more detail most the RF value and CQ, I've got a divide writeup to assistance clarify all of that (with charts) at Handbrake RF + slower speeds = craziness.

If y'all went with Average Bitrate, your file size has already been "decided". Changing this won't affect the file size whatsoever farther. Going with slower settings here will effort to pack more quality into that file size you've chosen. Going with faster settings here will result in less quality.

Details: This is where the time tradeoff comes into play. The veryslow preset is about the most hard-core anyone should typically become, and it tin can take a long time even on a quick car. This is ane of those areas where you'll have to experiment on your auto and find something reasonable.

Keep in listen that there are diminishing returns as you get slower. Compared to "veryslow", the "placebo" setting takes forever and a twenty-four hours. At the very least, it'll commonly add a few hours, if not days, depending on your source and computer. Even worse, you might non even notice the visual divergence (it'due south chosen "placebo" for a reason). On the other hand, the divergence betwixt "ultrafast" and "medium" (skipping superfast, veryfast, faster, and fast) might only be a few minutes and will often requite a quite noticeable deviation.

Finally, when on the quest for quality, keep in mind that days of encode fourth dimension is no substitute for simply choosing a ameliorate Constant Quality or higher Boilerplate Bitrate. Wearisome settings will let you get more blindside-for-your-buck, simply it's not going to work miracles. Certain, a 350MB Television show encoded at actually slow settings will look improve than the same 350MB Tv set show encoded at fast settings. Merely a 600MB encode of the aforementioned Tv set testify will trounce both of them fifty-fifty if information technology was done at really fast settings.

—

x264 Tune

In general, these focus on shifting "bits" between detailed & flat areas, depending on the setting. To be honest, you lot don't have to actually empathise what they do – other people have done the grunt work figuring them out, then they're whittled down to pretty simple "one size fits all" settings.

None – This is like the "onetime" Handbrake presets. Zero inherently wrong with it. It's something of a centre-route setting.

Film – For Telly/Movies/Pic and 3D blitheness (Pixar movies for instance)

Blitheness – For 2D animation (Mikey Mouse, Simpsons, etc)

Grain – For very grainy movies/shows. For example, movies like 300 or Saving Individual Ryan (the embankment scene). Note that this tries to KEEP the grain, which uses a boatload of bitrate, and tends to issue in higher file sizes when using Constant Quality (if you're using Avg Bitrate, brand sure y'all're using a loftier bitrate, or overall quality will suffer.).

Stillimage – For all the same images (slideshow/pictures).

PSNR/SSIM –  Generally for testing/comparative purposes. These stand for "elevation signal to noise ratio" and "structural similarity". x264 has some enhancements that improve the image every bit y'all would see it (robbing "particular" from places you wouldn't notice it anyway, and putting that particular where you would notice it). These settings disable those, so that the prototype is more "technically" correct so that a computer can compare the video with the source to see how accurate/identical information technology is.

Zerolatency – Meant for fast encoding with quick streaming.

Short version: Picture show, Animation, and Grain are what you probably desire to employ virtually of the fourth dimension (perhaps "None" also). The others are for pretty edge cases that most people don't take to worry near.

Fast Decode (checkbox)

Normally y'all do *non* want this checked. A few exceptions:

• Check it if you're trying to play your videos on an older estimator that struggles to decode H264.
• Bank check it if playing videos on an older device that struggles to decode H264.
• You lot could optionally cheque information technology if uploading to YouTube or other video-sharing sites. Information technology may make it quicker for the site to decode it and put your video upward. Information technology's usually non necessary.

It disables a few H264/x264 optimizations, making it easier to play just at the expense of a larger file (or lower quality if using an average bitrate). Since nigh recent computers/devices accept built-in hardware support for these optimizations, you usually don't demand to bother with it. If yous notice that playback on your favorite device is choppy, effort checking this though.

—

H.264 Profile & H.264 Level

This is where things can go a little tricky. College profiles & levels tend to become you improve compression (so better quality in a given filesize). Even so, yous're going to be limited by the contour support of the hardware devices yous're planning to play your videos on. Here'due south the guild of things:

Baseline -> Primary -> Loftier
one.0 -> 1b -> 1.1 -> one.2 -> ……. -> five.1 -> v.ii (this one's easy enough to figure out)

Currently, Loftier Profile, Level 4.1 is the nigh popular contour on recent / cutting edge devices. Such a device volition also play Baseline/Chief, and whatever level betwixt 1.0-iv.0. The industry'south stagnated at Level four.ane for a couple years, probably because it's at the point where it'southward "adept enough" until H265 starts taking over.

Here are a few examples of contour back up for pop devices:

iPhone 3, iPhone 3GS: Baseline Contour, Level iii.0
iPhone iv, iPad 1, AppleTV ii: Main Profile, Level three.ane
AppleTV three: High Profile, Level 4.0 (may really support 4.i)
iPhone 4S, iPhone 5, iPad ii, iPad 3, iPad Mini: High Profile, Level 4.1

Blackberry seven & seven.1 devices:  Loftier Profile, Level 3.i (they recommend using Baseline Profile though)
Blackberry 10, Blackberry Playbook: High Contour, Level iv.2

WD Television receiver Play & TV Live: High Profile, Level 4.ane

BluRay devices (those which will read from a USB hard drive for instance) should normally support High/Level four.1, but are ofttimes somewhat picky and have a tendency to complain nigh being "too complex". I haven't actually bothered to try determining the exact crusade, but if you run into this event, you can try inbound bluray-compat=1 in the "Boosted Options" window (note that your file size may increase somewhat). If that doesn't work, endeavour Main profile or a lower level.

Samsung & Nokia don't list profiles on their spec sheets for phones/tablets. Probably safe to assume at to the lowest degree Level four.0 on their devices that record in 1080p.

Roku, Boxee Box, Netgear NeoTV don't list profiles on their spec sheets for media streamers. Probably safe to assume at least Level 3.1 for 720p devices and Level 4.1 for 1080p.

…y'all'll have to practise your ain excavation for devices from other manufacturers.

Short version here is that for devices which are a couple generations old, Main Profile, Level 3.0 is commonly supported.

Almost every current-generation device supports High Profile, Level four.1.

Thus, y'all probably don't want to exceed Level 4.1. If you go whatsoever higher, your video probably won't play, or volition play-with-glitches on whatever electric current smartphones, tablets, etc. Note that some slower computers which lack hardware playback back up may also struggle to smoothly play back videos encoded at very loftier levels.

—

Enough with the complicated/difficult stuff. At present the easier bits.

—

Format – MP4 file vs MKV file

This is known equally a "container". Doesn't touch the quality, so don't stress besides much over this 1.

MP4 file – This is what you usually want to utilise. It has the highest histrion & device compatibility. Windows Media Player won't play MKV past default. Quicktime, iPhones/iPads/AppleTV/etc don't play MKV files either. MP4 is the prophylactic bet and works perfectly fine.

MKV file – This is a more flexible, only less supported container. Technically, you tin jam multiple video streams in it, add together DVD menus, use a wider variety of codecs, and a whole whack of other things (none of that through Handbrake, mind you). The two notable exceptions when information technology comes to Handbrake are that it will let you to employ the Theora (VP3) video codec, and FLAC or Vorbis audio codecs. In v0.ten information technology will also allow you to use Googles VP8 codec.

Short version: Unless you have a specific reason to utilize MKV, use MP4. Notation that "Canadian Man" left a comment indicating that some Samsung TVs have audio sync bug when playing MP4 files over USB – if you run into like issues you may want to encode using the MKV container instead.

—

Video Codec – H.264 (x264) vs MPEG-four vs MPEG-ii (vs H.265/x265/HEVC vs VP8 in v0.10)

H.264 – This is probably the *reason* you lot're using Handbrake to begin with. It's the newest codec offered, results in high quality at low file sizes, and is supported past virtually every contempo device out there.

MPEG-four – An older codec, and very few reasons to use it. To give you an thought, old devices/players that won't play anything newer than DivX will usually do well with MPEG-4. If you have a really old (or really cheap) phone that has very basic video playback adequacy, information technology might work on those besides. And if you're hoping to edit your video later in a five-year onetime editing program that lacks H264 support, this gives you an option to do and so.

MPEG-2 – Unless you have a specific reason for using this (across time travel to the late xc'south), don't.

Theora – Only available when using the MKV container, it's positioned somewhere between MPEG-4 and H.264 in terms of specifications. Not very popular in the mainstream – Linux users and the open source community in general tend to be nearly familiar with information technology. Those who utilize it normally have specific reasons for doing then – if y'all've never heard of information technology, it's probably not what you're looking for.

H.265 – New for Handbrake v0.10, this allows you to encode your video using the new H.265/x265 encoder. As you might guess, H.265 (likewise known equally HEVC) is the successor to H.264. Don't go encoding all your videos in x265 just however though! Here are a few reasons why you might want to wait a while earlier making the switch from x264 to x265 (as of early-mid 2015):

• x265 encodes take a very long time. I did a number of tests with a 46 minute Telly show from BluRay (1440×1080) with the veryslow preset. Using x264, the times were each around 2 hours (+/- 30 mins). Encoding the same episode using x265, times ranged from 21-34 hours.
• x264 is very mature with many years of development behind it. x265 on the other hand is very immature and withal has a lot of room for improvement. Depending on what you encode, an x264 encode could very well come out looking better (and beingness smaller in file size) than an x265 encode. Eventually, x265 should blow away any x264 encode, but nosotros're not quite there withal… these things have time.
• Nearly no device support yet. VLC v2.ii+ is about the merely mainstream player so far on desktop/mobile. Aught built-in yet from iDevices (technically FaceTime tin use H.265 on the iPhone 6, but no playback support nevertheless). Android but added API support in "Lollipop", only I oasis't come up across devices with hardware back up. 4K BluRay players aren't expected until the end of 2015. Intel/nVidia just started adding hardware decode support to contempo devices near the terminate of 2014 and early 2015. Basically, things are pretty early in terms of support.

Update: As of January 2018, x265 is considerably more mature. The latest version of iOS (11) and macOS (High Sierra) support HEVC. The latest version of Windows ten supports hardware decode of HEVC on supported hardware. For those using software players, all the common open source players (VLC, MPC, etc) have had actually solid support for a practiced long while now.

The biggest downsides currently are as follows:

• Encode fourth dimension. x265 still takes significantly longer than x264.
• Playback on devices without hardware decode. Decoding in software uses a good bit of CPU ability and sucks down bombardment life much faster.

…while yous tin can make a good case for using x265/HEVC nowadays, before y'all go encoding your entire collection, I strongly suggest doing a few tests first to ensure you don't come across problems playing back the video on your devices.

VP8 – New for Handbrake v0.ten, this won't show up unless you select the MKV container. If you lot've never heard of it, I tend to remember of VP8 as "Google's version of H.264". It tends to exist inferior to x264, except in mayhap a few very specific circumstances. Information technology'due south intended to be patent-free (and hopes were once that it would become part of a standard for spider web video), though in that location'south a huge mess surrounding all of that which you tin can search around for and read upward on if you're interested (both the patent side and the web browser side). As for encode time: a video that took 2.5 hours for me to encode in x264 took a little over 6 hours using VP8. If anyone actually uses VP8 on a regular basis, I'd be very interested in hearing almost what you use it for and why in the comments.

VP9 – The successor to VP8. It does have hardware decode on Intel and AMD'south latest chips as of 2018 (Skylake+ and Raven Ridge), is the preferred codec for Google Chrome and Mozilla Firefox, and is predominantly used by YouTube. Netflix uses it on supported devices (many Android phones). Information technology'south successor will be AV1 which is currently in development.

Short version: x264 for broadest compatibility and encode speed reasons. x265 if pushing for smallest possible file sizes and time/compatibility aren't issues for you. VP9 if interacting with a lot of open source stuff or trying to avert H264 and HEVC license fees.

—

Framerate (FPS), and Variable vs Constant framerate

Same as source – You lot almost always want to use this instead of manually picking a frame rate. Handbrake is smart and will about always get this right. If yous detelecine or deinterlace, it will also practise the smart affair hither too and change the frame rate to exist accurate. Manually setting the frame rate to something incorrect will frequently result in the video looking choppy/stuttery. Manually reducing the frame rate generally won't reduce the file size by as much as you'd expect either. At that place are very few edge cases where manually setting information technology makes sense – normally it doesn't.

Variable Framerate – Platonic near of the time (especially if de-telecining). If the "true" frame rate bounces effectually (or does after de-telecining), this will continue things looking as good & stutter-free every bit the original (and perhaps keep from encoding extra wasted frames). And if the "true" frame rate doesn't bounciness around, you'll end up with a constant frame rate anyhow.

Constant Framerate – I'd only go with this if I needed a specific frame rate & had manually set information technology.

Short version: "Same as Source" and "Variable" unless you have a solid reason for forcing something else.

—

On to the "Motion picture Settings" window.

(accessed via a button towards the upper right)

SIZE – Anamorphic – Unless you're doing some manual resizing, you're usually best to use "Strict". I can't think of a lot of reasons to use "Loose" unless you're resizing the video resolution (loose makes it adequately like shooting fish in a barrel). "Custom" is across the telescopic of this write-upwards, just allows you to exercise a bit of manipulation, including changing the aspect ratio if you have a desire to smush/stretch things. Don't use "None" unless yous know what you're doing.

SIZE – Cropping – Use Automated. That way, it won't waste material space trying to relieve any black bars (your device will add blackness bars if necessary). On the other hand, if you want black bars manually saved as function of the video stream, experience costless to set information technology to "none" and change the values to all 0's.

Hitting the "Preview" button is ordinarily a skilful idea if you're trying to tweak hither.

If you want more detail on the anamorphic and cropping settings, I put together a video that thoroughly goes over each of the options. It's long, simply there'south a "table of contents" on the right side and then feel free to skip around to the function(s) yous're interested in: https://www.youtube.com/watch?v=IDJH5p15tNU

Next, if you click the "Filters" push button…

FILTERS – Detelecine – Setting to "Default" is a skilful idea. If your source is telecined, information technology'll detelecine automatically. If it'due south not, it won't. Set up-and-forget.

FILTERS – Decomb – Setting to "Default" is a good idea here too. If your source is interlaced, it'll automatically deinterlace it. If not, it won't. Just similar the higher up. Set-and-forget.

You normally don't want to employ "Deinterlace" unless decomb is giving you lot bug or you take one of those oddball situations where you want to manually prepare it for some other reason.

FILTERS – Denoise – Usually, go on this off. A couple exceptions:

• Turn information technology on if you lot accept noise/grain in your source you lot desire to get rid of.
• Plough it on if you desire to reduce your filesize slightly (or better overall quality) at the expense of softening your image some.
• Turn information technology on and apply a CUSTOM value if you're trying to become rid of "dancing dots".

UPDATE: I put together a new denoise write-up with video and images if you're interested in de-noise settings.

FILTERS – Deblock – Off. It'due south supposed to get rid of blockiness but in my experience it ends up blurring everything a crazy amount that makes the video hard to sentinel. On the plus side, it pretty much destroys racket/grain in the process.

—

For Audio Settings, Subtitles, and Advanced Settings, zero's really changed so rather than re-write it all, I suggest reading the quondam writeup for version 0.9.vi if y'all demand further details on those options.

—

That about sums it up. Equally a quick note, I've actually generalized a fair bit – especially when it comes to the Abiding Quality vs Boilerplate Bitrate part. But hopefully this has given yous enough of an agreement that you lot're comfy using the new system.

mossandii1949.blogspot.com

Source: https://mattgadient.com/a-best-settings-guide-for-handbrake-0-9-9/

Share this post