80ef6ac4e2
BGM_103's loop bounds are bit offsets in the decoder context, and each wave's duration follows from its declared byte rate, cross-checked against decoded PCM to 0.007 %. Cycle media length 62.34 / 63.29 s against 61.87 s wall: ratio 0.985, where a uniform 8.5 % slowdown predicts 1.085 -- 10 % away and on the other side of 1.0. The method's error bar is its own 1.5 % self-disagreement between two stems that must have equal duration, which is why the loop page refused this conversion for a finer question. It is adequate for an 8.5 % effect. Does NOT settle the frame clock: audio can hold real time on a timer while rendering lags, and 27.6 fps and the 8.5 % splash excess are both frame-clock numbers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
42 lines
2.5 KiB
Plaintext
42 lines
2.5 KiB
Plaintext
# Is this container's AUDIO clock real time? -- 2026-08-30
|
|
#
|
|
# WHY: ui-keyframe-time-unit.md reads "the game presents at 27.6 fps" off frame
|
|
# counts over wall-clock windows on one container. A guest running ~92 % of real
|
|
# time produces the same numbers, and three trials sharing a container cannot
|
|
# separate the two. sylpheed-port raised the general form of this after finding
|
|
# their own box takes 146.6 s of wall clock for 137.44 s of media (+6.7 %) on a
|
|
# 720p Theora decode, and warned that cross-agent timing must go through media
|
|
# length rather than wall clock.
|
|
#
|
|
# THE REFERENCE, and it is media-derived, not wall-clock derived:
|
|
# BGM_103's loop bounds are BIT offsets in the XMA decoder context
|
|
# (menu-bgm-loop-fields-conflict.md), and each wave's duration follows from its
|
|
# own declared byte rate on the disc, cross-checked against the decoded PCM
|
|
# (4 211 729 frames / 48 000 Hz = 87.744 s, 0.007 % from the declared 87.75).
|
|
#
|
|
# ctx bits/s declared cycle bits media s wall s wall/media
|
|
# 0 353470 22,034,741 62.34 61.87 0.9925
|
|
# 1 358325 22,677,193 63.29 61.87 0.9776
|
|
#
|
|
# ⚠️ THE METHOD'S OWN ERROR BAR IS 1.5 %. The two stems are sample-synchronous and
|
|
# must have equal duration; the linear bits->seconds conversion gives 62.34 and
|
|
# 63.29, disagreeing by 1.5 %. That is the precision available here, and it is why
|
|
# menu-bgm-loop-fields-conflict.md refused this conversion for the loop question.
|
|
# It is good enough for THIS question, which is about a 8.5 % effect.
|
|
#
|
|
# ✅ RESULT: wall/media = 0.985 +- 0.015.
|
|
# A uniform 8.5 % slowdown predicts 1.085. The measurement is 10 % away from
|
|
# that AND ON THE OTHER SIDE OF 1.0 -- wall clock is if anything SHORTER than
|
|
# media, not longer. A container running the whole guest slow is REFUTED.
|
|
#
|
|
# 🔴 WHAT THIS DOES **NOT** SETTLE, and it is the part that matters.
|
|
# This bounds the AUDIO clock. On a box with no GPU, audio can hold real time on
|
|
# a timer while RENDERING lags -- so it does not follow that the frame clock is
|
|
# real time, and every number the doubt was raised about (27.6 fps, the 8.5 %
|
|
# splash excess) is a FRAME-clock number.
|
|
#
|
|
# What it does establish is that the two clocks can be COMPARED: if the frame
|
|
# clock ran 8.5 % slow while audio did not, a UI animation's wall-clock period
|
|
# would exceed its declared period in a run whose audio rate is nominal. That is
|
|
# a single-capture measurement, and it is what frame_vs_audio_clock.py does.
|