datum blog

What actually happens when you press 'copy'

Mon, 01 Jun 2026 00:00:00 GMT

You drag a folder onto a drive. A progress bar fills up. The OS tells you the copy is complete. You eject, label, and ship.

That workflow is fine for moving vacation photos. It is not fine for moving camera originals that cannot be recreated. The difference is not about the files themselves. It is about what "complete" means.

A robust copy pipeline has five phases. Each one exists because a specific, documented failure mode demanded it. When you understand what each phase does and what breaks without it, you stop trusting progress bars and start trusting evidence.

Interactive figure: Five-phase copy pipeline: enumerate, hash, write, verify, and manifest.

Phase 1: Enumerate

Before a single byte moves, the pipeline walks the source and builds a manifest of every file and directory it intends to copy. File paths, sizes, timestamps, permissions. The full tree, recorded before anything changes.

This sounds trivial. It is not.

The failure it prevents: partial copies that look complete. If you start copying files as you discover them, you have no way to know when you are done. A camera card with 400 clips and a nested folder structure can be partially traversed if the card is pulled early, if a directory is locked by another process, or if a filesystem error makes a subdirectory invisible. Without a complete enumeration up front, you cannot compare what you copied against what existed. You land with 398 files, the copy tool reports success, and two clips are silently missing.

Enumeration also catches problems before the slow part starts. A destination with insufficient free space, a source with unreadable directories, filename conflicts on the target volume. All of these are cheaper to discover before you start moving terabytes.

The output of this phase is a source manifest: a list of everything that should exist on the other side when the job is done.

Phase 2: Hash

With the source manifest in hand, the pipeline reads every source file and computes a cryptographic hash. xxHash, SHA-256, MD5, or all three depending on the requirements. The hash is a fingerprint of the file's exact contents. Change one bit and the hash changes completely.

The failure it prevents: copying corruption faithfully. If you only hash after copying, you can prove the destination matches what you sent. But you cannot prove the source was healthy when you read it. Camera firmware bugs, failing flash controllers, and degrading media all produce files that are internally corrupt but still readable. A source hash taken before the copy gives you a reference point. If the source file is already damaged, you have evidence of when the damage existed. Without it, you discover the corruption downstream and have no way to determine whether it happened during the copy or was present on the card.

Source hashing is also the foundation of deduplication. On multi-day shoots, the same LUT files, sidecar XMLs, and camera metadata appear on every card. Hashing the source lets the pipeline recognise duplicates without byte-comparing files across volumes.

This phase is the slowest part of the pipeline for large jobs because it requires a full sequential read of every source byte. It is also the most valuable. The source hash is the single most important piece of evidence in the entire chain.

Phase 3: Write

Now the bytes move. The pipeline reads each source file and writes it to the destination. This is the phase that your operating system's copy dialog shows you. It is also the phase that most people confuse with the entire process.

The failure it prevents: nothing, on its own. The write phase by itself only guarantees that your software asked the operating system to place bytes on the destination. It does not guarantee those bytes arrived correctly. It does not guarantee every file was included. It does not guarantee the destination is readable.

This is not a criticism. Moving data is necessary. But the write phase is just transportation. Treating it as the whole pipeline is like treating the flight as the whole logistics chain: you still need to verify the cargo manifest at the other end.

Modern pipelines optimise the write phase aggressively. Parallel writes to multiple destinations from a single source read. Adaptive buffer sizing based on drive throughput. Write ordering that keeps the source drive's read head sequential even when multiple destinations have different performance characteristics. All of this matters for speed. None of it matters for correctness without the phases on either side.

One detail that trips people up: operating systems use write caches. When your OS reports that a file write is complete, it often means the bytes have been accepted into a memory buffer, not that they have been committed to the physical media. Ejecting a drive immediately after a copy finishes can interrupt the cache flush. The OS said "done" while bytes were still in flight. This is not a theoretical risk. It is one of the most common causes of data loss on set.

Phase 4: Verify

The pipeline reads every file back from the destination and hashes it. Then it compares the destination hash against the source hash from Phase 2. A match means the bytes on the destination are identical to the bytes that were on the source at the time of hashing. A mismatch means something changed during transit.

The failure it prevents: silent write errors. Hard drives, SSDs, USB controllers, Thunderbolt cables, bus adapters, and RAID controllers can all introduce errors during writes. These errors are rare per-byte, but when you are writing hundreds of gigabytes, "rare per-byte" becomes "routine per-job." A single bit flip in a compressed video frame can destroy the frame or cause a decoder crash. A single bit flip in a metadata header can make an entire file unreadable.

Verification catches all of these. It is the only phase that proves the destination is healthy. Not "probably fine," not "no errors were reported." Actually, independently verified.

There is a subtle distinction here that matters. Some tools hash during the write: they compute a checksum from the bytes as they flow through memory on their way to the destination. This is better than nothing. But it proves what your software sent, not what the drive received. A true verification requires an independent read-back from the physical media. The drive has to seek back to the beginning, read the file again, and produce a hash that matches. That second read is the evidence.

The cost is time. Verification roughly doubles the total duration of a copy job because it requires reading the entire dataset from the destination. On a tight schedule, this is the phase people are tempted to skip. It is also the phase whose absence causes the most damage.

Phase 5: Manifest

With source hashes, destination hashes, and verification results in hand, the pipeline writes a manifest. This is a structured record of what was copied, when, from where, to where, and whether each file passed verification. Formats vary. ASC MHL is the film industry standard. Some pipelines write CSV logs, XML reports, or database entries.

The failure it prevents: unverifiable claims. Without a manifest, you are asking people to trust your word that the copy was verified. Three months from now, when a file is missing or a frame is corrupt, nobody will remember whether this particular drive was verified at copy time. The manifest is the receipt. It is timestamped, it contains the hashes, and it can be independently checked against the files on the drive.

Manifests also enable the concept of a chain of custody. When a drive ships from set to a post facility, the facility can verify the manifest against the files they received. If everything matches, they know the drive was not altered in transit. If something mismatches, they know exactly which files are suspect. Without a manifest, the only option is to call the DIT and ask "did you check everything?" That is not a workflow. That is hoping.

A good manifest also records what was not copied. Files that were skipped, directories that failed enumeration, and hashes that did not match on the first attempt. This negative evidence is just as important as the positive. Knowing that a job completed with zero errors is different from not knowing whether there were errors.

Why your OS skips three of these

When you drag a folder in Finder or Explorer, here is what actually runs: enumerate (partially, as it discovers files), write. That is it. No source hash. No read-back verification. No manifest.

The OS copies files correctly almost all of the time. For documents, downloads, and application data, that is fine. The failure rate is low enough that it does not justify the time cost of hashing and verifying every file.

Camera originals are different. They cannot be re-created. They represent days of work by dozens of people. And they are large enough that "rare per-byte" errors become statistically likely over the course of a job. The risk profile is completely different, and it demands a process that matches.

The cost of skipping

Each phase has a time cost. Enumeration is fast, usually seconds. Source hashing is slow, proportional to the data volume. Writing is slow, limited by the slowest drive in the chain. Verification is slow, another full read pass. Manifest generation is fast, usually seconds.

A full five-phase pipeline takes roughly twice as long as a simple copy. On a 2TB card, that might mean 40 minutes instead of 20. That feels expensive in the moment, sitting in a truck at midnight waiting for a progress bar.

But the alternative is not "20 minutes and it works." The alternative is "20 minutes and you hope it works." The next time someone discovers it did not work, the cost is a reshoot, a missed delivery, or footage that simply no longer exists.

The five phases exist because people learned this the hard way. Every phase was added in response to a real loss. Enumeration was added after partial copies were shipped as complete. Source hashing was added after corrupt originals were faithfully duplicated to three drives. DITs writing bash scripts at 3am discovered every one of these failure modes the hard way. Verification was added after silent write errors destroyed footage that tested fine at the source. Manifests were added after facilities received drives with no evidence and no recourse.

"Copy complete" is not a statement about your data. It is a statement about one phase of a five-phase process. The question is not whether the copy finished. The question is whether you have evidence that it worked.

What DIT bash scripts got right (and where they broke)

Mon, 18 May 2026 00:00:00 GMT

In 2006, the RED ONE started shipping with CF card media. No ingest software existed for it. The camera assistant handed the card to someone with a MacBook Pro and no job title, and the footage needed to get onto a drive, then a second drive, with proof that all copies were identical. If any copy was wrong, the day's shoot was unrecoverable.

The solution was Terminal.

rsync and a prayer

rsync was the default, not because it was the best option, but because it shipped with macOS and handled recursive copies with checksums. The command was simple enough to memorise:

rsync -avP --checksum /Volumes/RED_CARD/ /Volumes/RAID_A/DAY_01/

That was the entire ingest pipeline. One line.

Verification was manual. Run md5sum or shasum against both source and destination, diff the output in a second Terminal window. If the hashes matched, label the drive, case it, move to the next card.

This was the complete data management workflow on a significant number of productions through the late 2000s. It was slow and manual, but it was correct.

Then the scripts got longer

Scripts grew incrementally. The same five commands ran for every card, so they went into a .sh file. Then a timestamp in the log. Then a free space check before copy. Then audio notifications on completion and failure.

#!/bin/bash
# offload.sh — v11 (don't ask about v4 through v8)

SRC="$1"
DST="$2"
LOG="$DST/copy_log_$(date +%Y%m%d_%H%M%S).txt"

echo "=== OFFLOAD START ===" >> "$LOG"
echo "Source: $SRC" >> "$LOG"
echo "Destination: $DST" >> "$LOG"
echo "Started: $(date)" >> "$LOG"

df -h "$DST" >> "$LOG"

rsync -avP --checksum "$SRC/" "$DST/" 2>&1 | tee -a "$LOG"

echo "=== VERIFICATION ===" >> "$LOG"
cd "$SRC" && find . -type f -exec md5 {} \; | sort > /tmp/src_hashes.txt
cd "$DST" && find . -type f -exec md5 {} \; | sort > /tmp/dst_hashes.txt

diff /tmp/src_hashes.txt /tmp/dst_hashes.txt >> "$LOG" 2>&1

if [ $? -eq 0 ]; then
    echo "VERIFIED — all checksums match" >> "$LOG"
    afplay /System/Library/Sounds/Glass.aiff
else
    echo "*** MISMATCH DETECTED ***" >> "$LOG"
    afplay /System/Library/Sounds/Sosumi.aiff
    afplay /System/Library/Sounds/Sosumi.aiff
    afplay /System/Library/Sounds/Sosumi.aiff
fi

echo "Finished: $(date)" >> "$LOG"

The triple error sound is a real pattern from production scripts. It exists because a single Glass.aiff is easy to sleep through, and a silent copy failure means lost time. Repeated alerts solved a real failure mode: the operator not noticing.

What the scripts knew

Collected together, DIT bash scripts from 2006 to 2012 form an accidental specification for on-set data management.

Every script had the same structure. Copy the files. Hash the copies. Compare the hashes. Log everything. Report the result. Independent practitioners converged on the five-phase copy pipeline without coordinating. Some scripts added RAID health checks, free space calculations, automatic folder structures keyed to camera roll numbers, or email alerts over hotel WiFi. The core was always the same five operations.

The convergence is the interesting part. No spec existed. The requirements emerged from the work: take data off a temporary medium, put it somewhere safer, prove the copy is correct.

Why some DITs never stopped

Some experienced DITs still use scripts despite knowing every graphical tool on the market. They have evaluated them, tested them, recommended them to others. Then they go back to their own scripts.

The reason is auditability.

A self-written script has no ambiguity about what it does. It runs rsync with --checksum, not a faster mode that skips verification. It hashes source and destination independently rather than trusting a copy tool's exit code. The log format is explicit because the operator chose every field. The failure modes are known because the operator wrote the error handling (or didn't, and learned from the result).

A graphical tool is a black box. When a producer asks "are you sure that copy is good?" the answer "the app showed a green checkmark" means trusting someone else's definition of "good." "Checksum verified" is not a yes-or-no question. It matters how the hash was computed and when. "I hashed source and destination independently with SHA-256 and diffed the output, here's the log" is a different class of answer.

This is not about preference. It is about the difference between observable and opaque verification.

What the scripts couldn't do

The scripts had hard limits, and those limits tracked production scale.

A single bash script handles four cards from one camera. It does not handle eight cameras shooting to two card slots each, dual-system audio on a Sound Devices recorder, and six more cards arriving from second unit. That scenario requires parallel copies with backpressure, queue management, priority ordering, progress tracking across multiple destinations, and handoff of verified media to editorial before the last card finishes copying.

All of that can be built in bash. People have. The result is a few thousand lines of shell that only the author understands, that breaks when a macOS update moves the path to md5, and that has no error handling for failure modes that haven't occurred yet.

The specific failure modes:

No concurrency model. Bash scripts run sequentially. Parallelising with background jobs and wait creates race conditions in log output and error handling.
No state persistence. If the script crashes mid-copy, there is no record of which files completed. The entire offload restarts from scratch.
Platform fragility. md5 vs md5sum, BSD find vs GNU find, Homebrew path changes across macOS versions. Scripts written on one machine often fail on another.
Single operator dependency. The script works for the person who wrote it. A replacement DIT on day two of a shoot cannot debug someone else's bash.

Dedicated tools earned their place here. Not by doing something scripts couldn't do in principle, but by handling concurrency, state recovery, and cross-platform consistency at a level that single-author shell scripts cannot sustain.

The implicit spec

DIT scripts contain an implicit product specification. Every line traces to a concrete incident or requirement.

No product manager spec'd triple-Sosumi error alerts. No UX researcher determined that the copy log should include a df -h disk space snapshot at the start. No feature request asked for copy resumption after a power failure killed the truck's inverter. These features exist because a specific production incident made them necessary.

The useful measure for any copy tool is whether it works under production conditions: hour fourteen, six drives, the AD asking when media will be ready for editorial. Bash scripts met this test by construction. No splash screen, no onboarding flow, no update notification, no analytics ping. Instant launch, single function, clear result.

The scripts remain the clearest specification for what data management software needs to do. Not what it could do. What it needs to do.

Why your Premiere conform is broken (and where the frames go)

Tue, 28 Apr 2026 00:00:00 GMT

You send the XML. The colourist imports it into Resolve. They call you twenty minutes later. "Your timeline is 50fps." You check the sequence settings. 1080p25, progressive, no fields. You exported correctly. You did everything right. And the conform is still broken.

This is one of the most persistent problems in professional post-production. Premiere Pro's FCP7 XML export contains bugs that have been documented by colourists, conform artists, and finishing editors for over a decade. Some are fixed. Most are not. All of them cost hours.

This post maps the specific failures, explains the mechanics behind each one, and describes the workarounds that working professionals actually use. If you have ever had a conform fall apart after leaving Premiere, you will recognise some of these.

The landscape of a Premiere conform

The conform is the moment where editorial decisions meet original camera media. The editor works with proxies or transcoded dailies. When the cut is locked, the timeline description travels to the colourist or finishing house, where it is matched against the high-resolution source files. The format that carries this description is usually one of three things: an EDL, an AAF, or an XML.

From Premiere Pro, the standard export for grading handoff is FCP7 XML. This is Apple's XMEML format, originally designed for Final Cut Pro 7. Premiere adopted it as its primary interchange format because the ecosystem already supported it. Resolve, Baselight, Flame, Hiero, and Scratch all read it. The format handles multi-track timelines, nested sequences, speed changes, and transitions. On paper, it is the right tool for the job.

In practice, Premiere's implementation of the FCP7 XML export has a cluster of bugs that affect timing, frame rates, and metadata accuracy. The bugs are not theoretical. They show up in real conforms, on real schedules, with real budgets attached.

The seven bugs

The interactive table below summarises the known issues. Click any row for a longer explanation of the mechanism.

Premiere FCP7 XML bug summary

Field dominance on progressive: critical in Premiere 25.0 and 25.1. Progressive 25fps sequences export as interlaced and import as 50fps. Fixed in 25.2.
23.976 exported as 24fps: critical. About 1 frame of drift every 42 seconds, or about 128 frames over 90 minutes. Only partially fixed.
Timecode string mismatch: high severity. The <string> timecode can disagree with the authoritative <frame> count.
displayformat always wrong: medium severity. Drop-frame versus non-drop-frame cannot be trusted from the standard field.
Speed or conform double-apply: critical. Retimed clips can play at the wrong speed after conform.
Frame rounding on retimes: high severity. One-frame disagreements accumulate across edits.
Source timecode misread: high severity. Some MXF and MOV sources are read with the wrong source timecode.

Three of these are critical. They do not produce subtle errors. They produce conforms that are visibly, obviously wrong in ways that halt the grading session.

Bug 1: Your 25fps timeline becomes 50fps

This is the one that generates the most support tickets. In Premiere Pro 25.0 and 25.1, exporting a progressive 25fps sequence via FCP7 XML writes the field dominance metadata incorrectly. Instead of fielddominance=none (progressive), it writes fielddominance=lower (interlaced, lower field first).

Every downstream tool that reads this XML does the correct thing with the incorrect data. When Resolve sees fielddominance=lower at 25fps, it interprets the content as 25fps interlaced, which is 50 fields per second. It creates a 50fps timeline. Baselight does the same. Flame does the same. The tools are not wrong. The XML is.

The bug only affects sequences created from scratch in Premiere 25.x. If you opened a project originally created in version 24.x, the export was correct. Adobe fixed it in version 25.2 (build 10), but the fix only applies if you update and re-export. Every XML that left a 25.0 or 25.1 installation carries this error.

The same bug also affects 29.97fps progressive sequences. The field dominance is written as lower even when the sequence is explicitly set to "Fields: No Fields (Progressive Scan)."

The fix is a single find-and-replace in a text editor: change <fielddominance>lower</fielddominance> to <fielddominance>none</fielddominance>. But you need to know the bug exists before you think to look for it.

Bug 2: The silent drift at 23.976

This one is worse in some ways because it does not announce itself. It starts quiet and gets louder.

In the FCP7 XML format, the difference between true 24fps and 23.976fps is encoded by a single boolean flag called ntsc. When ntsc is TRUE, the frame rate is reduced by the familiar 0.1% NTSC factor: 24 becomes 23.976, 30 becomes 29.97, 60 becomes 59.94. When Premiere exports a 23.976fps sequence with ntsc=FALSE, every downstream tool reads it as true 24fps.

The rate error is 24 / 23.976 = 1.001001. That is a drift of approximately one frame every 42 seconds. On a 30-second spot, you will never notice. On a feature film, the numbers look like this:

23.976 vs 24fps drift examples

30-second spot: less than 1 frame of drift.
5-minute short: about 7 frames.
22-minute episode: about 31 frames, roughly 1.3 seconds.
44-minute episode: about 63 frames, roughly 2.6 seconds.
90-minute feature: about 128 frames, roughly 5.3 seconds.
120-minute feature: about 171 frames, roughly 7.1 seconds.

Try selecting the 90-minute preset. By the end of a standard feature, the conform has drifted by roughly 128 frames. That is 5.3 seconds. Dialogue is completely out of sync with picture. Cuts land in the wrong place. And because the drift is gradual (linear over the programme length), the first reel might look fine during a spot check. The problem only becomes obvious in the back half, by which point the colourist may have graded 40 minutes of material against a timeline that was never correct.

Bug 5: The speed change trap

This is the hardest bug to diagnose because it only affects some clips on the timeline.

When Premiere exports an XML containing clips that have been retimed (speed changed), it bakes the frame rate conform into the speed value for those clips. If a 50fps clip is conformed to 25fps (a 50% speed interpretation) and then the editor applies an 80% creative speed change, Premiere writes a speed of 40% into the XML. It multiplied 80% by the 50% conform factor.

The problem: Premiere does not do this for clips that have not been retimed. Non-retimed clips export with their raw durations, and the downstream tool is expected to apply its own frame rate conform. This creates an inconsistency within a single timeline. The grading tool re-applies the conform to everything, which is correct for the non-retimed clips and wrong for the retimed ones. The retimed clips end up playing at half their intended speed.

This compounds with nesting. If the retimed clip is inside a nested sequence, each nesting level can introduce its own conform factor. The result is clips playing at speeds that bear no obvious relationship to the editor's intent.

The workarounds people actually use

The community has developed a set of survival strategies, none of them elegant.

Manual XML editing. Open the XML in a text editor, find-and-replace the broken values. This works for the field dominance bug and the ntsc flag. It does not help with speed change interactions or frame rounding errors, because those require understanding the relationship between specific clips and their source media.

Export as EDL instead. Many colourists now request EDLs from Premiere editors specifically because the EDL format is too simple to carry the bugs. An EDL is just a flat list of timecodes and reel names. No field dominance metadata. No ntsc flags. No speed effect encoding. The limitation is real: EDLs support a single video track, no speed ramps, and the CMX3600 format truncates filenames to eight characters. But for a single-track cutlist, the EDL arrives intact when the XML does not.

Export as AAF. The Advanced Authoring Format uses a completely different encoding and avoids most of the FCP7 XML bugs. Several professionals report that AAF exports from Premiere handle 25fps progressive content correctly where XML fails. The tradeoff is that AAF files are binary, harder to debug, larger, and not universally supported (Flame, for example, prefers XML or EDL).

Flatten retimes before export. For the speed/conform interaction bug, the workaround is to duplicate the sequence, render all retimed clips in place, replace them with the rendered versions, and then export. This removes all speed effects from the XML, avoiding the double-conform problem. It also destroys the editor's ability to adjust retimes after handoff, which is sometimes acceptable and sometimes not.

Always send a reference render. This does not fix any bugs. It lets the colourist detect them. Export a low-bitrate H.264 alongside the XML. The colourist plays it against the conformed timeline and spot-checks every cut point, speed change, and in/out transition. If something does not match, they know before they start grading.

Launder through Resolve. A surprisingly common workflow: import the broken Premiere XML into Resolve, let Resolve partially correct the errors during import, then re-export a new XML from Resolve. Resolve's XML writer is more spec-compliant than Premiere's. This adds a step and can introduce its own rounding errors, but it often produces a usable result.

Why the standard format is not standard

The root of the problem is that FCP7 XML is not Premiere's native format. It is a translation layer. Premiere converts its internal timeline model (which uses a tick-based time system with 254016000000 ticks per second) into Apple's frame-count-based XMEML schema. Every translation is lossy. The bugs documented above are places where the translation goes wrong.

Adobe knows about these issues. The field dominance bug was fixed relatively quickly once it was reported. But bugs 3, 4, 5, and 6 have been present since at least CS6 (2012) and remain unfixed in the current stable release. The timecode string mismatch and the displayformat error are so long-standing that the community treats them as known constants rather than bugs.

Adobe has introduced OTIO (OpenTimelineIO) export in the Premiere Pro beta channel. This is a promising direction, but as of early 2026 it is not in the stable release, and the beta implementation has its own metadata fidelity issues: clip names revert to original filenames on roundtrip, and tape names are lost entirely. For now, FCP7 XML with manual corrections remains the standard path.

What a proper correction layer looks like

The right solution is not to fix XMLs by hand. It is to build a parser that knows about Premiere's specific failure modes and corrects them programmatically during import.

A Premiere-aware conform tool needs to do five things:

Detect Premiere origin. Premiere embeds proprietary attributes like MZ.Sequence.VideoTimeDisplayFormat in its XMLs. If these are present, the tool activates correction mode.
Fix field dominance. If fielddominance is lower or upper but the timebase is 25 and the source media is progressive, force it to none.
Fix the ntsc flag. Cross-reference the declared frame rate against the source media (via probe data). If source files are 23.976 and the XML says true 24, correct the flag.
Ignore displayformat. Never trust the DF/NDF indicator from Premiere. Derive it from the rate and the proprietary MZ.Sequence.VideoTimeDisplayFormat code if available.
Use frame counts, not strings. Always compute timecodes from the <frame> element and the rate. Never trust the <string> element.

This is the approach we are building into Muster's conform engine. The goal is that a colourist who does not own Premiere, and should not need to, can import a Premiere-originated XML and get a correct timeline without manual intervention.

The broader lesson

Premiere Pro is the most widely used NLE in the world. Its XML export is the primary interchange format for tens of thousands of conform workflows every year. And it has had documented, reproducible timing bugs in that export for over a decade.

This is not a Premiere-specific failing. It is a structural problem with interchange formats that are translations rather than native representations. Every NLE-to-grading-tool handoff involves a lossy conversion, and the bugs live in the gap between what the source application means and what the target application reads. The only reliable defense is a correction layer that understands both sides of the conversation.

If you are an editor sending XMLs to a colourist: always include a reference render. If you are a colourist receiving XMLs from Premiere: check the field dominance, check the frame rate, and never trust the timecode strings. If you are building tools that parse these files: trust the frame counts, probe the source media, and assume the metadata is guilty until proven innocent.

Why the frame is green

Tue, 21 Apr 2026 00:00:00 GMT

You open a 10-bit ProRes file in your custom playback tool and the viewer fills with green. Not a little green tint. Full, saturated, Kermit green. The file plays fine in QuickTime. Resolve shows it correctly. Your tool shows a green rectangle with maybe a faint ghost of detail if you squint.

This is one of the most common bugs in video decoder integration, and it has a single, specific cause. The pixel values are being normalised against the wrong range.

What you're actually looking at

That green frame is not random. It's your actual image data, but every channel is being read as a value very close to zero.

A 10-bit video signal uses code values from 0 to 1023. When you upload those values to a GPU texture as 16-bit unsigned normalised (R16Unorm in Metal and Vulkan, DXGI_FORMAT_R16_UNORM in DirectX), the GPU normalises against the full 16-bit range: 0 to 65535. Your brightest pixel, code value 1023, becomes 1023 / 65535, which is approximately 0.0156. Your shader sees a value of 0.016 where it expected 1.0.

The result: luma is nearly zero and both chroma channels are nearly zero. And zero chroma in YCbCr space has a very specific colour.

Why zero means green

Video is almost never stored as RGB. It's stored as YCbCr, where Y is luma (brightness) and Cb/Cr are colour difference channels. The neutral point for chroma is not zero. In a normalised 0.0 to 1.0 range, neutral chroma sits at 0.5 (corresponding to code value 512 in 10-bit, or 128 in 8-bit). A Cb of 0.5 and a Cr of 0.5 means "no colour." Grey. Neutral.

When both Cb and Cr are at 0.0 instead of 0.5, the YCbCr-to-RGB conversion matrix produces a strong green bias. The BT.709 conversion matrix defines luma as 0.2126R + 0.7152G + 0.0722B. Green dominates the luma coefficient because human vision is most sensitive to green. When you invert that relationship with zero chroma offset, the math pushes everything toward the green primary.

Specifically, with Y near zero and Cb/Cr at their minimum instead of their midpoint, the conversion produces negative R and B values (which clamp to zero) and a small positive G value. Green channel survives. Red and blue do not. The result is a green frame.

This is not a coincidence or a quirk of a particular implementation. It falls directly out of the matrix maths. Any YCbCr system built on BT.601, BT.709, or BT.2020 coefficients will produce green when chroma channels are biased toward zero. The green primary always carries the most luma weight, so it's the last channel standing when everything else clips.

The R16Unorm trap

The core problem is a mismatch between the data's actual bit depth and the GPU texture format's normalisation range.

When a decoder hands you a 10-bit Y plane, the values sit in the range 0 to 1023. But they're stored in 16-bit words, typically left-shifted to the top of the 16-bit range (values 0 to 65472 in steps of 64) or packed at the bottom (values 0 to 1023 with the upper 6 bits zero).

If the decoder packs values at the bottom of the word and you use R16Unorm, the GPU divides every value by 65535. Your 10 bits of real data occupy less than 2% of the normalised range. The image is there, technically, but it's crushed into a sliver near zero.

The correct format for bottom-packed 10-bit data is R10X6Unorm (Metal's .r16Unorm with manual rescaling, or Vulkan's VK_FORMAT_R10X6_UNORM_PACK16). This format tells the GPU that only the top 10 bits are significant, so it normalises against 1023 instead of 65535. Your peak white becomes 1.0, as it should.

If your API doesn't support R10X6 natively, the fix is to multiply by 65535.0 / 1023.0 (approximately 64.0) in your shader. Some developers left-shift the data to the top of the 16-bit word before upload instead, which also works: a value of 1023 becomes 65472, which normalises to 0.9990 under R16Unorm. Close enough for display, though not bit-exact.

Why ProRes, DNxHR, and H.265 trigger this

This bug appears disproportionately with ProRes, DNxHR, and H.265 10-bit content because these are the formats most likely to deliver 10-bit planar YCbCr data to your application.

ProRes always decodes to planar YCbCr. The Apple VideoToolbox decoder on macOS hands you a CVPixelBuffer with a pixel format like kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange or kCVPixelFormatType_422YpCbCr10BiPlanarVideoRange. The "10Bi" means 10-bit biplanar. The Y and CbCr planes each use 16-bit words with the 10-bit values in the high bits.

DNxHR follows a similar pattern through its decoder. H.265 10-bit (common in mirrorless camera output, screen recordings, and streaming deliveries) decodes to the same family of pixel formats.

8-bit content rarely triggers this bug because R8Unorm normalises against 255, and 8-bit data fills the full 0 to 255 range. The normalisation is correct by default. It's the jump to 10-bit in a 16-bit container that creates the mismatch.

This is also why the bug tends to appear when developers move from 8-bit to 10-bit support. The 8-bit path worked perfectly. The 10-bit path uses the same upload logic, same texture format, and suddenly everything is green.

The partial green variant

Sometimes you don't get a solid green frame. You get an image that's recognisable but with a heavy green cast and crushed contrast. This usually means one of three things:

Only the chroma planes are wrong. The Y plane is being normalised correctly (perhaps it's being handled as a different texture format or the decoder left-shifted it) but the CbCr plane is still being divided by 65535 instead of 1023. Luma looks roughly correct, so you see a dim, low-contrast, monochrome-ish image with a green push because the chroma offset is wrong.

The UV offset is missing. Even with correct normalisation, if your shader doesn't subtract 0.5 from the Cb and Cr channels before the matrix multiply, you get a colour bias. The neutral point for chroma is 0.5 in normalised space, not 0.0. Skipping the offset shifts every pixel's colour. Depending on the content, this can produce a green or magenta tint across the whole frame.

Mixed bit depths across planes. Some decoders output the Y plane at one bit depth and chroma at another (or with different packing). If you're treating all planes identically and they aren't identical, one set of channels will be wrong while the other is right.

Each of these produces a different-looking image from the same file, and the common thread is that the pixel data is fine. The interpretation is wrong.

How to diagnose it

If you're seeing green, work through this checklist:

Check your texture format. Is the GPU texture format's normalisation range appropriate for the actual bit depth of the data? For 10-bit data in 16-bit words, R16Unorm is almost certainly wrong unless the data is left-shifted to fill the 16-bit range.

Check the decoder's packing convention. Does your decoder put 10-bit values in the high bits or the low bits of the 16-bit word? VideoToolbox on Apple platforms uses high-bit packing. FFmpeg's p010 format uses high-bit packing. Other decoders may differ. Read the documentation, then verify by inspecting the raw buffer values for a known test pattern.

Check your normalisation. After the GPU normalises the texture sample, does a peak-white pixel produce a value near 1.0 in your shader? If it produces 0.016, you have the R16Unorm problem. Multiply by 65535.0 / 1023.0, or switch to a format that understands 10-bit data.

Check your UV offset. After normalisation, are you subtracting 0.5 from Cb and Cr before applying the colour conversion matrix? If not, your neutral axis is wrong and everything will have a colour cast.

Check your matrix coefficients. Make sure the YCbCr-to-RGB matrix matches the source content. BT.709 for HD. BT.2020 for UHD. BT.601 for SD. The wrong matrix won't produce green, but it will produce subtly wrong colour that's hard to debug on top of a normalisation issue.

Render a test frame. Upload a known pattern (say, 10-bit values for 75% colour bars) and verify every patch. If your white patch comes out as very dark green, the normalisation is wrong. If the patches are approximately right but hue-shifted, the UV offset or matrix is wrong.

The real lesson

The green frame is actually a useful diagnostic. It tells you something very specific: your values are being normalised against a range they don't fill. Once you know that, the fix is mechanical. Match the texture format to the data's actual bit depth, or rescale in the shader.

The harder bugs are the ones that produce a plausible-looking image that's subtly wrong. A frame that's slightly dim. Colours that are almost right but shifted by a degree or two on the vectorscope. Those errors come from the same family of causes (wrong normalisation, wrong offset, wrong matrix) but at a scale that doesn't trigger the obvious green alarm.

When your frame is green, the pipeline is telling you exactly where to look.

References

ITU-R BT.709-6: Parameter values for the HDTV standards for production and international programme exchange
ITU-R BT.2020: Parameter values for ultra-high definition television systems for production and international programme exchange
Apple Developer Documentation: CVPixelBuffer pixel format types and biplanar YCbCr formats
Vulkan Specification 1.3: VK_FORMAT_R10X6_UNORM_PACK16 and related multi-bit packed formats
Metal Feature Set Tables: Pixel format capabilities for R16Unorm and packed 10-bit formats
Microsoft DirectX: DXGI_FORMAT enumeration and video format support
Charles Poynton, Digital Video and HD: Algorithms and Interfaces (2012), chapters on YCbCr encoding and normalisation

Testing that your scopes aren't lying

Mon, 20 Apr 2026 00:00:00 GMT

A GPU compute shader can render a 1920x1080 vectorscope in under a millisecond. The equivalent CPU implementation takes roughly 80 to 120 milliseconds, depending on the machine and the complexity of the trace. That is not a subtle difference. It is the difference between a scope that updates at video rate and one that updates like a progress bar.

So you write the GPU path. You port the math to WGSL or GLSL, you dispatch a compute shader that bins every pixel into the correct chrominance coordinate, you accumulate intensity into a texture, and you ship it. The scope renders beautifully. It looks right.

But "looks right" is doing a lot of work in that sentence.

Why the CPU path exists

Oscillio renders scopes on the GPU because it has to. Real-time video monitoring at 24fps or higher demands it. But every scope type also has a CPU implementation that produces the same output, pixel for pixel. This is not a fallback for machines without a GPU. It is the reference.

The CPU path is written in straightforward Rust. No SIMD intrinsics, no threading tricks, no clever bit manipulation. It processes pixels in scanline order, applies the colour math with f64 precision, and writes into a plain Vec<u32> framebuffer. It is slow. It is also unambiguous. When the CPU path says a particular input pixel maps to a particular position on the vectorscope at a particular intensity, that answer is definitionally correct, because the CPU path is the spec.

This might seem like a lot of code to maintain for something users never see. It is. But the alternative is worse: a GPU-only pipeline where correctness is defined by "does it look right to a human squinting at the output." That is not a definition. That is a hope.

What goes wrong on the GPU

GPU compute shaders introduce three categories of precision problems that do not exist in scalar CPU code.

Floating point differences. GPUs typically operate in f32. Many GPU architectures implement fused multiply-add (FMA) operations that produce slightly different rounding than separate multiply and add on the CPU. For most graphics work this is irrelevant. For a scope, it means a pixel that should land at chrominance coordinate (0.312, 0.329) might land at (0.312, 0.330). One least-significant-bit of error in the bin index. Multiply that across two million pixels and you get a vectorscope that is subtly, systematically wrong. Not visibly wrong on any single frame. Wrong in a way that would mislead a colourist making precise skin tone judgments.

Atomic operation ordering. Vectorscope rendering is fundamentally a histogram problem. Multiple pixels map to the same bin, and their intensities need to be accumulated. On the CPU, this is a simple bins[index] += intensity. On the GPU, thousands of shader invocations run simultaneously, so accumulation requires atomic operations. Atomic adds on integer values are well-defined and consistent. But the order in which those atomics execute is not deterministic. If you are accumulating floating point values with atomicAdd, the result depends on execution order because floating point addition is not associative. The sum 0.1 + 0.2 + 0.3 does not necessarily equal 0.3 + 0.1 + 0.2 in IEEE 754.

Oscillio sidesteps this by quantising intensity to integer values before atomic accumulation. But that quantisation introduces its own error budget that needs to be tracked and tested.

Driver-specific behaviour. The same WGSL shader running on the same logical GPU can produce different output depending on the driver version. We have seen a case where an Intel Arc driver change altered the rounding behaviour of f32-to-u32 conversion inside a compute shader, shifting scope traces by one pixel on certain input values. The shader was correct. The driver was correct. The combination was different from what it was three months earlier.

Building the test harness

Testing image-producing code is not like testing a function that returns a number. You cannot write assert_eq!(gpu_output, expected) because "expected" is a 1024x1024 texture with millions of possible correct values, and exact equality is the wrong metric anyway.

Oscillio's scope test harness works in three layers.

Layer 1: Golden master comparison

For each scope type (waveform, vectorscope, histogram, CIE diagram), a set of reference input frames are rendered through the CPU path. The output textures are stored as 16-bit PNG files in the test fixtures directory. These are the golden masters.

The test runs the same inputs through the GPU path and compares the output against the golden master. But "compares" is not pixel-exact equality. It is a per-pixel tolerance check: for each pixel, the absolute difference in each channel must be below a threshold. For Oscillio, that threshold is 2 in 8-bit space (roughly 0.8% intensity error) and 1 in the bin-index domain.

When a golden master comparison fails, the harness writes three files: the expected image, the actual image, and a difference map that amplifies the error by 10x so it is visible to a human reviewer. This matters because scope precision bugs often produce differences that are invisible at 1:1 zoom but meaningful at the signal level.

Layer 2: Statistical validation

Golden master tests catch regressions, but they do not catch systematic bias. If the GPU path consistently shifts the vectorscope trace 0.5 pixels to the right, it might pass the per-pixel tolerance on every individual pixel while still being wrong in aggregate.

The statistical layer computes summary metrics across the entire output: mean error, max error, error standard deviation, and the 99th percentile error. These metrics are compared against budgets defined per scope type. The vectorscope budget is tighter than the waveform budget because chrominance precision matters more than luminance precision for the use cases where people rely on vectorscopes.

The harness also checks for bias. If the mean signed error (not absolute error) is consistently positive or negative, that indicates a systematic offset, not random noise. The bias threshold is set at 0.1 in 8-bit space. Anything above that triggers a failure even if every individual pixel is within tolerance.

Layer 3: Synthetic edge cases

Real video frames are poor test inputs because they exercise the common case. Most pixels in most frames produce similar chrominance values, cluster around similar luminance levels, and do not stress the boundaries of the scope's coordinate space.

The synthetic test suite generates inputs designed to exercise the edges: single-pixel inputs at extreme chrominance coordinates, flat fields at specific code values, gradients that sweep through the entire gamut, patterns that force every pixel into the same histogram bin (maximum atomic contention), and frames with values at the exact boundary between adjacent bins.

The single-bin-contention test is particularly valuable. It creates an input where every pixel maps to the same vectorscope coordinate. The CPU path produces a clean result because accumulation is sequential. The GPU path dispatches thousands of atomic adds to the same memory location simultaneously. If the atomic accumulation has any precision loss, it shows up here as a discrepancy between the GPU sum and the CPU sum. This test caught a bug in our original implementation where we were using atomicAdd on f32 values instead of quantised integers. The error was tiny per pixel but compounded to a visible intensity difference at high contention.

Running it

The test suite runs on CI against three GPU backends: Vulkan (Linux, discrete GPU), Metal (macOS, Apple Silicon), and DX12 (Windows, NVIDIA). Each backend gets its own tolerance budgets because driver precision varies. The Metal path is slightly more precise than the Vulkan path on the same logical operations, which we attribute to Apple's tighter shader compiler behaviour, though we have not confirmed that.

Tests run on every commit that touches the scope rendering code. A full run takes about 40 seconds, most of which is GPU setup and teardown. The actual rendering and comparison is fast. The CI machines have GPUs specifically because headless CPU-only testing would not catch the bugs that matter.

When a test fails, the review process is manual. A developer looks at the difference map, decides whether the error is a real bug or a legitimate precision change (like a driver update), and either fixes the shader or updates the golden master. Updating a golden master requires a comment in the commit explaining why the old reference was wrong or why the new precision characteristic is acceptable.

This is deliberately not automated. The decision to accept a new precision baseline is a judgment call about signal integrity, and we do not want that decision made by a threshold.

The cost of two paths

Maintaining both CPU and GPU implementations of every scope type is real work. When the rendering algorithm changes, both paths need updating. When a new scope feature ships, it ships twice. The CPU path is typically 3x more code than the GPU path because scalar code cannot lean on implicit parallelism.

The alternative is trusting the GPU output because it looks right. We tried that early on. It produced scopes that were wrong by 1 to 2 pixels on certain input values, in ways that no human reviewer caught during development, but that a colourist would eventually notice when making critical adjustments near the edges of legal gamut. A scope that is wrong at the margins is worse than no scope at all, because it teaches you to distrust the tool.

The CPU reference path costs us roughly two weeks of additional engineering per scope type. The confidence it buys is worth more than that.

You don't need a LUT, you need a pipeline

Mon, 09 Mar 2026 00:00:00 GMT

You downloaded a LUT pack. You dragged the .cube file onto your adjustment layer. The footage looked cinematic. You shipped it.

Then you got a project that was shot on a different camera, and the LUT looked terrible. So you found another LUT. And another. And now you have a folder with 400 LUTs and a growing suspicion that there's a better way.

There is. It's called colour management, and it's simpler than the OCIO documentation makes it sound.

What a LUT actually is

A LUT is a sampled snapshot of a colour transform at a specific grid resolution. It takes input RGB values and maps them to output RGB values. It knows nothing about what camera the footage came from, what display you're viewing on, or what colour space you're working in. It's a lookup table. It looks things up.

When someone hands you a LUT called "ARRI_LogC_to_Rec709.cube", that LUT encodes a specific conversion from a specific log encoding to a specific display standard. Change any variable (different camera, different display, different working space) and the LUT gives you the wrong answer. It's not broken. It's just answering a different question than the one you're asking.

Interactive figure: Transfer-curve comparison for the encodings discussed in this section.

This is why your folder of 400 LUTs exists. Each one is a frozen answer to a specific question. A colour managed pipeline asks the question dynamically instead.

What a pipeline is

A colour managed pipeline separates the transform into steps:

Input transform. What colour space and encoding is this footage actually in? ARRI Log-C4 with Wide Gamut 4 primaries? Sony S-Log3 with S-Gamut3.Cine? The input transform converts from the camera's encoding to a common working space.
Working space. Where you do your grading. This is a defined, documented colour space that doesn't change between projects. In ACES, it's ACEScg (linear, AP1 primaries). In a custom OCIO config, it could be whatever makes sense for your facility.
Display transform. What are the characteristics of the monitor you're looking at right now? Rec. 709 SDR? P3 D65? PQ for HDR? The display transform converts from your working space to whatever the display needs.

Each step is a defined, swappable, documented transform. Change the camera? Update the input. Change the monitor? Update the display. The working space stays the same. Your grade stays the same. That's the whole idea.

Interactive figure: Before-and-after comparison illustrating the visual difference discussed in this section.

Why LUTs still exist

LUTs aren't evil. They're useful in specific situations:

On-set monitoring. A LUT on a SmallHD gives the DP an approximate look. Fast, predictable, and the monitor doesn't need OCIO installed.
Client review. Baking a LUT into dailies gives the producer a consistent look without requiring colour management on their laptop.
Final delivery. Some delivery specs require baked LUTs in the output.

The problem is using LUTs as your colour management strategy rather than as a delivery format. A LUT on your monitoring chain is fine. A LUT as the only thing standing between your camera negative and your grading software is not.

Getting started without losing your mind

The OCIO documentation assumes you already understand colour science. You don't have to. Here's the minimum viable setup:

Step 1: Pick a config

Don't build your own. Use one that already exists:

ACES 1.3. The industry standard. Well-documented, wide support, good default for most work. Download the OCIO config from the Academy's GitHub.
SPI-Anim / SPI-VFX. Sony Pictures Imageworks configs. Battle-tested in VFX. Simpler than ACES if you don't need the full pipeline.
Studio config. Many post houses have a house config. Ask before building your own.

Step 2: Tell your software where it is

Every colour-managed application needs to know where your OCIO config lives. Set the OCIO environment variable:

export OCIO=/path/to/your/config.ocio

Or point to it in your application's preferences. DaVinci Resolve, Nuke, and Blender all have OCIO config fields in their colour management settings.

Step 3: Set your input

When you import footage, tell the software what encoding it's in. If it's ARRI footage, the input should be ARRI LogC3 or LogC4 (depending on the camera). If it's Sony, S-Log3. If it's a VFX render, it's probably linear with whatever primaries the render engine used.

This is the step that LUT workflows skip entirely. The LUT assumes it knows the input. The pipeline asks you to be explicit about it.

Step 4: Set your display

Tell the software what monitor you're looking at. If it's a standard HD monitor, that's Rec. 709. If it's a P3 display, that's DCI-P3 or Display P3. If it's HDR, that's PQ or HLG depending on the spec.

That's it

Those four things (config, environment variable, input, display) give you a colour managed pipeline. Your grades are now portable between cameras, between monitors, between facilities. You can change any variable without the image falling apart.

The folder of 400 LUTs

You don't have to delete it. But you probably won't open it much anymore. When the pipeline handles the colour management, the LUTs become what they always should have been: creative looks and delivery conversions, not structural dependencies.

The day you stop thinking about which LUT to use and start thinking about which input transform matches your footage is the day colour management starts working for you instead of against you.

Integer-accurate colour math

Mon, 23 Feb 2026 00:00:00 GMT

You've measured a white bar. Your waveform reads 940. The question nobody asks: is that 940, or is it 939.9997 that got rounded up at the last moment before display?

For creative grading, the difference is invisible. For measurement, it's the difference between a signal that passes QC and one that doesn't. Between a scope you can trust and one that's guessing.

The answer depends on whether your colour math is running in floating point or fixed-point integer arithmetic. The two give different results more often than you'd expect.

The BT.709 matrix

Every HD video signal encodes colour as YCbCr. The conversion from RGB is defined in ITU-R BT.709, and the matrix coefficients are specific:

Y  =  0.2126 R + 0.7152 G + 0.0722 B
Cb = -0.1146 R - 0.3854 G + 0.5000 B
Cr =  0.5000 R - 0.4542 G - 0.0458 B

These are the numbers. They come from the CIE luminous efficiency function weighted for the 709 primaries. They're not negotiable and they're not approximate. The standard defines them to four decimal places.

For 10-bit video, the output values are scaled into a defined range. Luma (Y) occupies code values 64 to 940. Chroma (Cb and Cr) occupies 64 to 960, with 512 representing zero. These are also exact. A full-white signal is Y = 940, not 939 or 941.

Where floating point breaks

Take a simple case: convert a 10-bit RGB triplet of (940, 940, 940) to YCbCr. This is peak white. The luma result should be exactly 940 and both chroma channels should be exactly 512.

In floating point, the computation looks straightforward. Multiply each component by its coefficient, sum the results, scale to the output range, and round. But floating point doesn't represent these coefficients exactly. The number 0.7152 becomes 0.71520000000000001 in double precision (the nearest representable IEEE 754 value). That difference is on the order of 10^-17, which seems negligible. Multiply it by a 10-bit value, add it to two other similarly imprecise products, scale the result by 876 (the luma range), and the accumulated error starts to matter.

The result isn't 940.0. It's 939.9999999999998 or 940.0000000000002, depending on the platform, the compiler's floating-point optimisation flags, and whether the CPU is using 80-bit extended precision internally before rounding to 64-bit. On some paths you get 940. On others you get 939 after truncation, or 941 after an unlucky rounding cascade.

This isn't hypothetical. Different implementations of the same formula produce different integer results for the same input because the floating-point intermediate values aren't identical. Two scopes built by different developers, both implementing BT.709 correctly, can disagree by one code value. For a creative tool, that's irrelevant. For a measurement tool, it means one of them is wrong.

The problem compounds at the edges

The worst cases aren't peak white. They're the values near the legal limits where a single code value determines whether a signal passes or fails. A luma value of 940 is legal. A value of 941 is not. If your conversion produces 940.4999 and you round down, you get 940: legal. If the same input on a different code path produces 940.5001 and you round up, you get 941: illegal.

The same problem appears at the bottom of the range. Code value 64 is legal black. Code value 63 is below legal range. A conversion that produces 64.0001 and one that produces 63.9999 will give you different answers for the same input.

Chroma has the same issue. The neutral point is 512 for both Cb and Cr. A pure grey input should produce exactly 512 on both chroma channels. In floating point, you often get 511.9999 or 512.0001. After rounding, that's either 512 or 511 or 513. The error is one code value. In a creative context, nobody would ever see it. In a scope, it means your chroma trace has a DC offset on grey that shouldn't exist.

Interactive figure: Comparator showing how different rounding choices produce different integer results.

How integer math fixes it

The fix is to do what the hardware did: work entirely in integers. The BT.709 coefficients can be represented as ratios of integers with a fixed denominator. The standard approach uses a power-of-two denominator so the final division can be a bit shift.

For example, using a 16-bit scale factor of 2^16 (65536):

0.2126 * 65536 = 13933.4336  -> round to 13933
0.7152 * 65536 = 46871.3472  -> round to 46871
0.0722 * 65536 =  4732.2192  -> round to 4732

Now the luma calculation becomes:

Y_scaled = 13933 * R + 46871 * G + 4732 * B
Y = (Y_scaled + 32768) >> 16

That + 32768 is the rounding bias. Adding half the denominator before the right shift gives you correct rounding (round-half-up) instead of truncation. Every intermediate value is an integer. Every operation is exact. There's no accumulated floating-point error because there are no floating-point operations.

The key detail is choosing the integer coefficients so they sum to exactly the denominator. 13933 + 46871 + 4732 = 65536. This guarantees that equal RGB inputs produce an output that's exactly equal to the input (after scaling), because the sum of the products equals the input value times the denominator. Peak white in, peak white out. No drift.

When the coefficients don't sum exactly, you adjust the largest one. Since the green coefficient has the most significant bits, nudging it by one count has the smallest relative effect. Better to be off by 1/65536 on the green coefficient than to have the entire system drift by one code value on common inputs.

The rounding bias matters

The choice of rounding strategy isn't cosmetic. Truncation (just shifting without adding the bias) introduces a systematic negative error. Every result is biased toward the lower code value. On average, you're off by half a code value, and the error is always in the same direction. A scope that truncates will read consistently low.

Round-half-up (adding 0.5, or the integer equivalent of half the denominator) eliminates the systematic bias. The error on any individual sample is at most half a code value, and it's equally likely to round up or down. There's no DC offset in the error.

For a waveform monitor, this distinction is the difference between a trace that sits cleanly on the graticule line and one that's consistently one pixel low. On a Tektronix hardware scope, the conversion was done in dedicated silicon that used integer math with correct rounding. The trace sat on the line. If your software scope truncates instead of rounding, your trace won't match the hardware, and the hardware was right.

The inverse matters too

Conversion is bidirectional. YCbCr comes in from the video signal, gets converted to RGB for display and analysis, then possibly back to YCbCr for output. Each conversion is an opportunity for error. If the forward conversion uses integer math and the inverse uses floating point (or vice versa), the round-trip isn't lossless even when mathematically it should be.

This is why Oscillio runs the entire signal path in integer arithmetic. The YCbCr-to-RGB conversion, the measurement calculations, the histogram binning, the trace rendering coordinates. Every operation that touches a code value uses integer math with explicit rounding control. A value that enters the pipeline as 940 is still 940 when it reaches the display, not 939 and not 941.

The alternative is to hope that the floating-point path through your particular compiler on your particular CPU produces the right answer for every possible input. Hope is not a measurement strategy.

Why this affects you

If you're building a creative tool (a colour grading panel, a preview window, a thumbnail generator) none of this matters. The visual difference between Y = 940 and Y = 939 is zero. Nobody can see it. Use whatever math is most convenient.

If you're building a measurement tool, or using one, it matters completely. A waveform monitor exists to tell you the exact code values in your signal. If the monitor's internal math introduces a one-code-value error, the monitor is reporting a signal that isn't the signal you sent it. It's a measurement instrument that doesn't measure accurately. The fact that the error is small doesn't make it acceptable. Voltmeters don't get to be off by one millivolt because the difference is small.

The hardware scope vendors understood this. The Tektronix WFM7120 didn't use floating point for signal conversion. Neither did the Leader LV-5800. They used dedicated integer pipelines with controlled rounding, because measurement is not approximation.

Software scopes that want to be taken seriously as measurement tools need to meet the same bar. When the trace says 940, the signal should be 940. Not 939.9997 rounded up. Not 940.0003 rounded down. Exactly 940, because the math that produced it was exact.

The parametric log transform: one equation, every camera

Mon, 26 Jan 2026 00:00:00 GMT

A timeline arrives with footage from three cameras. The A-cam shot ARRI LogC4. B-cam was a Sony VENICE in S-Log3. The drone sent back RED Log3G10. Three different log encodings, three different white papers, three sets of transfer function equations that look nothing alike.

Except they are alike. They are the same equation with different constants.

That claim sounds reductive, but it holds up under scrutiny. Every major cinema log encoding, from every major manufacturer, is an instance of a single parametric form: a piecewise function with a logarithmic segment, a linear tail near black, and a handful of published coefficients that fully define the curve. Knowing this changes how conversions work, how new cameras get supported, and how much of "camera colour science" is actually just six numbers in a table.

The shape of a log curve

Every cinema log encoding does the same job. The camera sensor captures light linearly, meaning twice the photons produce twice the signal. But the human eye doesn't work that way. Perception is roughly logarithmic: the difference between 1 and 2 candles feels the same as the difference between 100 and 200. Storing linear sensor data directly would waste most of the code values on highlights that all look "bright" and starve the shadows where banding actually matters.

A log curve redistributes code values so that each photographic stop gets a roughly equal share. That's why log footage looks flat. It's not damaged or wrong. It's been packed for efficient transport, and it needs a known transform to unpack it for viewing.

The question is: what specific curve does the packing?

One equation to rule them all

OpenColorIO, the open-source colour management framework used in most professional post-production software, defines a transform called LogCameraTransform. It implements what the OCIO documentation calls a "parametric Lin-to-Log / Log-to-Lin" model. The core equation for the log segment (above a linear cutoff) is:

LogValue = LogSideSlope * log10(LinSideSlope * linear + LinSideOffset) + LogSideOffset

And below the cutoff, a simple linear segment takes over:

LogValue = LinearSlope * linear + LinearOffset

That's it. Five coefficients for the logarithmic region (LogSideSlope, LogSideOffset, LinSideSlope, LinSideOffset, and base), two for the linear tail (LinearSlope, LinearOffset), and a cutoff point where one region hands off to the other.

Every major camera manufacturer's log curve is an instance of this parametric form. Different constants, identical structure. ARRI LogC4 is this equation with one set of numbers. Sony S-Log3 is this equation with another set. They look like proprietary formats. They are published constants for a shared mathematical form.

What each coefficient does

Understanding the coefficients turns the equation from abstract notation into physical intuition.

LinSideSlope scales the linear input before the logarithm. It controls the overall gain applied to the scene-linear data. A higher value stretches the input range that gets mapped into the log curve, effectively determining how many stops of dynamic range the encoding can represent. ARRI's LogC4, designed for a sensor with over 17 stops of range, uses a different LinSideSlope than Sony's S-Log3, which targets around 15 stops.

LinSideOffset shifts the linear input before the log is taken. This is the term that handles what happens near zero and below. Real camera sensors have noise floors and can produce negative values (through black level subtraction). The offset ensures the argument to the logarithm stays positive, preventing the curve from heading toward negative infinity. It also controls where "scene linear zero" maps in the output.

LogSideSlope scales the output of the logarithm. It determines the steepness of the curve in the code value domain. A steeper LogSideSlope means each stop of exposure occupies more code values, giving finer gradation per stop but covering fewer total stops within the 0 to 1 output range.

LogSideOffset shifts the entire log output up or down. This positions the curve vertically, controlling where middle grey lands in the code value range. Most log encodings place 18% grey somewhere between 0.38 and 0.42 in normalised code values, but each manufacturer chose slightly differently. The LogSideOffset is how they did it.

LinearSlope and LinearOffset define the straight-line segment near black. Below a certain exposure level, the logarithmic curve would curve too steeply, creating issues with noise amplification and quantisation. The linear segment replaces the log curve in this region with a gentle straight line. The slope and offset are chosen so that the two segments meet with matched value and matched first derivative, producing a smooth, continuous function with no visible kink.

The parameters, side by side

Interactive figure: Curve comparison showing how camera log encodings differ by constants in the same equation.

Here are the actual published constants for four widely used log encodings, expressed as OCIO LogCameraTransform parameters:

Parameter	ARRI LogC4	Sony S-Log3	RED Log3G10	Canon C-Log2
LogSideSlope	0.0647954	0.255958	0.224282	0.092864
LogSideOffset	0.5515593	0.410557	0.386053	0.556929
LinSideSlope	14.0	5.26316	155.975327	87.099375
LinSideOffset	0.0928	0.01125	2.0	1.0
LinearSlope	6.359295	6.62194	0.01	4.889494
LinearOffset	0.092778	0.037584	0.0	0.133337
Lin break	0.01	0.01125	0.000064	0.0001
Log break	0.1574	0.1673	0.0928	0.1350

These numbers are not secrets. ARRI publishes LogC4's specification. Sony's S-Log3 white paper includes the full transfer function. RED released Log3G10's coefficients. Canon documents C-Log2 in their camera SDKs. OCIO's built-in configs collect them all in one place, normalised to the same parametric form.

Look at the table and some patterns emerge. ARRI's LogSideSlope is the smallest, reflecting LogC4's design for very high dynamic range (the curve is shallower per stop, but covers more stops). RED's LinSideSlope is enormous because Log3G10 normalises its linear input differently, using a larger scale factor before the log. Sony's LinearSlope is steeper than the others, meaning S-Log3's linear-to-log transition happens with a slightly more aggressive shadow segment.

But these are differences of degree, not of kind. Every camera manufacturer solved the same optimisation problem: how to distribute a finite number of code values across a wide dynamic range in a way that minimises visible quantisation at every exposure level. They arrived at the same mathematical form and chose constants tuned to their sensor characteristics.

The linear tail

The linear segment near black deserves its own moment. It exists because of a practical problem: the logarithm of zero is negative infinity.

If you trace the pure log curve down toward zero exposure, the output value drops without bound. In a real system with finite bit depth, this means the lowest exposure levels would demand an absurd number of code values. Worse, sensor noise in the deep shadows would be amplified by the steepening curve, turning subtle noise into visible banding.

The solution is to define a "linear break point" below which the log curve switches to a straight line. The linear segment is gentler, gives the shadows enough code values to stay clean, and joins the log segment smoothly. The break point itself varies by manufacturer. ARRI's LogC4 transitions at about 0.01 in scene-linear. RED's Log3G10 breaks much lower, at 0.000064. That difference reflects a design choice about how much deep shadow detail the encoding prioritises.

Getting the break point wrong (or ignoring it entirely) is a common source of errors in hand-written log transforms. The parametric model handles it automatically. Define the six coefficients and the break point, and the math guarantees continuity.

Why this matters in practice

When you understand that all these log curves share a common form, several things become clear.

First, converting between log encodings is not a lookup table problem. It's an analytic inverse. You can go from S-Log3 to scene-linear and then from scene-linear to LogC4 with exact math. No sampling grid, no interpolation error, no 33-point cube approximation. The inverse of the parametric log equation is another parametric log equation. OCIO does this by default when you chain LogCameraTransform operations.

Second, when a new camera comes out with a new log curve, you don't need to wait for someone to ship a LUT pack. You need six numbers and a break point. If the manufacturer publishes a white paper with the transfer function (and they almost always do), you can extract the OCIO parameters directly. The curve is fully defined.

Third, comparing cameras becomes less mystical. The difference between LogC4 and S-Log3 is not "ARRI colour science versus Sony colour science." It's a different LinSideSlope, a different LogSideOffset, a different break point. You can see exactly where the curves diverge and by how much. The engineering is transparent. The same transparency applies to the colour space matrices that sit alongside these transfer functions.

And fourth, custom log encodings for VFX pipelines or virtual production become straightforward. If your LED wall needs a specific transfer function to match the response of a particular camera, you build it by choosing six parameters, not by sculpting a LUT by eye.

They published the numbers

This is, in some ways, the most remarkable part. Camera manufacturers could have kept their log curves as opaque black boxes. Some older encodings were exactly that: undocumented curves that you had to reverse-engineer from test charts and reference images.

But the major manufacturers chose to publish. ARRI's LogC4 specification is a free PDF. Sony's S-Log3 white paper walks through the math. RED's IPP2 documentation includes Log3G10's full definition. Canon, Panasonic, and Blackmagic have all followed suit. The industry converged not just on a shared mathematical form, but on a culture of documenting it openly.

OCIO's LogCameraTransform is the practical expression of that convergence. It says: here is the general equation, and here are the constants for every camera we know about. If your camera isn't in the list, give us the constants and it will be.

The next time you see "S-Log3" in a dropdown menu and feel a flicker of uncertainty about what that means, remember: it's five coefficients, a linear tail, and a break point. The same five coefficients, linear tail, and break point as every other camera in the list. The equation is the same. Only the numbers change.

References

ARRI. "ARRI LogC4 Logarithmic Color Space: Specification." ARRI Technical Documentation, 2022.
Sony. "Technical Summary for S-Gamut3.Cine/S-Log3 and S-Gamut3/S-Log3." Sony Professional White Paper, 2014.
RED Digital Cinema. "Image Processing Pipeline (IPP2)." RED Technical Documentation, 2017.
Canon. "Canon Log Transfer Characteristic." Canon Cinema EOS White Paper, 2020.
OpenColorIO Contributors. "LogCameraTransform." OpenColorIO Documentation, Academy Software Foundation. https://opencolorio.readthedocs.io/
OpenColorIO Contributors. "Built-in Transforms: Camera Log Encodings." OCIO v2 Configuration Reference. https://opencolorio.readthedocs.io/
Selan, Jeremy. "Cinematic Color: From Your Monitor to the Big Screen." VES Handbook of Visual Effects, 2012.

The exposure tools your camera already has (and why they lie)

Mon, 12 Jan 2026 00:00:00 GMT

You've been told to "expose to the right." You've been told to "protect your highlights." You've been told that false colour is the best exposure tool, or that the waveform is, or that the histogram is. Everyone has an opinion, and the opinions contradict each other.

Here's the thing: they're all measuring different things. And they're all lying to you, slightly, in different ways.

What zebras actually show you

Zebras are a threshold display. They show you where pixel values exceed a number you set. That's it. They don't know what the scene looks like. They don't know what's important. They draw stripes on anything that's bright enough, whether it's a specular highlight you're happy to clip or a face that's about to lose detail.

The number they compare against depends on what signal they're looking at. If your camera outputs Log-C to the monitor, the zebra threshold is in log code values. If it outputs a Rec. 709 conversion, the threshold is in display-referred values. Same scene, different zebra pattern. Neither is wrong. They're measuring different things.

The common gotcha: you set your zebras at 70% because someone told you that's correct skin exposure. On a 709 output, that might be true. On a Log-C output, 70% is nowhere near where skin sits. Log curves compress highlights, so the code value for a face is much lower than you'd expect. You're measuring the right number in the wrong domain.

What false colour actually shows you

False colour maps brightness ranges to colours, typically blue for shadows, green for midtones, pink for skin, red for clipping. It's a more nuanced tool than zebras because it shows you the entire exposure distribution at once.

But false colour has the same domain problem. Is it operating on the log signal or the display-referred signal? A face that reads as "correct skin exposure" in one domain might read differently in another. And the colour mapping itself varies between manufacturers. ARRI's false colour isn't the same as SmallHD's.

This is the part that trips up experienced operators. You learn one false colour scale, you internalise it, and then you switch to a different monitor or a different camera and the colours don't mean what they used to. The tool looks the same. The readings have shifted. Nothing in the interface tells you why.

The waveform is better, but not enough

The waveform monitor is the closest thing you have to an honest exposure tool. It plots every pixel's brightness vertically, spread across the horizontal axis of the frame, so you can see the full distribution of the image at a glance. Shadows at the bottom, highlights at the top, midtones where they fall.

It has two advantages over zebras and false colour: it shows you everything at once rather than just flagging a threshold, and it gives you a sense of spatial distribution. You can see which part of the frame is bright and which is dark.

But the waveform is still domain-dependent. A waveform displaying a log signal has a compressed shape compared to the same scene displayed in 709. Skin that sits at 42% on a Log-C waveform sits at 55–60% on a 709 waveform. If you're reading log levels with 709 instincts, you'll consistently underexpose by a stop or more. You'll think you're being careful. You'll be throwing away shadow detail.

Interactive figure: Transfer-curve comparison for the encodings discussed in this section.

The curve above shows why. Log encoding redistributes code values so that shadows get more room and highlights get less. On a linear or display-referred scale, midtones sit near the middle. On a log scale, they sit lower. Same light, different number. The waveform faithfully shows you whatever signal it receives, but it doesn't tell you which signal that is.

Why zone-based tools are different

Zone-based exposure tools, inspired by Ansel Adams' zone system, divide the exposure range into perceptually even steps and show you where things fall. The key insight is that they're anchored to the scene, not the encoding.

Adams divided the world into eleven zones, from pure black to pure white, with each zone representing one stop of light. Zone V was middle grey. A face was Zone VI. Bright clouds were Zone VII or VIII. The system was designed around the physics of light, not the characteristics of any particular film stock.

Modern zone-based tools apply the same logic to digital cinema. They map the camera's sensor data into perceptual zones, actual stops of light above and below middle grey, so that a face always reads as a face, regardless of whether you're monitoring in Log-C, S-Log3, or Rec. 709. The display domain becomes irrelevant because the tool has already translated the signal into scene-referred stops.

This is a genuine step forward. You're no longer reading a number that means different things depending on your monitoring chain. You're reading a measurement that corresponds to the light in front of the lens. If something reads as two stops over middle grey, it's two stops over middle grey, on any camera, in any log format, through any monitoring path.

Interactive figure: Before-and-after comparison illustrating the visual difference discussed in this section.

The practical upshot

You don't need to throw away your waveform or your false colour. They're useful tools. But you need to know which domain they're operating in, and you need to compensate for it. If you're monitoring in log, learn where skin sits on a log waveform instead of guessing from 709 experience. If you're using false colour, know whose false colour scale you're reading and what signal it's mapped to.

And if you have access to a zone-based exposure tool, use it. Not because it's fancier, but because it removes an entire category of error. You stop asking "what code value is this pixel?" and start asking "how many stops of light is this?" The first question depends on your encoding. The second question depends on the scene. The scene is what you're trying to photograph.

Same file, four apps, four different images

Mon, 29 Dec 2025 00:00:00 GMT

Open a single ProRes 422 HQ file tagged 1-1-1 (BT.709 primaries, BT.709 transfer, BT.709 matrix) in four applications. DaVinci Resolve shows saturated, punchy colour. Final Cut Pro looks brighter, with lifted shadows. Premiere Pro looks like one or the other depending on a checkbox. VLC shows something else entirely.

The pixels have not changed. The decode is identical. The four applications disagree about what the decoded values mean on the way to your display.

This is not a format or decode problem. Every application is reading the file correctly. The disagreement is specifically about colour interpretation: gamma curves, gamut mapping, and whether to honour the display's ICC profile. That disagreement is predictable once you know what each application actually does.

What the file declares

Every QuickTime and MP4 file can carry colour metadata in its colr atom. The Apple variant is nclc (nonconstant luminance coding). The ISO variant is nclx. They encode three integers and, for nclx, a flag:

Colour primaries (which red, green, and blue define the gamut)
Transfer characteristics (the gamma curve or OETF applied during encoding)
Matrix coefficients (how RGB was converted to YCbCr)
Full range flag (nclx only: code values 0-255, or legal range 16-235)

These values are enumerated in ISO/IEC 23001-8 (also ITU-T H.273). The same metadata can appear inside the video bitstream itself, in the VUI (Video Usability Information) of H.264 and H.265 streams. ProRes stores its own copy in the elementary stream frame header.

The metadata is not ambiguous. 1-1-1 means BT.709 primaries, BT.709 transfer, BT.709 matrix. 9-16-9 means BT.2020 primaries, PQ transfer, BT.2020 non-constant luminance matrix. The values are defined. The disagreement between applications is not about what the file says. It is about what they do with that information on the way to the screen.

Interactive figure: Side-by-side comparison of how different tools interpret the same tagged image.

Four applications, four rendering pipelines

Resolve: bypass by default

DaVinci Resolve in its default colour science mode (DaVinci YRGB, colour management off) does not transform pixel values from the file's colour space to the display's colour space. It sends decoded values straight to the GPU. On a Mac with a Display P3 panel, BT.709 code values land on P3 primaries without gamut mapping. Reds and greens are visibly oversaturated compared to a BT.709 reference monitor.

This is deliberate. Resolve bypasses macOS ColorSync entirely. Blackmagic's assumption: anyone doing serious colour work has a calibrated reference monitor on SDI through a DeckLink or UltraStudio, where the output path sends exact code values and the monitor handles its own calibration. The GUI viewer is a preview, not a reference.

Switch to DaVinci YRGB Color Managed mode and the behaviour changes completely. Resolve reads the colr atom, assigns an input colour space per clip, transforms through a wide-gamut working space (DaVinci Wide Gamut / Intermediate), and outputs to the chosen delivery space. This is a real transform-graph pipeline with explicit intent at every stage. But it is off by default in new projects, and a substantial number of Resolve users never enable it.

Final Cut Pro: full ColorSync, gamma 1.96

Final Cut Pro is fully colour-managed. It reads the file's colr atom, passes the tagged colour space to macOS ColorSync, and ColorSync transforms the image to the display's ICC profile. On any Mac display manufactured since roughly 2015, that profile is Display P3 with a D65 white point.

The critical detail is the transfer function. Apple's ColorSync applies a display gamma of approximately 1.96 to BT.709 content. Not 2.4 (BT.1886, the broadcast reference standard). Not 2.2 (sRGB's effective gamma). The value 1.96 descends from the original Macintosh system gamma of 1.8, adjusted upward for modern panels. The practical result: BT.709 content in Final Cut Pro renders brighter and lower-contrast than the same file on a BT.1886 reference monitor. Shadows lift. Midtones open up. The image looks "washed out" to anyone expecting broadcast contrast.

This is a deliberate rendering decision for bright-room viewing conditions on a consumer display. It means Final Cut's viewer will never match a grading suite. A colourist who grades on a reference monitor calibrated to BT.1886 and exports a QuickTime will hear "it looks washed out" from every client reviewing on a Mac.

Premiere Pro: two modes, two images

Premiere Pro 25.x performs automatic colour space conversion, transforming each source clip from its detected colour space into the sequence's working space. The default SDR working space is BT.709 with 2.4 gamma.

The complication is the Display Color Management toggle in Preferences > General. When enabled, Premiere compensates for the display's ICC profile via ColorSync, matching Final Cut's rendering path. When disabled, it sends values to the GPU without display compensation. On a P3 Mac, disabled means the same oversaturation as Resolve's default. Enabled means the gamma 1.96 lift, matching Final Cut.

Same file. Same application. Two different images. The toggle is off by default and buried deep enough that many editors have never seen it.

Premiere also has a history of omitting NCLC tags from exported QuickTime files. Without the tag, QuickTime Player falls back to default assumptions and applies its own gamma transform. The colourist's export looks different from the editor's export. Not because of the grade. Because of missing metadata.

VLC: minimal interpretation

VLC reads BT.709 and BT.2020 tags and can perform rudimentary colour space conversion, but it does not honour the display's ICC profile. It does not transform to the monitor's actual gamut.

On a P3 Mac, VLC shows more saturated colours than Final Cut because it is not mapping BT.709 content back to the intended gamut. It shows darker midtones than Final Cut because it does not apply the Apple gamma 1.96 lift. Against Resolve's default viewer, VLC looks similar but not identical: both bypass system colour management, but their decoders handle the BT.709 transfer function with slightly different precision.

VLC is showing the data with almost no interpretation applied. That is useful diagnostic information. It is not a reference.

Why the gamma 1.96 problem persists

The single most common colour complaint in post-production: a colourist grades on a reference monitor calibrated to BT.1886 (gamma 2.4), exports a QuickTime, and the client says it looks washed out. The colourist's monitor showed one thing. The client's Mac showed another. Neither is lying.

The mechanism is specific. A file tagged 1-1-1 (BT.709 primaries, BT.709 transfer, BT.709 matrix) triggers Apple's ColorSync gamma 1.96 rendering path. Blacks lift to not-quite-black. Contrast softens. The pixel values are unchanged. The display rendering is lighter than what the colourist approved on a 2.4 monitor.

Two workarounds exist. Resolve can export with "Rec 709-A" gamma tags, which signal a 1/1.961 transfer function and avoid triggering the ColorSync lift. The BBC's open-source qtff-parameter-editor rewrites NCLC tags in QuickTime files after export. Both are workarounds for a fundamental disagreement: Apple and the broadcast world use different gamma models for BT.709 content on consumer displays, and neither is planning to change.

The range trap

On top of gamma and gamut disagreements sits the full-range vs. limited-range question. BT.709 video uses "legal" range: code values 16-235 for 8-bit luma, with 0-15 and 236-255 reserved for headroom and footroom. Full range uses 0-255. The nclx atom has a full_range_flag to signal which encoding was used. Many encoders set it incorrectly. Many decoders ignore it.

The symptoms are specific. Limited-range data treated as full-range: the image looks washed out, blacks sit at dark grey (code value 16 rendered as 16/255 instead of 0), whites never reach peak white. Full-range data treated as limited-range: shadows crush to black, highlights clip. This is the single most common cause of "my video looks flat."

Range errors compound with gamma and gamut mismatches. A file with wrong range AND wrong gamma AND wrong primaries is three interpretation errors stacked together. Each one makes the others harder to isolate.

What "it looks right in Resolve" actually means

"It looks right in Resolve" means: the image on Resolve's GUI viewer, bypassing system colour management, rendering to whatever display is connected, with whatever project colour science is active, looks acceptable to one person in one room.

It does not describe what the file contains. It does not predict what a reference monitor would show, what the client will see in QuickTime, what the broadcast chain will do with the signal, or how the image will render in a browser on a phone.

The file's colour metadata describes what the pixel values mean. The application's rendering pipeline decides how to present those values on a specific display. Those are different operations. Conflating them is the root of almost every colour disagreement in post-production.

Diagnosing which interpretation is correct

The viewer is not the diagnostic tool. The metadata is.

Pull up FFprobe and read the colour tags directly:

ffprobe -v quiet -show_entries stream=color_primaries,color_transfer,color_space,color_range -of default=noprint_wrappers=1 input.mov

This tells you what the file declares. color_primaries=bt709, color_transfer=bt709, color_space=bt709, color_range=tv (limited range). If any of those fields say "unknown," the file is missing metadata and every application is guessing. That is the first thing to establish.

Next, compare scopes, not pictures. A waveform monitor is not affected by the display's ICC profile, the GPU's gamut mapping, or the room lighting. It shows the code values. The viewer shows an interpretation of those values through a rendering pipeline. When scopes and viewer disagree, the scopes are correct.

If the file's tags are present and correct, the question becomes: which application's rendering pipeline matches the intended viewing environment? Content graded for broadcast delivery on a BT.1886 monitor is correct at gamma 2.4. The same file viewed through ColorSync on a Mac will look different. Neither rendering is wrong. They are rendering for different display standards.

The practical diagnostic sequence:

Probe the file. Confirm the colr atom values (or VUI parameters for H.264/H.265). Confirm range.
Check the scopes. Do the code values match what the grade intended? Black at 16 (limited) or 0 (full)? Peak white at 235 or 255?
Identify the target display standard. BT.1886 for broadcast. ColorSync/gamma 1.96 for Mac consumer delivery. sRGB for web.
Choose the application whose pipeline matches. Resolve with colour management off matches no standard. Final Cut matches Apple's consumer rendering. Resolve with colour management on, pointed at BT.1886 output, matches broadcast.

The file is not the problem. The rendering disagreement is the problem. And the rendering disagreement is resolvable once you stop asking "which app looks right" and start asking "right for which display, in which viewing conditions, for which audience."

References

Charles Poynton, sde, vui, nclc, nclx
ISO/IEC 23001-8 / ITU-T H.273, Coding-independent code points
BBC, qtff-parameter-editor
Academy Software Foundation, Web Color Preservation
Larry Jordan, Caution: Premiere Pro, Final Cut Pro X and QuickTime Player Don't Show the Same Color the Same Way
Frame.io, Color Management Cheat Sheet for DaVinci Resolve
CineD, Quicktime Gamma Shift Bug

"Just send me a ProRes": a translation guide

Mon, 17 Nov 2025 00:00:00 GMT

The email says "just send me a ProRes." Which ProRes? ProRes 422? 422 HQ? 4444? 4444 XQ? ProRes RAW? At what resolution? What frame rate? What colour space? With or without an alpha channel? ProRes is not a quality setting. It is a family of codecs, and the name alone tells you almost nothing about the file.

"Just send me a ProRes" is the delivery equivalent of "make it pop." It communicates intent without precision, and the gap between intent and precision is where expensive re-deliveries happen.

The ProRes family is five (or six) codecs

ProRes isn't a codec. It's a family of codecs with dramatically different characteristics:

ProRes 422 Proxy. Tiny files for offline editing. Not for delivery.
ProRes 422 LT. Lighter version of 422. Sometimes acceptable for broadcast.
ProRes 422. The workhorse. Broadcast delivery standard.
ProRes 422 HQ. Higher bitrate. Master quality. What most people probably mean.
ProRes 4444. Adds a fourth channel (alpha). Up to 12-bit. VFX delivery.
ProRes 4444 XQ. Highest quality. 12-bit. The one nobody asks for because nobody knows it exists.

Interactive figure: Reference table comparing ProRes variants and where they do or do not belong.

When a client says "ProRes," they usually mean 422 HQ. But if you're delivering VFX plates, they might mean 4444. And if they're working on an M1 Mac and playing back in QuickTime Player, they might not realise that "ProRes" means something different at every quality level.

The file size difference is real. A minute of 4K ProRes 422 HQ is roughly 7.5 GB. The same minute in ProRes 4444 XQ is over 20 GB. If someone asks for ProRes and you deliver 4444 XQ, you've given them the best quality and the worst transfer time, and they'll wonder why their Dropbox is full.

"H.264 is web quality": no it isn't

This might be the most persistent misconception in post-production. H.264 is a compression standard, not a quality level. It can produce a 2 Mbps stream for YouTube or a 200 Mbps master that's visually indistinguishable from ProRes. The codec is the language. The bitrate, profile, and level determine the quality.

The confusion comes from where people encounter H.264. Most of the H.264 they see is heavily compressed web video: YouTube, Vimeo, streaming platforms. So H.264 becomes associated with "lossy web stuff" and ProRes with "professional quality." But that's a usage pattern, not a technical limitation.

H.265 (HEVC) adds another layer of confusion. It's roughly twice as efficient as H.264 at the same quality, but "twice as efficient" means the files are smaller, not that the quality is lower. A 100 Mbps HEVC file often looks as good as a 200 Mbps H.264 file. This matters enormously for camera originals: modern cameras that record in HEVC internally are producing excellent masters in half the file size.

The reason professional workflows still prefer ProRes and DNxHR over H.264/H.265 is not quality; it's decode performance. H.264 and H.265 use temporal compression (they describe the difference between frames rather than each frame independently), which means scrubbing to an arbitrary frame requires decoding a chain of dependent frames first. ProRes and DNxHR are intraframe codecs where every frame stands alone, so random access is instant. For editing, that distinction matters more than any bitrate comparison.

DNxHR: the other professional codec

DNxHR is Avid's answer to ProRes. It fills exactly the same role (intraframe, high-quality, designed for editing) and comes in its own family of quality tiers: DNxHR LB, SQ, HQ, HQX, and 444. The quality tiers roughly parallel the ProRes family, and the workflow advantages are identical.

The difference is ecosystem. ProRes is Apple's format and historically required macOS to encode (though that's less true now). DNxHR is Avid's format and works everywhere. If your post house is Avid-based, they'll ask for DNx. If they're on a Mac-based Premiere or Resolve pipeline, they'll ask for ProRes. The technical merits are near-identical. It's a question of which decoder their pipeline already has.

When someone asks for "ProRes or DNx," they're really asking for "an intraframe codec I can edit natively." Give them whichever one matches their NLE.

Container vs codec: the box and the language

This is where things get tangled for people outside post. A .mov file is a container. A .mp4 file is a container. Both of them can hold H.264 video. The extension on the file tells you what kind of box it's in, not what language the video speaks.

ProRes lives in .mov containers. DNxHR can live in .mov or .mxf containers. H.264 can live in .mov, .mp4, .mkv, or .ts containers. When a client says "send me an MP4," they're asking for a container. When they say "send me a ProRes," they're asking for a codec. When they say "send me a ProRes MP4," they're asking for something that doesn't exist. ProRes doesn't go in MP4 containers.

This isn't pedantry. If you send a .mov file to a system that only accepts .mp4, the fix might be as simple as re-wrapping the container without touching the video, a process that takes seconds and doesn't degrade quality. But if the recipient doesn't know the difference, they'll assume the file is broken, re-encode it at a fraction of the original quality, and blame you for the result.

The practical delivery checklist

A codec is not a specification. It is the beginning of one. "Send me a ProRes" fills in one parameter out of ten. The other nine are where rejections happen.

When someone asks for a file and the spec is vague, every one of these parameters needs a value:

1. Codec and quality tier. Not just "ProRes," which ProRes? Not just "H.264," at what bitrate? The difference between ProRes 422 and 422 HQ is roughly 50% in file size. The difference between 422 HQ and 4444 is an entirely different chroma structure. If they cannot answer, suggest ProRes 422 HQ for master delivery and H.264 at 50+ Mbps for review.

2. Resolution. "4K" means 3840x2160 to broadcasters and 4096x2160 to cinema people. Those 256 missing pixels will cause a DCP build to fail. Pixel aspect ratio matters too: square pixels (1:1) for HD and UHD, or something else if the project is anamorphic.

3. Frame rate. 23.976 fps and 24.000 fps are different frame rates. The 0.1% difference causes audio drift over the length of a feature. In NTSC territories, "24p" almost always means 23.976. In cinema (DCI), 24 means 24.000. The same ambiguity exists between 29.97 and 30, between 59.94 and 60. Never round the frame rate.

4. Colour space. Three components must all be specified: primaries (BT.709, BT.2020, DCI-P3), transfer function (BT.1886, PQ, HLG), and colour range (legal or full). A file encoded in BT.2020 PQ played back on a system expecting BT.709 will look desaturated and flat. A file tagged as legal range but encoded as full range will have crushed blacks and clipped highlights. These are exactly the kind of metadata fields nobody checks until delivery day.

5. Transfer function. Often bundled with colour space, but it is a separate parameter. A file graded for a 2.4 gamma display (BT.1886) will look different on a system expecting PQ (ST 2084) for HDR. SDR and HDR are not flavours of the same thing. They require different mastering, different monitoring, and different metadata. If nobody specifies, Rec. 709 with BT.1886 transfer is the safest assumption for broadcast, and sRGB for web.

6. Audio layout. A 5.1 mix delivered as six discrete mono tracks is not the same as a single 6-channel interleaved track. The receiving system may interpret discrete mono tracks as six separate stereo pairs. Channel order matters: SMPTE order for surround is L, R, C, LFE, Ls, Rs. Beyond the mix format, the delivery spec needs to state which channels carry what. A common broadcast layout puts the stereo programme mix on channels 1-2, music and effects on 3-4, dialogue stem on 5-6, and descriptive audio on 7-8.

7. Sample rate and bit depth. 24-bit, 48 kHz PCM is standard for professional video delivery. The spec needs to say so explicitly, because 16-bit audio still exists, 96 kHz recording sessions exist, and 48.048 kHz pulldown workflows exist.

8. Container. ProRes belongs in a QuickTime MOV container. ProRes in an MP4 container is technically possible (FFmpeg can do it) but practically broken. Many players and NLEs will not open it. .mxf for broadcast and Avid workflows. .mp4 for web distribution. Match the container to the destination, not to preference.

9. Timecode. Start timecode matters: 01:00:00:00 is the most common broadcast convention, but some deliverables require 10:00:00:00 or a specific programme-start time. For 29.97 and 59.94 fps content, the spec must state drop-frame or non-drop-frame. Drop-frame timecode skips frame numbers (not actual frames) at specific intervals to keep the display synchronised with wall-clock time. Non-drop-frame counts sequentially. Most US broadcast requires drop-frame. Most film post uses non-drop-frame. If the start TC is wrong, every edit note, subtitle cue, and QC report references the wrong frames.

10. Naming convention. Automated ingest systems parse filenames to route content. A file named final_v2_FINAL_really_final.mov will fail ingest at any facility with automation. The naming convention typically requires structured fields: programme title, season, episode, codec, frame rate, audio configuration, version, date. No spaces, no special characters, maximum length. Ask before rendering.

Five ways files get rejected

These are composites of real failures. Every one of them involved a file that was technically a valid ProRes.

Wrong colour space tagging. A production delivered ProRes 422 HQ graded in DaVinci Resolve with BT.2020 primaries, but the export settings tagged the file as BT.709. The broadcaster's QC system flagged the colourimetry as out-of-spec because the pixel values exceeded the legal BT.709 gamut. Entire programme rejected. Turnaround: 48 hours.

Wrong frame rate entirely. A facility delivered a 23.976 fps programme when the broadcaster required 29.97 fps for playout. Not a re-wrap. A standards conversion. Turnaround: one week.

Swapped audio channels. A post house delivered eight channels of audio with the M&E and dialogue stems swapped. The broadcaster's automated playout pulled the wrong channels for their international feed. Caught in QC only because someone listened.

Missing bars and tone. A streaming platform's automated QC rejected a delivery because the file started at frame 1 of programme content. The spec required 60 seconds of bars and 30 seconds of black before programme start. The content itself was technically flawless. The rejection was procedural but non-negotiable.

Resolution rounding. A production delivered 3840x2160 (UHD) when the spec called for 4096x2160 (DCI 4K). Two numbers that both get called "4K." The DCP build failed. Re-render the entire programme.

Delivery specification template

Every field below has caused a rejection at some point. Fill them all in. Share the completed spec before the edit starts, not after the render finishes.

DELIVERY SPECIFICATION
======================

Programme: [Title]
Episode:   [S01E01]
Version:   [TX / Textless / Trailer]

VIDEO
-----
Codec:              Apple ProRes 422 HQ
Container:          QuickTime (.mov)
Resolution:         1920x1080
Frame Rate:         25 fps (progressive)
Pixel Aspect Ratio: 1:1 (square)
Colour Primaries:   ITU-R BT.709
Transfer Function:  BT.1886 (2.4 gamma)
Colour Range:       Legal (64-940 10-bit)

AUDIO
-----
Codec:        Linear PCM (uncompressed)
Sample Rate:  48 kHz
Bit Depth:    24-bit
Layout:
  Ch 1-2:     Stereo Programme Mix
  Ch 3-4:     Music & Effects (M&E)
  Ch 5-6:     Dialogue Stem
  Ch 7-8:     Commentary / Descriptive Audio
Loudness:     -24 LUFS (EBU R128)

TIMECODE
--------
Start TC:     01:00:00:00
Frame Rate:   25 fps
Format:       Non-drop-frame (N/A for 25 fps)

STRUCTURE
---------
00:58:00:00 - 00:59:00:00   Colour Bars + Tone (-18 dBFS)
00:59:00:00 - 00:59:50:00   Black
00:59:50:00 - 01:00:00:00   Slate / Countdown
01:00:00:00                  Programme Start
[Programme End]              2 seconds black

FILE NAMING
-----------
Format:  [Title]_[Episode]_[Version]_[Codec]_[Date].mov
Example: TheShow_S01E01_TX_ProResHQ_20260315.mov

Adapt the specifics to the project. The point is not that every delivery uses these exact values. The point is that every delivery needs values in every field. Next time someone says "just send me a ProRes," send them a version of this template with blanks and ask them to fill it in. It takes five minutes. A re-delivery takes two days if lucky and a week if not.

The five minutes it takes to confirm these details will save the five hours it takes to re-render and re-upload when the spec was wrong. And if the answer is truly "I don't care, just send me something," go with ProRes 422 HQ in a .mov, Rec. 709, with a stereo mix on tracks 1-2. That is the safe default. It is what "just send me a ProRes" almost always means.

The QuickTime gamma problem

Mon, 03 Nov 2025 00:00:00 GMT

The symptom

A colourist grades a file on a calibrated reference monitor. Exports it. The client opens it in QuickTime Player on a Mac. The blacks are lifted, the contrast is flattened, the midtones are washed out. The same file on Windows looks correct.

This was not a codec issue, a bit depth issue, or an export setting gone wrong. It was a gamma interpretation disagreement between Apple's colour management pipeline and every broadcast standard in existence. It persisted for roughly twenty years.

The mechanism

Video files carry colour metadata. In QuickTime and MP4 containers, this lives in the colr atom as NCLC (nonconstant luminance coding) tags: three 16-bit integers for colour primaries, transfer characteristics, and matrix coefficients. A file tagged 1-1-1 declares BT.709 for all three, the standard encoding for HD video since 1990.

When QuickTime Player on macOS encountered a 1-1-1 file, it handed the metadata to ColorSync, Apple's system-level colour management framework. ColorSync performed a transform from the file's declared colour space to the display's ICC profile. This is correct colour management. The problem was inside the transform.

Apple's pipeline applied an effective display gamma of approximately 1.96 to BT.709 content. The broadcast standard for BT.709 displays is a gamma of 2.4, formalised as ITU-R BT.1886. The sRGB standard on most Windows monitors specified an effective gamma of 2.2. Apple's 1.96 was lower than both.

Lower gamma means lifted midtones. Brighter, flatter, less contrasty. Every colour-managed application on macOS went through this same pipeline: QuickTime Player, Preview, Safari, Chrome, Quick Look. All exhibited the same washed-out result.

On Windows, the same file played with the expected contrast. Not because Windows had better colour management, but because it had effectively none. Windows video applications sent pixel values straight to the display without a transform. On a monitor with native gamma near 2.2, this produced a result close to the broadcast standard. Correct by accident.

Where 1.96 came from

In 1993, Apple shipped ColorSync with a system gamma of 1.8. This was not arbitrary. Early Mac CRTs, built for desktop publishing, had a measurably different phosphor response from consumer televisions. The 1.8 figure reflected actual hardware and was convenient for prepress, where a lighter gamma better predicted print output.

The rest of the industry used 2.2.

When Apple transitioned to wider-gamut displays and a more sophisticated colour pipeline in the mid-2000s, the effective gamma for video content shifted to approximately 1.96. This sat between the legacy Mac gamma (1.8) and the sRGB standard (2.2). It was a deliberate backward-compatibility compromise, maintaining visual consistency for existing Mac users while inching toward the industry norm. The result matched neither Mac convention, nor broadcast convention, nor sRGB.

The broadcast world did not care about Apple's transition. A reference monitor displays gamma 2.4. That is the standard. An operating system that intercepts the signal and applies 1.96 instead is, from the perspective of anyone delivering broadcast content, producing an incorrect image.

Workarounds

The post-production industry developed a set of workarounds, none of them satisfying.

Some encoders wrote a transfer_characteristics value of 2 ("unspecified") instead of 1, producing NCLC tags of 1-2-1. This caused ColorSync to skip its gamma interpretation. It was also technically incorrect: the encoder was lying about the file's colour space to avoid a correct-but-unwanted transform.

DaVinci Resolve introduced a "Rec 709-A" gamma tag option specifically for this problem. A professional colour grading application needed a special export setting to work around operating system behaviour. That alone tells you how entrenched the issue was.

The BBC published qtff-parameter-editor, an open-source tool whose entire purpose was to rewrite three integers in a file header so that Apple's colour management would stop making the video look wrong.

Why it lasted twenty years

Apple's implementation was not, strictly speaking, a bug. ColorSync read the file's declared colour space, consulted the display's ICC profile, and performed a mathematically correct transform. The transform just used gamma assumptions that differed from the broadcast industry's expectations.

Changing the value would break backward compatibility. Every application relying on ColorSync, every ICC profile tuned for Mac displays, every piece of content authored with Mac gamma in mind. Apple could not change a number in a lookup table without changing the visual appearance of every colour-managed image on every Mac.

There was also a philosophical disagreement. Apple's position: the display profile should determine final appearance. The broadcast industry's position: video content should display with a specific, known gamma regardless of the display hardware. Both defensible. Incompatible.

The partial fix

In 2009, Mac OS X 10.6 Snow Leopard quietly changed the default system display gamma from 1.8 to 2.2. Apple did not emphasise this in the release notes. It was the most significant colour management change Apple had ever made.

But system display gamma and video playback gamma are different things, managed by different parts of the pipeline. The 2.2 shift brought still images and the desktop closer to the rest of the world. Video playback remained at approximately 1.96 for years afterward. It took further macOS updates, the transition to P3 displays, and a new generation of colour management APIs before the situation improved meaningfully.

Even today, QuickTime Player on macOS does not produce an image identical to a BT.1886 reference monitor. The gap is smaller than it was in 2008. It has not fully closed.

Practical implications

Files tagged with original 1-1-1 NCLC values still exist in archives, on hard drives, on YouTube, on client review platforms. Any file encoded between roughly 2001 and 2015 and tagged with standard BT.709 metadata falls in the gamma-ambiguous era. The metadata is correct. The file is correct. The playback result depends on which platform interprets it.

For tools handling these files today:

Do not assume QuickTime Player is a reference. It never was, and the gamma gap has not fully closed. Validate against a calibrated monitor or a player with explicit BT.1886 support.
Preserve NCLC tags. The 1-2-1 workaround was necessary in its time, but stripping transfer characteristics from files makes the ambiguity permanent. Correct tags with correct playback is better than no tags with unpredictable playback.
Flag gamma-era files. Any workflow ingesting archival content should identify files from this period and surface the potential for gamma misinterpretation. The file is not wrong. The metadata is not wrong. But the rendered result may not match the original creative intent.

The QuickTime gamma problem was not a bug. It was two correct systems, built on different assumptions about what a display should do, looking at the same numbers and seeing different images.

References

Charles Poynton, "sde, vui, nclc, nclx." poynton.ca
ITU-R BT.709-6. Parameter values for the HDTV standards for production and international programme exchange.
ITU-R BT.1886 (2011). Reference electro-optical transfer function for flat panel displays used in HDTV studio production.
IEC 61966-2-1:1999. Default RGB colour space, sRGB.
Todd Dominey, "Why Are Videos Washed Out on the Mac? Exploring QuickTime Gamma Shift" (2021). blog.dominey.photography
CineD, "Quicktime Gamma Shift Bug: What Is It and How to Combat It" (2024). cined.com
BBC qtff-parameter-editor. github.com/bbc/qtff-parameter-editor
Apple Developer Documentation, "Tagging media with video color information." developer.apple.com
Academy Software Foundation, Encoding Guidelines: Web Color Preservation. github.com/AcademySoftwareFoundation

How an 80-bit audio signal encodes time

Mon, 08 Sep 2025 00:00:00 GMT

Most people think of timecode as a number. 01:04:23:12. Hours, minutes, seconds, frames. Parse the string, do some arithmetic, move on.

But LTC (Linear Timecode) is not a string. It is an audio signal, a square wave recorded on tape or transmitted over a cable, encoding 80 bits of data per frame using a modulation scheme borrowed from telecommunications. Decoding it while a tape machine shuttles backwards at 30x play speed is a fundamentally different problem than parsing four numbers separated by colons.

Biphase mark encoding

LTC uses biphase mark coding to turn binary data into an analogue audio signal. The scheme has two rules:

Every bit period starts with a transition. High goes low, or low goes high. This transition is the clock edge.
A binary 1 gets a second transition at the midpoint of the bit period. A binary 0 does not.

A stream of all 1s produces the highest frequency: transitions at every half-bit period. A stream of all 0s produces the lowest frequency: transitions only at bit boundaries, half the rate.

At 30 fps with 80 bits per frame, the bit rate is 2,400 bits per second. All-ones gives a 2,400 Hz signal. All-zeros gives 1,200 Hz. Real timecode data produces a mix of frequencies between these two. For 25 fps (PAL/EBU), the range is 1,000 to 2,000 Hz. For 24 fps, 960 to 1,920 Hz.

These frequencies sit comfortably in the middle of the audio band. This was deliberate. It means LTC can be recorded on any audio track, transmitted over any audio cable, and processed by any audio amplifier without modification. No special hardware, just sound.

Two properties make biphase mark coding the right choice for this job. First, it is self-clocking. The receiver extracts the bit clock directly from the signal transitions, so tape speed variations do not require a separate clock reference. Second, it is direction-independent. The encoding can be decoded regardless of whether the tape is moving forwards or backwards.

Interactive figure: Waveform view of biphase mark encoding for LTC.

The 80-bit frame

Each LTC frame is exactly 80 bits long. The bits are transmitted least significant bit first and are organized into four categories: time data, user bits, flag bits, and a sync word.

Time data (26 bits). The time of day is stored in BCD (binary-coded decimal), split across the frame in four fields: frame number (0 to 29), seconds (0 to 59), minutes (0 to 59), hours (0 to 23). Each field is broken into a units nibble and a tens portion, interleaved with other data throughout the frame.

Bits	Field
0-3	Frame units (BCD, 0-9)
8-9	Frame tens (BCD, 0-2)
16-19	Seconds units (BCD, 0-9)
24-26	Seconds tens (BCD, 0-5)
32-35	Minutes units (BCD, 0-9)
40-42	Minutes tens (BCD, 0-5)
48-51	Hours units (BCD, 0-9)
56-57	Hours tens (BCD, 0-2)

User bits (32 bits). Eight groups of four bits each, interleaved between the time fields (bits 4-7, 12-15, 20-23, 28-31, 36-39, 44-47, 52-55, 60-63). These carry arbitrary data. Common uses include reel number, date, and scene/take identification. Two binary group flag bits (43 and 58) tell the receiver how to interpret them.

Flag bits. Bit 10 is the drop-frame flag: set to 1 when using 29.97 fps with frame-number skipping. Bit 11 is the colour frame flag, used to identify the relationship between timecode and the NTSC or PAL colour frame sequence. Bit 27 is the biphase correction bit, a parity bit set so that each complete frame contains an even number of transitions. This guarantees that every frame starts with the same polarity, which simplifies decoder design.

Sync word (bits 64-79). The fixed 16-bit pattern 0011 1111 1111 1101. This pattern serves three purposes. It marks frame boundaries, allowing the decoder to find the start of each frame in a continuous stream. It is unique, meaning no valid combination of timecode data can accidentally produce the same bit sequence. And it is asymmetric: read forwards, the pattern is 0011111111111101; read backwards, it becomes 1011111111111100. This asymmetry tells the decoder which direction the tape is moving.

Interactive figure: Map of the 80-bit LTC frame and what each field means.

Recording on tape

LTC is recorded as audio, typically on the highest-numbered track of a multitrack tape machine. The recommended level is roughly -10 dBu, about 10 dB below nominal operating level.

This level is a compromise. Too hot and harmonic distortion adds spurious transitions that corrupt the biphase encoding. Hot timecode also bleeds into adjacent audio tracks through crosstalk. Too quiet and noise and tape dropouts cause decode errors. The -10 dBu sweet spot provides enough signal-to-noise ratio for reliable decoding while keeping crosstalk manageable.

An empty guard track is kept between the timecode track and the nearest audio track. On a 24-track machine, timecode goes on track 24, track 23 stays empty. This was not optional. LTC sits between 1,200 and 2,400 Hz, a frequency range where crosstalk into dialogue or music is extremely audible and effectively impossible to remove in post.

Professional videotape recorders solved this differently. They had a dedicated longitudinal address track, physically separate from the audio heads, with its own level and alignment optimized for timecode.

Crystal drift

Every timecode generator runs on a crystal oscillator, and every crystal drifts. The amount of drift determines how long two devices will stay in sync after being jam-synced at the start of a shoot.

Crystal accuracy is measured in parts per million. Converting ppm to real-world timing at 30 fps:

Oscillator	Accuracy	Daily drift	Frames per 24 hours
Standard quartz (XO)	±20-50 ppm	±1.7-4.3 s	±51-130
Temp-compensated (TCXO)	±0.5-5 ppm	±0.04-0.43 s	±1.3-13
Oven-controlled (OCXO)	±0.01 ppm	±0.0009 s	~0.03

A standard quartz oscillator at 20 ppm accumulates about 1.7 seconds of drift per day. That is 51 frames at 30 fps. A single frame of drift (33 ms) is enough to create visible lip-sync error.

Professional timecode generators from Ambient and Denecke use TCXOs, achieving less than one frame of drift per 24-hour shooting day. Cheap cameras use standard quartz, where several frames of drift per hour is common.

Crystal frequency is also temperature-dependent. Quartz follows a characteristic frequency-temperature curve (an inverted parabola for AT-cut crystals) that can shift by 10 to 20 ppm across the operating temperature range. Moving equipment between air-conditioned interiors and a hot exterior can produce step changes in drift rate. TCXO designs measure the crystal temperature and apply a correction factor, which is why professional generators specify their accuracy across a temperature range like ±0.5 ppm from -20 C to +60 C.

What happens at speed

Because LTC is a frequency-modulated signal, changes in tape speed directly change the signal frequency. A 2x shuttle doubles all frequencies. A 30x rewind shifts a 1,200-2,400 Hz signal to 36,000-72,000 Hz.

Biphase mark encoding tolerates this well because the decoder does not look for a fixed frequency. It looks for transitions. But extreme speeds push the signal outside the passband of the decoder's input electronics. At very high forward speeds, the transitions come too fast for the comparators to track. In reverse, the same problem applies, compounded by the mechanical challenge of reading a tape moving in the wrong direction past a playback head.

Most professional LTC decoders track speeds from about 1/30x to 60x nominal play speed. Within that range, the self-clocking property of biphase mark encoding handles speed variations automatically. The decoder extracts timing from the transitions themselves, not from an assumed clock rate.

Reverse playback works because of the asymmetric sync word. The decoder recognizes the backwards pattern, knows the tape direction, and reverses its bit ordering. The time data still reads correctly. The biphase correction bit (bit 27) was calculated for forward playback, so some decoder implementations handle it differently in reverse, but the time values remain valid.

Dropouts and flywheel

Tape-based LTC is vulnerable to physical damage. A scratch or coating defect spanning a few millimetres of tape can destroy enough signal to make one or more frames undecodable.

Professional decoders handle this with flywheel algorithms. When the decoder loses the signal, it continues counting frames based on the last known good timecode value, extrapolating forward (or backward) at the detected play speed. If the dropout is short (a frame or two), the flywheel bridges the gap invisibly. If the dropout is longer, the flywheel accumulates error and the decoder must wait for a valid sync word to re-establish position.

Electrical interference is the other common failure mode. LTC occupies the same frequency range as audio content, so it picks up mains hum harmonics, RF interference, and cable crosstalk. Professional practice routes timecode cables separately from audio cables and uses balanced connections for common-mode rejection.

Jam-sync

Jam-sync is how timecode generators on different devices get aligned. A master generator provides a reference signal. Slave devices read the incoming LTC, set their internal counters to match, and then disconnect and free-run on their own crystal oscillators.

This is the critical detail that non-specialists miss. Jam-sync sets a starting value. It does not create an ongoing lock. From the moment the cable is unplugged, each device's accuracy depends entirely on its own crystal. Two cameras jammed at call time will start in perfect agreement and diverge from there, frame by frame, at a rate determined by the quality of their oscillators.

Professional practice for re-jamming:

Start of each shooting day. Non-negotiable.
After any power cycle. Turning a camera off typically resets its counter.
At lunch or major breaks. Every 4 to 6 hours compensates for drift on cameras with standard oscillators.
After frame rate changes. Switching between 23.976 and 29.97 for slow-motion work disrupts the timecode relationship.

The most common jam-sync failure is staleness. Cameras jammed at 7 AM are still shooting at 3 PM without a re-jam. Eight hours at 20 ppm produces about 0.6 seconds of drift: 17 or more frames. That is not a nuisance. It is a multi-camera sync failure.

Some devices offer continuous jam (or jam-lock), where the slave constantly follows the incoming timecode. This eliminates drift but introduces a different risk: if the incoming signal has dropouts or glitches, the slave's counter glitches too. Most production sound mixers prefer one-shot jam with periodic re-jamming for this reason.

Why it matters

LTC was designed in the 1960s for a world of analogue tape machines, and it works the way analogue signals work. It is not a data format that happens to be carried on audio. It is an audio signal that happens to encode data. The encoding, the signal level, the guard tracks, the crystal tolerances, the flywheel algorithms: these are all properties of the signal, not the number. Understanding LTC means understanding the signal.

References

SMPTE ST 12-1:2014, "Time and Control Code"
Phil Rees, SMPTE/EBU Timecode
Wikipedia, Linear timecode
Telestream, The Use of Time Code within a Broadcast Facility
Bodet Time, Comparative analysis of oscillators: MEMS vs TCXO vs OCXO vs Rubidium
Frame.io, Timecode and Frame Rates
Alister Chapman, Notes on Timecode and Timecode Sync for Cinematographers
libltc project, ltc.h File Reference

WaveAgent and the beta that never ended

Mon, 08 Sep 2025 00:00:00 GMT

If you've mixed production sound on any professional shoot in the last fifteen years, you've used WaveAgent. Or you've been told to use WaveAgent. Or you've downloaded WaveAgent, opened it once, squinted at the interface, and gone back to doing things the hard way. It occupies a peculiar place in the production sound ecosystem: universally known, genuinely useful, and permanently unfinished.

The title bar still says "Beta."

It said "Beta" in 2008. It says "Beta" now. The version number never climbed past 1.20. The official documentation carries a note that reads, "Features and specifications will change." They did change, a few times, over a few years. Then they stopped changing. The note stayed.

This is a story about a tool that did its job well, and about the specific kind of quiet failure that happens when a free utility from a hardware company meets a decade of format evolution. It's not a tragedy. It's barely even a complaint. But if you've been in production sound long enough, you've felt the gap that WaveAgent left when it stopped keeping up.

What it was built for

Sound Devices announced WaveAgent at NAB 2008 as a free companion utility for their 7-Series digital recorders: the 702, 702T, 722, 744T, and the newly released 788T. It was positioned as a "WAV file librarian," and that term was more precise than it sounded. A librarian organises, catalogues, and retrieves. That's exactly what WaveAgent did.

You could drag a folder of polyphonic Broadcast Wave files onto WaveAgent and immediately see everything a production sound mixer cares about. Timecode. Sample rate. Bit depth. Channel count. Scene and take numbers. Track names. The bext chunk. The iXML metadata that production recorders write alongside the audio. All of it, laid out in a clean list with a waveform display for visual confirmation.

Beyond inspection, WaveAgent could split poly files into mono, combine mono files into poly, batch-rename files using metadata templates, and generate PDF sound reports. That last feature was the one mixers used most. At the end of a shoot day, you could produce a printed report of every file, every take, every channel, every timecode value. Hand it to the assistant editor with the drives. Done.

The 788T even had a dedicated "Wave Agent Control Mode" that let you plug the recorder into your laptop via USB and edit metadata directly on the device. Sound Devices understood the workflow from cart to cutting room. WaveAgent was the bridge.

The honest label

Here's the thing about the beta designation: it was honest. Sound Devices never pretended WaveAgent was a supported product. The product page still describes it as "free, unsupported software." That's not a disclaimer buried in the EULA. It's the second thing you read after the product name.

In practice, "unsupported" meant something specific. It meant no guaranteed update cadence. No bug-fix SLA. No promise that the next macOS release wouldn't break it. No commitment to supporting new file formats, even the file formats that Sound Devices' own recorders would start producing a few years later.

The production sound community heard "free" and "beta" and interpreted it as "works fine, just hasn't had the label updated." That interpretation was correct for about six years. Then the assumptions baked into the software started colliding with the reality outside it.

Version 1.20 and the long silence

The last real update shipped in July 2014. Version 1.20 added support for 32-track files and updated compatibility for Mac OS 10.9 and Windows 8.1. At the time, 32 tracks was generous. The 788T recorded 12 tracks. Most production work used 4 to 8 channels. Thirty-two was headroom.

After 1.20, nothing. No 1.21. No 2.0. No announcement, no sunset notice, no blog post explaining the decision. WaveAgent just stopped receiving updates. The download page stayed up. The installation files stayed available. Sound Devices kept linking to it from their support articles. But the software itself entered a kind of stasis, frozen at the assumptions of 2014.

2014 was a different world for production sound. Recorders used 16-bit and 24-bit integer encoding. Channel counts were modest. The iXML specification was stable. macOS was on Mavericks. WaveAgent's model of what a production BWF file looked like was still accurate.

It wouldn't be for long.

The world moved

Three things happened, roughly in sequence, and none of them were WaveAgent's fault.

32-bit float arrived. Sound Devices themselves led this charge. The MixPre II series, released around 2017, introduced 32-bit float recording to the prosumer and professional production sound market. The 8-Series recorders (888 and Scorpio) followed. Thirty-two-bit float changes the fundamental contract of recording: there is no clipping in the traditional sense, gain staging becomes a post-production decision, and the file format uses IEEE 754 floating-point representation instead of PCM integer encoding. WaveAgent was built around integer audio. It does not support 32-bit float files. Not partially. Not with degraded display. It simply cannot open them. Sound Devices' own recorders now produce files that Sound Devices' own utility cannot read.

Channel counts grew. The Scorpio records 32 channels across 36 tracks. The 888 handles 16 channels and 20 tracks. Modern productions routinely use layouts that would have been exotic in 2014: multiple booms, a dozen wireless lavalieres, plant mics, ambience rigs, safety tracks, multiple mix buses. WaveAgent's 32-track ceiling, generous a decade ago, is now a constraint. And beyond raw track count, the complexity of iXML metadata has evolved to cover Ambisonics channel ordering, surround configurations, and loudness measurements that WaveAgent's parser doesn't understand.

macOS broke the binary. In 2019, macOS Catalina dropped support for 32-bit applications. WaveAgent was a 32-bit app. Overnight, every Mac user who upgraded lost access to the tool. Sound Devices responded not with a recompile, but with a support article: "Installing Wave Agent on Mac OS Catalina and Big Sur." Similar guides followed for Monterey, Ventura, Sonoma, Sequoia, and Apple Silicon. Each one described workarounds. None of them described a new build. The application binary from 2014 persists, propped up by Gatekeeper exceptions and Rosetta 2 translation, each macOS cycle adding another layer of fragility.

The specific irony

It's worth sitting with the 32-bit float problem for a moment, because it's not just a compatibility gap. It's Sound Devices competing with themselves.

When Sound Devices introduced 32-bit float recording, they marketed it extensively. Their website has explainers, FAQ pages, sample files, and technical white papers about 32-bit float. It's a genuine innovation that changed production sound practice. Mixers no longer need to ride gain as aggressively. The safety margin is effectively infinite. It's good technology.

But WaveAgent, the tool Sound Devices built to help mixers manage files from Sound Devices recorders, cannot read the files that Sound Devices recorders now produce by default. The mixer who buys a Scorpio, records a full day in 32-bit float, and then sits down with WaveAgent to verify metadata and generate sound reports will discover that the tool cannot open any of their files.

This isn't an obscure edge case. This is the primary use case, on the primary recording format, from the same manufacturer.

What people do instead

The honest answer is workarounds, and the workarounds are fine individually but collectively they represent a workflow that nobody designed.

BWF MetaEdit, funded by the Library of Congress and maintained by MediaArea, is excellent for metadata inspection and editing. It understands bext chunks, iXML, and newer extensions. It's actively maintained and cross-platform. But it's built for archivists, and the interface reflects that heritage. It doesn't do poly splitting or audio playback. It doesn't generate sound reports.

Reaper can explode a polyphonic WAV into separate tracks. Pro Tools can import poly BWF files and display channel metadata. But opening a 24-channel poly BWF in a DAW just to read its metadata is a category error. You're launching a recording studio to do the work of a librarian.

MediaInfo gives you a quick technical summary. Python scripts using the soundfile library handle batch operations. Some mixers have written custom tools that do exactly what they need and nothing else. The fragmentation is functional but inelegant, and it means that a task WaveAgent handled in one window now requires three or four different tools depending on what you're trying to learn about the file.

The production sound community on JWSoundGroup has been having the same conversation for years: what replaces WaveAgent? The thread titles tell the story. "Wave Agent alternative for MacOS." "Wave Agent ?" "Installing Wave Agent on Mac OS Ventura." Each one is a small expression of the same larger gap.

Hardware companies and their utilities

WaveAgent's trajectory follows a pattern familiar to anyone who's watched professional media tools over the past decade. A hardware manufacturer builds a free utility to support their product. The utility is good. People depend on it. But utilities don't generate revenue. They're a cost centre, justified by hardware sales, maintained as long as someone at the company champions them.

Sound Devices is a hardware company in Reedsburg, Wisconsin. They make exceptional recorders. Their firmware updates are regular and substantial: the 8-Series gets meaningful new features with each release. That's where the engineering attention goes, and it should. Firmware makes the hardware more capable. A companion desktop utility, however useful, doesn't sell recorders.

The CL-WiFi tells the same story in miniature. It was a WiFi adapter for the 788T with an iOS companion app for remote metadata entry. Sound Devices discontinued support in October 2015. The iOS app stopped working after iOS 10. When Bluetooth became the preferred wireless protocol, they built the Wingman app for the MixPre and 8-Series. The old tool died. The new tool served the new hardware.

WaveAgent didn't even get a clean ending. It just stopped receiving updates, one macOS version at a time, one file format at a time, until the gap between what it understood and what the world required became too wide for affection to bridge.

The gap

What makes WaveAgent's absence felt isn't any single feature. It's the combination. Metadata inspection plus poly splitting plus audio playback plus sound reports plus batch renaming, all in one window, all designed by people who understood what a production sound mixer needs to see at the end of a twelve-hour day. No single alternative replicates that combination. The gap isn't empty. It's full of fragments. And fragments, however capable, are friction.

If you recorded 24-bit integer audio on a 788T in 2012, WaveAgent is still the best tool for the job. If you recorded 32-bit float on a Scorpio this morning, WaveAgent cannot help you at all. The tool didn't break. The industry outgrew it. And the container format assumptions it was built on are now a decade out of date.

The beta label, in hindsight, was the most honest thing about it. Sound Devices told us from the beginning that this was unfinished software. We just didn't expect "unfinished" to become the permanent state.

Five timecode disasters and what they teach you

Mon, 25 Aug 2025 00:00:00 GMT

Timecode failures don't announce themselves. They start quiet. Everything looks fine on set. The jam-sync reads back correctly. The cameras are rolling, the sound recorder is rolling, and the little numbers on every device match. Then the footage arrives in post, and the editor discovers that nothing lines up.

The cost is always the same: post-production hours. The most expensive hours on any production, spent on work that should have been unnecessary.

Here are five ways it goes wrong.

1. Mixed drop-frame and non-drop-frame on multicam

Three cameras are covering a live event. Two are set to drop-frame timecode at 29.97 fps. The third, rented from a different house and prepped by a different crew, is running non-drop-frame at the same frame rate. All three cameras jam-sync to the same master clock at call time. The timecode values match. Everyone confirms sync. Shooting begins.

For the first 59 seconds, there is no problem. All three cameras produce identical timecode values. The divergence begins at the one-minute mark. Cameras 1 and 2, running drop-frame, skip frame numbers 00 and 01 at the start of minute one. Their count jumps from 00:00:59:29 to 00:01:00;02. Camera 3, running non-drop-frame, counts straight through: 00:00:59:29 to 00:01:00:00.

Camera 3 is now two frame numbers behind the other two cameras. The actual video frames are still in real-time sync because all three cameras are running at the same 29.97 fps rate from the same jam point. But the labels on those frames disagree.

The error compounds at every minute boundary except the tenth minutes. By the ten-minute mark, camera 3 is 18 frame numbers behind. By one hour, the gap is 108 frame numbers. That is 3.6 seconds of timecode discrepancy on footage that is, in reality, perfectly synchronous.

When the editor imports all three angles and syncs by timecode, the NLE finds frames with matching timecode values that are actually 2 to 108 frames apart in real time, depending on how far into the shoot they fall. Cuts between camera 1 and camera 3 produce visible jumps. Lip-sync drifts progressively. And the error is non-linear, because it accumulates at minute boundaries and pauses at every tenth minute. Manual correction is not just tedious; it requires a per-minute offset table.

The only reliable recovery is audio waveform sync. The timecode from the non-drop camera is useless for multi-camera alignment against the drop-frame cameras. The entire timecode workflow for that camera is discarded, and the sync is rebuilt from scratch using the audio.

The lesson is verification, not trust. Every device on the shoot must be confirmed to the same DF/NDF mode during jam-sync. The frame rate can match and the timecode can read identically and the counting mode can still be wrong. It only takes one camera.

2. Free-run versus record-run confusion

A documentary shoot. Two cameras and a separate sound recorder. The sound mixer sets up a master timecode generator and jam-syncs the recorder in free-run mode, so timecode runs continuously and reflects time of day. The A camera is also free-run and jam-synced.

The B camera operator, less familiar with the timecode workflow, has their camera set to record-run. In this mode, timecode only advances while the camera is recording. It starts from wherever it was last set, which might be 00:00:00:00, or might be 01:47:32:08 from the last clip of a previous shoot.

The B camera's timecode now bears no relationship to the timecode on the A camera or the sound recorder. The sound recorder says 14:23:45:12 for a given moment. The B camera says 01:47:32:08 for the same moment. There is no offset that can reconcile them, because the B camera's timecode only ticks when it is recording. Every time the operator stops and starts the camera, the relationship between the B camera's timecode and real-world time changes.

It gets worse. If the B camera is power-cycled or the recording is stopped and restarted from a reset state, record-run timecode can produce duplicate values. Two completely different moments in time labelled with the same timecode. This breaks not just sync but the fundamental assumption that timecode is unique within a given source.

The post-production impact is total for the B camera. Multi-camera sync by timecode is impossible. Sound sync by timecode is impossible. Everything from the B camera must be re-synced by audio waveform or by visual cues like clappers.

There is a subtler variant worth knowing. Even when all devices are set to free-run, confusion arises if some are set to "free-run preset" (timecode starts at a manually entered value and then runs from there) while others are set to "free-run time-of-day" (timecode follows the device's internal clock). If the preset value does not match time of day at the moment of jam, there will be a constant offset between devices. It is correctable, but only if someone documents it.

3. Crystal drift over a 12-hour shoot day

A documentary crew calls at 7 AM. Two cameras and a sound recorder jam-sync at call time. The shoot runs until 7 PM. Twelve hours, run-and-gun style. There are no breaks long enough for a re-jam, or the crew simply forgets.

The cameras use standard quartz crystal oscillators, typical of mid-range cinema cameras. A standard quartz oscillator with 20 parts-per-million accuracy drifts by approximately 0.07 seconds per hour, roughly 2 frames at 30 fps.

Over 12 hours, a single device can drift approximately 0.86 seconds from its jam point. That is 26 frames. But the number that matters is not the absolute drift of any one device. It is the relative drift between two devices, which depends on the difference in their crystal frequencies. If two cameras drift in opposite directions, the worst case is double: 1.7 seconds, or 51 frames.

In realistic conditions, with cameras at different temperatures (one shooting exteriors in the sun, one in a cool interior), a relative drift of 5 to 10 frames over 12 hours is common. At 30 fps, 5 frames is 167 milliseconds. That is clearly visible lip-sync error. Audiences notice sync problems above about 45 milliseconds.

The failure mode is insidious because it is gradual. Early footage from the morning syncs perfectly. It was just jam-synced. By mid-afternoon, dialogue is noticeably out of sync with picture. By late afternoon, it is worse. The drift is approximately linear, which means it is theoretically correctable with a time-stretch applied per clip. But detecting the drift rate, calculating the correction, and applying it to every clip in the timeline is hours of forensic work that nobody budgeted for.

The mitigation is well-established. Re-jam at every break. The industry standard is at least twice per day: once at lunch, once at any other extended pause. Better still, use temperature-compensated crystal oscillators (TCXOs), which are standard in dedicated timecode generators like the Tentacle Sync E or Ambient ACN-CL. These devices drift less than 1 frame per 24 hours. A few hundred dollars per unit eliminates the crystal drift problem entirely.

4. Wrong start-of-day timecode and midnight rollover

A broadcast production sets the master timecode generator to 01:00:00:00, which is a common convention. The hour of headroom below the programme start provides space for pre-roll, bars, and tone. But someone enters 10:00:00:00 instead of 01:00:00:00. Or the generator was not reset from a previous show and still reads 23:58:00:00.

If the master timecode is wrong, every device jam-synced to it inherits the error. All footage is recorded with incorrect time-of-day references. When this footage arrives at the post facility, the timecode values do not match the production logs, the script supervisor's notes, or the sound reports. Any workflow that relies on timecode to correlate picture and sound, or to locate specific takes, is broken at the source.

The midnight rollover variant is more subtle and more destructive. A multi-day shoot uses time-of-day timecode without resetting at midnight. Footage shot at 11:55 PM on day one carries timecode approaching 23:59:59:29. Footage shot five minutes later at 12:05 AM on day two starts at 00:05:00:00. The timecode has wrapped past midnight.

EDLs and conform tools assume timecode is monotonically increasing within a programme. When timecode wraps from 23:59:59:29 to 00:00:00:00, some tools interpret this as a backward jump. Depending on the software, the result is rejected edits, incorrect relinking, or outright crashes. This specific failure was documented often enough in the broadcast engineering literature to become a named pitfall.

The conform failure is where the cost lands. The online editor receives an EDL or AAF referencing timecode values that do not match the source media. Every clip fails to relink. The conform must be done manually, which on a complex programme can take days. The audio post house receives split tracks with timecode that does not match picture. Every take must be synced by waveform or clapper.

If the wrong start timecode happens to overlap with footage from a different reel or day, timecode values become ambiguous. A timecode of 10:23:15:07 could refer to two completely different frames from two different recordings, and no automated tool can resolve the ambiguity.

Prevention is simple in principle: verify the master timecode generator's output before jamming any devices. Use a standardised start-of-day convention and document it. For multi-day shoots, use date-stamped user bits or embed date information in iXML metadata to disambiguate days.

5. LTC bleed into production audio

A production uses LTC (Linear Timecode) fed via audio cable to cameras and recorders. The LTC signal is a modulated audio tone oscillating between 1,200 and 2,400 Hz, and it runs through audio infrastructure alongside production sound.

The bleed can happen in several ways. LTC recorded on a track of the production sound recorder crosstalks into adjacent audio tracks. A timecode generator connected via a splitter cable feeds both a timecode input and an audio input on a camera, with insufficient isolation between channels. An LTC cable runs in the same bundle as microphone cables, inductively coupling the timecode signal into the mic lines. Or a camera with a combined mic/timecode input on a 3.5mm jack gets crosstalk between the timecode and audio channels inside the camera body itself.

The sound of LTC bleed is distinctive and immediately recognizable: a rapid, high-pitched ticking or buzzing, like a data modem compressed into the middle of the frequency spectrum. It is present continuously for the entire duration of recording. It does not come and go. It does not change character. It is relentless.

Here is why it is nearly impossible to fix. The LTC frequency range, 1,200 to 2,400 Hz, sits directly on top of the fundamental frequencies and harmonics of human speech. This is not a coincidence of physics; it is simply that both systems operate in the band where audio equipment performs best. Any filter aggressive enough to remove the timecode signal will also remove or severely damage the dialogue it is overlapping with.

LTC is not a steady-state tone. It is a frequency-modulated signal whose frequency shifts constantly as the encoded data changes. A standard notch filter, which removes a narrow frequency band, cannot track it. You would need an adaptive filter that follows the signal's modulation, and even then the overlap with speech harmonics makes clean separation extremely difficult.

Modern machine-learning noise reduction tools like iZotope RX and Cedar can sometimes reduce the bleed, but rarely eliminate it completely without introducing artifacts. The processing trades one kind of damage for another: less timecode buzz, more metallic or hollow-sounding dialogue.

The prevention is entirely about signal routing. Record LTC on a guard track, with at least one empty track between the timecode track and the nearest production audio track. Keep LTC cable levels at approximately -10 dBu (-20 dBFS), high enough to decode reliably but low enough to minimize crosstalk energy. Never run timecode cables in the same bundle as microphone cables. Use dedicated timecode inputs rather than splitter cables. And where possible, avoid recording LTC on production audio tracks entirely. Modern wireless timecode devices can write timecode directly to camera metadata without passing through the audio path.

The common thread

Every one of these failures shares a root cause. Timecode is a system of assumptions. It assumes all devices agree on the frame rate. It assumes they agree on the counting mode. It assumes all clocks are synchronized. It assumes the starting value is correct. It assumes the signal path is clean.

When any of these assumptions is violated, and in the field, under pressure, with rented equipment and mixed crews, they are violated constantly, the result is not graceful degradation. It is binary failure. The timecode either matches and sync works, or it does not and you are rebuilding from scratch.

The unifying lesson is that timecode problems are verification problems. Every disaster on this list could have been prevented by a check that takes less than thirty seconds: confirm DF/NDF mode, confirm free-run, re-jam at lunch, verify the start value, listen to the audio tracks. The thirty seconds you skip on set become thirty hours in post.

References

Alister Chapman, Notes on Timecode and Timecode Sync for Cinematographers
Frame.io, Timecode and Frame Rates: Everything You Need to Know
Frame.io, Video Post-Production Workflow Guide: Timecode
Tentacle Sync, Sync E specifications
B&H Photo, Timecode versus Sync: How They Differ and Why it Matters
Production Expert, Timecode Part 4: Practical Applications
Production Expert, Why Does Timecode Not Start At Zero?
JW Sound Group, Audio Bleeding: Timecode Systems Ultrasync One Splitter Cable
Tentacle Sync Forum, Audio Bleed on Camera Media
Creative COW, Using timecode, LTC, SMPTE on a film set

Container surgery without a DAW

Mon, 14 Jul 2025 00:00:00 GMT

A sound editor asks you to trim two seconds of silence off the head of a field recording. The file is a 48kHz/24-bit polyphonic BWF, eight channels, 47 minutes long. About 1.3 gigabytes.

The normal approach: open the file in Pro Tools or a similar DAW, select the region, bounce it out. The DAW decodes the entire file into its internal mixing engine, applies the edit, then re-encodes and writes a new file. For a trim operation that removes silence, this involves billions of unnecessary sample conversions. It also takes time, consumes memory, and introduces an encode cycle that, depending on the DAW's export settings, might not even be bit-identical to the original.

There is another way. If you understand the structure of the container, you can do the trim with byte arithmetic. No decoding. No encoding. No quality loss. Just moving a pointer.

The anatomy of a WAV file

A WAV file is a RIFF container. RIFF (Resource Interchange File Format) is one of the simplest container formats ever designed. The entire structure is built from chunks, each following the same pattern:

[4-byte ID] [4-byte size (little-endian)] [payload bytes...]

Every chunk declares what it is and how big it is. A parser can walk through the file by reading 8 bytes, noting the chunk ID and size, then either parsing the payload or skipping ahead by size bytes to reach the next chunk. That's the whole protocol.

A standard WAV file contains at minimum two chunks inside the RIFF envelope:

fmt (note the trailing space, it's a 4-byte ID) describes the audio format. Sample rate, bit depth, channel count, block alignment. This chunk is small, typically 16 or 18 bytes of payload. Everything a decoder needs to know about how to interpret the raw samples.

data contains the actual interleaved PCM samples. In a 47-minute 8-channel 48kHz/24-bit file, this chunk is nearly the entire file. The samples sit there in order, channel by channel within each sample frame, frame after frame. No compression, no indexing, no headers within the data. Just numbers.

A Broadcast Wave Format (BWF) file adds more chunks to this base:

bext carries the broadcast extension metadata defined in EBU Tech 3285. The critical field is time_reference, a 64-bit sample count from midnight that gives the file its position on the timeline. Also holds originator information, origination date and time, UMID, and optionally loudness measurements per EBU R 128.

iXML holds production metadata as XML. Scene, take, tape name, track names, channel assignments, circled-take flags, recorder model, project name. This is the chunk that lets a conform tool reconnect a recording to the script supervisor's notes.

You might also find axml, LIST, JUNK (padding for future in-place edits), or ds64 (the 64-bit size extension for files over 4 GB). But the principle never changes. Chunks, one after another, each self-describing.

Interactive figure: Chunk-by-chunk walkthrough of the container structure discussed here.

Trimming without touching the audio

Back to the trim operation. We need to remove two seconds of silence from the head of an 8-channel, 48kHz, 24-bit file.

First, the math. Two seconds at 48,000 samples per second is 96,000 sample frames. Each frame contains 8 channels at 3 bytes per sample (24-bit), so one frame is 24 bytes. The number of bytes to remove: 96,000 * 24 = 2,304,000.

The trim operation is:

Parse the chunk table. Walk through the file, note every chunk ID, its offset, and its size. Don't read the data payloads, just the 8-byte headers.
Write a new RIFF header. The total RIFF size decreases by 2,304,000 bytes.
Copy the fmt chunk verbatim. Nothing about the format has changed.
Write the data chunk header with its new size (original data size minus 2,304,000), then seek past the first 2,304,000 bytes of the original data chunk and copy the rest.
Update the bext chunk. The time_reference field needs to advance by 96,000 samples, because the file now starts two seconds later on the timeline.
Copy all other chunks (iXML, axml, JUNK, anything unknown) verbatim.

The result is a bit-identical subset of the original audio with corrected metadata. No sample was decoded. No sample was re-encoded. The PCM values in the output file are the exact same bytes that existed in the input file, just starting from a different offset.

This is what makes it lossless in the strictest sense. Not "perceptually lossless" or "lossless compression." Literally the same bytes.

Channel extraction

The same chunk-level thinking applies to extracting individual channels from a polyphonic file. A dialogue editor might need just the boom track (channel 1) from an 8-channel poly.

PCM interleaving means the samples are laid out as:

[ch1 s0] [ch2 s0] [ch3 s0] ... [ch8 s0] [ch1 s1] [ch2 s1] ...

Extraction walks through the data chunk one frame at a time, copying only the bytes for the desired channel. For our 24-bit 8-channel file, each frame is 24 bytes. Channel 1 occupies bytes 0 through 2 of each frame. The operation reads 24 bytes, writes 3 bytes, advances, repeats.

The new file gets a fmt chunk with num_channels set to 1 and block_align recalculated accordingly. The data chunk shrinks to one-eighth its original size. The bext timecode stays the same, because the temporal position hasn't changed. The iXML gets updated to reflect a mono file with the correct track name.

No decode. No encode. The sample values in the output are, again, the same bytes that existed in the input, just with the other channels' bytes removed from between them.

Metadata rewrite

Sometimes the audio is fine and the metadata is wrong. Track names that don't match the actual content. A scene/take field left over from the previous setup. A timecode reference that's off by a frame because the recorder's word clock drifted.

In a chunk-based format, metadata rewrite is the simplest operation of all. Parse the chunk table. Modify the bext or iXML payload. Recalculate the chunk size (it might change if the XML is shorter or longer). Write the file back: RIFF header with the new total size, then every chunk in order, with the modified metadata chunk carrying its updated payload.

The data chunk passes through untouched. You can pipe it from input to output without even reading it into memory. Just copy the bytes.

For small metadata corrections, you can sometimes operate in-place. If the new iXML payload is the same length as the old one, or shorter (padded with nulls), you can seek to the chunk's payload offset and overwrite it directly. This is why many production recorders write a JUNK chunk after iXML: the padding reserves space for later metadata edits without rewriting the entire file.

Why this matters

The alternative to all of this is to treat audio files as opaque blobs that only a DAW can open. Need to trim? Launch Pro Tools. Need a mono extraction? Launch Pro Tools. Need to fix a track name? Launch Pro Tools.

For a facility processing hundreds of files per day, that workflow does not scale. A DAW is an editing environment, not a file manipulation tool. Using it for container surgery is like opening Photoshop to rename a JPEG.

The chunk structure of RIFF/BWF is simple enough that a purpose-built tool can perform these operations in seconds, streaming data from input to output without holding the entire file in memory. A 1.3 GB poly trim allocates a few kilobytes for the chunk table and a read buffer. The operation is I/O-bound, not CPU-bound, because there is no processing. Just byte copying with arithmetic.

This is the kind of operation Spool handles: batch trim, channel extraction, metadata correction, format validation, all operating at the container level. Not because we wanted to avoid using a DAW, but because the operations themselves don't require one. They never did.

Understanding the container format well enough to operate on it directly isn't a shortcut. It's the correct level of abstraction for the problem. A trim is a byte offset change. A channel extraction is a stride operation. A metadata fix is a chunk rewrite. When you see them that way, the 30-second DAW bounce for a two-second trim starts to look like the workaround, not the other way around.

The audio file nobody can open

Mon, 30 Jun 2025 00:00:00 GMT

The production sound mixer delivers a hard drive at wrap. On it: polyphonic Broadcast Wave files, 24 channels each, meticulously recorded across boom mics, lavalieres, plant mics, and ambience rigs. Every channel is labelled. Every take has timecode. The metadata is clean.

The assistant editor drags a file into their DAW. Two channels of silence.

Not because the file is broken. Not because the recording failed. Because the DAW saw 24 channels, assumed stereo, took the first two, and those happened to be empty ISOs waiting for a different mixer's configuration. The other 22 channels of perfectly good production audio are right there in the file. The tool just didn't look for them.

What "polyphonic" means in practice

A polyphonic BWF is a single WAV file containing multiple channels of audio. On a feature film, a Sound Devices 970 or Cantar X3 might record 24 or 32 tracks simultaneously: booms, body mics, plant mics, a stereo mix, and sometimes ambisonic captures from a spatial microphone.

This is different from multi-mono, where each channel gets its own file. Both approaches exist in production. Both are valid. The industry never standardised on one, so every downstream tool has to handle both. Most tools handle multi-mono fine because a mono WAV is hard to misinterpret. The problems start with polyphonic files.

In a polyphonic BWF, the fmt chunk tells you how many channels exist and the sample rate. That's it. It doesn't tell you what each channel is. Is channel 1 a boom? A lav? The left side of a stereo mix? A height channel from an Ambisonics array? The fmt chunk doesn't know and doesn't care. It just knows there are 24 of them.

Where the channel map lives

The actual channel identification lives in two places, both optional.

The iXML chunk carries a TRACK_LIST element where each track gets a name, an interleave index, and sometimes a function tag. This is the production sound metadata. When a mixer labels their channels on the recorder ("Boom", "Lav Alice", "Lav Bob", "Plant SFX"), those names go into iXML. A well-configured recorder writes detailed track lists. A poorly configured one writes "Track 1" through "Track 24" and calls it a day.

The channel mask in the fmt chunk extension (for WAVE_FORMAT_EXTENSIBLE files) maps channels to speaker positions using Microsoft's channel assignment bitmask. Left, right, centre, LFE, and so on, up to 18 predefined positions. This was designed for surround-sound playback, not production audio. There's no bitmask value for "boom mic" or "plant mic behind the door." Production channels don't map to speaker positions because they're not meant for speakers. They're meant for a mixing stage.

This is the fundamental mismatch. The channel identification system baked into the WAV format assumes you're describing a speaker layout. Production audio doesn't have a speaker layout. It has a collection of microphones that were pointed at different things. The metadata formats that actually describe production channels (iXML, the ADM/BW64 standard for object-based audio) are bolt-on additions that many tools have never heard of.

What goes wrong

A DAW that doesn't read iXML opens a 24-channel BWF and has to decide what it's looking at. Common failure modes:

Stereo assumption. The tool assumes anything with more than one channel is stereo, takes channels 1 and 2, and ignores the rest. This is the most common failure and the most destructive, because it silently discards 22 channels of audio without warning. If channels 1 and 2 happen to be mix tracks, you get something that sounds plausible but isn't the original recordings. If they happen to be empty ISOs, you get silence and spend twenty minutes wondering if the sound department recorded anything at all.

Channel mask misinterpretation. The tool reads the WAVE_FORMAT_EXTENSIBLE channel mask and tries to map 24 channels to a surround layout. Channels get assigned to LFE, rear surrounds, height speakers. The boom mic is now routed to the subwoofer output. The lav is playing from the right rear. Nothing is where it should be, and if you're monitoring in stereo, half the channels vanish into outputs that don't exist.

Partial import. The tool imports all 24 channels but puts them on a single track as an interleaved surround file. You can see the waveforms, but you can't solo channel 7 or mute channel 12. The audio is all there and completely inaccessible for editorial work.

Ambisonics misidentification. Some files carry ambisonics flags in iXML, indicating the first four channels are a B-format spatial capture (W, X, Y, Z). A tool that sees the ambisonics flag might try to decode those channels to speaker feeds, applying rotation matrices and shelf filters to what is actually a boom microphone. The audio plays back but sounds like it's been run through a broken reverb.

The silence problem

The worst outcome is silence, because silence looks like a failure to record rather than a failure to interpret. A picture editor who gets two channels of silence from a 24-channel poly file will assume the sound department didn't deliver. They'll call production. Production will check the drive, open the file in a tool that reads all channels, confirm the audio is there, and send the same file back. The editor will import it again with the same result.

This loop can repeat for days before someone identifies the actual problem: the DAW is not reading the file incorrectly in a technical sense. It's reading the channels it knows how to find. It just doesn't know there are others.

Why tools don't read the metadata

The obvious question: if iXML tells you what each channel is, why don't all tools read it?

Because iXML is an optional extension with no enforcement mechanism. The spec was designed by production sound manufacturers (Aaton, Sound Devices, Zaxcom) for their own equipment. It's well documented, widely used in professional production sound, and almost completely unknown outside that world. DAW developers who have never worked in film production don't know iXML exists. Video editing tools that handle BWF for the timecode in the bext chunk have no reason to parse a second chunk of XML they've never encountered.

There's also the problem of trust. Even when a tool does read iXML, the metadata might be wrong. Channel names from a recycled template. A track count in iXML that disagrees with the fmt chunk. Ambisonics flags on a file that contains straight mono ISOs because the mixer toggled the wrong setting. The metadata can lie, and a tool that trusts it without verification can produce results that are wrong in more creative ways than a tool that ignores it entirely.

What correct handling looks like

A tool that handles polyphonic BWF correctly does several things.

It reads the fmt chunk for channel count and sample format. It reads the bext chunk for timecode. Then it reads the iXML chunk for track names, functions, and layout information. If iXML is present and the track count matches fmt, it presents each channel with its label. If iXML is absent or contradictory, it presents all channels with generic labels and flags the discrepancy. It never silently drops channels. It never force-fits production audio into a surround speaker layout.

The key principle is: when the metadata is ambiguous, show everything and let the operator decide. Don't guess. Don't assume stereo. Don't assume surround. Don't assume anything about what a channel contains based on its position in the interleave.

This is not a hard engineering problem. Parsing iXML is straightforward XML reading. Comparing the iXML track count against the fmt channel count is a single integer comparison. Presenting 24 channels on 24 tracks instead of 2 is a layout decision, not a technical limitation. The tools that get this wrong aren't facing difficult constraints. They're making assumptions they never needed to make.

The pattern

This is a recurring theme in production audio: the information exists, in a well-documented format, in the file you already have. The file isn't broken. The spec isn't ambiguous. The recorder wrote everything correctly. The problem is that the tool on the receiving end has a narrower model of the world than the file demands.

Twenty-four channels of production audio is not exotic. It's Tuesday on a feature film set. The formats that describe it have existed for over a decade. The failure isn't in the recording or the format or the delivery. It's in the assumption, baked into too many tools, that audio comes in stereo pairs and anything else is someone else's problem.

Interactive figure: Channel inspector showing how multichannel audio metadata maps tracks and channel names.

It shouldn't take a phone call to production to find out that the audio was there all along.