Skip to content

AKAI: a volume's emptiness is explained by the partition's allocation map - #24

Merged
bmxcode merged 1 commit into
mainfrom
d16-akai-empty-volumes
Aug 20, 2026
Merged

AKAI: a volume's emptiness is explained by the partition's allocation map#24
bmxcode merged 1 commit into
mainfrom
d16-akai-empty-volumes

Conversation

@bmxcode

@bmxcode bmxcode commented Aug 20, 2026

Copy link
Copy Markdown
Owner

Closes #16. Closes #17.

Ten volumes across three discs listed empty with no explanation, which is the ADR-0012 signature exactly: it reads as an empty volume rather than as a wrong answer. They are two different faults, and neither turned out to be what its issue proposed.

The deliverable was not the two bugs but the invariant behind them. test_a_claimed_disc_yields_at_least_one_file asserted per disc, which is the weaker half of what ADR-0012 says; it now asserts per volume, which is the form that would have caught the E-mu index banks of #15 years earlier — those discs always had some bank with records in it. Of 79 images and 71 claimed by a backend, exactly three fail the per-volume form and none fail the per-disc one.

What settles it

A structure that was sitting unread in the partition header: at 0x70A, immediately after the volume directory's hundred slots, a block allocation map — one u16 per block, as many as the partition declares at 0x00.

It is verified rather than merely plausible, and that distinction is the whole reason it is allowed to decide anything. A file's chain length and the size its directory entry declares are stated by two different structures on the disc, and across all 44 AKAI discs they agree for 14 607 of 14 607 files — exactly, with no disc disagreeing anywhere.

The exclusion behind that figure is itself a finding. Five volumes sit on blocks the map calls free and their chains are gone with them; four of the five hold readable directories and 63 files of real audio. They are deleted volumes, on mastered CD-ROM that never reused the blocks.

Read against the map, the ten empty volumes are three different situations:

Map code at the start block The disc is saying Volumes
chain link or 0xC000 the block holds file data Advance Orchestra ×4, OMI ×1
0x0000 the block belongs to nothing Kickin' Lunatic Beats 2 CD1 VOLUME 018
0x4000 a directory belongs here Kickin' Lunatic Beats 2 CD1 ×4

#17 is the container, and not in the way either reading proposed

The issue asked for this to be settled first, and it was, because it changes what the rest of the deliverable can claim. Both candidate readings are wrong: the MDX decoder is not mis-decoding, and the four start blocks are not stale.

The chain around the fault is unremarkable — 16 299 blocks, every one a valid DEFLATE stream emitting exactly 32 768 bytes, the only stored block being the tail remainder. What is wrong is that the file does not contain all of the disc. Two independent structures agree on the displacement:

  • the four volume directories are each present in the image exactly 16 blocks (131 072 bytes) below where the volume entry points, and the file directories in partition 1 put the first gap earlier still, at 8 blocks;
  • partition 2's header sits at block size − 16, which knows nothing about the first measurement.

131 072 bytes is four MDX blocks — a quantity of the container, which the AKAI filesystem has no notion of. That is what identifies the layer. CD2 of the pair is short by one such block; its partition 1 survives it intact, which is why it lists 20 volumes and 1 346 files with nothing to report.

So the 669 files that disc yields are not all trustworthy, as the issue warned. Nine files at the tail of 13-TRACK 06 extract audio belonging to other samples: id is not 3, valid is not 0x80, the name does not decode and the rate reads 1 734 Hz. Nothing detects that — it is recorded in the changelog's known limits and in #23, not fixed here.

Nothing moved

872 volumes and 56 662 files across all 79 images, before and after, unchanged to the number. Backends and resolved offsets identical. The only difference anywhere in the collection is ten notes on ten volumes.

That is a design property and not luck: the map explains an emptiness and never gates a listing, because every gating fix was measured and costs real audio.

Pinned by _AKAI in tests/test_discs.py Volumes Files Noted
AKAI Advance Orchestra Upgrade 97 Vol.1 18 464 4
AMG - Kickin' Lunatic Beats 2 AKAI CD1 18 669 5
AMG - Kickin' Lunatic Beats 2 AKAI CD2 20 1 346 0
OMI … Universe Of Sounds Vol.1 (Roland S-770,S-750) 28 900 1
Back in Time Records - Big Bang 8 380 0
ProSamples vol.01 - Hip Hop and R&B Drumloops 7 82 0
ProSamples vol.19 - Pop Brass 3 139 0
ProSamples vol.24 - Breakbeat 15 113 0

The noted count is pinned as tightly as the file count, deliberately: a note appearing where none was measured is a backend explaining away something nobody looked at.

The known wrong constant

<HH over entry[12:16] is gone. +12 is the type byte, +13 a separate field, start at +14 unaffected — which is why nothing ever listed differently and the bug survived: no code read the type. The doc's "u16 LE type" is corrected.

Types are identified as 1 = S1000, 3 = S3000, 7 = CD3000, against the high bit on the file type byte — the same signal that already names a kept original .s3p rather than .s1p. No file in any of the 338 type-1 volumes sets it; 8 of 9 type-3 and 57 of 91 type-7 volumes hold nothing but high-bit files, the rest mixed, because a volume may hold both generations. Type 0 means the sampler will not load the volume, which is not the same as there being nothing in it.

On +13 this PR disagrees with the issue and reports its own measurement. The issue says an incrementing per-volume index on two discs of 44; sweeping all 4 400 non-empty slots finds it on oneOMI … (Roland S-770,S-750), running 2, 3, 4 … 28 over 27 live volumes in slot order and 0 on the unused slot. The likely explanation for the discrepancy is that the earlier sweep predates ADR-0012, when the two OMI SampleCell discs were still being claimed as AKAI. One disc is not enough to say what the field is, so the doc records the measurement and stops.

Rejected alternatives

In ADR-0022, with what each costs:

  • Reject type 0 — discards four volumes carrying 63 files.
  • Require the directory to parse — a plausibility test of the kind ADR-0012 exists to refuse, and it misses VOLUME 016, which points at 0x01 filler decoding to 101010101010.
  • Use the map as an allocation flag — drops the 63 files and every volume on every S3000 and CD3000 disc, 100 of them, because there a directory block heads a chain into the volume rather than standing alone. 0x4000 means "volume directory" on S1000 discs only.
  • Recover the four directories 16 blocks low — they are right there and they parse. Nothing on the disc declares that displacement; finding them means searching backwards for a block that looks like a directory, which also turns up a sixth directory-shaped block at 6387 belonging to no volume. It is the arithmetic-where-no-header-agrees that ADR-0015 refused and ADR-0021 upheld, and the displacement is not even constant across the image.
  • Call the damage in the note — claims more than the map supports. The note states the disagreement; the analysis lives in the ADR and the format doc.

What this deliberately does not claim

The notes report and do not diagnose. A free block under an empty volume is an unused slot on one disc and a damaged image on another, and the map cannot separate them — Kickin' Lunatic Beats 2 CD1's VOLUME 018 is very probably the second, since a directory of 14 entries sits 16 blocks below it, and the note still only says the block is free.

No map, no note. A partition declaring nothing usable yields no map, and an empty volume there gets nothing and fails the invariant. Emitting a fallback note would explain away precisely the case the invariant exists to catch.

0x8000 appears 14 times on one disc and never under a volume, so it has no reading and falls to a note that names the code without interpreting it.

Found in passing, deferred

  • AKAI: only the first partition of a multi-partition disc is read #22 — only the first partition of an AKAI disc is read. Partitions tile end to end at multiples of the size declared at 0x00 and hold real content: Advance Orchestra declares 7 680 blocks of an image of 66 616, with partition 2's volume directory sitting exactly where the first ends and its first volume named 01 VA SUS F. Most AKAI discs list a fraction of what they hold. The format doc has said to walk the partition table since it was written; nothing does.
  • A sample payload whose header disagrees with its directory entry is extracted silently #23 — a sample payload whose header disagrees with its directory entry is extracted silently. The nine bad files above are visible for free at the moment the payload is read, on four separate signals, and none is checked.

Verification

All four steps in CLAUDE.md pass. SAMPLERDISC_TEST_DISCS over the curated set: 170 passed, zero skips (126 before; the new AKAI tables and per-disc map check account for the rest). Synthetic fixtures only — akai_partition now writes the block count and a real allocation map, with three keyword arguments modelling the three situations measured on the shelf.

🤖 Generated with Claude Code

Ten volumes across three discs listed empty with no explanation -- the
ADR-0012 signature -- for two different reasons (#16, #17). Each now
carries a note naming the block and what the partition's own block
allocation map at 0x70A says is in it.

No volume or file count moves: 872 volumes and 56 662 files across the
79-image collection, before and after. The map explains an emptiness and
never gates a listing, because the gating fixes cost real audio.

Settles #17 against the container: the four allocated volumes on
Kickin' Lunatic Beats 2 CD1 are not a mis-decode and not stale start
blocks. That image is short of the disc by four 32 KB MDX blocks, which
two independent structures agree on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@bmxcode
bmxcode merged commit c533f4e into main Aug 20, 2026
1 check passed
@bmxcode
bmxcode deleted the d16-akai-empty-volumes branch August 20, 2026 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant