ClipReady vs HandBrake

HandBrake is excellent, free, and the answer to a very large number of video problems. It describes itself as a video transcoder, which is exactly what it is, and if what you need is a transcoder you should use it and stop reading here.

The reason people arrive at this comparison is that they searched for “HandBrake without re-encoding” and found that the option does not exist. It does not exist because it cannot: re-encoding is the entire mechanism. This page is about the jobs where that mechanism is the wrong tool.

The one difference everything else follows from

HandBrake decodes every frame of your video and encodes it again. ClipReady copies the encoded video across without decoding it.

Everything below is a consequence of that.

When HandBrake is the right tool

Be honest about this, because most of the time it is:

• You need a smaller file. Compression is the job. ClipReady cannot do it and does not try, because there is no encoder on its default path.
• Your source is a format Apple’s stack cannot carry at all, VC-1 or AV1. Somebody has to re-encode, and HandBrake is very good at it.
• You want a device preset. Apple TV, iPhone, a target bitrate. That is HandBrake’s home ground.
• The picture needs to change: deinterlacing, cropping, scaling, denoising, burning in subtitles.

When re-encoding is the wrong answer

• The file is already the right codec and Final Cut just will not take it. A Blu-ray remux is usually H.264 or HEVC, formats Final Cut has always supported. The picture was never the problem; the container and the timestamps were. Re-encoding it is destroying something to fix something else.
• Final Cut reads the wrong frame rate. That is MKV’s millisecond clock, not your video. HandBrake fixes it incidentally, by laying down fresh timestamps during the encode, and charges you the whole picture to do it.
• The audio is silent and the video is fine. Only the audio track needs to change. Re-encoding the video too is collateral damage.
• Provenance matters. If you are archiving, or citing footage, “the video was never decoded and rebuilt” is a claim you can make about a remux and cannot make about a transcode.

What about ffmpeg -c copy?

Fair question, and it is closer to the right answer than HandBrake for these jobs. It copies the video without re-encoding, exactly as it should.

What it does not do is fix what is broken. A straight stream copy carries MKV’s quantized timestamps into the new file, so Final Cut still reports 23.81 fps. It writes multichannel audio without a named channel layout, so dialogue can arrive in the wrong speaker. It cannot decode DTS-HD or TrueHD to something Apple plays. And it will happily produce a file with none of those problems visible until you are in the timeline.

There is a fourth, and it is the one nothing else in the category appears to have noticed: an unpatched muxer writes open-GOP recovery points into the file as though a decoder could start cold on them, and Final Cut takes it at its word. The result is one scrambled frame at the same timecode every time.

ClipReady does the same copy, then repairs those four things specifically, and shows you what it is going to do to every track before it starts.

The honest summary

If you need the file to be smaller or different, use HandBrake. It is a better encoder than anything ClipReady will ever contain, because ClipReady contains none.

If the file is already fine and the wrapper, the clock, or the audio format is what is standing between you and your timeline, re-encoding is an expensive way to solve a problem you do not have.

Related

• ClipReady — the app this page describes
• Why Final Cut says your 23.976 file is 23.81 fps
• No sound from your MKV in Final Cut or QuickTime