ReMapping — implementation requests

ReMapping manuals · Implementation requests ← Rendering guide Production log →

Three independent improvements to ReMapping. They apply to the system generally; productions/reference appears only as a concrete example. Each request states the goal, the current problem, what is required, and the acceptance criteria that decide whether it is done — the acceptance criteria are live tick boxes.

In one line. One new feature (a guided voice-recording studio), one bug with a known cause (diagnostic overlays lost between RenderSettings and SceneSettings), and one systematic gap (no documented high-frame-rate profile family).

Contents
  1. Guided voice-recording studio
  2. Diagnostic overlays in remapping still
  3. High-frame-rate output profiles
#RequestKindState
1Guided voice-recording studionew featurerequested
2Diagnostic overlays in stillsbug — cause knownopen
3High-frame-rate output profilesnew featurerequested
Table 1: The three requests at a glance. Only the second has a confirmed cause and a known file to change.

Guided voice-recording studio

requested

Goal. Let a narrator record every script line through one simple local interface, without opening source code, managing files by hand, or typing a separate terminal import command for each take.

The current problem

remapping voice record imports a pre-recorded audio file but cannot capture microphone audio interactively. Today the narrator has to find the script, record in another app, export a WAV, find the line ID, import the file, and then check it separately — six context switches per line.

Figure 1: The required loop, one narration line at a time. Everything stays inside a single interface; the narrator never names a file or types a line ID.

The required workflow

Show readable script and line ID
→ Record
→ Stop
→ Replay
→ Re-record if needed
→ Run checks
→ Accept
→ Save and move to the next line

Required features

Per-take checks

Before acceptance, show clear pass / warning / fail results for each of these:

CheckWhat it reports
Script matchOmissions, additions, substitutions, repetitions.
PronunciationTerms defined in the production lexicon, and terms requiring review.
Audio qualityRequired format, clipping, levels, noise floor, hum, dropouts, DC offset, signal-to-noise ratio, excessive silence.
ConsistencyLevel, background noise, tone and pacing compared with nearby accepted takes.
Timing and beatsMeasured duration, proposed timing markers, and any marker requiring human approval.
Table 2: The five check families a take must pass before it can be accepted. Every one of them is a report — none of them may silently modify the take or the script.

The interface must not silently change the script, the line ID, pronunciation choices, timing markers, or approvals. It reports; the human decides.

Helpful enhancements

Safety rules

  1. A new take stays a draft until the user selects Accept.
  2. An accepted take is never replaced without explicit confirmation.
  3. Delete actions are deliberate and confirmed.
  4. Acceptance seals/imports a take only — it must not silently grant QC, text, pronunciation, marker, or mix approvals.

Suggested entry point

remapping voice studio productions/reference

Acceptance criteria

Diagnostic overlays in remapping still

open   cause confirmed

The problem. The command accepts the diagnostic flags but draws neither the safe-area guides nor the anchor markers:

uv run remapping still productions/reference \
  --frame 600 \
  --show-safe-area \
  --show-anchors

Expected behaviour. --show-safe-area draws title-safe and action-safe guides on the still; --show-anchors draws anchor markers. Both must work for every production with --frame, --time, and --scene ID --time:

uv run remapping still productions/reference \
  --time 8 \
  --show-safe-area \
  --show-anchors

Confirmed cause

The flags are parsed and stored in RenderSettings, but they are lost when plan_film() constructs SceneSettings. The drawing logic already exists in remapping/scene/scene.py — this is a settings-propagation bug, not a rendering one.

Figure 2: Where the flags are dropped. The CLI and the drawing code are both correct; the two are simply not connected through the planner.

File to inspect:

remapping/film/plan.py

The SceneSettings(...) construction needs to preserve:

show_safe_area=settings.show_safe_area,
show_anchors=settings.show_anchors,

Required fix

Acceptance criteria

Existing workaround

uv run remapping anchors sample productions/reference \
  --scene mixed \
  --output mixed-anchors.png

This draws labelled anchors and safe-area guides only at scene time 0. It is not a replacement for arbitrary-time still overlays.

High-frame-rate output profiles

requested

Goal. A systematic, documented high-frame-rate profile family available to any compatible production and supported resolution — instead of isolated one-off profile definitions.

Requested coverage

Implementation requirements

The bitrate rule is the part that is easy to get wrong. Doubling the frame rate does not double the required bitrate, and a 1080p120 file does not want a 2160p bitrate. The profile family has to derive its targets, not copy them.

A production-local template

If a local high-frame-rate profile is needed, name it clearly — delivery-2160p120:

[output_profiles.delivery-2160p120]
size = [3840, 2160]
fps_num = 120
fps_den = 1
container = "mp4"
codec = "h264"
codec_profile = "high"
pixel_format = "yuv420p"
colour_primaries = "bt709"
transfer = "bt709"
matrix = "bt709"
range = "limited"
purpose = "2160p 120 fps delivery"

[output_profiles.delivery-2160p120.rate_control]
mode = "vbr"
target_bps = 80000000
max_bps = 120000000

This is one example only — the system should provide equivalent options across every supported resolution.

Expected use:

uv run remapping render productions/reference \
  --profile <high-frame-rate-profile-id> \
  --draft-timing \
  --workers auto

Acceptance criteria

ReMapping manuals · Implementation requests ← Rendering guide Production log →