On about 2 200 records of esi32-gm and 3 800 of protozoa, the sample record's end_L pointer (+30) runs roughly 45 frames — 90 bytes — past the payload that +34 plus RECORD_LEN_BIAS produces. The two fields disagree, consistently, on two discs.
Found while decoding the loop points in #31 (ADR-0025).
Why it matters
Those records also declare a loop end inside the longer extent and therefore past the audio the reader emits. Such loops are refused rather than clamped, which is the right call on measurement — protozoa's clamped loops score −0.10 on the splice-shape test against +0.86 for the ones that fit — but it is why esi32-gm yields loops on only 107 of its 2 265 samples, 5%, while eiiix-1 yields 97%.
If the extent field is the truthful one, the reader is 90 bytes short on those samples and roughly 2 200 + 3 800 loops are being refused for a reason that is our bug rather than the disc's.
What was tried, and why it did not settle it
Scanning candidate loop ends across ±96 frames around the declared one — reading past the record so an end beyond the payload is visible — and taking the peak of the splice-shape correlation:
| Disc |
records scanned |
peak within ±2 frames of the declared end |
esi32-gm |
260 |
10% |
protozoa |
1 217 |
20% |
A uniform peak over the scanned window would give about 3%. So both are better than chance and neither is an answer. Nothing was changed on the strength of it.
Where to start
- The 90 bytes is suspiciously close to the 92-byte header, and on these discs
end_L − end_R == 92 exactly on 2 110 of esi32-gm's records and 3 855 of protozoa's. A base that differs by one header length between the two pointer sets would explain it.
RECORD_LEN_BIAS = 2 is documented as "verified across a 12-record chain". A wider re-measurement of the stride between consecutive records would say directly whether the record is longer than believed.- Any change here moves payloads on two discs.
tests/test_discs.py pins the SHA-256 of every sample payload per disc, so it will fail loudly, which is the point.
Written up in docs/formats/emu3.md under "A loop end past the audio is refused, not clamped".
On about 2 200 records of
esi32-gmand 3 800 ofprotozoa, the sample record'send_Lpointer (+30) runs roughly 45 frames — 90 bytes — past the payload that+34plusRECORD_LEN_BIASproduces. The two fields disagree, consistently, on two discs.Found while decoding the loop points in #31 (ADR-0025).
Why it matters
Those records also declare a loop end inside the longer extent and therefore past the audio the reader emits. Such loops are refused rather than clamped, which is the right call on measurement —
protozoa's clamped loops score −0.10 on the splice-shape test against +0.86 for the ones that fit — but it is whyesi32-gmyields loops on only 107 of its 2 265 samples, 5%, whileeiiix-1yields 97%.If the extent field is the truthful one, the reader is 90 bytes short on those samples and roughly 2 200 + 3 800 loops are being refused for a reason that is our bug rather than the disc's.
What was tried, and why it did not settle it
Scanning candidate loop ends across ±96 frames around the declared one — reading past the record so an end beyond the payload is visible — and taking the peak of the splice-shape correlation:
esi32-gmprotozoaA uniform peak over the scanned window would give about 3%. So both are better than chance and neither is an answer. Nothing was changed on the strength of it.
Where to start
end_L − end_R == 92exactly on 2 110 ofesi32-gm's records and 3 855 ofprotozoa's. A base that differs by one header length between the two pointer sets would explain it.RECORD_LEN_BIAS = 2is documented as "verified across a 12-record chain". A wider re-measurement of the stride between consecutive records would say directly whether the record is longer than believed.tests/test_discs.pypins the SHA-256 of every sample payload per disc, so it will fail loudly, which is the point.Written up in docs/formats/emu3.md under "A loop end past the audio is refused, not clamped".