How to Use Handbrake to Rip DVDs (Mac Only)


Handbrake is one of the most popular Mac freeware titles that are downloaded at MacUpdate and Version Tracker. You can download a free copy of Handbrake at the site hosted by m0k. 

Handbrake is used to rip DVDs. It’s different from another popular DVD-rip software, MacTheRipper, because Handbrake also performs compression. The current version, as of August 5, is 0.7.1. It’s in Universal Binary.

  • This VTC version: 1.0.1
  • Video length: 4 minutes 58 seconds
  • Video format: QuickTime
  • Video compression: H.264
  • Video resolution: 720 x 540 pixels
  • Audio commentary: Not available
  • Audio: None
  • This VTC is only available to members.
  • Correction: AAC is not part of MPEG-2 but MPEG-4. A correction has been made accordingly in the latest version of this VTC.

  • Mac video tutorials   Mac video tutorials

    Please read Terms of Use for Guests before watching any of the video tutorials.

    This entry was posted in Video tutorials (VTCs). Bookmark the permalink.

    3 Responses to How to Use Handbrake to Rip DVDs (Mac Only)

    1. zahadum says:

      (A) Be aware that handbrake has severe limitations about subs & dubs – they have a near religious contempt for the user’s data integrity: they will discard or mangle important parts of the content from your dvd!

      1) handbrake only supports 2 channels of audio: so you will be forced to throw away the director/writer’s commentary or the actors’ commentary, or the soundtrack, or the multi-channel surround-sound, or the foreign language subs (or the english dubs for an international film, as the case may be), etc etc etc.

      2) handbrake treats subs even worse than dubs!! …

      … you can only save one language! (which is a DEATH BLOW to second-language learners, especially from asia, who rely upon subs to toggle between the first & second languages) …

      and even worse, the subs for this (single) language are BURNED directly into the video track! (which scales HORRIBLY on very large (tv) and very small screens (ipod) alike, making the subs almost illegible) …

      … even more unforgivably, handbrake is completely incapable of supporting CC (closed caption) instead of generic subs, which would be the easist way to get legible glyphs on the screen (strangely, another opensource project – VLC – does not have this ridiculous limitation)…

      … unfathomably, the handbrake refuse to offer their users a GRACEFUL way to handle raster subs – namely, the option to save them out as a separate file that can be overlayed (or not) over the main title video track (this multi-track approach has the virtue of offering a small but uselful improvement to legibility when the playback screen size is scale3e).

      … moreover, the handbrake devs insist that they will make no effort to incorporate any OCR function for automatic conversion of the subs into proper text (that would -by definition- have no legibiliy problems at all at any playbook resolution!). Indeed, the devs claim — without any evidence of surveying the handbarke user community — that existing OCR libaries have such high error rates that users would too frustrated with the –supposed– low quality …

      [For the record, i can report to you that D-Subtitler (which is one of the few apps for the mac) has almost no problem converting raster subs that are typo-graphically well formed. Unfortunately, many so-called ‘professional’ subtitling service bureaux do a HORRENDOUSLY stupid job of laying out the text! … eg, idiotic use of italics generates all sorts of false ligatures that confuse simple OCR tools like D-Subitler.]

      (B) In terms of performance, PPC/G4 consumers (as distinct from pros on G5’s) will need to plan on a time-budget of 1 day per dvd title 🙁 because handbrake will execute at 3 fps (2-pass) … however, if you have the latest x86 hardware, you will experience real-time 1:1 at 30fps throughput 🙂

      unfortunately for the millions of PPC/G4 owners, you will get no joy from cheap usb ($100) hardware-based accelerators (such as the elgato Turbo) that can also offer real-time conversion performance – on legacy hardware! – for applications which are based on Quicktime, which handbrake is (mercifully) not! …

      … The handbrake devs CATEGORICALLY dismiss any possibility of working on a driver for these kinds of transcoding acclerators: they regard the video quality of the output from the h264 hardware as unacceptable.

      (fyi: while the handbrake devs do not offer any emperical banchmarks for this –or any other — of their emphatic laws of the universe, you do need to appreciate the inherent limitations of these transcoder acclerators: the h264 video processor (vpu) that is oem’ed by elgato & miglia is actually a merchant chip originally designed to balance the compromises required in real-time on a mobile phone/camera; it is unclear from the chip vendors web site whether or not this VPU has its brains hard-wired to perform only one quality profile, or whether this VPU has been (properly_) designed to have the flexibility to the quality algorithms be parametrically controlled by firmware/software).

      … however, the handbrake devs do hold out the slim possibility of VPU acceleration if and only if they are automagically supplied a driver by the (other) opensource project that supplies the handbrake project with its h264 library (alas, these devs on the h264 dont seem to be respond to inquires by email).

      however, even if the h264 crew (or the VLC crew, who alos dont repsond to emails) were to eventually offer support for these usb VPU’s, by the time the drivers moved upstream into a public release of handbrake (it can take handbrake a year for a major change to propagate from design spec to RC code), so much time might have passed by that the millions of PPC/G4 owners would have long since upgraded to intel macs, making the point moot.

      so PPC/G4 owners should basically anticipate that handbrake will turn their (formerly multi-thousand dollar machine) into a glorified — albeit glacially slow — vpu.

      of course, if PPC/G4 users of handbrake relax their archival-level quality constraints, then a legacy machine will offer much better turn-around times …

      … eg: a PPC/G4 can also deliver real-time 1:1 (30 fps) transcoding performance if you:

      a) select a simpler codec – eg generic mpeg4, rather than h264 that tricked out for high-complexity.

      b) select smaller resolution – 320×240 rather than 480p; note that the qvga will be acceptable watching full-screen at close quarters, but will never be suitable for watching at a distance up-sampled on a big-sceen HD tv)

      c) select a single-pass – this option alone cuts your total re-compression time in half! … however, the cost of this extra speed is the loss if picture detail for intricate or fast-moving scenes, because handbrake doesnt get a chance to go through the file twice, armed ahead of time with non-local knowledge of scene construction; running handbrake only a single-pass means that the transcoder has to guess, instead of know for sure, how the content scene is going to develop … this lack of forecasting information in a single-pass transcoding means that handbrake must always compromise when making decisions about how much data it can safely discard).


      All in all, new-comers to handbrake should understand a couple of basic points:

      1) the devs regard the handbrake project as a private club not a open community: they make their philosophy abundantly clear in their FAQ (where they have the gall to invoke the design precepts of unix as a their guiding philosophy); and they publically threaten _several_ posters on their messageboards for persisting in lines of questioning which they consider off-limits!

      the handbrake devs are very clear that the only features that they will ever consider adding to handbrake are the ones that command the interest or usefullness of founders of the project.

      if you want a new feature in handbrake, then be prepared ahead of time to be disappointed (or to code it yourself).

      2) the devs of handbrake believe that the users of the project have an an obligation to understand the details of a feature before they burden the devs with any questions on the messageboard!

      tha handbrake messageboard explicitly threatens any questor with banishment of they do not follow a strict regime of prepartion before asking for help or making suggestions:

      a) first, read through all the user guides
      b) then read through all the FAQ
      c) then search all threads on teh message boards for previous coverage

      at some point, one will not be surprised if the handbrake devs demand that users also familiarize themselves with the all the extant bug reports (and why not demand fluency with the VCS system for the source code too!)

      In short, handbrake is good at what it does & is not good at what it does NOT do.

      If you can live with that limitation — near complete contempt for the integrity of your data, as well as nearly insufferable arrogance towards its user community — then handbrake is the correct choice for you.

      [Corrections made by Administrator upon request from the post author]

    2. Emmanuel Gomez says:

      Disclosure: I have no connection with the Handbrake developers (or community), except as a user of the Handbrake application. In other words, I have not posted to (or read) any of the Handbrake related message boards, and cannot speak to the attitude of the developers or any other community members.

      That said, I cannot let this whiny attack stand without rebuttal.

      First and foremost, I have to point out that Handbrake is open source software, developed and made available for your free and unrestricted use, without making any demands of you, and in fact, providing important freedoms not available with any commercial software.

      In other words, to quote the poster above: “if you want a new feature in handbrake, then be prepared ahead of time to be disappointed (or to code it yourself).” This is as it should be. The tone of this remark is astounding to me: at what point did anyone become entitled to make demands of the Handbrake developers’ donated time? Does this poster sign the Handbrake devs’ paychecks? I think it’s fair to say that no one should expect a positive response to a blunt demand for functionality in any open source software.

      Appalling sense of entitlement aside, on to the factual issues:
      Handbrake has had a release since the above post (0.9.3), which resolves much of the described limitations on ripped audio tracks. The current release of Handbrake will encode up to 4 independent audio tracks into the output file, if the container format supports it. (Hint: mkv and mp4 are far more capable container formats than avi).

      Each of the audio output streams (up to 4) are independently configurable, allowing, for instance, the pass-thru of the original language audio track (raw AC3 pass-thru is supported, not sure about DTS), and an AAC compressed version of up to three alternate language audio tracks. So Handbrake handles dubs pretty well, and I suspect that most users will find it sufficient (and *useable*).

      Regarding the comments about Handbrake’s subtitle handling, I have no rebuttal. Unfortunately, the subtitle limitations are as described, and thus, fairly severe. I advise users to employ a separate program for subtitle extraction. On the Mac, D-Subtitler is a decent choice.

      In short, Handbrake a fantastically useful (and useable) piece of software. If you want feature changes or additions to any open source software (including Handbrake), don’t whine about it; roll up your sleeves and get to coding, or put up some money as a bounty to encourage capable programmers to address your needs. Free software is, first and foremost, offered as-is. Just because you can download an application (and it’s source code!) for free does not entitle you to *anything*, especially not to any expectation that the developers do your bidding.

    3. Honza says:

      I have spent a LOT of time reading their forums, and as a programmer and an electronics engineer I have plenty of interest in video encoding AND the devices which are the target of the Handbrake product (which I have quite a thorough knowledge with some of them), so I can state for a fact that a lot of the devs seem to ONLY know how to code, they do not have the social skills to act like normal people in society (even on the net), they are constantly rude to people asking perfectly normal (most of the time) questions, and they quite often make statements that are totally unfounded at best and completely untrue at worst, especially when it comes to the technical issues of the devices they are targeting. The worst thing you can do as a new poster to their forum is actually question their previously stated facts. I have seen threads locked for some weak excuse because somebody mentioned the devs were being unhelpful, or aggressive, or obstructing a dialog on a particular problem (and they were). I constantly see aggressive egotistical better-than-thou behavior on their part towards their users.

      On the other hand, I know plenty of people who give most of their time for free, and they manage to talk to people normally without condescension, so what is the Handbrake developers excuse? Free application? Not in my book. The only expectation that you have with free stuff, is that you’re still treated like a human being by the giver…

    Leave a Reply

    Your email address will not be published.

    Notify me of followup comments via e-mail. You can also subscribe without commenting.