Why keep a remux?¶
TL;DR
Keep a verified remux as your preserved disc source. Make smaller or more compatible copies when useful, but create future versions from that source rather than repeatedly re-encoding an already lossy conversion.
Preserve the source, choose the playback copy¶
A remux changes the container without re-encoding the selected streams. Transcoding decodes and re-encodes them; with lossy encoding, the result need not retain all their information. Changing a container alone is therefore different from compressing again.1
A preserved remux and a convenient conversion serve different purposes. One retains the selected disc streams; the other can reduce storage, bandwidth or playback requirements. Keeping both is reasonable. A high-quality conversion may be visually indistinguishable in your viewing conditions, but that does not make it an interchangeable preservation source.
Future formats should start from the preserved source¶
We cannot know which future codec or device ecosystem will best suit a library. The practical editorial recommendation is to keep one stable source and derive each new playback copy from it:
| Approach | What the next conversion starts with |
|---|---|
| Remux → playback copy A; remux → playback copy B | The same preserved disc source each time |
| Remux → lossy copy A → lossy copy B | A source already altered by the first lossy conversion |
A later encoder cannot reliably recover information discarded by an earlier lossy encode. Generational losses need not be obvious in every scene, and their visibility depends on settings and content. Future codec names such as “AV2” or “AV3” are not assumptions this preservation policy needs: it remains useful whichever formats become practical.
Without the preserved source, a new source-based conversion may require reading the disc again. Retaining it saves that work and preserves options. It costs storage and still needs backups and integrity checks; it is not a guarantee of perpetual hardware compatibility.
A disc source is not the studio master¶
UHD Blu-ray video is already a distribution encode. “Original” here means the selected streams from a particular disc edition, not uncompressed camera material or the studio mastering file. A remux usually omits disc menus and may omit extras, alternative cuts, languages or subtitles. Preserve the full disc structure separately if those are part of your archival goal.
Keep an edition record and stream inventory: video profile, BL/EL/RPU where applicable, audio tracks, subtitles, chapters and the extraction tool/version. Verify that the intended data survived; an MKV extension alone proves nothing about completeness. Save a checksum to detect later file changes, while recognising that a checksum by itself cannot prove a correct initial extraction.
Compatibility can mean different changes¶
| Change | Preservation consequence |
|---|---|
| Container-only remux | Can retain selected encoded streams without another lossy encode; metadata and stream selection still need checking |
| Lossy video or audio transcode | Creates a derivative with potentially irreversible information loss |
| Removing FEL or rewriting DV metadata | Can change Dolby Vision reproduction even without re-encoding the base layer |
| Tone-mapping HDR into SDR | Produces a display-oriented derivative; retain the HDR source for future HDR playback |
Conversion is useful when it solves a real playback need. Keep the source so that today's compatibility choice does not become tomorrow's only input.
Playback quality: beyond opening a file · MEL and FEL · Display compatibility
Scope: playback, not disc extraction¶
This guide starts with an existing UHD Blu-ray remux. Disc ripping, drive selection and extraction procedures are outside its scope. MakeMKV's FAQ is an external starting point. A dedicated, current UHD extraction-guide link will be added after review. Keeping the intended video, audio and metadata is still relevant to playback verification.
-
FFmpeg documentation, Streamcopy and Transcoding, sections 3.1–3.2. PRIMARY; checked 6 November 2026. Supports the processing distinction; the preservation workflow above is editorial guidance. See S34 in the source library. ↩