fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

port: escalation resolved -- a uniform black hold is positively excluded

Browse Source 
Their measurement orders the four gaps by the screen being LEFT: menu 0 and 1
frames, EXTRAS 2, title 3. Direction, button and incoming screen are each
positively ruled out -- the same pair both ways differs, (B) gives 0 and 2 while
(A) gives 1 and 3, and an incoming menu takes 3 from the title and 2 from EXTRAS.

That resolves the escalation I raised: a uniform value is not merely unsupported
but excluded, so 0 is no longer one option among several. It is the only honest
uniform choice, because it models the gap as absent rather than as constant.
black_hold_units is unchanged at 0; its justification is replaced.

And my own rule is now refuted rather than unadopted. Gap plus the incoming
screen's opening black-clear held at 16/16/18 on three transitions; their fourth
gives 16, 14, 16, 18, and decisively the two transitions with the same incoming
screen have different gaps, so the incoming screen cannot determine it. A fourth
point did to a three-point fit exactly what it should.

Not keying per outgoing screen: three screens with one value each restates the
data, which is the objection I raised against my own 16/16/18. BLOCKED row
rewritten to ask for a second value on any one outgoing screen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
This commit is contained in:
Sylpheed port agent
2026-08-30 18:35:00 +00:00
parent 9cf04a4fc6
commit 398bf0dbb1
2 changed files with 36 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/port/BLOCKED.md
View File

@@ -863,7 +863,7 @@ units/frame simply not apply to them? And note the two-strip agreement constrain
the strips to each other, not the absolute rate -- both ratios come from one
capture under one fps assumption, and 1 unit per 1/30 s at 28.5 fps gives 1.053.
### `black_hold_units`: 0 is now wrong on 4 of 5 transitions, and every alternative is a fit
### ~~`black_hold_units`: 0 is now wrong on 4 of 5 transitions~~ — RESOLVED: uniform is excluded
**Derived from Decoder `auto/build-ordinal-audit` plus my own `verify-dwell`.**
@@ -885,3 +885,17 @@ ever measured, that would test the constant-black-period idea properly.
Value stays 0 meanwhile; `verify-dwell` reports the shortfall rather than
absorbing it.
### When there is more than one gap measurement per outgoing screen
**Derived from Decoder `auto/build-ordinal-audit`.**
They ordered the gaps by the screen being LEFT: menu 0 and 1 frames, EXTRAS 2,
title 3 -- ruling out direction, button and incoming screen positively. That
resolves the earlier escalation: **a uniform value is excluded**, so
`black_hold_units` stays 0 meaning *not modelled*.
**The ask, low priority:** a second measurement for any one outgoing screen. Three
screens with one value each restates the data; two values for one screen would
make "keyed on the outgoing screen" predictive rather than descriptive. Nothing
ships on it -- the port omits the gap and says so in `verify-dwell`.