BitrateCraft · Audio and text tracks · bitratecraft.org
Subtitles, Closed Captions and Chapters
Text tracks in HandBrake occupy their own panels because they travel through the file differently from video and audio. A subtitle can be copied, converted, rendered permanently into the picture, or discarded, and each of those choices changes what the container has to store. The same applies to chapter markers, which are metadata rather than a stream and therefore depend entirely on the container writing them out.
Track types and where they come from
Subtitle material arrives in two broad forms. Text formats such as SubRip, Advanced SubStation Alpha and WebVTT store characters together with timing, language and sometimes styling. Bitmap formats store compressed images of the rendered text, which is why they cannot be converted to a text track and keep their appearance. A title scanned from a physical source can also carry a caption channel inside the video program itself, which the interface exposes separately from the subtitle tracks.
When a title is opened, the subtitle panel lists every track the scan found, plus any external file the operator has imported. Each row chooses one action: pass the track through when the container accepts the format, convert it when a compatible text representation exists, burn it into the picture, or leave it out of the output entirely.
Importing external text files
External subtitle files are attached to a title rather than to the program as a whole, so they are re-selected whenever the source changes. The working sequence is short.
- Place the external file beside the source using the same base name, or select it explicitly from the panel.
- Confirm the character encoding. A file saved as UTF-8 imports cleanly; older single-byte encodings can produce mangled accents.
- Assign the correct language tag so that players can choose the track by language.
- Decide per track whether the result should be a soft track or rendered into the picture.
Styling is the main casualty of conversion. Complex scripts with positioned text and custom fonts lose that information when they are translated into the simpler representations that common containers support, and the result inherits the player's default font instead. If the appearance is part of the deliverable, keeping the original format is the only way to preserve it.

Burn-in versus soft tracks
Burn-in renders the text into the video frames, which guarantees that the text appears on every player and cannot be switched off. The costs are real: the picture is re-encoded whether or not the video settings remained unchanged, the text is destroyed by any later crop or scale, and the frames get noisier around letter edges, which consumes a little more rate. Soft tracks stay separate from the picture and can be switched, restyled or removed, but they require the player to support the container and the specific text representation used.
| Form | Stored as | Typical use | Limits |
|---|---|---|---|
| Soft text track | Discrete stream or box | Everyday distribution with player choice | Player support and styling limits |
| Soft bitmap track | Discrete stream | Material that must keep its original look | Cannot be converted to text; limited container support |
| Rendered into picture | Part of the video frames | Screens and devices with no track handling | Irreversible; forces a video encode; not selectable |
Mixed strategies are common: a soft compatibility track for general use plus one rendered track for the handful of cues that must always appear. That combination near-doubles the bit cost of the affected cues but removes the class of complaint where a viewer reports missing text.
Closed caption handling
Caption channels embedded in a video program are detected during the scan and reported separately from subtitle tracks. They are carried in the line data of the video signal rather than as a stream of their own, so they become available for output only when the source format actually carries them. Selecting the caption channel produces a text track in the output that can then be treated like any other soft track for language tagging and ordering.
Two consequences follow. First, a caption channel that exists in one title of a batch may be absent in the next, so automation that assumes its presence will produce inconsistent outputs. Second, because the caption data is timed to the original broadcast clock, trimming the video with a range selection shifts every cue if the range excludes the start of the program; the caption stream does not re-synchronise itself. Rendered or soft, the results should be spot-checked at the first and last cue rather than only in the middle.
Forced tracks
A forced track marks the individual cues that must be shown even when the viewer has subtitles switched off, which is the normal treatment for foreign-language dialogue inside an otherwise domestic program. Two mechanisms exist. A flag on existing cues marks them inside the same track, and a forced-only selection builds an output track containing just those cues. The second is safer in practice because players that ignore the flag still show the whole track when it is enabled.
Support is uneven. Matroska stores the forced flag in a way that current players honour; the simpler text representation used inside MP4 carries the flag less reliably, and viewers may see either the entire track or none of it. Where the requirement is contractual rather than cosmetic, rendering the cues into the picture is the only fully dependable route, at the cost of losing all viewer control.

Chapter markers and naming
Chapter markers are positions with labels, not streams. They are taken from the source scan: a mounted physical title contributes its own marker set, and files contribute whatever their container stores. When the scan finds no markers, the panel stays empty and the output simply has none. Markers cannot be invented from nothing, so a title that needs an index has to acquire one from its source.
Naming is editable per marker. Default labels follow the position number, which is rarely useful in a viewer, so descriptive names are applied before the job is queued. Because the pager in a player usually shows the label, the naming step is the only chance to make the index readable. Removing a marker is possible; adding one between two existing positions is not.
Container behaviour differs. Matroska stores a chapter list with its own time base, and MP4 stores markers in a table with fixed offsets, which means a large frame-rate change in the video filter chain can move markers by a frame or two. Chapter granularity also affects the file: a marker is cheap, but hundreds of them make scrubbing in a viewer slightly less precise because each chapter boundary starts a new decoding reference point in some players.
Questions that come up
Why does the subtitle panel report a track with no language?
The source did not carry a language tag for that stream. Assign one manually before encoding, otherwise the output depends on the viewer guessing correctly at playback.
Can styling be preserved when moving to a different container?
Only up to the limits of the target representation. Positioned text, fonts and karaoke effects need a format the container can carry; otherwise the cues are simplified. Comparing the two available representations is covered in the container and muxing reference.
Do trimmed ranges break caption sync?
A range that starts partway through a program removes the earlier cue timing, so text can appear late or not at all. Encode the full title when captions matter and trim with a player afterwards.
Related reading: the filter and scaling guide explains why a rendered track forces a video encode, and the transcoding glossary lists the track and container terms used above.