Skip to content

emu3 E-IV: the loop is read from the record's pointer block but has no independent confirmation on eiv-analogia #50

Description

@bmxcode

Context

On E-IV a sample record is located and sized by its E3S1 directory entry — a big-endian record-length field — because the record's own in-record length/pointer block is explicitly not usable on E-IV: the EIII extent rule (+34 plus a bias of two) matches the next-record distance on 0 of 522, 0 of 3893 and 0 of 934 consecutive pairs across the three E-IV discs, and no other offset survives all three (emu3.md, "The record's own length field is not usable"; ADR-0020).

The loop, however, is still decoded from that same in-record eight-pointer block. _eiv_samples in fs/emu3.py hands sample_pointers(window) to the shared _loops() in sample/emu3.py, which gates the loop on that block's own start (must open at DATA_START = 92) and end pointers. So on E-IV the loop is read from the one structure the format otherwise distrusts, and its end gate leans on a field the doc has shown does not size the record here — with the directory-derived frame count as the only reliable backstop.

What the evidence gap is

The loop-validation oracle in emu3.md ("Loop points") — the splice/join and shape correlation, with a wrong start at the same end as the control — confirms loops on the EIII/ESI discs. On E-IV it can lack the power to say anything, because E-IV loops are overwhelmingly the whole-extent "no loop" (bounds inset a fixed few bytes from frame 0 and the last frame), leaving almost no audio before the loop start or after the loop end for the windowed correlation.

That is not hypothetical on eiv-analogia: 441 of its 449 records pass every structural gate, but only 34 carry audio loud enough at both ends to score, and those 34 show nothing — a lack of power, not a refutation (ADR-0025 records this explicitly). After ADR-0030/D23 refused the whole-extent form at both ends, eiv-analogia drops from 449 loops to 6. Those 6 surviving loops are emitted entirely on the rule the other reference discs establish, with no independent per-record confirmation on the disc itself.

Not this, and why

  • Not eiv-vitous or eiv-studio. Their loops were validated by the shape test — at +0.68 and +0.86 — and are kept on that evidence (ADR-0025, ADR-0030). The gap is the disc where the oracle had no power, and the general risk it names for any future E-IV disc dominated by whole-extent loops.
  • Not #44 (E-IV banks that are named, declare a length and read nothing — an extent/binding problem, upstream of any loop).
  • Not #41 (the whole-extent "no loop" refused only at frame 0), which D23/ADR-0030 closed. That refusal is why only 6 loops remain to worry about here; it did not confirm them.
  • Not the origin fix in #49. That corrected where E-IV records are found at a non-zero filesystem origin and does not touch the pointer decode.

What closing this would establish

An independent measurement with power on the residual E-IV loop population — the non-whole-extent loops eiv-analogia keeps after D23 — that says they splice where a control (the same end, a wrong start) does not, the way the EIII/ESI loops do. The doc already notes the forward-windowed oracle is the wrong instrument for near-whole-extent loops and that a period-based / pre-start window is what carries the discs it has no forward power on; the question is whether that (or another metric) can score eiv-analogia's survivors at all. If nothing can, the honest outcome is to state plainly that E-IV loop emission on that disc rests on borrowed evidence — which is currently recorded in ADR-0025 but not surfaced as a limitation the way the extent gaps are.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions