Game Music Audit: Why 18 Playback Slots Only Map to 17 Audio Files

When "18 Tracks" Becomes a Muddle

In game audio production, candidate tracks, selected works, stored files, and actual playback assignments gradually drift apart. When replacing map music, old files may linger in storage; two scenes may also share the same recording. When production notes say "18 tracks," nobody can quite say what that number is actually counting.

Take VOLT NOMAD as an example. Cross-referencing its production notes against the code revealed that 18 BGM playback slots actually reference only 17 distinct audio files; adding the victory sound effect brings the referenced file count to 18; and the audio directory contains 19 files. Four different numbers, each with a reason to exist.

This audit originated from commit f074703 in the game-jam-lab repository, with a review date of September 11, 2026. It should be noted that the investigation involved no listening comparisons and no music was regenerated — all conclusions come from static analysis of code and files.

Distinguishing Selection Records from Actual Assignment

What the Production Brief Records

The project's music production brief (SUNO_MUSIC_BRIEF.md) records each track's purpose, title, Suno song ID, selected A/B candidate version, and corresponding game file. This is a production-phase "intent record."

The extended notes on enemy-specific music reveal a detail: some initial candidate tracks were eliminated for being too short. The team then regenerated tracks at the specified duration, and made further attempts on candidate versions that still ended early. Records show the original Relay Hydra A version was 1 minute 54 seconds long, and Grid Leech A was 2 minutes 34 seconds.

These durations are historical production records; this investigation did not re-retrieve and measure every Suno candidate version. They can only support a narrow conclusion: during production, duration was indeed a selection criterion.

The Evolution from Candidate to Implementation

The version history advances from the candidate records at 5ab837b to the enemy-specific music at 290d302, and this thread helps distinguish "stored candidates" from music that "actually made it into implementation." The gap between the two is exactly what the audit needs to bridge.

Tracing the Name-to-Playback-Key Mapping Chain

Two Dictionaries, Two Responsibilities

The game's music code contains two dictionaries with different roles. EncounterBGMKeys maps encounter or form IDs to BGM keys; BGMStreams then maps those keys to audio files. Only by completing both steps can you avoid mistaking a renamed key for an unused work.

A few typical mappings:

Encounter ID	BGM Key	Referenced File
gearmaw	hunt	piston_hunt_loop.ogg
vaultback	vaultback	blue_vault_pulse.ogg
phase_mantis	phase_mantis	critical_parallax.ogg
prime_current_form_1	prime_current_form_1	prime_current_crownless_protocol.mp3

Gearmaw's dedicated track uses a generic key name hunt — if you only look at the key name without tracing the mapping chain, it's easy to draw the wrong conclusion.

Selection Logic Determines Actual Playback

The desired_bgm_key() function is the actual executor of selection. Title screen or gallery, normal battle or boss fight, final boss form — all affect its return value. The existence of an entry in the dictionary does not mean the target scene can actually trigger it. Selection branches were also examined, but this investigation did not play through every scene one by one.

18 Slots, 17 BGM Files, 18 Including Sound Effects

Automated Counting Results

Automated counting of the dictionaries and Git-tracked audio yields four different counts:

Counted Object	Quantity
Keys in BGMStreams	18
Distinct audio files referenced by those keys	17
Referenced files including the standalone victory sound effect	18
Stored files in the target audio directory	19

The sources of discrepancy can be explained one by one. singularity and ending_world share arch_singularity.ogg — two separate scene slots do not produce two works. The earlier map track subterranean_hunt.ogg is still stored in the directory but is no longer within the reference scope of the examined BGM dictionary; the current map key points to six_core_descent.mp3. This is a classic case of "keeping the old file after replacement," and the investigation did not delete this unreferenced file.

The production brief's "18 tracks" statement corresponds to distinct BGM files plus the victory sound effect. Maintaining counts of keys, files, and stored material separately can reveal duplicates and omissions during cleanup or porting.

Why Each Count Matters

The four numbers each answer a different question: 18 slots answers "how many playback positions does the game need," 17 files answers "how many distinct BGM segments actually exist," 18 including sound effects answers "how many referenced audio segments are there in total," and 19 stored files answers "how many things are on disk." Confusing them leads to wrong decisions during porting or cleanup.

Differences Between Measured File Durations and Production Notes

Precise Measurements with ffprobe

Running ffprobe on the 19 audio files extracted from Git showed that all audio streams are 48 kHz, 2 channels. Durations of some selected files:

File	ffprobe Duration (seconds)
blue_vault_pulse.ogg	180.040000
cascade_trinity.ogg	179.880000
critical_parallax.ogg	179.800000
nomad_victory_signal.mp3	12.973500

The "3:00" and "0:13" in the production table are rounded descriptions, not precise loop points or stop times. The values above are also just file durations reported by ffprobe, not perceptual measurements of audible sound at the start and end.

The Unresolved Mystery of Loudness Processing

The brief records that initial tracks were mastered to approximately -18 LUFS, but the original WAV files are not in this repository. This investigation neither reproduced that mastering process nor can it confirm whether every track currently has the same loudness. Whether the MP3 files added later underwent equivalent processing cannot be assumed either.

LUFS (Loudness Units Full Scale) is a loudness measurement unit defined in the ITU-R BS.1770 standard, used to uniformly measure the perceived loudness of audio programs rather than simple peak levels. It differs from traditional dBFS (decibels full scale): dBFS describes a signal's amplitude relative to digital full scale, while LUFS incorporates the human ear's sensitivity to different frequencies (via K-weighting filters) and channel energy, making it closer to loudness as actually heard. Streaming platforms typically use around -14 LUFS as reference loudness, while game audio often masters BGM to around -18 LUFS to leave enough dynamic headroom for sound effects and dialogue. LUFS measurements also include different time windows such as short-term, momentary, and integrated (Integrated), with Integrated LUFS most commonly used to describe the average loudness of an entire track. To reproduce or verify mastering results, the original uncompressed files are needed, because lossy formats like MP3 may already have altered loudness characteristics during encoding.

Loop Configuration and Perceptual Approval Are Two Different Things

Loop Enablement at the Code Level

When switching BGM, the implementation layer enables looping for Ogg and MP3:

if next_stream is AudioStreamOggVorbis:
    (next_stream as AudioStreamOggVorbis).loop = true
elif next_stream is AudioStreamMP3:
    (next_stream as AudioStreamMP3).loop = true

Godot's AudioStreamMP3 documentation does record the loop property. But code requesting repeated playback and music being continuous at the start-end junction are completely different issues. This investigation did not audition for seam noise, silence, or beat misalignment.

Ogg Vorbis and MP3 are two common audio compression formats, but their loop support in game engines differs. The Ogg Vorbis format natively supports writing loop point information in file metadata, and the Godot engine can read this metadata and seamlessly jump back to the loop start at the specified sample position. In contrast, the MP3 specification does not include a standard loop point metadata field, so Godot's AudioStreamMP3 class implements looping through the loop property and an optional loop_offset property: when enabled, the entire file plays repeatedly from start to finish. This means MP3's loop point is fixed at the file's beginning and cannot set precise loop intervals in the middle of the file like Ogg can. For music like BGM that requires precise loop continuity, Ogg is usually the more suitable choice; MP3 is more often used for one-shot sound effects or scenarios with lower loop precision requirements. File duration itself is also affected by encoder delay/padding, and the length reported by ffprobe may differ from the actual audible content by tens of milliseconds.

Crossfade Parameters

Two AudioStreamPlayer instances handle scene transitions, with a configured crossfade duration of 0.85 seconds. The short victory sound effect uses an independent player and does not enter the full BGM loop. These observations describe playback code, not measured listening comfort or mix quality.

Preserving Enough Evidence for the Next Replacement

Output of the Verification Script

The verification script reads dictionaries and audio from a fixed commit, recording reference existence, counts, SHA-256 hashes, and ffprobe data. The saved results were generated using ffprobe 9.0.1. The entire process involved no audio conversion or upload.

What Records Are Needed for the Next Replacement

Ideally, the next replacement should preserve: candidate ID, reason for selection, game key, target file, and the degree to which perceptual verification was completed. Such records can both identify playback destinations and indicate which checks remain pending.

The value of this method is not limited to a single project. Any project with a game audio library of some scale can use the three-stage audit of "selection records → playback keys → actual files" to uncover hidden duplicates, omissions, and zombie files. The reason "18 tracks" is unclear is that it mixes four different levels of counting together — broken apart, every number becomes clear and explainable.

One-line Summary

A static audit of code and files breaks down the four counting meanings of "18 tracks," revealing duplicates, omissions, and zombie files in a game audio library.

Paragraph Summary

Using the VOLT NOMAD project as an example, the article conducts a static audit of its game audio library. The investigation found that the "18 tracks" statement conflates four different levels of counting: 18 BGM playback slots, 17 distinct referenced audio files, 18 referenced files including the victory sound effect, and 19 files actually stored in the directory. The discrepancies stem from two scenes sharing arch_singularity.ogg, and the replaced subterranean_hunt.ogg remaining as a zombie file in storage. The article also explains how the code's two-layer dictionary mapping (EncounterBGMKeys and BGMStreams) determines actual playback, the differences between ffprobe-measured durations and the rounded values in production notes, and the distinction between loop-enabling code and perceptual verification. Finally, it proposes a chain-record method of "candidate ID → reason for selection → game key → file → degree of perceptual verification" for any game audio library project to reference.