Build a release (DEBUG=0) Sega CD disc for a profile, record its playback without the DEBUG HUD, and qualify that recording against an existing gate-PASS DEBUG recording of the byte-identical packed stream using the GPGX LOGVDP DMA trace and visual inspection. Use for "release build", "HUDなしで録画", "/release", or whenever a publication playback video must not carry the debug overlay.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Build a release (DEBUG=0) Sega CD disc for a profile, record its playback without the DEBUG HUD, and qualify that recording against an existing gate-PASS DEBUG recording of the byte-identical packed stream using the GPGX LOGVDP DMA trace and visual inspection. Use for "release build", "HUDなしで録画", "/release", or whenever a publication playback video must not carry the debug overlay.
release: HUD-free playback build
Produce the playback artifact a viewer should see: the same stream the DEBUG
build already qualified, played by a release player that draws no debug
overlay.
Run every command from the repository root.
Why this skill exists separately
record builds DEBUG=1 by default because the on-screen HUD is what the
schema-16 upload gate reads. A release build draws no HUD, so:
there is no HUD TSV and no _gate.json for a release recording;
harness/gpgx_logvdp/extract_frame_tsv.py cannot run, because it aligns the
DMA trace to HUD frame numbers;
compilation's normal precondition, a gate JSON whose recording matches the
input MKV, cannot be satisfied by the release capture itself.
None of that means a release capture is unqualified. It means its evidence comes
from a different place: the DEBUG recording that already passed, plus proof that
the release disc carries the same bytes and the release player does no more VDP
work. This skill states that chain explicitly. Do not reuse a DEBUG gate JSON by
hand-editing it, and do not claim a release capture has a HUD gate.
Preconditions
Require all of the following before building anything:
A completed record capture of the same profile whose schema-16 HUD result
has gate PASS (alert NONE or WARNING), together with its
logs/<run>_hud.tsv, , and the compact RetroArch
log kept beside its lossless MKV.
logs/<run>_hud_gate.json
The same encoder/player version in tools/av_version.txt for both. A
release build at a different e/p has no baseline; produce the DEBUG
recording first through run.
The current packed stream in out/PROFILE/, produced by that same DEBUG
pipeline and not modified since.
A missing or FAIL baseline gate stops this skill. Do not substitute a
release-only visual check for the qualification.
Stage 1: Prove the stream did not change
The release build reruns make disc, which rewrites the packed stream. The
DEBUG gate only transfers to the release capture when those bytes are
identical, so record their hashes first and check them afterwards:
A release build writes out/PROFILE_release.iso and out/PROFILE_release.cue,
so it never overwrites the out/PROFILE.iso / out/PROFILE.cue pair a DEBUG
build produced from the same packed stream. Both discs can therefore exist
side by side and be compared.
Build the release disc, then verify:
sha256sum -c tmp/PROFILE/stream_hashes.txt
Every line must report OK. A changed byte means the release disc is not the
qualified stream; stop and find out what moved before recording. DEBUG selects
only the player build, so a difference here is a pipeline bug, not an expected
release/debug variation.
Stage 2: Build and record
record owns the recording mechanics; this skill only selects the release
build and the same duration used for the baseline:
Keep the complete Mega-CD startup, use the default fixed-Replay offline
FFV1/FLAC path, and reserve at least 30 seconds beyond the source duration as
record requires. The Replay is regenerated for this disc; a Replay made for
the DEBUG disc belongs to a different binary and must not be reused.
Verify the capture exactly as record specifies: native 320x224, about
60000/1001 fps, bounded duration, a non-empty audio stream, the requested
packet and decoded-frame counts, and a RetroArch log that reaches
Content ran for a total of and Unloading core.
Stage 3: Qualify with the LOGVDP DMA trace
Both builds run under the managed GPGX LOGVDP core, so both emit the core's DMA
timing trace. Compare the release capture with the gate-PASS DEBUG capture:
The tool separates the player's own transfers, which run from 68000 work RAM,
from the BIOS and CD-player startup, and splits each by the accesses-per-line
rate the core reports: the highest rate a region used is its blanking rate and
anything lower is active display. It reports the core's own access counts and
deliberately does not translate them into VRAM words; the trace is a DMA timing
model, not the encoder's R2V accounting.
It fails when any of these hold:
the core logged an error kind absent from the baseline;
the release player's DMA reaches active display more than the baseline's does;
the release player performs more total DMA than the DEBUG build, which also
drew the HUD and therefore bounds it.
Judge the absolute amount of DMA that reaches active display, not its share.
Removing the HUD lowers the total, so an unchanged spill necessarily raises the
percentage; that is bookkeeping. What corrupts a frame is DMA running while the
raster is live. The default 5 percent tolerance absorbs the different Replay
start frame and bounded window; do not raise it to make a result pass.
Expect the name-table DMA to drop sharply between the two builds. That is the
HUD's Window-row and sprite-table work disappearing, and it is the difference
this build exists to make.
Stage 4: Inspect the picture
The HUD is exactly what the automatic checks read, so its absence makes human
inspection part of the qualification rather than a courtesy. Extract named
stills from the lossless MKV and look at them:
Confirm in that invocation's own directory and montage:
the Mega-CD startup and CD-player screens appear first;
playback begins after the START transition and advances through the movie;
no HUD row is present anywhere, which is what proves the release build ran;
no torn tiles, stale patterns, dark 4-pixel dashes, or colour breakup;
the tail is intact.
Never montage a shared check directory with *.png.
Stage 5: Compile and upload
Hand the verified lossless MKV to compilation for the 2048x1568 square-pixel
transcode and the upload. Its normal HUD-gate precondition is satisfied by this
skill's chain instead: the byte-identical stream, the baseline gate, the LOGVDP
comparison, and the visual inspection. State that substitution when reporting;
do not present the release capture as carrying its own gate.
Title and description follow YOUTUBE.md. A release
capture is the plain (playback) video. When a DEBUG capture of the same
encode was already uploaded, retitle it to (playback, DEBUG HUD) so the two
stay distinguishable and the HUD-free one is the video a viewer is sent to.
Say in the description that no debug overlay is drawn.
Report
Report the profile and stem, the release disc build, the packed-stream hash
result, the baseline recording and its gate maxima, the LOGVDP comparison
verdict with the player blanking/active-display split for both builds, the
visual inspection result, the final MP4 path with raster/SAR/DAR and duration,
and both YouTube URLs.
