AKAI/MDX: four allocated volumes on Kickin' Lunatic Beats 2 CD1 yield no files

[bmxcode]

Distinct from #16, though it shows up on the same disc. There the empty volumes are unallocated slots with a default name and a type byte of 0. Here they are allocated volumes with real names, sitting in sequence among thirteen that extract perfectly.

What happens

AMG - Kickin' Lunatic Beats 2 AKAI CD1.mdx lists 18 volumes and extracts 669 files. Four yield nothing:

  12  type=1 start= 4079 '13-TRACK 06'    21 files
  13  type=1 start= 4707 '14-TRK06 MF1'    0 files   <--
  14  type=1 start= 5087 '15-TRK06 MF2'    0 files   <--
  15  type=1 start= 5216 '16-TRACK 07'     0 files   <--
  16  type=1 start= 5648 '17-TRK07 MF'     0 files   <--
  17  type=0 start= 5965 'VOLUME 018'      0 files       (this one is #16)

The four are structurally identical to the thirteen that work — type byte 1, a name following the disc's own scheme, a start block inside the image — and they are the last four allocated volumes on the disc. Every volume up to 13-TRACK 06 extracts.

What is at those blocks

Not directories. Three hold what looks like 16-bit PCM and one holds zeros:

14-TRK06 MF1  block 4707  6b 03 d1 03 2a 04 76 04 70 04 5f 04 56 04 96 04 …
15-TRK06 MF2  block 5087  87 04 f2 04 a1 05 44 06 80 06 46 06 06 06 11 06 …
16-TRACK 07   block 5216  09 00 09 00 0b 00 1a 00 18 00 13 00 06 00 08 00 …
17-TRK07 MF   block 5648  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 …

_files stops immediately on each: the type byte of the first entry is not one of p s d x m q t.

Where to start

This is a compressed .mdx — 378 443 564 bytes on disk expanding to 534 083 584 — so the first question is whether the fault is in the container or in the filesystem. Two readings fit the evidence and they point at different layers:

1. The container returns the wrong bytes past some point. ADR-0006 classifies MDX blocks by decode attempt, so a block that decodes the wrong way would hand back plausible-looking audio rather than an error. The transition is sharp — everything through block 4079 works, everything from 4707 does not — which is the shape a container-side fault would have. The all-zero block at 5648 is also suggestive of a block that produced nothing.
2. The volume start blocks are genuinely stale, as in AKAI: unallocated volume slots keep a stale start block and list as empty volumes #16, and this rip simply lost its last four volumes. The disc is one of a CD1/CD2 pair; CD2 is present and should be checked the same way.

Reading 1 is the one to rule out first, because if the container mis-decodes here it may be mis-decoding elsewhere without anything noticing — and unlike #16 that would mean the 669 files this disc does yield are not necessarily trustworthy either.

A useful cross-check: AKAI.S3000.Sound.Library.1.mdx and the other .mdx images in the collection extract cleanly, so whatever this is, it is not every MDX.

Why it matters

Along with #16 this blocks making the tests/test_discs.py invariant per-volume rather than per-disc. Of 79 images in the collection and 71 claimed by a backend, three fail the per-volume form; this disc is one of them, for this reason and for #16's.

Discs needed

AMG - Kickin' Lunatic Beats 2 AKAI CD1.mdx and CD2.mdx, both present locally.