BitrateCraft · Presets and operations · bitratecraft.org

Disclaimer: Independent technical documentation and configuration guide. Not affiliated with The HandBrake Team. No software downloads hosted

Presets, Profiles and Custom Settings

A preset in HandBrake is a named bundle of encoder settings, filter choices, audio and subtitle rules and output options that can be applied to a title in one action. The distinction that matters operationally is between a preset, which is a recipe the program applies, and an exported settings block, which is a portable description of that recipe. Understanding both is what allows a configuration built on one machine to be reproduced predictably on another.

How preset families are organised

Built-in entries are grouped by intent rather than by codec, and the grouping reflects the hardware and delivery target each entry was written for. The general family covers everyday archival and viewing copies. The web and device families target screens with a narrow decoding budget. The container-specific family fixes output format along with the encoder. The hardware family routes encoding to a graphics accelerator instead of the processor. Each entry specifies not only video settings but also the audio layout, the subtitle behaviour and the container, which is why two presets that look similar in the video panel can produce quite different files.

Several entries deliberately leave the width, height and frame-rate fields unset. A preset written that way follows the source dimensions, so the same entry can handle a standard-definition title and a high-definition one without editing. That is the single most useful property a shared preset can have, and it is the one most often destroyed by an operator who saves a preset immediately after a title has imposed its own numbers on the panel.

Saving a custom preset

A custom preset is created from the current panel state, which means the state has to be worth keeping before the save is issued. The order below avoids the common mistake of capturing a value that belonged to one title.

1. Load a close built-in entry as the base so that unset fields stay unset.
2. Change only the properties that genuinely should differ, leaving dimension and frame-rate fields blank where they were blank.
3. Check the audio rows and the subtitle rules, since they are part of the preset whether or not they were touched.
4. Save under a descriptive name and, where the interface allows, into a folder that states the purpose rather than the date.
5. Re-apply the saved preset to a second title and confirm that the panels changed as expected.

Presets are stored in the user profile rather than inside the program, so an update rarely disturbs them. They can be reordered and renamed afterwards; renaming a preset does not alter the settings it carries. Deleting one is immediate and is not recoverable through the interface, which is another argument for exporting anything that took effort to assemble.

Exporting and importing settings

Exported settings travel as plain text, which makes them diff-friendly and reviewable. Two exchange paths exist: copying the block for the selected preset, and writing or reading a file that contains a complete list. Both carry the same content, so the choice is one of convenience rather than of capability.

• Copying a single block suits a quick hand-off between two operators working on the same title class.
• Writing a full list avoids re-issuing several hundred separate settings calls and keeps a team aligned on one revision.
• Reading a list merges its entries alongside existing ones, so imports are additive and a duplicate name becomes an ambiguity the operator has to resolve.
• Malformed text is rejected as a whole rather than partially applied, which keeps the preset list consistent after a bad paste.

Reviewing an export before sharing it is worth the minute it takes. The block states encoder family, quality target, filter chain, audio and subtitle rules and container, so a scan of the text reveals whether a hardware encoder or an unusual rate has been captured by accident.

Portability and version drift

Portability is limited by what a preset can assume about the machine that reads it. Three assumptions fail most often. An encoder named in the preset may not be present in the reading build, particularly where a hardware family depends on a specific driver. A filter chain may reference behaviour that changed between releases, which alters the result without an error. And a preset saved with explicit dimensions carries those dimensions everywhere, so a carefully tuned entry becomes useless on material of another shape.

The practical answer is to keep one revision of the preset list alongside the job set, name a folder per encoder family, and re-verify a single short title after any program update before a large batch is queued. Distributing presets together with the reference notes for the same family keeps the reasoning attached to the settings, which matters far more than the settings alone once a configuration leaves the machine where it was written.

Questions that come up

Related reading: the batch and automation guide extends a single preset into a repeatable job set, and the transcoding glossary defines the encoder and container terms used above.