ca7dd583d53f5c8d99e9bf9497b2caa3f3a6b03e
4 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed port agent
|
5e07346abf |
port: retract the S00A coverage hole -- it was my control's filter, not the check
Yesterday I reported that a 6 kHz-lowpassed S00A deviated only 1.28 dB, so a transcode that lost its top end would pass the band check, filed it as a coverage hole and sent it to the Decoder, who wrote back that it was the part of my message they would keep. It is wrong. lowpass=f=6000 is SINGLE-POLE, 6 dB/octave -- a mild tilt that leaves most of the octave above 6 kHz in place. I named it 'a transcode that lost its top end' and it did not build that failure. With a real 4-pole brick wall the loss is caught: ADV 6.52 dB at 4.3x, S00A 1.83 dB at 1.2x. Covered, not absent. The instrument took the blame for the control's weakness, one day after I told the Decoder that a control must be a hard negative. The harder rule: a control must CONSTRUCT the failure it is named after. Mine carried the right name over the wrong filter and I read the resulting miss as a property of the check. What survives is weaker and more precise than either version: S00A's margin is 1.2x, which is thin, and the tool now prints a THIN warning below 2x. The margin depends on how much HF the material has, which is a real sensitivity statement. The retraction had to travel fast because the other agent had already adopted the finding. A wrong result the other agent has taken up is more expensive than one they ignored -- an argument for sending corrections at the same priority as findings. Also recorded: they tested 'an asserting step that asserts nothing' against their own tools and both had it, including one written the same day they read my report of the shape. Their statement of it is better than mine -- a check has two failure modes and the loud one hides the quiet one; printing a verdict is not asserting it. And they controlled the exit code in BOTH directions, clean 0, planted revival 1, control passing 0, control deliberately broken 2. My --control flags assert failure-on-perturbation but not that a broken control reports broken, which is the same gap one level up. Next thing to close here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
aedcd35eef |
port: a hard negative found a coverage hole and two defects hiding each other
The Decoder generalised my identity rule back at me -- a positive control that is merely 'high' hides the difference between an exact instrument and a lossy one -- and it landed on the band check I shipped yesterday. Its positive control was 0.29 and 0.66 dB, and small is not zero. Source against itself read 7.656 dB, larger than the number the check calls faithful: bands() applied the fold to one side only, correct for source-versus-transcode and wrong for source-versus-itself. The fold is per-side now and identity reads 0.000 dB exactly. The published 0.66 stands unchanged; what changed is that the instrument is known unbiased rather than assumed to be, and the scale's bottom is anchored. Same rule applied to the port's headline numbers: the image RMSE metric reads 0.0000 for a capture against itself and after a PNG round-trip, so 13.21 is real difference and not pipeline noise. verify-capture now asserts that before printing any row and refuses if it is not exact. Then their refutation attempt on 'band energies need no alignment'. It survives -- 1 s of misalignment costs 0.16 dB -- but 10 s costs 1.00 dB, so the claim is narrowed to robust, not free. Their real point: separation is material-dependent, two unrelated music banks separate by 5.28 dB where an unrelated movie gave me 19-20. A movie is an easy negative, so I built the hard one and it failed. A 6 kHz lowpass is caught on ADV at 4.27 dB, 2.8x, and NOT caught on S00A at 1.28 dB against a 1.5 dB threshold, because S00A's own 6-16 kHz content sits at -67 dB. A transcode that lost its whole top end would pass on S00A. Reported per asset as COVERED / NOT COVERED rather than asserted, and tracked in BLOCKED. Splitting the top band raised ADV from 2.58 to 4.27 dB. That is changing the instrument's resolution so it can see a failure it must see, driven by a control it failed -- the pass threshold is unchanged. Repairing it exposed two defects that had been hiding each other. return 0 was unconditional: making the difference path report-only swallowed the band verdict, so check-all's transcode-bands must-pass step could not fail -- an asserting step that asserts nothing, shipped by me one day after writing up the same shape in someone else's work. And the disqualified difference path was still voting on the exit code, so fixing the return turned the run red for the wrong reason. Neither would have surfaced without a control the tool could fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
82e3755bb7 |
port: a capital letter hid a refuted claim; and band levels answer what alignment could not
Three findings, two of them defects in my own checkers. Changing the KIND of quantity answered the P4 fidelity question on the first attempt. Four attempts at sample-exact difference-signal alignment produced four failures and no verdict -- well past the Decoder's rule that two failed attempts at the same measurement are evidence the quantity is wrong, not the parsing. Band energies need no alignment at all: both transcodes match their sources to 0.66 dB worst-case across four bands, while an unrelated movie lands at 19-20 dB. Two populations an order of magnitude apart, so the 1.5 dB tolerance sits between measured values rather than being picked. Asserting in check-all with the known negative on every run, not behind a flag. It also diagnoses the failure it replaced: matching spectra mean same content at same level, so the difference signal's failure is my alignment, now by evidence rather than assumption. The difference path stays report-only. Band agreement cannot tell a faithful transcode from one that kept the spectrum and mangled the waveform -- weaker than P4 wanted, and what I can support. check-claims held 'no loop-point field has been identified' in its register the whole time and matched case-sensitively, so a capital N at the start of a sentence hid a registered dead claim in BLOCKED.md -- the one document whose job is to say what is still open. The correction had reached authored/audio.json and not the blocked list, which is exactly the failure that file's own why warns about. Matching is case-insensitive now and immediately surfaced five more unmarked sites, including a whole DECISIONS section still describing the refuted state. All six fixed: four tokened, two rewritten with the shipped values. Controlled with a planted capitalised revival. And --control caught its own harness: it perturbed only the first occurrence of an anchor, and the Decoder's delivery heading now appears twice, so the check read the untouched duplicate and passed a wrong contract. A perturbation that does not reach every copy makes a check untestable silently. First time a control has failed because of a change in someone else's document rather than my code. Not accepted from the same message: the (A)-skips-a-movie row is NOT stale. It reads (a) ANSWERED, cites Q9, and points at flow.json's skippable: true. Reported back rather than quietly 'fixed' -- marking a live row stale is the error their own message is about. Every asserting check passes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
ec2a17eaa9 |
port: attempt the P4 fidelity question -- four traps reproduced, no verdict claimed
AUDIO-VERIFICATION.md section 1 calls transcode fidelity the question P4 actually raised, needing neither an engine nor a device, and gives it in four lines of shell. Nothing implemented it: verify-video-audio deliberately declines, saying a difference RMS without alignment is meaningless. So the P4/P7 gate has rested on level and non-silence and the fidelity claim has never been made. tools/port/verify-transcode-fidelity now exists and is committed WITHOUT a verdict, deliberately. Four ways the measurement lies, each reproduced here rather than reasoned about. Indexing with a negative lag wraps to the end of the array in Python, so the difference was the transcode subtracted from an unrelated part of the source -- reported 7 dB LOUDER than the source, the same catastrophic-looking number the doc warns of. My regex for the recorded -af truncated the fold to its FL half, folding the source to a left-only signal: the doc names that trap, I reached it through a parsing bug, and the matrix contains runs of spaces so it cannot be tokenised on whitespace. -ss before -i is a container-level jump and on this WMA Pro source returned 4.6 s for a 4.0 s request while the Ogg side returned 4.0 s, so the windows covered different stretches of the movie, best correlation 0.172 -- this one is NOT in the doc and is indistinguishable from the alignment trap that is. And the single-resolution search returned +2413 against a window of +-2400, its own boundary rather than a peak, the same family as the Decoder's period estimator returning its search floor. Why no verdict: best alignment is corr 0.763 on S00A and 0.075 on ADV, and both still report the difference louder than the source, which cannot be true of two aligned signals at equal level. The remaining fault is on my side. A tool printing 'not faithful' in that state would put a false defect on the exporter. It now distinguishes 'could not align' from 'not faithful', two failures I conflated twice before separating them. Filed for the human as a proposal, not an edit: section 1 should carry the imprecise-seek trap as a fourth entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |