A sample payload whose header disagrees with its directory entry is extracted silently

[bmxcode]

Found while settling #17, and not worked on there.

Every AKAI sample payload begins with a 150-byte header that repeats the file's name at offset 3. The directory entry gives the same name. Nothing compares them, and where they disagree the file extracts anyway — as a WAV that opens, plays, and is somebody else's audio.

Where it bites

AMG - Kickin' Lunatic Beats 2 AKAI CD1.mdx yields 669 files. Nine of them are wrong:

block 4449 '094AIRBEA6-R'  payload header: id=179 valid=0x03 name unreadable rate=1734
block 4513 '094AIRBEA7-L'  payload header: id=4   valid=0x15 name unreadable rate=4052
block 4541 '094AIRBEA7-R'  payload header: id=116 valid=0x19 name unreadable rate=3677
...  9 in total, all in volume '13-TRACK 06', all past block 4449

The cause is that image, not those files — it is short of the disc it was made from by four 32 KB blocks, so everything past the first gap has slid (#17, ADR-0022). The point here is that nothing noticed. id is not 1 or 3, valid is not 0x80, the name does not decode, and the rate is 1734 Hz; all four are visible for free at the moment the payload is read, and all four were ignored.

A rate of 1734 is the loudest of them. No sampler wrote that, and it goes into a WAV header unchallenged.

What a check would look like

At parse_sample time, for a file the directory calls a sample:

• payload[0] is 3 (or 1 for a program);
• payload[15] is 0x80;
• decode_name(payload[3:15]) equals the directory's name;
• the rate at 138 is one the format doc lists — 44 100, 22 050, 33 075, 29 400, 48 000 are what 380 reference samples use.

The interesting question is what to do on a mismatch, and it is not obvious. Refusing the file loses audio that may be perfectly good with a wrong name; extracting it silently is what happens now. Skip-and-log is the house style for damaged input, and this is damaged input — but it needs measuring across the collection first, because a mismatch may be commoner than these nine and some of it may be benign.

Measure before deciding

The sweep behind these numbers checked the name only. Across the 44 AKAI discs, run all four tests and count: how many files fail, on how many discs, and whether the failures cluster the way these do — at the tail of one volume, on an image with an established gap — or scatter, which would mean the check is wrong rather than the discs.

Discs needed

AMG - Kickin' Lunatic Beats 2 AKAI CD1.mdx for the nine known bad files; the rest of the AKAI collection for the false-positive rate.

[bmxcode]

Done in #36, and not in the way this issue expected. Recording why, because the shape of the answer is the useful part.

The bug does not reproduce. Across all 44 AKAI discs and 56 490 sample entries, 96 payloads disagree with their directory entry and all 96 were already being refused — the nine files named above included. Nothing was extracted silently. _looks_like_header has tested the id, the valid byte and the name's decodability since D3, and parse has tested the rate; three and a half of the four tests proposed here were already there.

The 96 are also exactly the 96 skips the README already reported: 92 "do not begin with an AKAI sample header" plus four "implausible sample rates". Same files, not a disjoint set.

What was actually wrong was the message. payload does not start with an AKAI sample header is true of a payload that is mid-audio and of one that is a perfectly good sample under the wrong name alike, and it says neither which of four tests failed nor that a directory entry was involved. That is why nobody checked whether the check existed. It now reads:

payload header carries id 224 not 3, a name that does not decode in the AKAI
charset, placed by an entry named 'PADY CHORD06'

and is counted apart from damage in the summary and the manifest.

Ruling out the false-positive case this issue pointed at is what found a real defect. The S3000 192-byte header is not a variant to be aware of — it is 13 451 of the 56 490 AKAI samples, on nine discs, and every one was read at 150. That put 42 bytes of header into the front of the audio as PCM, dropped the last 21 frames of the sound and left every loop point 21 frames out. See #36 and ADR-0027.

On the measurement this issue asked for. The failures cluster exactly as hoped — 60 of 65 are a run to the end of one volume, and the other 34 AKAI discs have none — but the name comparison, the test this issue is about, fires 60 times and never once on its own. On these images the displacement lands mid-audio and mid-audio does not look like a header, so the id and valid tests always catch it first. It ships anyway, because it is the only test that asks whether a payload is this sample rather than a sample, and #25 will need that. It has no positives on real data and is exercised synthetically alone; the ADR, the format doc and docs/README.md's "What is not done" all say so rather than implying a count it does not have.

One thing came out of the sweep that this issue could not have anticipated: a rip can lose a run of blocks inside a partition without any header going missing, so declared == present is not a clean bill of health. 25 files on three discs — #35.