Logo DigiBoostera 3 DigiBooster 3
Facebook Google+
Deutsch Polski
DigiBooster 3 is a music tracker. Its history has roots in ancient times of Amiga. Amiga was the first popular computer having stereo PCM audio output. Then it had a potential to be used as a device for making music. This potential has been fully exploited. The Ultimate Soundtracker was the first in 1987. NoiseTracker was the second in 1989. ProTracker had beat'em up in 1991. Amiga was getting faster processors. Multichannel software mixing was a logical step forward. Tomasz and Waldemar Piasta have done this step in 1998 creating DigiBooster Pro 2. It has been later bought by APC&TCP. Development stalled after version 2.21, but has been ressurected in 2007 by APC&TCP in cooperation with Grzegorz Kraszewski. It has been decided that DigiBooster 3 will be rewritten from scratch in C. Now, after 4 years of development, DigiBooster 3 reached public beta stage.
DigiBooster 3 runs on three operating systems:
MorphOSMorphOS (PowerPC)
AmigaOS 4AmigaOS 4 (PowerPC)
AmigaOS 3AmigaOS 3 (M68k)
DBM0 Format Specification 1.4
05 Oct 2013

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:

0 Chunk ID 4 bytes Four ASCII codes of capital letters.
4 Data Length 4 bytes In bytes, excluding this header.

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

0 'D' 'B' 'M' '0' 4 bytes File format identifier.
4 ver. rev.   2 bytes Version and revision of the creator.
6 reserved   2 bytes Reserved.

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

0 'N' 'A' 'M' 'E' 4 bytes Chunk identifier.
4 44 ($C2) 4 bytes Data length, fixed, 44 bytes.
8 Module
Name
44 bytes 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

0 'I' 'N' 'F' 'O' 4 bytes Chunk identifier.
4 10 ($0A) 4 bytes Data length, fixed, 10 bytes.
8 Instr.   2 bytes Number of instruments in the module (up to 255).
10 Samples   2 bytes Number of samples in the module (up to 255).
12 Songs   2 bytes Number of songs (DBPro 2.x limited it to 5).
14 Patterns   2 bytes Number of patterns in the module (up to 1024).
16 Tracks   2 bytes Number of tracks in the module (4 to 254, even).

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

0 'S' 'O' 'N' 'G' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
   
Song block:
 
0 Song
Name
44 bytes Song name string.
44 Length   2 bytes Number of entries in the song playlist.
46 Playlist
...
  variable Playlist entries (numbers of patterns).

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

0 'I' 'N' 'S' 'T' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
   
Instrument block:
 
0 Instrument
Name
30 bytes Instrument name string.
30 Sample   2 bytes Number of sample used by this instrument (1).
32 Volume   2 bytes Instrument default volume (from 0 to 64 including).
34 Sample Rate 4 bytes Sampling rate for note C-4 in Hz.
38 Loop Start 4 bytes The first looped sample.
42 Loop Length 4 bytes Length of loop in samples (0 for no loop).
46 Panning   2 bytes Instrument panning (−128 = full left, +128 = full right).
48 Flags   2 bytes Flags (see below).

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

0 'P' 'A' 'T' 'T' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
   
Pattern block:
 
0 Rows   2 bytes Number of rows in the pattern.
2 Data Length 4 bytes Length of packed data in bytes.
6 Packed
Data
variable Packed pattern data.

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

$00
$06
$03
$52
$02
$00
$03
$31
$36
$0F
$70
Row skip. It implies all entries in the row 0 are empty.
Track number (counted from 1).
00000011 – note and instrument follows.
The note, D-5.
Instrument 2.
Row skip. All entries in row 1 are empty except of track 6.
Track number.
00110001 – note, command 2, parameter 2 follows.
The note, F#3.
The second command, Fxx (tempo change).
The second parameter, so the complete command is F70.

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

0 'S' 'M' 'P' 'L' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
   
Sample block:
 
0 Flags 4 bytes Sample flags (see below).
4 Length 4 bytes Number of sample frames.
8 Sample
Data
variable PCM audio data.

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

0 'V' 'E' 'N' 'V' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
8 Envs   2 bytes Number of volume envelopes stored in the chunk.
   
Volume envelope block:
 
0 Instr.   2 bytes Number of instrument the envelope is attached to.
2 Flg.   1 byte Envelope flags (see below).
3 Pts.   1 byte Number of envelope sections (up to 31).
4 S1   1 byte Number of point of the first sustain.
5 L1   1 byte Number of point of loop start.
6 L2   1 byte Number of point of loop end.
7 S2   1 byte Number of point of the second sustain.
8 Position   2 bytes Time position of the first env point in ticks.
10 Value   2 bytes Volume value (0 .. 64) for the point.
  · · ·  
132 Position   2 bytes Time position of the last env point in ticks.
134 Value   2 bytes Volume value (0 .. 64) for the point.

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

0 'P' 'E' 'N' 'V' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
8 Envs   2 bytes Number of panning envelopes stored in the chunk.
   
Panning envelope block:
 
0 Instr.   2 bytes Number of instrument the envelope is attached to.
2 Flg.   1 byte Envelope flags (see below).
3 Pts.   1 byte Number of envelope sections (up to 31).
4 S1   1 byte Number of point of the first sustain.
5 L1   1 byte Number of point of loop start.
6 L2   1 byte Number of point of loop end.
7 S2   1 byte Number of point of the second sustain.
8 Position   2 bytes Time position of the first env point in ticks.
10 Value   2 bytes Panning value (−128 .. +128) for the point.
  · · ·  
132 Position   2 bytes Time position of the last env point in ticks.
134 Value   2 bytes Panning value (−128 .. +128) for the point.

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.

0 'D' 'S' 'P' 'E' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
8 Mask length   2 bytes Number of following track echo mask bytes.
10 Echo track mask variable One byte per track (see below).
  · · ·  
  Delay   2 bytes Global echo delay as in 'W' tracker command.
  Feedback   2 bytes Global echo feedback as in 'X' tracker command.
  Mix   2 bytes Global echo mix as in 'Y' tracker command.
  Cross   2 bytes Cross channel echo as in 'Z' tracker command.

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.

0 'P' 'N' 'A' 'M' 4 bytes Chunk identifier.
4 Data Length 4 bytes Data length, variable.
8 Encoding   2 bytes Encoding number.

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:

N string $00

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.