60145720ed
Answered against the pre-registration committed before the capture, with a content hash added to the draw logger. The buffer rotates three times faster than the content changes: 177 presents carry 3 base addresses but only 102 distinct content hashes, and the modal run is exactly 2 presents per decoded frame. Consecutive presents with changed content = 0.5739, inside the pre-registered R band of 0.40-0.60. That is precisely the failure that invalidated my first answer this morning. The base address changed every present, which I measured and read as one decode per present. The content did not. ADV.wmv is authored at 30.000 fps, so 2 presents per movie frame is 60 presents/s, and 2 units/present x 60 = 120 units/s. Both controls pass, and they are the ones the withdrawn version lacked -- its two guards tested how I READ the buffer, neither tested whether a buffer change meant a decode. Control 1, a static texture must hash constant: the splash atlas changes once, at an era boundary, and never within an era -- 1 change in 403 samples. Noting that I first wrote this control as "must be constant" and it read FAIL; stated that way it was wrong, because a re-upload is real content change and the control has to separate temporal from alternating. A control that is too strong gets waved away, which is its own failure. Control 2, the movie luma hash must not be constant: 102 distinct. Consequence: the plate's t=236 is 1.97 s, not 3.93 s, and the port shows it ~1.96 s late. That is play-test finding 3, and "about two seconds" is the size the human reported. Every declared duration in seconds across the corpus is half what we have been quoting; unit counts are untouched. The 2.13 s third route is explained by emulator speed, and that explanation is labelled POST-HOC and is not offered as support -- fitting a speed factor to close a gap is what this corpus keeps losing claims to. Reach: one boot. This number has moved twice today and a second independent boot should come before the port rewrites a timeline. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
21 lines
894 B
Plaintext
21 lines
894 B
Plaintext
# DECODE vs ROTATE -- does the guest decode a new movie frame every present?
|
|
# Answered against movie-decode-vs-rotate-preregistration.md, committed first.
|
|
|
|
movie luma draws: 177 frames 422..599
|
|
presents carrying a movie luma draw: 177
|
|
distinct BASES: 3 {'11890000': 59, '11700000': 59, '11570000': 59}
|
|
distinct HASHES: 102
|
|
|
|
CONTROL 2 -- the movie luma hash must NOT be constant: PASS
|
|
|
|
consecutive presents with CHANGED luma content: 101/176 = 0.5739
|
|
pre-registered: D decode-per-present ~1.00 (accept >=0.90) -> 60 units/s
|
|
R rotate-per-present ~0.50 (accept 0.40-0.60) -> 120 units/s
|
|
|
|
run lengths (consecutive presents showing the SAME content):
|
|
1 present(s): 29 #############################
|
|
2 present(s): 72 ##################################################
|
|
4 present(s): 1 #
|
|
|
|
VERDICT: R -- rotate per present. Guest 60 fps. 120 UNITS/S.
|