SampleCell discs are Mac HFS volumes behind an Apple Partition Map, not a sampler format

[bmxcode]

Two discs in the test collection are reported as no recognised filesystem. They are filed as "SampleCell", and the working assumption was that ER at byte 0 was an unknown sampler format. It is not — and knowing what it actually is changes the scope considerably.

Which layer

Filesystem. These are Macintosh HFS volumes behind an Apple Partition Map. There is no proprietary sampler filesystem involved at all.

Sampler / hardware

Digidesign SampleCell — a Mac NuBook/PCI sampler card, so its libraries shipped as ordinary Mac media rather than as a sampler-native disc.

What's known about the format

ER is the Apple Driver Descriptor Record, not a magic of ours

Block 0 is a standard Apple DDR (sbSig = 0x4552, 'ER'), and the fields check out against the images:

Field	Vol. 1	Vol. 2
sbSig	0x4552	0x4552
sbBlkSize	512	512
sbBlkCount	576 983	576 998
Image size	577 800 × 512	577 600 × 512

Apple Partition Map at block 1

Vol. 1 carries four entries, Vol. 2 one:

Vol. 1   'Apple'          Apple_partition_map   start 1        63 blocks
         'Silverlining'   Apple_Driver          start 64       32 blocks
         'M/O a'          Apple_HFS             start 96       576400 blocks
         'Extra'          Apple_Free            start 576496   487 blocks

Vol. 2   'Macintosh'      Apple_HFS             start 32       576966 blocks

Silverlining is the well-known Mac disk driver; Vol. 2's block 4 additionally carries Copyright © 1988-91 Pinnacle Micro, Inc., a Cirrus 295MB (SCSI #0) drive string and 68k driver code. These are magneto-optical removable cartridges, not pressed CD-ROMs — which is also why the partition layouts differ between the two volumes.

HFS volumes, and the payload is AIFF

Reading the Master Directory Block at partition start + 1024:

	Vol. 1	Vol. 2
MDB signature	0x4244 ('BD', HFS)	0x4244
Volume name	Sonic Images V1	Sonic Images V2
Files / dirs	926 / 79	404 / 52
Allocation block size	5 120	4 608

Marker counts across each volume: Vol. 1 has 708 FORM and 5 352 AIFF; Vol. 2 has 132 FORM, 1 121 AIFF and 74 Sd2f (Sound Designer II).

So the audio is standard AIFF. Once HFS can be walked, this is the same shape as the existing ISO 9660 backend, which already classifies and copies .aiff payloads.

What supporting it would take

1. Apple Partition Map parsing — small, and it fits the existing origin probe (ADR-0005) rather than needing anything new: the partition map says where the filesystem starts.
2. fs/hfs.py — the real work. HFS is well documented (Inside Macintosh: Files) but it is a full B-tree filesystem, considerably more than the ISO 9660 backend.
3. Nothing at the sample layer — the payload is AIFF, already handled as a copy.

Worth deciding first

HFS is a general-purpose Mac filesystem, not a sampler filesystem, so this is a genuine scope question rather than an obvious yes. The argument in favour is the one already made for ISO 9660: a meaningful share of these collections are not sampler-format discs, and reading them costs a module and saves the user a second tool. The argument against is that anyone with a Mac, or hfsutils, or 7-Zip can already mount these — unlike an AKAI or E-mu disc, where nothing else will.

I lean toward documenting it and not building it, unless more SampleCell discs turn up. Two specimens, both from the same library, and both readable by existing tools.

A free oracle if anyone does build it

The same library exists in this collection in AKAI form — Optical Media International (OMI) - Sonic Images Universe Of Sounds Vol.1, which is mislabelled by its archive as a Roland S-770 disc but is AKAI, and reads today: 28 volumes, 636 samples.

So an HFS implementation can be checked against a known-good extraction of the same sounds, rather than against "the WAVs sound plausible". That is a much better position than most new formats start from.

---

Discs referenced (not attached, per ADR-0008):
OMI Universe of Sounds Sonic Images Vol. 1 (SampleCell).iso (295 833 600 bytes) and Vol. 2 (295 731 200 bytes), both from archive-oldschoolscds.