1. Introduction

This is the official specification of DBM0 file format used by DigiBooster 3 for storing music modules. Version 3 of DigiBooster does not introduce any extensions to the format, so files saved with version 2 and 3 are both ways compatible. It applies to module players as well, every player supporting DigiBooster Professional 2, will play modules saved with version 3. The only difference between a module saved with version 2 or 3 is version number encoded in the file header.

The DBM0 format is chunk-based, similarly to good old IFF. Every chunk starts with a header, containing chunk identifier and its data length in bytes. Traditional chunk order is (NAME, INFO, VENV, PENV, SONG, INST, PATT, SMPL). DigiBooster 3 preserves this order when saving, but loader does not depend on it, and accepts any order with one exception that INFO must be placed before SONG, INST, PATT, and SMPL. Writing chunk order dependent loaders assuming more than this INFO rule is strongly discouraged. A chunk header is defined as follows:

All multibyte numbers (16 or 32 bits) are stored with big-endian byte order (native for M680x0 and PowerPC processors) regardless of host byte ordering. Sound samples are stored in big-endian as well, the same for chunk identifiers. Text informations (module name, song names, instrument names) are assumed to be encoded with ISO-8859-1 (Latin1) character set, DigiBooster 3 performs no conversions, so every character with code above 127 is just passed through and displayed with local encoding. That is why using such characters is not recommended. Possible future Unicode support will be added via additional chunks. If a byte is treated as a bitfield, bit 0 is the least significant, bit 7 is the most significant.

2. DBM0 File Header

Total size: 8 bytes. Version and revision are bytes interpreted in BCD (Binary Coded Decimal) code. It means every nibble codes one decimal digit. For example $21 means 21 decimal here, not 33. Reserved word is always 0 in files saved by DigiBooster 3.

3. Chunk NAME – The Module Name

Total size: 52 bytes. The chunk contains the module name. The name is limited to 44 characters. Note that it may be not NULL-terminated. DigiBooster 3 fills empty space after the name with zeros, but if the name uses all 44 bytes, there is no terminator. The chunk is optional, if not present, DigiBooster assumes empty name.

4. Chunk INFO – Global Module Info

Total size: 18 bytes. Global information about the module. Note that minimum number of tracks is 4 and it is even always. This chunk is mandatory, and must be placed before SONG, INST, PATT and SMPL chunks. DigiBooster 3 accepts zero values for number of instruments, samples, songs and patterns. Creating such modules is dangerous however, as it may confuse other loaders. While saving DigiBooster 3 ensures that there is at least one instrument, one pattern and one song.

5. Chunk SONG – Song Playlists

Song blocks for all the songs are stored one by one, without any padding. Number of song blocks must be equal to number of songs specified in the INFO chunk. Song name is not NULL-terminated, but is padded to 44 bytes with $00. The chunk is mandatory. DigiBooster is able to load a module without valid song chunk, it creates a song 0 containing just one entry, pattern 0. DigiBooster Pro 2.x had a limit of 5 songs. Number of songs in DigiBooster 3 is limited to 32 767.

6. Chunk INST – Instrument Info

Instrument block size is 50 bytes. Flags field uses only two least significant bits:

• bit 0 = forward loop
• bit 1 = ping-pong loop

The rest is unused and should be 0. Bits 0 and 1 are mutual exclusive, if bit 0 is set, bit 1 is ignored.

Instrument blocks are stored one by one, without padding. Number of instrument blocks must be equal to number of instruments specified in the INFO chunk. Instrument name is not NULL-terminated when uses all the 30 bytes. The chunk is mandatory. DigiBooster is able to load a module without valid instrument chunk, it creates an empty instrument 1 with no name, and no sample.

Notes:
  (1) Sample numbers here start from 1.

7. Chunk PATT – Musical Score

Pattern chunk contains musical score of module songs, divided into patterns. Every pattern is stored as a pattern block. Number of pattern blocks must be equal to number of patterns specified in the INFO chunk. Every pattern block is aligned to 16 bits, so if number of packed bytes is odd, an additional $00 is added at the end, which must not be processed by loader. The chunk is mandatory. DigiBooster is able to load a module without valid pattern chunk, it creates an empty pattern 0 with 64 positions.

Pattern compressed format is based on a fact, that many entries (or even whole rows) of a pattern are empty usually. The idea is to save only non-empty ones. Every entry starts from track number. The special value of $00 means skipping to the next row. Because of this tracks are numbered starting from 1, not 0. Because track number is a byte, and only even number of tracks is allowed, a DBM0 module can have no more than 254 tracks. For non-zero track number, the following byte is a bitfield indicating which elements of a pattern entry are stored:

• bit 0 = note
• bit 1 = instrument
• bit 2 = first command
• bit 3 = first command parameter
• bit 4 = second command
• bit 5 = second command parameter

Any component may be ommited, but the order is kept always.

Note encoding

A note consists of two nibbles, the first one is octave (from 1 to 7), the second one is a halftone within the octave (from 0 to 11).

An example

Notes and clarifications

1. Entries in a row are not required to be ordered by track number, ascending. On the other hand, DigiBooster 3 always saves in this order.
2. Even if you specify all entries in a row one by one, you still have to emit $00 code at the end of row.
3. DigiBooster 2.21 documentation describes the format wrong, as it states track number is stored after the bitfield.

8. Chunk SMPL – Audio Samples

In the 'flags' field only 3 bits are used:

• bit 0 = sample is 8-bit
• bit 1 = sample is 16-bit
• bit 2 = sample is 32-bit

Sample blocks are stored one by one without padding. Number of sample blocks must be equal to number of samples specified in the INFO chunk. On the other hand number of samples need not to be equal to number of instruments. One sample may be used by multiple instruments, unused samples may be contained in the module as well. Sample data are stored as signed integers in big-endian byte order. The chunk is mandatory. DigiBooster is able to load a module without valid sample chunk, it creates an empty sample 0. 8-bit and 32-bit samples are deprecated. DigiBooster 3 converts all samples to 16 bits when loading modules and stores all samples in 16 bits.

9. Chunk VENV – Volume Envelopes

Note that number of envelope sections (not points) is stored, which is simple number of points − 1. The size of an envelope block is fixed at 136 bytes. Flag field at offset 2 uses following bits:

• bit 0 = evenlope is turned on
• bit 1 = evenlope first sustain is active
• bit 2 = evenlope loop is active
• bit 3 = evenlope second sustain is active

The upper 4 bits are reserved and should be 0. The volume envelope block has fixed length even if there is less than 32 points in the envelope. Unused points are zeroed. There is no reserved field before the first point, as DigiBooster 2.21 documentation mistakenly specifies. Envelope blocks are stored one by one, without padding. Instrument number is counted from 1, positions of sustains and loop are counted from 0.

10. Chunk PENV – Panning Envelopes

Note that number of envelope sections (not points) is stored, which is simple number of points − 1. The size of an envelope block is fixed at 136 bytes. Flag field at offset 2 uses following bits:

• bit 0 = evenlope is turned on
• bit 1 = evenlope first sustain is active
• bit 2 = evenlope loop is active
• bit 3 = evenlope second sustain is active

The upper 4 bits are reserved and should be 0. The volume envelope block has fixed length even if there is less than 32 points in the envelope. Unused points are zeroed. There is no reserved field before the first point, as DigiBooster 2.21 documentation mistakenly specifies. Envelope blocks are stored one by one, without padding. Instrument number is counted from 1, positions of sustains and loop are counted from 0.

NOTE: For unknown reasons DigiBoosterPro 2.x converted [−128, +128] range of panning values into [0, 64] range when saving, and converted back when loading (loosing 2 bits of resolution this way). DigiBooster 3 always saves true, unscaled values. When loading, it checks program version in the module header. If module has been saved with version 2, conversion is performed, if it has been saved with version 3, values are loaded without scaling.

11. Chunk DSPE – Digital Signal Processing Effects

The DSPE chunk was not documented in DigiBooster Pro 2.x manual. Now it is official. The chunk structure has been revealed by analysing DigiBooster Pro 2.21 source code. For now this chunk contains informations about global echo parameters. The chunk may be extended in the future.

Global echo track mask defines for which tracks global echo should be initially turned on. It may be changed later with the tracker 'V' command. Every track takes one byte in the mask. Then mask length in bytes is equal to number of tracks in the module. Byte $00 means the global echo is on for a track, byte $01 means the echo is off. After the echo mask, four initial global echo parameters are stored. While each of them has 0 to 255 range, they are stored as 16-bit values. Meaning of these parameters is exactly the same as in respective tracker echo commands 'W', 'X', 'Y', and 'Z'. Refer to the User's Manual for details.

When the chunk is not present in the module, it is assumed that initially global echo for all the tracks is off. Global echo default parameters are: 64 ($40) for delay, 128 ($80) for feedback, 128 ($80) for mix and 255 ($FF) for cross-echo.

12. Chunk PNAM – Pattern Names

This chunk has been introduced in DigiBooster 3. It is optional and contains names of patterns. It is stored after the SMPL chunk, so even badly written 2.x compatible loaders should just ignore it.

Encoding number specifies character encoding used in names. Two values are allowed. 0 means unknown ASCII compatible 8-bit codepage. It means characters above 127 may be displayed wrong. DigiBooster 3 does no conversion when displaying names with encoding 0. 106 value means UTF-8 encoding. DigiBooster 3 will decode it and display, replacing all not displayable characters with '?'.

Number of stored names is equal to number of patterns declared in 'INFO' chunk. Order of names is the same as order of patterns in 'PATT' chunk. Names are stored without padding. Every name is stored as follows:

The first byte, N, contains byte length of the string, including the terminating zero at the end. After this byte, the string proper is stored with zero terminator.

13. Version History

• 1.0 (12.03.2011): the first version.
• 1.1 (17.03.2011): text unified with AmigaGuide document included to public beta 22 of DigiBooster3.
• 1.2 (27.01.2012): officially documented DSPE chunk.
• 1.3 (18.09.2013): note about storing panning envelope points.
• 1.4 (05.10.2013): clarifications in VENV and PENV chunk descriptions.
• 1.5 (30.10.2013): sample index in instrument block, mistake fixed in PATT description.