Music hardware variants

Native exports and command inventories. Reproduce with python3 tools/extract_music_variants.py.

There are six music selections, each with five hardware-specific resources. The driver banners establish these targets:

Initial gallery export: format and scope

All thirty are custom Sound Images Generation 2 DOS sequences, rather than SMF MIDI, WAV, or tracker MOD files. Each has one song, a resource-relative directory and descriptor, and timed command streams. All parse using the recovered common command grammar and all parts reach their first loop at the corresponding SCC-1 arrangement's end tick. Division and initial tempo also agree across the five versions of each piece.

The new export preserves the entire native resource, including bytes outside parsed streams, and provides all five original executable drivers. The JSON inventories retain exact command bytes, operands, source positions, musical ticks and loop destinations. They deliberately omit a MIDI interpretation: at the time of this initial export, only the SCC-1 interpretation had been verified by executing the driver. The later runtime verification below covers all four sampled arrangements. Successful parsing of the other variants is structural evidence, not equivalent to verifying their hardware output.

The main listening gallery now has a five-way hardware selector. The SCC-1 MIDI mapping is verified against its original driver. The other four variants have provisional MIDI and Ogg comparisons: python3 tools/render_music_variants.py applies the recovered SCC-1 mapping to each native sequence and renders with the same FluidSynth/FluidR3 GM settings. This allows comparison without waiting for full hardware reconstruction.

These provisional versions preserve source tick positions and the commands handled by that mapping, but pass native instrument numbers through as GM program numbers. They omit opcode 97's effect and inherit the SCC-1 treatment of opcode 99 (last-note release only on channels 0–11). They may therefore have incorrect instruments, envelopes, pitch behaviour or note releases. They are not verified emulations of Sound Blaster FM, LAPC-1, GUS or AWE32 playback. Original command inventories remain separate and preserve commands omitted by MIDI conversion. All exports stop at the first loop and add all-notes-off; listening copies include a release tail and no DC blocker or corrective filter.

At that stage, FM instrument/register handling, LAPC-I instrument setup, GUS instrument loading and AWE32 synthesis setup still needed tracing. Native FM playback and the LAPC-I upload have since been reconstructed, as described below. No separate instrument or sample bank extraction is claimed by this pass. Complete native sequences and executable drivers remain available. Provisional render settings, source/MIDI/audio hashes and omitted opcode-97 counts are recorded in analysis/audio/variants/previews.json.

The gallery can be rebuilt without rerendering audio using python3 tools/music_gallery.py. The SCC-1 render script also rebuilds it.

Measured differences

Number of source sequence parts (including any setup or inactive parts):

Differences are not confined to instrument selection:

• Group 2 has 521 note commands in SCC-1 versus 609 in LAPC-1, GUS and AWE32, and 374 in Sound Blaster. These count opcodes 00–7F; they are not counts of distinct pitches or a claim about perceived musical complexity.
• Group 6 has 1,264 opcode-95 commands in LAPC-1 versus 2,773 in SCC-1, GUS and AWE32. Opcode 95 is pitch bend in the verified SCC-1 driver. Hardware-specific semantics still require verification in the others.
• Sound Blaster streams make extensive use of opcode 97, whereas the other variants do not use it in these arrangements. Its Sound Blaster meaning needs tracing rather than inheriting the SCC-1 handler's meaning.
• SCC-1 and AWE32 use opcode 9D controller pairs; LAPC-1 and GUS arrangements omit them. Even variants with matching part and note counts are not assumed identical.

manifest.json includes resource sizes, SHA-256 hashes, opcode histograms and end ticks. Native files are byte-for-byte copies of the previously unpacked resources. The per-part JSON can support detailed arrangement comparisons without conflating source commands with a particular synthesiser's behaviour.

Unified output layout

All five hardware variants use analysis/audio/variants/group-N-HARDWARE.*:

• .bin: unchanged native sequence.
• .json: native command inventory, without assumed MIDI semantics.
• .mid and .ogg: MIDI conversion and listening rendition.
• -check.json: source PCM and encoded audio diagnostics.
• SCC-1 additionally has -events.json: decoded MIDI events used by the original-driver verification harness.

variants/previews.json is the single playback/provenance manifest for all 30 renditions. Its file paths are relative to analysis/audio/; each entry records whether driver semantics are verified. Renderers update their own resources while preserving the other variants. scc1-sequences.json and scc1-verification.json retain the SCC-1 extraction summary and verification results. The top-level analysis/audio/ contains the gallery and the variants/ and effects/ directories; there are no duplicate top-level music exports.

FM hardware variants and AWE32 effects

Sound Blaster model names do not uniquely identify the FM synthesiser. The main historical distinctions are:

Creative's Sound Blaster programming manual describes the OPL2/OPL3 distinction. Emulator implementations also distinguish Creative CQM from Yamaha OPL. The SB16's 16-bit sampled-audio capability does not automatically improve FM instruments. Games must explicitly use the additional OPL3 features to benefit from them. Physical cards can also differ in output filtering, mixing and noise.

Darker's reconstructed FM music path uses OPL2-compatible features. Our DBOPL and Nuked selections are alternative synthesis implementations, not named Sound Blaster card profiles. --music=soundblaster_fm --opl=nuked uses an OPL3 emulator in its OPL2-compatible mode; it does not emulate an entire AWE32 board.

A Yamaha-equipped AWE32 contains an OPL3 FM synthesiser as well as the separate EMU8000 sample synthesiser. The existing soundblaster_awe32 music mode uses the latter and the game's AWE32 arrangement. It is not an enhanced rendering of the FM arrangement.

There is, however, an additional AWE32 signal path worth distinguishing: OPL FM output can receive EMU8000 reverb and chorus, depending on the card configuration. The Linux EMU8000 driver explicitly initialises the FM input channels and exposes FM reverb and chorus depths. This could change the sound heard from an AWE32 while a game is using its ordinary FM driver. A subsequent trace of Darker's AWE32 library found that it initialises the FM input channels with zero reverb and chorus sends. The additional game setup call adjusts music volume, not FM effects. See the hardware-effects investigation. Externally configured effects in an ordinary FM setup remain a separate machine-configuration variable; the developers' own settings are unknown.

Our current DOSBox-derived EMU8000 core leaves the incoming OPL audio connection unimplemented: its source marks the FM memory/input path as unfinished. A meaningful soundblaster_fm_awe32 experiment would therefore require implementing and verifying that connection and selecting documented effects settings. Simply adding an alias would not reproduce it. That extension remains deferred in light of the zero-send configuration; no such mode is currently exposed, and no extra reverb or chorus has been added to FM.

Stereo in the current music modes

All modes feed a two-channel output device, but two channels do not necessarily contain different signals. The following describes the current default music backends, rather than every possible historical card or SoundFont override:

We checked the rendering paths and compared left and right samples in the first ten seconds of every available section in the complete native FLAC collection. All 13 FM sections had identical channels in those excerpts; every other exported mode had sections with unequal channels. SCC-1A stereo was additionally confirmed in the 30-second group-1 comparison render. These are excerpt checks, not a claim that every instant of every stereo arrangement differs between channels. Centred instruments and passages can produce identical left/right signals, while panning and device effects can create stereo elsewhere.

The original effects hardware detector can disable effects on a standalone music device without OPL hardware. Our reconstruction supplies FM effects independently of music-device selection.

Flight sound-effect positioning is separate from music. Mono FM music does not imply that all game audio is mono. SoundFont overrides may also change the stereo character relative to the native hardware backend.

Runtime sequencer verification

The reconstruction offers --music=none|soundblaster_fm|midi|roland-lapc|roland-sc55|roland-scc1a|gravis|soundblaster_awe32. Sound Blaster retains the native FM instrument path. midi remains the SCC-1 arrangement through a selectable SoundFont bank; roland-sc55 plays that arrangement on an emulated SC-55. LAPC-I uses Munt and the original custom instrument upload, AWE32 uses its native synthesis library and EMU8000, and Gravis uses UltraMID and GF1. Explicit SoundFont overrides remain available. Runtime playback loops continuously rather than stopping at the end of the gallery preview.

The four sampled drivers have now been executed for 16,384 scheduler updates per arrangement and compared with the C++ sequencer's timed events. SCC-1, LAPC-I and GUS are captured at their MIDI byte-output routines; AWE32 is captured at the equivalent note, program, bend and controller calls into its synthesis library. All 24 streams match, including repeated loops. The original PIT cadence and Q16 tempo arithmetic are preserved. This verifies the runtime event mapping beyond the initial provisional gallery conversion described above; it does not retroactively change the existing MIDI/Ogg exports.

Two differences matter: SCC-1 command 99 releases the previous note only on channels 0–11, whereas the other three sampled drivers release it on every sequence channel. GUS also omits the initial channel-volume writes made by the other drivers. Their command 94 consumes no argument; this differs from the Sound Blaster version.

LAPC-I initialisation at 07DF–08F9 uploads custom Roland timbres and patch assignments through SysEx. A generic GM SoundFont cannot reproduce those uploads. Its rendition therefore preserves the arrangement's note/control stream but not necessarily the intended instruments. The other sampled variants likewise depend on the chosen bank rather than the original card's sample ROM, patches, envelopes, effects and voice allocation. Roland emulation is now available through Munt as described below.

Original Roland instrument upload

The LAPC-I driver initialiser at 07DF expands its instrument table at 1A98 and emits 824 bytes through MIDI output routine 07A7. The captured SysEx upload and decoded message data contain twelve Roland DT1 messages: six timbres followed by six patch assignments. The reconstruction reproduces this upload byte-for-byte before Munt playback.

These are custom synthesis definitions, including oscillator, filter and envelope parameters, rather than uploaded audio samples. The ten-byte names are skipped, so the driver does not supply descriptive names. Every patch assignment selects memory timbres, neutral key shift and fine tuning, twelve-semitone pitch bend, assignment mode zero and reverb disabled.

--music=roland-lapc --mt32-rom-dir=/path/to/roms selects Munt instead of SoundFont playback. It requires a compatible control/PCM ROM pair supplied separately. CM-32L is preferred for the LAPC-I driver; MT-32 pairs are also recognised. The custom instruments survive music changes. Native upload and sequence comparisons are independent of ROM availability. Six-group PCM checks have passed with both MT-32 1.07 and CM-32L 1.02 ROM pairs.

Unmapped Roland percussion notes

Munt's Rhythm: Attempted to play unmapped key diagnostic also occurs with correct CM-32L ROMs and the original LAPC-I sequence events. In the CM-32L 1.02 control ROM, rhythm settings begin at 8580; entries for MIDI keys 52, 55, 57 and 58 are [127, 0, 7, 0]: the timbre is OFF and the output level is zero. Munt therefore ignores those notes, rather than substituting General MIDI drums.

We executed the full native driver initialiser at 0713, emulating only the MPU-401 acknowledgement/command transport and delay, and captured MIDI output at 07A7. It produces exactly the same 824 bytes as the instrument uploader at 07DF: six timbre definitions and six patch assignments, with no rhythm-map upload. The unused generic SysEx sender at 07BC has no direct caller or function-table entry in this driver.

Native scheduler execution over 16,384 updates per group gives these nonzero- velocity note-on counts on MIDI channel 10 (status 99h):

These events are already covered by the native timed-stream regression checks. The evidence indicates an original arrangement quirk with factory rhythm settings, not missing custom-instrument initialisation. Assigning replacement drums changes the playback; no remapping is applied by default. The optional experiments below deliberately supply replacements. The diagnostic is not a ROM loading failure and does not stop other notes playing.

Opening Roland arrangement: independently looping part

The opening LAPC-I resource (00/40) has twelve sequencer parts. Eleven set their loop markers at musical tick 3504; part 10 sets its marker at tick 3888. All first jump at tick 12672. Executing the original 00/35 driver under Unicorn confirms this is not a static-export artefact: handlers 03B3 (store loop pointer) and 03AF (restore it) record the expected targets. Both first jumps occur at scheduler call 4043; subsequent jumps occur at 6968 for part 0 and 6846 for part 10. No compensating delay is added by the jump handler.

The intro contains the same three-note figure (65, 72, 68) at staggered starts: part 8 starts at tick 2208, part 9 at 2400, and part 10 at 2592, with the next two notes 96 ticks apart. Moving part 10 earlier by 384 ticks therefore aligns it with part 8; that fit alone does not establish incorrect decoding. Whether the unequal loop lengths reflect intended variation or an authoring error remains unknown.

Execution trace and FLAC inspection stems preserve the evidence. For the opening exports, track1 groups the eleven parts with the common loop, while track2 contains original part 10; both intros retain their complete leading silence from time zero.

Roland GM-bank experiments

The manual's “Roland” selection uses the LAPC-I/MT-32-family driver. It is separate from the SCC-1/Sound Canvas driver behind “General MIDI”, even though both hardware families were made by Roland. The LAPC-I initialiser checks the MPU transport acknowledgement, not the attached synthesiser's identity, and sends no device reset. A pre-existing synthesiser configuration could therefore matter; we have no evidence identifying the composer's actual configuration.

Roland supplied an MT-32 General MIDI conversion bank, not a replacement ROM. Its MTGM.MID is a setup file containing SysEx. The accompanying instructions date this version to 7 December 1993. Roland's download page provides MT2GM.EXE, which is an archive readable with unzip, despite its extension. The existing control and PCM ROMs suffice. MTGM.MID is 27,607 bytes, SHA-256 0d0308e00f9045241013f4943c21ba97cb59c3e4e723251ee05f9431b96fdc3c.

Three optional experiments were implemented, all with --music=roland-lapc:

The two percussion options retain the original events on the main device, so its unmapped-key diagnostics remain audible-event references in the console. Already-mapped percussion is not doubled. The options are alternatives, not switches to stack together. Omitting them restores original factory-map playback.

The full bank replaces all 64 writable timbres, changes patch assignments, partial reserves and receive channels. In particular, melodic receive channels become 1–8 instead of the factory 2–9: this can change which parts sound, not just their instruments. Applying Darker's six timbres afterwards does not undo those other changes. Some bank writes lie outside Munt's recognised memory regions and are reported and ignored. None of these experiments proves that Darker expected this bank; the separate-device option is a reconstruction of missing percussion, not a claim that the original used two devices.

What plays on the drifting opening part?

For discussion and export, track1 means the eleven parts sharing the common loop; track2 means original sequencer part 10. These are research stem names, not original titles, MIDI channel numbers or a long/short classification.

Track2 uses MIDI channel 8 (zero-based 7). It selects zero-based program 24, Syn Brass 1, at tick 1585, then program 32, Fantasy, at tick 6576. Its first notes after that second selection occur at tick 6578. These are factory melodic patches, not Darker's six uploaded patches, and not the missing rhythm notes. The out-of-sync part therefore exists without either percussion repair. Adding percussion did not create it.

The common loop lasts 9168 ticks; track2 lasts 8784 ticks. Their first loop jumps coincide, but later jumps drift. Their loop boundaries realign after 1,677,744 ticks: 183 common loops and 191 track2 loops, approximately 2 hours 58 minutes 25 seconds after the first common jump. This is a sequencer boundary, not a guarantee of identical synthesiser oscillator or reverb state.

An audit of all thirty arrangements found no equivalent drifting opening loop outside LAPC-I. The FM version of group 2 does contain a shorter loop: one part repeats every 768 ticks against 4608 ticks for the others, an exact six-to-one relationship. That is different from the LAPC-I opening's gradual displacement. The remaining arrangements have matching per-part loop lengths.

Listening under DOSBox did not clearly reveal track2. That observation does not contradict the native event trace: MIDI routing and synthesiser state still need identifying for that listening configuration. It is not evidence of an extra pause or a different loop handler in the original driver.

Corrected listening references and interpretation

The team prepared two hand-corrected opening mixes for future research:

• Group 1 — corrected intro
• Group 1 — corrected loop

Both are 139.359-second, 48 kHz stereo, 16-bit FLAC files. They are edited listening references, not native timing exports; their names identify their intended roles, not the native intro/loop boundaries. They were supplied as finished mixes and have been retained unchanged. The exact edit operations, gains and joins have not been independently reconstructed.

During comparison, moving track2's introductory melody earlier to align its end with track1, and aligning its loop to the end of track1's loop, produced a much more convincing musical fit. The corrected mixes preserve the team's proposed interpretation for listening. They do not replace the unmodified stems, source sequences or native execution trace. See the recording catalogue and provenance for both sets; the manifest records the corrected files separately.

Our working hypothesis is that the LAPC-I version was an adaptation of material primarily developed or checked on another setup, leaving unmapped percussion and an unintended loop mismatch. Supporting evidence includes the isolated loop anomaly and shared percussion material: in group 1's source streams, SCC-1, GUS and AWE32 each contain six key-52, three key-55, three key-57 and twelve key-58 note commands; LAPC-I retains two key-52, three key-57 and twelve key-58 commands. These are source-command counts, not the repeated native scheduler counts above, and do not establish identical event timings.

This is an inference, not confirmed authorship history. Another Roland device, such as a Sound Canvas, remains a candidate for the primary setup. Musical plausibility alone cannot identify a canonical mix or the composer's hardware.

Remaining hardware comparison work

The runtime event streams have been verified. Native AWE32 and Gravis synthesis are now implemented as described below; physical-hardware recordings can help check the emulator cores' remaining timbral differences. The original SCC-1 revision still awaits its internal processor ROM; the later SCC-1A v1.30 now has a verified complete set and native playback. The SC-55 is an independently identified and working period General MIDI alternative.

Nuked-SC55 supports CM-300/SCC-1 hardware when supplied with a complete matching ROM set. Further comparisons should help separate arrangement choices from device timbres, but cannot by themselves prove which hardware was used during composition.

SC-55 playback implementation

--music=roland-sc55 now provides SC-55 v1.21 hardware emulation for the original SCC-1/General MIDI arrangement, through the Nuked-SC55 backend. The existing midi option remains a SoundFont rendition. roland-lapc selects LAPC-I/MT-32-family emulation; the ambiguous former roland name now produces guidance to choose roland-lapc, roland-sc55 or roland-scc1a. This is a faithful SC-55 playback configuration, not a claim of SCC-1 hardware identity. The five v1.21 firmware/sample ROMs are fetched separately, identified by SHA-256 at runtime, and never embedded in the executable. The tested source is this ROM collection. The original SCC-1 v1.10/v1.20 set is still unavailable locally: its internal processor ROM R15199774 is the outstanding file. Its absence does not prevent running the same MIDI arrangement on a correctly emulated SC-55.

SCC-1A playback and comparison with SC-55

--music=roland-scc1a now runs the same original SCC-1/General MIDI event stream on Nuked-SC55's CM-300 hardware path with SCC-1A v1.30 firmware. The complete set in 8vvq0a.zip (roms/scc1a/) matches all five upstream SHA-256 definitions. Its paired program ROMs are R00128523 and R00128567; its three wave ROMs are R15279806, R15279807 and R15279808. This resolves emulation for the SCC-1A revision, not the missing original SCC-1 MCU.

Place cm300_rom1.bin, cm300_rom2.bin and cm300_waverom1.bin through cm300_waverom3.bin beside the packs, or supply --scc1a-rom-dir. ROMs remain external runtime assets; the existing SC-55 choice remains available.

We compared the first 30 seconds of each of the six music groups, starting a fresh device for each rendition. Both received the same native event sequence, with three seconds of firmware boot before playback. Measurements use 48 kHz stereo float output at unity gain, without clipping or normalisation. Full measurement results include RMS levels, peaks, waveform correlation, timing search and band power.

Broad band powers use mono downmixes, 4096-sample Hann windows, and bands 0–200, 200–1000, 1000–4000 and 4000–12000 Hz. Above 12 kHz, group 6 differs by +2.77 dB; the other groups differ by less than 0.20 dB in that band. Searching ±50 ms for a constant offset raises mono waveform correlation to 0.20–0.74 depending on the group, so a single fixed delay does not explain all the differences. Ten-millisecond RMS envelope correlations range from 0.53 to 0.97.

The renders are not sample-identical, but their average levels and broad spectral balance are very similar. These measurements do not establish a large perceptual change, identify which firmware behaviour causes each difference, or determine the composer's original hardware. Phase, modulation, voice timing and effects can all change waveform correlation without changing the overall instrument character. A listening comparison remains useful.

Both devices passed note playback, reset and exact output equality across 512- and 257-frame host buffers. SCC-1A also started successfully in the normal Debug game executable using ROMs installed beside the game packs.

Native AWE32 and Gravis playback

The reconstruction now offers native synthesis for the remaining two sampled arrangements. --music=soundblaster_awe32 uses the AWE32 sample ROM and an EMU8000 emulator; --music=gravis uses the original UltraMID resident driver and Gravis patches with a GF1 emulator. Explicit --soundfont overrides retain the previous comparison renditions. Sound effects remain on their separate original OPL path.

AWE32

Resource 00/37 contains both the Sound Images sequencer and Creative-style synthesis library. Its initialiser at 1002 installs the preset tables at 4818, 4A20, 4B8C, 5100, 5266, 5830 and 82AE. Note-on enters at 3EEA, note-off at 3E0A, controller changes at 4314, programs at 4454 and pitch bend at 45FE. The existing verified C++ sequencer now invokes those original library functions in an isolated x86 instance; their I/O drives the EMU8000 instead of being intercepted and redirected to a generic SoundFont.

An important compatibility detail occurs at 2B8E: this old library compares the device identification against exactly 000C. The upstream EMU8000 core reports 001C, causing the library to return success without most hardware initialisation. Reporting the earlier 000C revision enables the original initialisation sequence. Native sample-counter polling must also advance the emulated chip, including shutdown/release operations.

The sample ROM is the 1 MiB awe32.raw from the 86Box ROM collection. The synthesis core comes from DOSBox-X's EMU8000 implementation, derived from 86Box. The ROM stays a runtime asset.

Gravis UltraSound

Resource 00/36 locates UltraMID using its ULTRAMID signature at offset 0103 in a segment referenced by interrupt vectors 78–7F. MIDI output at 0E5D passes a byte in CL to resident service AX=0010. Patch loading, program interpretation, voice allocation and envelopes belong to that resident driver, not Darker's sequencer.

The reconstruction runs UltraMID 1.12 with the documented -c preload option, a 1 MiB GF1, port 240, DMA 3 and IRQ 5. Its original ULTRAMID.INI is important: the 1024K column maps GM programs to a reduced set of patches that fits card memory. This uses 85 distinct patches, rather than loading every individually named GM instrument. For example, program 0 maps to the bright-piano patch. These substitutions are original driver behaviour, not missing extraction.

The preserved Gravis installation in Boxer supplies the executable, INI and patch data. The UltraMID programming manual describes preload mode and resident services. The GF1 core is isolated from the pinned DOSBox source already used for FM effects. A small private DOS-service adapter supports startup, read-only patch loading, memory and DMA; it does not run the game or a full DOS operating system. Hardware interrupts execute UltraMID's original envelope handling, and hardware continues advancing while the library waits for voice ramps to finish.

Both hardware paths pass note/release, consecutive-group and output-block-size checks. Gravis additionally renders twenty seconds of all six groups on a separate audio thread. Original timed sequence comparisons are unchanged. These are working original-driver hardware emulations; analogue-output identity and the composer's preferred hardware still require independent evidence.

Register-polling audio continuity correction

Listening and waveform inspection exposed periodic clicks in the first native Gravis and AWE32 implementations. Both advanced their chip emulation during native register reads but discarded the resulting PCM. These missing waveform segments caused discontinuities even in offline exports; the problem was not host audio underruns. Both adapters now retain runtime polling samples in playback order. Gravis also counts those samples towards its BIOS clock.

The three-minute opening captures use the fixed playback path:

• Gravis.
• AWE32.

These are uninterrupted diagnostic captures of the opening arrangement, not intro/loop stems. The Gravis correction removes the 57 sample-to-sample steps larger than 0.2 in the first ten seconds of the previous stereo float export. Instrument balance and hardware fidelity remain separate listening comparisons.

Gravis RAM selection

--music=gravis --gus-ram=256 selects 256 KiB of card RAM. The other supported sizes are 512, 768 and 1024; 1024 remains the default. This changes the DRAM detected by the original UltraMID executable, which selects the matching preload column in ULTRAMID.INI. It does not replace the patches with a modern bank or change Darker's sequence. All four sizes use ULTRAMID -c.

Darker forwards MIDI to the resident driver rather than loading instruments per song. Per-song loading is an UltraMID capability, but is not offered here: it would change the game's original approach. The fetch script supplies the union of patches required by the four original preload maps. All six groups are checked at every RAM size.

Complete native music FLAC sections

The lossless music collection provides complete intros and loops for Sound Blaster FM (DBOPL), General MIDI (FluidR3), Roland LAPC-I/CM-32L, Roland SC-55, Gravis UltraSound with 1 MiB, and AWE32. All are 48 kHz stereo, 24-bit FLAC, rendered through the current engine without fades, per-track normalisation, filtering or extra tails. SC-55 exports alone use a fixed gain of 0.5 (−6.0206 dB), because their floating-point peaks exceed full scale; this avoids clipping while preserving relative levels between its pieces. Other modes use unity gain. Smaller Gravis RAM settings are not exported. Existing Roland GM percussion-bank exports are linked rather than duplicated, and the hand-corrected Roland research mixes remain unchanged.

The LAPC opening and FM group 2 have separately repeating parts, so those pieces are supplied as two parallel stems. Start both intros together; each then proceeds immediately into its own repeating loop. Leading silence is included. Group 6 starts directly with its loop. See the collection's timing notes and manifest for original part numbers, sample boundaries and hashes.

Scene and briefing music mapping

The scene and music catalogue lists the fresh entry path for all 124 script records, following explicit page chains and exposing music changes. Each of the six groups links to complete intro/loop FLACs for the exported hardware modes. The presentation browser groups animation clips by scene and links their active music directly.

Group numbers are one-based, whereas opcode 40 takes a zero-based selector. Level 1 starts with group 6 for the quotations, then changes to group 2 for the welcome and briefing. Startup and menu music use group 1; death/committal and the final presentation select group 6. Flight itself has no background music. Records without a selection inherit caller state; seamless continuation can bypass a briefing, so this catalogue must not be read as a compulsory playlist for every entry route.