I have listed 'four unaudited multi-leg claims' as open for several iterations and said I expected the same inversion in them: a count standing in for an exclusion argument. Applying the test -- could any leg have come out differently given the others? loop_start_why holds. Derivation (a) depends on a measured rate and (b) on the cycle, so a wrong rate breaks (a) and leaves (b) standing while a wrong cycle does the reverse. They fail independently, which is what 'two derivations' was claiming. Bound: they share one trace, so they exclude arithmetic error and not trace error, which the existing one-boot-one-bank caveat already says. arithmetic_why holds. The corpus's 28.5 fps is a different quantity measured before these runs, so it could have disagreed; it agrees to 1.4%. Corroboration rather than restatement. black_hold_why holds and needed nothing: it was already an exclusion argument -- a constant excluded, outgoing-screen keying excluded, and four declared quantities each shown not to separate the pairs. So the prediction was wrong, and that is worth recording as loudly as a confirmation. Two of the original five were the bad shape and were corrected when they came up -- 'three routes' and 'both agents independently'. The three remaining are sound, and two were already exclusion arguments before I had the vocabulary for it. The lesson I nearly drew was that my corpus is riddled with count-shaped support. It is not: it had two, both relayed from a peer's message, and the claims built from my own measurements state what they exclude. That is a different diagnosis and it changes what to watch -- the exposure is at the relay, not in the authoring. Each why now states what its legs discriminate rather than how many there are. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
208 lines
12 KiB
JSON
208 lines
12 KiB
JSON
{
|
|
"format": "sylpheed.timing/1",
|
|
"keyframe_units_per_second": 60,
|
|
"why": [
|
|
"HANDOFF Q1. The disc says a keyframe is at `t=30`; it does not say what a",
|
|
"`t` is. The unit was MEASURED off the running game, not decoded: a declared",
|
|
"15-unit fade lands on round(255*k/15) for all seven of its samples with k",
|
|
"stepping 2,4,6,8,10,12,14 on seven consecutive submitted frames -- so 2",
|
|
"units per rendered frame -- and the idle title presents at 28.3-28.8 fps,",
|
|
"a 30 Hz game, giving 60 units per second. A second line agrees: the",
|
|
"transition quad is declared black for 12 units, and a capture measured the",
|
|
"pure-black plateau at 0.17-0.23 s, where 12/60 = 0.20 s.",
|
|
"",
|
|
"Expressed as units-per-second rather than seconds-per-unit so the value is",
|
|
"exact rather than a repeating decimal a reader has to recognise.",
|
|
"",
|
|
"DELETE THIS FILE when a field on the disc is found that states the unit.",
|
|
"Nothing here is on the disc.",
|
|
"",
|
|
"🔴 DO NOT 'CORRECT' THIS AGAINST AN EMULATOR FRAME RATE. A draw-stream",
|
|
"measurement on 2026-08-29 found the presented units-per-frame rising 33 % over",
|
|
"a single boot (1.765 early, 2.357 late) and three independent readings of one",
|
|
"container's rate disagreeing with each other. That is the EMULATOR's",
|
|
"presentation pacing drifting, and no single units-per-frame figure describes a",
|
|
"run there.",
|
|
"",
|
|
"60 is a different quantity: the GAME's logical unit rate, measured off the",
|
|
"running game as HANDOFF Q1 (a declared t=30 landing on the linear value at",
|
|
"every one of seven sampled frames). The port renders at its own frame rate and",
|
|
"converts through this constant, so guest pacing cannot reach it. The two",
|
|
"numbers are not comparable and one is not evidence about the other."
|
|
],
|
|
"kind": "measured",
|
|
"source": "/reborn docs/port/HANDOFF.md Q1, docs/re/ui-keyframe-time-unit.md",
|
|
"ramp": "linear",
|
|
"ramp_why": [
|
|
"Also HANDOFF Q1, and part of the same measurement: the fade lands on the",
|
|
"linear value at every one of the seven sampled frames, so there is no ease."
|
|
],
|
|
"ramp_kind": "measured",
|
|
"dwell_seconds": null,
|
|
"dwell_why": [
|
|
"NOT SET -- because the dwell is DECLARED, and the port already plays it.",
|
|
"",
|
|
"This key has now been wrong in two opposite directions, and the second was",
|
|
"mine, so both are recorded.",
|
|
"",
|
|
"It first said 'a screen's dwell is its OWN keyframe group'. Then GP_TITLE",
|
|
"build 4 was measured dwelling ~1100 presented frames against a declared ~120,",
|
|
"and I generalised that into 'the boot is KNOWN TOO FAST [refuted] on both splashes'.",
|
|
"🔴 THAT WAS AN OVER-CORRECTION and it is withdrawn. Build 4 is the title: its",
|
|
"exit is caused by something outside its timeline, so it holds. A splash's exit",
|
|
"is caused by nothing, so it plays its declared timeline and leaves. The title",
|
|
"is the exception, not the rule, and one screen was never enough to overturn",
|
|
"the other two.",
|
|
"",
|
|
"MEASURED 2026-08-29 by the Decoder over 3 cold boots",
|
|
"(docs/re/structures/boot-splash-dwells-are-declared.md):",
|
|
"",
|
|
" publisher declared t=0..255 = 4.250 s corpus 4.30 / 4.60 / 4.37",
|
|
" developer declared t=0..210 = 3.500 s corpus 3.51 / 3.50 / 3.37",
|
|
"",
|
|
"The developer agrees to 1.1 %, two of its three runs to 0.3 %. The port emits",
|
|
"4.400 s and 3.650 s -- each declared value plus the 9-unit black hold, exactly.",
|
|
"So the pacing was right all along and nothing changes in the code.",
|
|
"",
|
|
"🔴 AND THE UNIT STAYS UNITS, NOT SECONDS. The same two dwells timed in the",
|
|
"Decoder's own container came out 15-20 % LONGER than both the declared values",
|
|
"and the corpus -- same disc, same timeline -- and three independent readings",
|
|
"of that container's rate disagree with each other. A seconds figure records",
|
|
"one emulator's pacing on one run. The units are on the disc. If anything ever",
|
|
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
|
|
"measured to wait beyond its group."
|
|
],
|
|
"dwell_kind": "measured",
|
|
"looping_focus_records": {
|
|
"_": [
|
|
"WHICH focus records the port draws, unconditionally and on a loop, OVER the",
|
|
"element's own sprite rather than instead of it.",
|
|
"",
|
|
"RESTORED 2026-08-30 on a MEASUREMENT, having been deleted on 2026-08-29 for",
|
|
"a real defect that was in the RENDERER, not in this table. The old entry made",
|
|
"`_draw` substitute the glow for the plate's own bright sprite, so the plate",
|
|
"was invisible at every instant (max 0 against max 252.5). `ScreenView` now",
|
|
"draws the base and the record over it, and the entry comes back."
|
|
],
|
|
"press_start/ptbtn00": {
|
|
"record_element": "ptbtn00f",
|
|
"period_units": 120,
|
|
"kind": "measured",
|
|
"source": "docs/re/structures/plate-pulse-measured.md, RE agent 2026-08-30",
|
|
"why": [
|
|
"MEASURED off the running game, held at the title with NO INPUT: the plate",
|
|
"oscillates continuously -- two windows in one boot of 58 s and 57 s, about",
|
|
"23 cycles each, with no decay and no settling.",
|
|
"",
|
|
"🔴 IT NEVER GOES OFF. The plate-absent floor is 159 thresholded green",
|
|
"pixels -- the title art's own, measured on live-title-build4-no-plate.png --",
|
|
"and the pulse bottoms at 714, four and a half times that. So `ptbtn00`",
|
|
"going transparent at t=244 is not the end of the plate; that is its EXIT",
|
|
"ramp, which plays when the screen leaves. While the screen is held the base",
|
|
"sits at its own hold (alpha 255 at t=238) and `ptbtn00f`'s cycle runs over",
|
|
"it. Base-only and base-plus-glow are what the 714 and the 1520 are.",
|
|
"",
|
|
"⚠️ 120 UNITS, NOT SECONDS, and that is the RE agent's own instruction. Their",
|
|
"run measured 2.530 and 2.540 s; an earlier corpus run measured 2.24 s. Same",
|
|
"declared number, different emulator pacing -- x1.27 and x1.12 against a",
|
|
"nominal 2.000 s, which IS 120 units at 60 units/s. Hardcoding 2.5 s would",
|
|
"author one loaded container's clock."
|
|
],
|
|
"limits": [
|
|
"ONE BOOT. Two windows inside it are not two boots.",
|
|
"It does NOT distinguish the boot title from an attract-loop title: run 1",
|
|
"opens at t~255 s against Q9's ~193 s no-input baseline, so it may already",
|
|
"be the attract title. Both are 'the title, held, no input' -- which is what",
|
|
"was asked -- but it is not proof about the first appearance.",
|
|
"🔴 714/1520 IS NOT AN ALPHA RATIO. The counter is thresholded pixels, so dim",
|
|
"pixels drop out first. No duty cycle and no ramp shape may be read off it;",
|
|
"the port draws the record's own declared alpha ramp and infers nothing."
|
|
]
|
|
}
|
|
},
|
|
"exit_ramp_deleted_why": [
|
|
"DELETED 2026-08-29, and the deletion is the point.",
|
|
"",
|
|
"`exit_ramp_seconds` (~0.4 s) and `exit_ramp_units` (24) were AUTHORED because",
|
|
"the disc had no time slot on a group's final keyframe, so the ramp into it was",
|
|
"the one unknown duration per screen. Under the corrected record layout",
|
|
"(formats-pin-2026-08-29c onward) there IS no untimed keyframe -- a group is an",
|
|
"8-byte header then frames x {u32 time; 36-byte pose}, so every pose is timed",
|
|
"including the last. The unknown the constant stood in for does not exist.",
|
|
"",
|
|
"MISSION section 3: 'When the RE agent later decodes something you had",
|
|
"authored, delete the authored entry and let the exporter emit it. That",
|
|
"deletion is the measure of progress.'",
|
|
"",
|
|
"VERIFIED DEAD BEFORE DELETING, not assumed: setting it to 9999 (166 seconds)",
|
|
"changed the boot's transitions by 0.04 s -- wall-clock jitter, not a 166 s",
|
|
"ramp. Both of its uses in ScreenView were gated on `not last_frame.has('t')`,",
|
|
"which no longer fires on any of the export's 866 keyframes.",
|
|
"",
|
|
"The measurement it recorded is not lost: HANDOFF Q7's ~0.4 s fade-out and the",
|
|
"0.17-0.23 s black hold are still measured facts, and the hold is still used --",
|
|
"`tools/port/verify-dwell` compares a transition INTERVAL against the oracle's",
|
|
"visible SPAN plus that hold. What is deleted is the port's need to invent a",
|
|
"duration the disc now states."
|
|
],
|
|
"black_hold_units": 0,
|
|
"black_hold_why": [
|
|
"0 = NOT MODELLED. The escalation is resolved: a uniform value is positively",
|
|
"EXCLUDED, so 0 is no longer one option among several -- it is the only honest",
|
|
"uniform choice, because it is the one that does not claim a constant exists.",
|
|
"",
|
|
"UPDATE: TWO candidate models are now excluded, not one. The Decoder has five",
|
|
"replicates with NO variation -- title->menu 3,3,3 and EXTRAS->menu 2,2 -- and",
|
|
"every differing value comes from a different ORDERED PAIR. The same origin",
|
|
"gives different values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3).",
|
|
"So a constant is excluded AND keying on the outgoing screen is excluded; only",
|
|
"an ordered-pair key survives, with a measured value needed per pair.",
|
|
"",
|
|
"I checked independently whether anything DECLARED predicts it, from the",
|
|
"quantities in my export. None does: outgoing close (15,10,10,10), incoming",
|
|
"clear (12,12,16,12), outgoing span (269,74,80,80) and incoming span",
|
|
"(80,80,269,74) each have two rows sharing a value with different gaps.",
|
|
"",
|
|
"I did NOT search combinations of them. Four intra-archive pairs against many",
|
|
"candidate two-screen functions fits by construction -- that is the error this",
|
|
"corpus has catalogued five times, and finding a formula here would be",
|
|
"indistinguishable from finding one in noise.",
|
|
"",
|
|
"The Decoder ordered the gaps by the screen being LEFT (frames): menu 0 and 1,",
|
|
"EXTRAS 2, title 3. Three hypotheses are positively ruled out, not merely",
|
|
"unsupported. DIRECTION: EXTRAS->menu (2) and menu->EXTRAS (1) are the same",
|
|
"pair both ways and differ. BUTTON: (B) gives 0 and 2, (A) gives 1 and 3.",
|
|
"INCOMING SCREEN: an incoming menu takes 3 from the title and 2 from EXTRAS.",
|
|
"",
|
|
"So the quantity varies 0-3 frames by outgoing screen, and any uniform non-zero",
|
|
"value is wrong as a MODEL rather than merely off in magnitude. 0 models the",
|
|
"gap as absent; 6 would model it as constant, which the data excludes.",
|
|
"",
|
|
"MY OWN RULE IS REFUTED, not just unadopted. It was gap + the incoming",
|
|
"screen's opening black-clear = a constant, holding at 16/16/18 on three",
|
|
"transitions. Their fourth gives 16, 14, 16, 18 -- and decisively, the two",
|
|
"transitions with the SAME incoming screen (main_menu) have different gaps,",
|
|
"so the incoming screen cannot determine it. A fourth point did to a",
|
|
"three-point fit exactly what it should.",
|
|
"",
|
|
"DO NOT key this per outgoing screen yet. Three outgoing screens with one",
|
|
"value each restates the data rather than predicting it -- the same objection",
|
|
"I raised against my own 16/16/18. Key it when a screen has more than one",
|
|
"measured value, and key it on the screen being LEFT.",
|
|
"",
|
|
"📌 CITATION ADDED 2026-09-01, and its absence propagated from the delivery.",
|
|
"This why carried over a thousand characters and NOTHING OPENABLE. The Decoder",
|
|
"sent the `(B)`-from-EXTRAS leg as an inline frame table with no file cited,",
|
|
"while docs/re/data/fade-four-transitions.txt -- which carries that leg and",
|
|
"eight others -- had been committed the whole time. They found it in their own",
|
|
"audit and cited it; it had already landed here uncited.",
|
|
"",
|
|
"⚠️ An uncited measurement propagates as an uncited value. The receiving end",
|
|
"cannot tell a summarised measurement from a recalled one, and both read as",
|
|
"prose.",
|
|
"",
|
|
"✅ AUDITED 2026-09-01 and this one needed nothing: it was already an EXCLUSION argument rather than a count. It excludes a constant, excludes keying on the outgoing screen, and excludes every declared quantity in the export as a predictor -- four of them named, each shown not to separate the pairs. That is the form the week's other claims were found to be missing."
|
|
],
|
|
"black_hold_kind": "measured"
|
|
}
|