cf6be709ab
No Canary patch was needed: UpdateLoopStatus already logs loop_start/loop_end, they just need the Apu category (--log_mask=13 --log_level=3). Decoded, from the menu, 8734 records all after BGM_103's contexts appear: ctx0 (wave 3876864) loop_start 3605682 loop_end 25640423 loop_count 255 ctx1 (wave 3930112) loop_start 3539158 loop_end 26216351 loop_count 255 The movie's three ADV streams log NO loop records -- they do not loop. Semantics visible in the trajectory: read_offset runs from 32 upward and 20 % of samples sit below loop_start, so the stream plays from the beginning and loop_start is where it returns AFTER loop_end. No wrap was observed -- the 45 s hold ended with read_offset at 17 M against a loop_end of 25.6 M. Two registered predictions REFUTED. loop_start is not ~0 but 11.6 % in. And a linear bits-to-seconds conversion is invalid: it gives 62.34 s and 63.29 s for two stems that must play sample-synchronously, which is impossible, so the data refutes the assumption on its own. That leaves a conflict I am not resolving: the field implies a cycle of roughly [10 s, 72 s]; my audio tracking reported offsets 0.25..57.18 s. Recorded as contested, with the likely weak link named as mine -- that locator's control used slices cut from the wave itself, exact copies, which is an easier problem than matching a real capture, and a control easier than the measurement does not bound its error. The port is told to change nothing: its trimmed 61.93 s loop is verified in its own output, and the length survives better than the placement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
41 lines
2.0 KiB
Plaintext
41 lines
2.0 KiB
Plaintext
# The XMA context's loop fields for the menu bed, read from the running game.
|
|
#
|
|
# 2026-08-30. run-canary --gpu=null --xma_param_probe=true --log_mask=13
|
|
# --log_level=3 (log_mask DISABLES categories: 13 = Kernel+Cpu+Gpu off, APU ON,
|
|
# and XELOGAPU is debug level, hence level 3). No Canary patch was needed --
|
|
# UpdateLoopStatus already logs these.
|
|
#
|
|
# Menu reached by the log oracle in 26.8 s; 45 s hold; 8 734 'Looped Data'
|
|
# lines, ALL of them after BGM_103's contexts appear. The movie's three ADV
|
|
# streams produce NONE, i.e. loop_count = 0 on them.
|
|
#
|
|
# ctx -> wave, from the probe's own byte_size:
|
|
# ctx0 packets=1893 byte_size=3876864 (wave 0)
|
|
# ctx1 packets=1919 byte_size=3930112 (wave 1)
|
|
#
|
|
# LOOP FIELDS (bit offsets; loop_count 255 = infinite):
|
|
# ctx0 loop_start = 3 605 682 loop_end = 25 640 423 len = 22 034 741
|
|
# ctx1 loop_start = 3 539 158 loop_end = 26 216 351 len = 22 677 193
|
|
#
|
|
# READ-OFFSET TRAJECTORY over the 45 s hold:
|
|
# ctx0 min 32 max 16 944 845 ctx1 min 32 max 17 165 054
|
|
# 20.0 % of samples are BELOW loop_start in both.
|
|
# Neither reaches loop_end, so NO WRAP was observed in this run.
|
|
#
|
|
# => playback starts at offset 32 (the first packet header) and runs forward;
|
|
# loop_start is where it returns AFTER loop_end. The first pass is longer
|
|
# than the cycles that follow.
|
|
#
|
|
# 🔴 A LINEAR bits->seconds conversion is INVALID. Applied to each stem with
|
|
# its own byte_size it gives:
|
|
# ctx0 62.34 s ctx1 63.29 s
|
|
# Two stems that play sample-synchronously cannot have loop durations 0.95 s
|
|
# apart, so the linearity assumption is refuted by the data itself. XMA frames
|
|
# are variable-length in bits.
|
|
#
|
|
# 🔴 AND IT CONFLICTS with the audio measurement. loop_start at 3.6 M of
|
|
# 31.0 M bits is 11.6 % in; linearly that is ~10 s, so the cycle would be
|
|
# roughly [10 s, 72 s] of the wave. The audio wave-offset tracking
|
|
# (menu-bgm-loop-measured.txt) put the observed offsets at 0.25 .. 57.18 s.
|
|
# Both cannot be right. Unresolved.
|