Skip to content

ISO 9660: convert the AIFF, and write each sound once - #27

Merged
bmxcode merged 1 commit into
mainfrom
d16-iso9660-audio
Aug 21, 2026
Merged

ISO 9660: convert the AIFF, and write each sound once#27
bmxcode merged 1 commit into
mainfrom
d16-iso9660-audio

Conversation

@bmxcode

@bmxcode bmxcode commented Aug 21, 2026

Copy link
Copy Markdown
Owner

The Best Service ProSamples discs added a third collection: 29 images,
16 AKAI and 13 ISO 9660. The AKAI half needed nothing -- 472 volumes,
11 730 samples, zero skips. The ISO 9660 half ships every sound twice,
as a full AIFF tree beside a full WAV tree, and extraction wrote both.

AIFF is now carried to WAV rather than copied out as .aiff. The samples
are big-endian and a WAV's are little-endian, so the bytes within each
value are reversed and the values are untouched -- exactly reversible,
no resampling, no change of depth. 8-bit is refused, because AIFF stores
it signed and WAV unsigned and carrying that means adding 128 to every
sample; AIFF-C is refused because it may be compressed and no disc here
has one to check a reader against.

The loop convention was not guessed. An AIFF marks its loop with two
MARK positions and the spec does not say whether the frame at the second
is played. These discs carry a WAV of every sound beside the AIFF, and a
WAV states its loop in a smpl chunk where the end is inclusive, so the
two files answer the question about each other: on 195 of 195 pairs
carrying a loop on both sides the end marker is exclusive, and on all
198 carrying an INST the root key matches exactly. That is the
convention SampleLoop already used for AKAI, so nothing had to change --
the disc confirmed a choice already made rather than settling a new one.

6 033 of the 7 498 AIFF hold audio that is already coming out as a WAV.
Those are reported as duplicates naming the file that holds the audio
instead of being written again. Matched on the audio and never on the
filename, and vol.43 is why: its 1 386 AIFF all share a name with a WAV
and not one shares its audio, being mastered a few frames longer -- 17
638 bytes against 17 616 on 43e-01chh01. A name-based rule would have
discarded a whole disc and said nothing.

A twin is kept where it carries something the written file lacks. On 314
pairs the AIFF has a root key and a loop and the WAV has no smpl chunk
at all. Same audio is not the same file, and deduplicating on the audio
alone would have dropped the metadata with it.

These discs are the only ground truth in this project for what a
conversion should produce. Every other format is checked against the
bytes it came from, which proves the payload was copied and says nothing
about whether it was understood; here the publisher shipped an
independent answer 6 033 times. tests/test_discs.py asserts it, along
with the disc that has no twins at all.

.exs, .fxp and .fxb classify as programs, so --keep-originals writes
them out. They hold the key ranges and envelopes a WAV cannot carry,
which is the argument ADR-0011 already made for AKAI programs, and they
are the shape ConvertWithMoss reads. Roughly 2 200 across the
collection, previously dropped.

Three things this found by running:

Every audio file copied off an ISO 9660 disc reported 0 Hz and 0 frames
-- 15 424 files whose manifest entry said nothing about the audio.
read_header walks to the end of the file rather than stopping at data,
because smpl is written after the audio as often as before it.

A kept original was named twice over: BONGOS M.exs.exs. original_suffix
appends what the backend supplies, which is right for a filesystem whose
names carry no extension and wrong for one whose names do. Without the
backend hook as well, every kept .exs landed in original/ renamed .bin.

A clean disc reported itself as a damaged one. vol.42 printed "skipped
423 damaged or unreadable entries" when all 423 were sounds already
written. Skipped grows a duplicate flag and the summary and manifest
count the two apart.

Across the 29 discs: 29 converted, 21 435 samples, 4 930 stereo pairs,
26 365 WAVs written and every one of them reads back as valid WAV with
audio in it, 5 719 duplicates suppressed, and one entry not written that
was not a duplicate -- a stereo pair on vol.20 whose halves declare
44 033 and 44 100, so the joiner refuses to fuse them and both mono
halves are written instead.

🤖 Generated with Claude Code

The Best Service ProSamples discs added a third collection: 29 images,
16 AKAI and 13 ISO 9660. The AKAI half needed nothing -- 472 volumes,
11 730 samples, zero skips. The ISO 9660 half ships every sound twice,
as a full AIFF tree beside a full WAV tree, and extraction wrote both.

AIFF is now carried to WAV rather than copied out as .aiff. The samples
are big-endian and a WAV's are little-endian, so the bytes within each
value are reversed and the values are untouched -- exactly reversible,
no resampling, no change of depth. 8-bit is refused, because AIFF stores
it signed and WAV unsigned and carrying that means adding 128 to every
sample; AIFF-C is refused because it may be compressed and no disc here
has one to check a reader against.

The loop convention was not guessed. An AIFF marks its loop with two
MARK positions and the spec does not say whether the frame at the second
is played. These discs carry a WAV of every sound beside the AIFF, and a
WAV states its loop in a smpl chunk where the end is inclusive, so the
two files answer the question about each other: on 195 of 195 pairs
carrying a loop on both sides the end marker is exclusive, and on all
198 carrying an INST the root key matches exactly. That is the
convention SampleLoop already used for AKAI, so nothing had to change --
the disc confirmed a choice already made rather than settling a new one.

6 033 of the 7 498 AIFF hold audio that is already coming out as a WAV.
Those are reported as duplicates naming the file that holds the audio
instead of being written again. Matched on the audio and never on the
filename, and vol.43 is why: its 1 386 AIFF all share a name with a WAV
and not one shares its audio, being mastered a few frames longer -- 17
638 bytes against 17 616 on 43e-01chh01. A name-based rule would have
discarded a whole disc and said nothing.

A twin is kept where it carries something the written file lacks. On 314
pairs the AIFF has a root key and a loop and the WAV has no smpl chunk
at all. Same audio is not the same file, and deduplicating on the audio
alone would have dropped the metadata with it.

These discs are the only ground truth in this project for what a
conversion should produce. Every other format is checked against the
bytes it came from, which proves the payload was copied and says nothing
about whether it was understood; here the publisher shipped an
independent answer 6 033 times. tests/test_discs.py asserts it, along
with the disc that has no twins at all.

.exs, .fxp and .fxb classify as programs, so --keep-originals writes
them out. They hold the key ranges and envelopes a WAV cannot carry,
which is the argument ADR-0011 already made for AKAI programs, and they
are the shape ConvertWithMoss reads. Roughly 2 200 across the
collection, previously dropped.

Three things this found by running:

Every audio file copied off an ISO 9660 disc reported 0 Hz and 0 frames
-- 15 424 files whose manifest entry said nothing about the audio.
read_header walks to the end of the file rather than stopping at data,
because smpl is written after the audio as often as before it.

A kept original was named twice over: BONGOS M.exs.exs. original_suffix
appends what the backend supplies, which is right for a filesystem whose
names carry no extension and wrong for one whose names do. Without the
backend hook as well, every kept .exs landed in original/ renamed .bin.

A clean disc reported itself as a damaged one. vol.42 printed "skipped
423 damaged or unreadable entries" when all 423 were sounds already
written. Skipped grows a duplicate flag and the summary and manifest
count the two apart.

Across the 29 discs: 29 converted, 21 435 samples, 4 930 stereo pairs,
26 365 WAVs written and every one of them reads back as valid WAV with
audio in it, 5 719 duplicates suppressed, and one entry not written that
was not a duplicate -- a stereo pair on vol.20 whose halves declare
44 033 and 44 100, so the joiner refuses to fuse them and both mono
halves are written instead.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@bmxcode
bmxcode merged commit 132802e into main Aug 21, 2026
1 check passed
@bmxcode
bmxcode deleted the d16-iso9660-audio branch August 21, 2026 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant