|ソースコード (0.9.4jp-r2-src)||2010-01-05 19:22|
|Mac OS X版HandBrake日本語版（Intel） (0.9.3-jp-b1（Intel版）)||2009-03-03 01:57|
|Mac OS X版HandBrake日本語版（PPC） (0.9.3-jp-b1（PPC版）)||2009-03-03 01:47|
|VLC media player（Mac OS X版） (1.0.5（PowerPC/32bit）)||2010-02-01 11:55|
|Windows版HandBrake日本語版 (0.9.4-jp-r2)||2010-01-05 17:58|
|Windows版HandBrake日本語版（コマンドライン版） (0.9.4（コマンドライン版）)||2010-01-05 17:57|
|英語版 (英語版HandBrake 0.9.5 Windowsコマンドライン版)||2011-01-04 18:14|
HandBrakeはオープンソースで開発されている、マルチプラットフォーム/マルチスレッド対応のビデオフォーマット変換ツールです。GPLで提供されており、Mac OS XやLinux、Windowsで動作します。
We are honored by your desire to help, but unlike some other open-source projects, we are neither willing nor able to accept material donations of any kind. Too many complications can arise from acceptance of such offers, and we’d rather stand on our own unindebted to others and in good stead than for something unexpected to arise and risk bad blood with our users.
MediaFork was the open-source community-contributed fork of HandBrake, titer’s original DVD conversion application. It has since merged with HandBrake and the name MediaFork should be considered deprecated.
Here's the deal with getting stuck at 100%...
It isn't stuck. (Usually)
It's usually still working on the conversion. Those comfortable in Terminal can use "top -o cpu" to see that HandBrake is probably the top item, and still using a large portion of your processor(s) speed.
Canceling the conversion at this point is virtually guaranteed to result in a broken file. (It's possible to get lucky, but if you've spent hours converting so far, why risk throwing it all away?)
Give it time, and it will almost always finish.
Many people have reported various voodoo actions to prevent this from happening. Waving a dead chicken about is probably just as good, and really now?couldn't you put that chicken to better use, by making a yummy sandwich?
From my own experience, tempered by what I've been seeing reported here in the forums, all I can say is that the pause is usually associated with particular discs, and that lower-end machines are more likely to be delayed at the end like this. (My PowerBook G4 1Ghz with 1GB of memory was delayed often, but my PowerMac dual 2Ghz with 2GB of memory rarely is.)
There have been times when I've returned to my faster machine and found it paused at the end of a conversion, and "top -o cpu" didn't list HandBrake at the top. In this case, all I needed to do was access the drive the converted movie was being saved to, and the process completed. This has happened maybe twice out of hundreds of conversions.
The only magic bullet here is time. Patience will be rewarded.
The most costly bullet is to get a better machine/more memory... But that's not a guaranteed solution - it just worked for me.
So generally, HandBrake really isn't "stuck", it just isn't displaying the last step(s) it needs to finish before the conversion is complete.
First off, you should know that HandBrake is not a DVD ripper. There are many of those out there. For Mac, the best option is Fairmount paired with DVD2OneX. For Windows, it's AnyDVD. HandBrake's about video conversion, not stripping copy protection. For best results, you should feed HandBrake unprotected video.
The first thing to check is frame speed, which will usually only be a problem if you change it from "Same as Source." Did you use 23.976? How does it look at 29.97? Or, if you're already at 29.97, try 23.976. More details can be found in the Framerate Guide.
Another possibility is B-Frames. If you're using the AVI container, make sure you don't have any enabled as part of your advanced x264 options. HandBrake cannot write AVI files that take advantage of B-Frames.
If it looks jerky muxed in an MKV container, try MP4. If it's jerky in one video player, see if it's also jerky in others.
--Sorry, HandBrake no longer supports Mac OS X versions older than 10.5.
Using 6-channel AAC sound in your movies? Upgrade to the latest version of iTunes.
Enable MP4 files larger than 4GB, also known as 64-bit MP4 files.
Okay listen. 100% quality? You're going to end up with a video that's way larger than the source. It's sorta misleading, but we haven't figured out a better way of presenting it. Here's the deal: 100% quality isn't "the same thing as the DVD" or anything like that. For x264, it means lossless mode. Sounds good, huh? Not exactly. DVDs already use lossy compression. x264 can't eat compressed video. It needs raw, decoded video, which takes up a lot of space. In comparison to that, 100% quality, lossless x264 takes up little space. But in comparison to the lossy compressed source on the DVD, it will still be quite chunky -- and it won't look any better than the source, either. Only use it if you know what you're doing.
As far as video encoding goes? There is no best. In general? 5 tons of flax!
This doesn't happen anymore, since with HandBrake 0.9.0. To fix older video, you can use a cryptic utility from Apple called Dumpster. Download Dumpster and open the video in it. You should see three listings for "trak". The first is the video, and the second is the main audio track, with the third and any other remaining traks being secondary audio tracks. Expand the third listing you see of "trak", then expand "tkhd" which is the track's header. At this point, a bunch of boxes--fields--should appear. Find the field labeled "flags" and replace its contents with 0. Hit tab (you have to do this for Dumpster to register changes). If you have any other audio tracks to disable, just repeat the process. Finally, save. Only the main audio will play now in QuickTime. If you want to listen to secondary tracks, there's no need to return to Dumpster, though if you want to, you can re-enable the tracks by changing the "flag" field to 2. Inside QuickTime Pro, you can you look at a movie's properties (Apple-J on the keyboard) and enable or disable tracks on a temporary basis before you play the video.
After updating to a new version of the HandBrake Macintosh GUI, you will need to go to the Presets Menu in the menu bar and select "Update Built In Presets". This will update your version of HandBrake with all of the newest built in presets while leaving all of your custom presets intact.
Well, if you're using the latest version of HandBrake, this shouldn't happen. But if you have older video...
Quick fix: install Perian or use VLC.
You can edit the videos in QuickTime Pro's Video Properties.
Or, you can download Dumpster. Open up the offending file, and drill down like so: moov -> trak -> trakhd. Among a bunch of other fields, you should see a 3*3 grid of boxes labeled "matrix." Make sure they read like so:
1.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 1.0Hit return after editing each cell. Then, save, and quit Dumpster.
Try using Open Source (Title Specific ...).
It is a variation on how the MacGui normally opens a source. Normally when you choose a source in the open source window, the MacGui does a full scan of the entire source, including all titles and chapters, etc. Now this is very convenient as the interface can load up all info from the dvd and allow you to select what you want right in the main window. However, with the advent of advanced copy protection including dummy cells, zero cells, and intentional "fringe" dvd mastering (to the point where some dvd's barely play on set top players) a full source scan can cause the HandBrake MacGui to crash or otherwise fall on its face.
In these instances, it may help to use Open Source (Title Specific) where the MacGui acts more like the cli in that you can specify just the exact title you want to open, avoiding much of the cruft that can come with a full source scan.
Here's how to use it (you will need to know the title number you wish to open, you can find this a number of ways like using dvdplayer and noting the title number of the main feature):
1. Go to File -> Open Source (Title Specific) ...
2. You will now be presented with the exact same Open Source window you are used to seeing. Choose your source as you normally would.
3. Now you will be asked which title number you want to scan. Enter the title number that you got from running dvdplayer.app or the like.
4. Click the "Open Title" button.
HandBrake will now just scan that title, hopefully bypassing some of the cruft in your source.
We strongly recommend against doing this.
MPEG-2 is a lossy source (meaning that visual data has been removed in order to compress the video). MPEG-4 (and H.264), the video codecs used by HandBrake, are also lossy. Since you will be using iMovie to render your content with yet another lossy codec, this represents a third generation of loss, which will make your final product look rather poor.
Instead, we recommend use of another tool (MPEG Streamclip is one solution) to convert your DVD to a less-lossy intermediate format called DV, which will import into iMovie but result in far less generational loss (thus improving the quality of the final output). There are no plans to introduce DV output in HandBrake.
Currently, Perian and VLC can both decode AC3 in MP4. However, neither is currently able to pass through that AC3 audio undecoded to a surround receiver. The best you can get is realtime downmixed Dolby Pro Logic II. Blame Apple.
Each episode is a separate title and has to be encoded separately. Select each title you want, then add it to the queue. Make sure you give each one a different file name, otherwise they will write over each other.
Not with HandBrake, no. You could just encode the video at a low resolution with a fast low quality encoder like ffmpeg, then extract the audio track.
Or you could use OSEx.
Code contributions are welcome from anyone, though only registered developers can check in code changes. Registration is quite simple, please see [#http://handbrake.fr/?page_id=9 the Dev page] for more details.
In short, you need quite a bit of experience with C coding and debugging on a Unix-like platform - right now, that means either Mac OS X or Linux. In addition, familiarity with jam and make and the open-source libraries used by HandBrake (see the contrib directory for details) would be very helpful, but that experience can be gained by working on HandBrake, of course.
Please note that no svn checkin access will be granted until you have demonstrated that you have created either significant bugfixes or feature enhancements for HandBrake from the latest copy of the code from our subversion repository. If you have concerns about the best way to go about this, please ask on the development forum. Details can be found on [#http://handbrake.fr/?page_id=9 the development page].
In general, any sorts of changes to either stabilize or add functionality to the existing API are welcomed. Please try to avoid changes that will modify existing API functionality, since many front-ends rely on function names and parameters in libhb to be static.
If you’re not familiar/comfortable with Subversion, before checking anything in (or, worse, committing a new revision), please take the time to review the Subversion Basic Work Cycle so you understand the basics of how Subversion functions, how to keep yourself updated with what others have checked in and avoid collisions, etc.
Please DO NOT distribute binaries of any release to the public, since we would prefer to ensure that each public binary release builds cleanly on all target platforms, passes fundamental regression tests, hasn’t made API changes that will break third-party GUIs, etc. Neither end-users nor developers want to deal with the inevitable support headaches that bugs and unsupported functionality in uncontrolled binary builds straight out of svn can cause.
"What happened to 0.8.5 and 0.8.0 finals?"
While part of it is that some major bugs were fixed (allowing us to remove the beta label), the main reason was all the new features! Many of these were arbitrarily scheduled on the Trac Roadmap for version 0.9.0 or even 1.0, but people got to them way sooner.
For example, active queuing and logging in the MacGui were originally supposed to be in 0.9.0. Better deinterlacing, .vob/.ts input, Matroska support, and a PSP preset were scheduled for even later! After moving enough tickets forward, it just seemed silly not to call it what it was.
Those paying attention at home might have noticed that the release prior to 0.9.0 was called 0.8.5b1 and the one before that was 0.8.0b1. No "b2"s or "finals" at all. This is, of course, an incredibly screwed up way to name software versions.
We don't have the willpower for feature freezes. We're like small children following shiny, bouncing, bright-colored balls.
Now we're going to try regular, incremental releases. May god have mercy on our souls. Consider them all to be somewhat unstable, unless someday HandBrake hits 1.0 (unlikely).
This incremental pattern held for 0.9.1 and 0.9.2 releases.
0.9.3 took longer to gestate than a human being and had enough changes and improvements to qualify as a 1.0 or at least a 0.9.9, but we decided to stick with the numbering scheme regardless.
The next release will be 0.9.4, with an as-yet-undecided feature set that will include live preview video encodes. The Trac Roadmap has been updated accordingly.
You need to build and install yasm for x264 to use cpu acceleration.
HandBrake requires a lot of control over the specific versions of 3rd party libraries it utilizes. For example, HandBrake requires a very up to date copy of libmp4v2 for MP4 muxing that no packaging system currently distributes. To make sure everything is to its specifications, it downloads and builds most of its dependencies and statically links them, all without touching your system libraries.
The one exception is libdvdcss. Because HandBrake does not contain any DVD decryption code, on Linux boxes it can dynamically bind to a system's copy of libdvdcss for that purpose.
Handbrake will run on vista however it requires to be run in administrator mode. To do this:
This started out as rhester's original words from the main website, and a collection of forum posts for various issues users are experiencing. Thanks go out to their authors. Baggss, Nonsanity, golias, sr55. If we missed anyone give us a shout.