Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to XM (file format).
Nothing was collected or created yet.
XM (file format)
View on Wikipediafrom Wikipedia
| XM | |
|---|---|
| Filename extension |
.xm |
| Internet media type |
audio/xm |
| Magic number | 0x1A at offset 37[1] |
| Developed by | Fredrik Huss (Mr.H of Triton) |
| Initial release | 1994[1] |
| Type of format | Module file format |
| Extended from | MOD |
XM, standing for "extended module", is an audio file type introduced by Triton's FastTracker 2.[2] XM introduced multisampling-capable[3] instruments with volume and panning envelopes,[4] sample looping[5] and basic pattern compression. It also expanded the available effect commands and channels, added 16-bit sample support, and offered an alternative frequency table for portamentos.
XM is a common format for many module files.
The file format has been initially documented by its creator in the file XM.TXT, which accompanied the 2.08 release of FastTracker 2, as well as its latest known beta version: 2.09b. The file, written in 1994 and attributed to Mr.H of Triton (Fredrik Huss), bears the header "The XM module format description for XM files version $0104." The contents of the file have been posted on this article's Talk subpage for reference.
This documentation is however said to be incomplete and insufficient to properly recreate the behaviour of the original program. The MilkyTracker project has expanded the documentation of the XM file format, in an attempt to replicate not only the behaviour of the original software but also its quirks. Their documentation of the XM file format is available on the project's GitHub repository.
OXM (oggmod) is a subformat, which compresses the XM samples using Vorbis.[6]
Supporting media players
[edit]- Windows Media Player – supports .XM files as long as the player version is x86 (32-bit). The UWP version dropped support for .XM files.
- Cowon jetAudio – A freeware audio player for Windows which supports .XM files
- Xmplay – A freeware audio player for Windows which supports .XM files
- Foobar2000 – A freeware audio player for Windows that supports .XM files through a plugin.
- VLC Media Player – An open-source media player for Windows, Linux, & macOS which supports .XM files
- MusicBee – A freeware audio player for Windows which supports .XM files
- OpenMPT – An open-source audio module tracker for Windows which supports .XM files and others, such as .MOD and .S3M.
- Audacious – an open-source audio player focused on low resource usage.
- Winamp - A proprietary audio player for Microsoft which supports .XM files
References
[edit]- ^ a b Kameñar, Vladimir (2007). The Unofficial XM File Format Specification. Colombia: CelerSMS. ISBN 978-958-53602-0-4. OCLC 1262695345.
- ^ Varga, Martin (2014). Learning AndEngine. Packt Publishing Ltd. ISBN 978-1-78398-596-8.
music composing (using the famous FastTracker 2)
- ^ Sawyer, Ben; Dunne, Alex; Berg, Tor (1998). Game Developer's Marketplace. Coriolis Group Books. p. 295. ISBN 978-1576101773.
- ^ Perekh, Ranjan (2006). "Audio File Formats and CODECs". Principles of Multimedia. McGraw Hill. p. 247. ISBN 0-07-058833-3.
- ^ Alves de Abreu, Valter Miguel (2018-07-17). "Analysing trackers and their formats". Recreating tracker music sequencers in modern videogames: an integrated model approach for adaptive music (MSc). University of Porto. p. 17. S2CID 192364225. Retrieved 2021-06-03.
- ^ Sweet, Michael (2014). "MOD File Sequencing". Writing Interactive Music for Video Games. Addison-Wesley. p. 272. ISBN 978-0-321-96158-7.
See also
[edit]XM (file format)
View on Grokipediafrom Grokipedia
History and Development
Origins and Creation
The XM file format, standing for eXtended Module, was created in 1994 by Fredrik Huss, known as Mr. H, a member of the demogroup Triton, specifically for use with the tracker software FastTracker II, which he co-developed with Magnus Högdahl (Vogue).[6][7] This development occurred within the context of the burgeoning PC demoscene, where Triton sought to advance music composition tools beyond the limitations of earlier formats. XM emerged as an extension of the earlier MOD format, originally popularized on the Amiga, by incorporating more advanced features such as multisampling-capable instruments and support for higher channel counts to enable richer, more complex compositions on evolving PC hardware.[8] The format was designed from the ground up rather than as a mere variation of ProTracker-style modules, allowing for greater flexibility in sample manipulation and pattern sequencing.[9] The initial release of XM accompanied a pre-release version of FastTracker II in 1994, supporting up to 32 channels and 16-bit sample depths, which significantly expanded creative possibilities compared to the 8-bit, 4-channel constraints of prior standards.[6][7] In the 1990s demoscene, where trackers like FastTracker II were essential for composing music on resource-limited PCs and Amigas, XM quickly gained traction among musicians for its efficiency in producing high-quality chiptunes and demos.[10]Evolution and Extensions
The original documentation for the XM format, provided in the XM.TXT file bundled with FastTracker II version 2.04, was authored by Mr. H of the Triton group in 1994 and released into the public domain.[11] This document described the core structure for XM version $0104 but contained notable incompletenesses, such as unclear details on instrument autovibrato sweep types and flawed notes on linear period tables for playback interpolation.[11] Subsequent updates in a 1995 revision by Guru and Alfred of the Sahara Surfers group added corrections, such as adjusting the note range to 1-96 (with 97 for key-off) and fixing the version identifier to $0104, yet gaps persisted in areas like envelope behavior and certain effect implementations.[11] In the early 2000s, community efforts addressed these deficiencies through corrections and extensions to the specification. ByteRaven and Wodan of the TNT/NO-ID group revised the original document, clarifying ambiguities in pattern compression and instrument envelopes based on reverse-engineering FastTracker II behavior.[2] Further detailing emerged from developers associated with MilkyTracker, including a comprehensive guide compiled by Matti "ccr" Hamalainen (TNSP) between 2000 and 2001, which incorporated real-world testing and prior modifications to fill gaps in loader implementation details like sample looping and effect chaining.[3] Unofficial extensions to the XM format have since introduced non-standard features while preserving much of the original structure. The ADPCM-compressed XM subformat, pioneered by ModPlug Tracker in the early 2000s, enables 4-bit ADPCM compression of samples to reduce file sizes by approximately a factor of two, though it applies a low-pass filter effect that slightly degrades audio quality.[2] In 2006, the μFMOD library introduced the Stripped XM subformat, which omits redundant header fields like song and instrument names to further minimize file sizes for embedded applications, supported by tools such as XMStrip for conversion.[2] Another extension, OXM, compresses instrument samples using Ogg Vorbis while retaining the XM framework, achieving significant size reductions for distribution; it originated around 2003 and is playable in compatible engines like FMOD.[2] A more exhaustive unofficial specification was published in 2021 by Vladimir Kameñar, titled The Unofficial XM File Format Specification, which comprehensively documents the original FastTracker II structure alongside the ADPCM and Stripped subformats at the bit-and-byte level, drawing on prior community work to resolve remaining ambiguities.[2]File Format Specification
Overall Structure
The XM file format employs a sequential layout that commences with the XM header, which provides essential metadata about the module, followed immediately by the headers for each pattern along with their corresponding packed data. Subsequent sections include the headers for each instrument, each potentially containing up to 16 sample headers, and concluding with the raw sample data blocks themselves. This organization supports a variable number of patterns (up to 256) and instruments (up to 128), enabling flexible module sizes while maintaining a linear reading order for playback engines.[2] Identification of XM files relies on the magic byte 0x1A positioned at offset 37, directly after the fixed identification string "Extended Module: " (17 bytes) and the module name (20 bytes padded with spaces). The conventional filename extension is .xm, and the Internet media type assigned to XM files is audio/xm, facilitating recognition by media players and libraries.[2][12] The header_size field at offset 60 specifies the length of header data from that offset, typically 276 bytes for standard modules (total header length 336 bytes), but variable and as low as 21 bytes for stripped variants (total 81 bytes). This accommodates different levels of metadata, such as a shortened pattern order table in stripped modules while retaining core structural data. The total file size is not fixed but calculated dynamically as the sum of the XM header length, the aggregate sizes of all pattern headers and data, all instrument and sample headers, and the raw sample data lengths, allowing for efficient storage without padding.[2] To optimize storage, pattern data utilizes a form of run-length encoding-like compression, where note, instrument, volume, and effect events are packed into compact binary representations, with the most significant bit signaling compression flags for efficient unpacking during playback. Sample data, stored as raw PCM, incorporates delta encoding for 8-bit and 16-bit signed integers, representing each value as the difference from the previous sample to reduce redundancy in waveforms with gradual changes. The format originated as an extension for the FastTracker II tracker software developed by Triton in 1994.[2][3]Module Header
The module header is the foundational component of an XM file, occupying the initial bytes and providing critical global metadata for module playback and structure. It begins with an identifier string to confirm the file type, followed by descriptive fields that outline the song's organization, audio configuration, and default parameters. This header ensures compatibility across trackers and players by specifying details such as the creating software and version adherence.[3][5][2] The header's fields are structured as follows, with offsets relative to the file start:| Offset | Size (bytes) | Field Name | Description |
|---|---|---|---|
| 0 | 17 | ID Text | Fixed string "Extended Module: " (ASCII, ending with space $20), identifying the file as a standard XM module. In stripped variants, it may use null bytes instead.[3][2] |
| 17 | 20 | Module Name | ASCII string for the module's title, padded with spaces or nulls; often up to 20 characters.[3][5] |
| 37 | 1 | Separator | Fixed byte $1A in standard XM files; $00 in stripped modules.[3][2] |
| 38 | 20 | Tracker Name | ASCII string naming the creating software, such as "FastTracker v2.00", padded with spaces or nulls. In stripped modules, it uses null bytes.[3][5][2] |
| 58 | 2 | Version Number | Word (little-endian) indicating format version; high byte for major, low for minor (e.g., 0x0104 for version 1.04). Stripped modules use 0x0000.[3][5][2] |
| 60 | 4 | Header Size | Dword (little-endian) specifying the total size of the header in bytes, starting from this field; typically 276 bytes for full order lists, but variable and shorter in stripped modules (minimum 21 bytes). This allows parsers to locate subsequent data.[3][5][2] |
| 64 | 2 | Song Length | Word (little-endian) defining the number of entries in the pattern order table (1-256); represents the song's total order count.[3][5][2][1] |
| 66 | 2 | Restart Position | Word (little-endian) indicating the pattern order index (0-255) for playback restart on loop; 0 often denotes no restart.[3][5][2][1] |
| 68 | 2 | Number of Channels | Word (little-endian) specifying audio mixing channels (typically 1-32, though up to 64 supported in extensions). Common values include even numbers like 2, 4, 8, 16, or 32.[3][5][2][1] |
| 70 | 2 | Number of Patterns | Word (little-endian) indicating stored patterns (1-256); defines the module's pattern table size.[3][5][2][1] |
| 72 | 2 | Number of Instruments | Word (little-endian) specifying instruments (0-128); 0 indicates sample-only mode.[3][5][2][1] |
| 74 | 2 | Flags | Word (little-endian); bit 0 (1 = linear frequency tables, 0 = Amiga-style); other bits reserved (typically 0). This affects pitch calculation during playback.[3][5][2][1] |
| 76 | 2 | Default Tempo | Word (little-endian) setting initial ticks per row (typically 80-200); controls row advance speed.[3][5][2][1] |
| 78 | 2 | Default BPM | Word (little-endian) for initial beats per minute (32-255); influences overall playback tempo alongside ticks.[3][5][2][1] |
| 80 | 256 (variable) | Pattern Order Table | Array of 256 bytes (or fewer in stripped modules, per header size); each byte indexes a pattern (0-255, or 0xFF for skips) to define song sequence. Full 256 bytes ensures broad compatibility.[3][5][2] |
Patterns
In the XM file format, patterns represent the core musical sequences, defining events such as notes, instruments, volumes, and effects across multiple channels over a series of rows, which collectively form the song's arrangement when referenced by the module's order table.[2] The number of patterns in a module is specified in the module header, with each pattern's position determined by the order table for playback sequencing.[3] Each pattern begins with a fixed 9-byte header that provides essential metadata for unpacking and interpreting the following data. The header structure is as follows:| Offset | Size (bytes) | Type | Description |
|---|---|---|---|
| 0 | 4 | DWORD | Header length (always 9) |
| 4 | 1 | BYTE | Packing type (0 for unpacked, though rarely used otherwise) |
| 5 | 2 | WORD | Number of rows (1–256) |
| 7 | 2 | WORD | Size of packed pattern data in bytes (0 indicates an empty pattern) |
Instruments
In the XM file format, instruments serve as organizational units that associate musical notes with specific samples, enabling multisampling and automated parameter control during playback. Each instrument begins with a header that defines its properties and links to up to 16 samples, allowing for more sophisticated sound design compared to earlier formats like MOD. The header's variable size is specified by a 4-byte unsigned integer (dword) at offset 0, with a minimum of 29 bytes for a standard empty instrument or 4 bytes in stripped variants where extraneous fields are omitted.[2][3] The instrument name follows at offset 4 as a 22-byte ASCII string, typically zero- or space-padded, providing a human-readable identifier. A single byte at offset 26 denotes the instrument type, which is usually set to 0 and holds no functional significance in standard implementations. The number of associated samples is indicated by a 2-byte unsigned integer (word) at offset 27, limited to 0-16 in FastTracker 2 but extensible up to 128 in some players. If samples are present, a 4-byte dword at offset 29 specifies the size of each sample header, ensuring proper parsing of linked sample data. Additionally, a 96-byte array at offset 33 maps samples to specific notes across 96 semitones (from C-0 to B-7), where each byte indexes the assigned sample number (0 for no sample, 1 to the number of samples in the instrument).[2][3][5] Envelopes provide time-based automation for volume and panning, defined within the instrument header to control how these parameters evolve over the course of a note. The volume envelope consists of 48 bytes (24 words) at offset 129, accommodating up to 12 points where each point is a pair of 2-byte unsigned integers: the first for the frame position (0-65535, representing ticks) and the second for the value (0-64, scaled to volume levels). Similarly, the panning envelope occupies 48 bytes at offset 177, using identical structure but with values from 0-64 mapped to -64 to +63 for left-right positioning. Envelope configuration is handled by subsequent bytes: offset 225 (1 byte) sets the number of active volume points (0-12), offset 226 does the same for panning; sustain points are 1-byte indices at offsets 227 and 230, while loop start and end points (0-11) are at offsets 228-229 and 231-232. Flags at offsets 233 and 234 (1 byte each) enable envelopes (bit 0), sustain (bit 1), and looping (bit 2), with linear interpolation applied between points during playback.[2][3] Further instrument parameters include a 2-byte word at offset 239 for volume fadeout (0-65535), which gradually reduces volume after the sustain point until silence. Vibrato effects are configured with four 1-byte fields at offsets 235-238: type (0=sine, 1=ramp down, 2=square, 3=random), sweep (initial depth ramp-up in ticks), depth (amplitude 0-15 semitones), and rate (speed in Hz/12). These elements collectively allow instruments to emulate dynamic instrument behaviors, such as string swells or stereo movement, by mapping notes to samples and automating their playback characteristics. Sample headers, referenced but not stored within the instrument section, provide per-sample details like length and tuning that integrate with these mappings.[2][3][5]Samples
Samples in the XM file format store raw audio waveforms that can be assigned to instruments, enabling multisampling where different samples are used for various pitches to create more realistic or varied sounds. Each instrument can reference up to 16 samples, with the instrument header containing an array of indices pointing to these samples in the file's sample section. The samples support both 8-bit and 16-bit audio depths and include provisions for looping to sustain notes indefinitely. The sample header is a fixed 40-byte structure that defines properties for each sample. It begins with a 4-byte unsigned integer for the sample length, specified in number of samples (not bytes), determining how many audio points the sample contains. Following this are two 4-byte unsigned integers for the loop start position and loop length, also in number of samples; a loop length of 0 indicates no looping. The header then includes a 1-byte unsigned integer for the default volume (range 0-64, where 64 is maximum), a 1-byte signed integer for finetune adjustment (range -128 to +127 in 1/8 semitone units, equivalent to -16 to nearly +16 semitones; FastTracker 2 uses -8 to +7), and a 1-byte flags field for the sample type: bit 0 enables forward looping, bit 1 enables bidirectional (ping-pong) looping, and bit 4 indicates 16-bit samples (otherwise 8-bit). A 1-byte unsigned integer specifies panning (0-255, with 128 as center), followed by a 1-byte signed integer for the relative note number (-128 to +127, used as a semitone offset from the mapped note to set the base pitch for transposition). The next 1-byte field is reserved in standard XM files (value 0 for delta encoding), though some extensions use it to indicate compression types like 0 for none or 8-bit delta; non-standard implementations may include 4-bit ADPCM compression here, preceded by a 16-byte lookup table for decoding. The header concludes with a 22-byte null-padded ASCII name for the sample. Sample data immediately follows the sample headers in the file, with each sample's data allocated contiguously based on its header. Data consists of signed integers in the specified depth: 8-bit as single bytes (-128 to +127) or 16-bit as little-endian words (-32768 to +32767). All samples use delta encoding for storage efficiency, where each value represents the difference from the previous sample point (starting from 0); during playback, values are reconstructed by cumulatively summing the deltas. For 16-bit samples, the data length in bytes is twice the sample length field value, while for 8-bit it matches directly. Looping operates on the decoded waveform: forward loops play from the start position to the end and repeat, while ping-pong loops reverse direction at the end point for seamless sustain. ADPCM compression, when present in extended files, packs 4-bit indices into bytes (two per byte), referencing the table for delta values before summing, reducing size by approximately 50% but potentially introducing artifacts.Effects and Playback
Effect Commands
In XM files, effect commands are used within pattern data to manipulate sound during module playback, such as altering pitch, volume, panning, and playback flow on a per-channel, per-row basis. Each pattern event includes a dedicated byte for the effect type (values 0 to 26 decimal, corresponding to hexadecimal 0-9 and A-Z) followed by a parameter byte (0 to 255 decimal), allowing precise control over audio parameters. These commands are executed tick-by-tick within each row, with many effects retaining their last non-zero parameter if the current one is zero, enabling continuous application without repetition. Effects are processed after note and instrument triggers but before volume column commands in compatible players.[2][13][3] The following table summarizes the primary effect commands available in XM, including their type values, parameters, and behaviors. Descriptions focus on FastTracker II compatibility, noting that some extended effects fall under type 14 (E), where the parameter's high nibble selects the subtype (e.g., E1x for fine portamento up).[2][13]| Type | Hex Display | Name | Description and Parameters |
|---|---|---|---|
| 0 | 0xy | Arpeggio | Cycles the note's pitch through the base note, base + x semitones, and base + y semitones every tick within the row; x and y are 0-15 (0 skips the step). Parameter 00 stops the effect.[13][3] |
| 1 | 1xx | Portamento Up | Increases the period by xx units per tick (except the first tick of the row), raising the pitch; xx is the speed (1-FF). Retains last non-zero parameter.[13][2] |
| 2 | 2xx | Portamento Down | Decreases the period by xx units per tick (except the first tick of the row), lowering the pitch; xx is the speed (1-FF). Retains last non-zero parameter, separate from type 1.[13][3] |
| 3 | 3xx | Tone Portamento | Slides the frequency toward a new note's target by xx units per row (applied per tick except the first), without changing the sample; xx is speed (1-FF). Ignores new notes if parameter is 00; retains last non-zero.[2][13] |
| 4 | 4xy | Vibrato | Modulates the frequency sinusoidally (or per waveform) with speed x (0-F, ticks per cycle/32) and depth y (0-F, amplitude/2); applied every tick. Retains last non-zero parameters; uses default sine waveform unless changed.[3][13] |
| 5 | 5xy | Tone Portamento + Volume Slide | Combines tone portamento (using speed from last 3xx) with volume slide (up by x if y=0, down by y if x=0, or both); x and y are nibbles (0-F), volume changes every tick except first. Retains parameters independently.[2][13] |
| 6 | 6xy | Vibrato + Volume Slide | Combines vibrato (using parameters from last 4xy) with volume slide (up by x if y=0, down by y if x=0, or both); x and y nibbles (0-F), volume changes every tick except first. Retains parameters.[3][13] |
| 7 | 7xy | Tremolo | Modulates the channel volume sinusoidally (or per waveform) with speed x (0-F, ticks per cycle/32) and depth y (0-F, amplitude); applied every tick, clamped to 0-64. Retains last non-zero parameters.[2][13] |
| 8 | 8xx | Set Panning | Sets the channel's panning position to xx (00 left, 80 center, FF right); takes effect next row. Reset by new instruments.[3][2] |
| 9 | 9xx | Sample Offset | Starts playback from position xx * 256 bytes into the sample (high byte offset); requires a note trigger. Retains last non-zero xx.[13][2] |
| 10 | Axy | Volume Slide | Slides channel volume up by x (if y=0) or down by y (if x=0), or both; amount 1-0F per row (applied per tick except first), clamped to 0-64. Retains last non-zero. Separate from volume column slides.[3][13] |
| 11 | Bxx | Position Jump | Jumps playback to pattern order position xx (00 restarts from beginning); takes effect after current row. Only rightmost per row applies.[2][13] |
| 12 | Cxx | Set Volume | Sets channel volume to xx (00 silent, 40 max, >40 ignored); takes effect immediately. Clamped in some players.[3][2] |
| 13 | Dxx | Pattern Break | Breaks to row (x*10 + y) in the next pattern order; x and y from low/high nibbles of xx. Only rightmost per row applies.[13][2] |
| 14 (with param subtypes) | Exx | Extended Effects | Subtype selected by high nibble of xx; includes fine portamento (E1x up by x units on first tick, E2x down), glissando control (E30 off, E31 on for tone porta), vibrato waveform (E4x, x=0-7 types like sine=0), finetune (E5x sets temporary finetune -8 to +7), pattern loop (E60 start, E6x loop x times from start), tremolo waveform (E7x like E4), retrigger (E9x every x ticks), fine vol slide (EAx up x, EBx down), note cut (ECx volume=0 after x ticks), note delay (EDx trigger after x ticks), pattern delay (EEx repeat row x extra times). Retains where applicable; some buggy in original FastTracker II.[2][13][3] |
| 15 | Fxx | Set Speed/Tempo | If xx < 20 (32 decimal), sets ticks per row (speed, 01-1F); if >=20, sets BPM (tempo, 20-FF). F00 sets infinite speed in XM (buggy). Affects all channels.[13][2] |
| 16 | Gxx | Set Global Volume | Sets master volume to xx (00 silent, 40 max); affects all channels immediately.[3][13] |
| 17 | Hxy | Global Volume Slide | Slides master volume up by x (if y=0) or down by y (if x=0), or both; 1-0F per row (per tick except first), clamped to 0-64. Retains last non-zero.[2][3] |
| 20 | Kxx | Key Off | Triggers note release (envelope off) after xx ticks (00 immediate, but avoid); parameter often ignored beyond that. Used for cutting sustains.[13][3] |
| 21 | Lxx | Set Envelope Position | Advances volume or panning envelope to frame xx (00-FF, but limited by envelope length); takes effect next tick.[2][13] |
| 25 | Pxy | Panning Slide | Slides panning left by y (if x=0) or right by x (if y=0), or both; 1-0F units per row (first tick only for fine). Retains last non-zero; units are 1/256 of range.[3][13] |
| 27 | Rxy | Multi Retrig Note | Retriggers the note every y+1 ticks, adjusting volume by x (e.g., x=1 decreases by 1, x=9 increases by 1; see FastTracker table for exact); retains parameters. Buggy with portamento.[2][13] |
| 18 | Sxx | ? (Unused in standard XM) | Not implemented in FastTracker II; some players ignore or treat as no-op.[3] |
| 29 | Txy | Tremor | Sets volume on for x+1 ticks, off for y+1 ticks per row; cycles until 00. Retains last non-zero; used for stuttering effects.[13][2] |
| 33 | Xxx | Extra Fine Portamento (extension) | Non-standard ModPlug extension: X1x increases frequency by 4x units on first tick; X2x decreases by 4x units. Retains. Other X subtypes (e.g., X5 panbrello) are extensions in modern players, not original XM.[3][13] |
| 35 | Zxx | Extended (Rare/Unused) | Not standard in FastTracker II; some players use for MIDI macros or hacks, but original XM ignores or treats as no-op. Sub-effects like extra fine slides may appear in variants.[2][13] |