textfiles/programming/FORMATS/p16-form.txt

358 lines
20 KiB
Plaintext

Below lists the format of the Protracker Studio 16 (PS16) header. This can
change if it doesn't allow for enough flexibility for the time being.
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³ PS16 Header Format: ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
Description Length Data Type Information
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Sig 5 Character This contains the string "PS16þ" which
acts as both an identifier to
determine the file, but also serves
as part of the text string which
can be done by TYPEing the file to
the screen.
SongName 75 Character This contains the 75-character name of
the music file. This may contain
the MODule name if converted from a
MOD, or it may contain information
on number of channels or whatever.
The final byte, 75, MUST have a ^Z
in it.
TypeOfFile 1 Byte This field holds what type of music
file the file is. If this field
contains a 0, then it is a module
with self-contained instruments.
If it is a 1, then it is a song
with the header and patterns, but
not the samples.
CommentOfs 4 Longint The Comment Offset field points to
the offset of the file where
comments begin. The comments
contain all text and information
pertinent to the music. The
sample names are also stored here.
See below for parsing information.
This field DOESN'T need to be
used. Just store a zero here if
there are no comments.
Version 1 Byte This is the version identifier for
the PS16 file. All versions of
PS16 formats will have the header
structure as described thus far.
The format from here on can change,
although it isn't likely. The
format described below is a Version
0 format.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Version 0 Header
NumPatterns 1 Byte Contains the number of patterns
(max 256) in the file.
totalPatternSize 4 Longint For quick reads off the disk, the
TOTAL pattern length is stored here.
The maximum total size of patterns
for any given music file is
3075 bytes per pattern * 256 patterns.
With the current player, this is
simply not possible.
SongLen 1 Byte This contains the number of sequences
in the PS16 file.
Sequences 128 Byte These are the sequences for the entire
PS16 music.
Samples 31*PS16Sample These are the 31 individual sample
structures, described below.
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³ PS16 Sample Header Format, Version 0: ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
Description Length Data Type Information
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
BitStruc 1 Bit Field These are bits that may be set for each
sample. The default for a MOD file
is: Bit 0 - Digital, Bit 1 - 0,
Bit 2 - 8-bit.
7 6 5 4 3 2 1 0
³ ³ ÀÄ 0 - Digital, 1 - Synthesized
³ ÀÄÄÄ (if bit 0=1) 0 - FM, 1 - Waveform
ÀÄÄÄÄÄ 0 - 8-bit, 1 - 16-bit.
Volume 1 Byte Default volume for the sample. Range
is 0 to 64 decimal. Please, ALWAYS
make it default to this range.
FineTune 1 Byte This field must contain one of the
following values:
0 - Tuning 0
1 - Tuning 1
2 - Tuning 2
3 - Tuning 3
4 - Tuning 4
5 - Tuning 5
6 - Tuning 6
7 - Tuning 7
8 - Tuning -8
9 - Tuning -7
10 - Tuning -6
11 - Tuning -5
12 - Tuning -4
13 - Tuning -3
14 - Tuning -2
15 - Tuning -1
Length 4 Longint This contains the length of the
sample. Currently, my player
doesn't support greater than 64k
samples, and I really don't see
the need. It's here in case it's
needed.
Repeat 4 Longint This contains the repeat start for
the sample. Again, this can be
>64k
RepeatLength 4 Longint This contains the repeat length for
the sample. If the sample Length
is greater than the sample Repeat
plus the sample RepLen, then the
sample can be clipped to Repeat+
RepLen. If you didn't get that,
don't worry about it.
C-2 Freq 2 Word The default playback frequency of
a sample's C on octave 2. This
can be used to fine tune a sample,
but it defaults to 8448.
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³ PS16 Pattern Format, Version 0: ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
Immediately following the version 0 header structure are the patterns. The
reason that the offset of the patterns in the file is not contained in the
header is because it was felt that the patterns would probably not be
relocated.
When converting from the MODule format, this format will always be a minimum
of 253 bytes smaller than the patterns in a MODule. A MODule's pattern is
always 1,024 bytes. This is obvious since a MODule note and effect occupies
four bytes, and there are four channels per row. With 64 rows in a file,
this equation becomes: 4 bytes * 4 channels * 64 rows = 1,024 bytes.
A PS16 note occupies three bytes. A "note" in PS16 consists of the actual
note, an instrument, and a special effect and its data.
A PS16 note will use the following table to convert from Amiga periods to
its own notes, and they will be stored as such:
ÚÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄ¿
³ 1³ 2³ 3³ 4³ 5³ 6³ 7³ 8³ 9³ 10³ 11³ 12³
³ 1712³ 1616³ 1524³ 1440³ 1356³ 1280³ 1208³ 1140³ 1076³ 1016³ 960³ 906³
³ C-0³ C#0³ D-0³ D#0³ E-0³ F-0³ F#0³ G-0³ G#0³ A-0³ A#0³ B-0³
ÃÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄ´
³ 13³ 14³ 15³ 16³ 17³ 18³ 19³ 20³ 21³ 22³ 23³ 24³
³ 856³ 808³ 762³ 720³ 678³ 640³ 604³ 570³ 538³ 508³ 480³ 453³
³ C-1³ C#1³ D-1³ D#1³ E-1³ F-1³ F#1³ G-1³ G#1³ A-1³ A#1³ B-1³
ÃÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄ´
³ 25³ 26³ 27³ 28³ 29³ 30³ 31³ 32³ 33³ 34³ 35³ 36³
³ 428³ 404³ 381³ 360³ 339³ 320³ 302³ 285³ 269³ 254³ 240³ 226³
³ C-2³ C#2³ D-2³ D#2³ E-2³ F-2³ F#2³ G-2³ G#2³ A-2³ A#2³ B-2³
ÃÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄ´
³ 37³ 38³ 39³ 40³ 41³ 42³ 43³ 44³ 45³ 46³ 47³ 48³
³ 214³ 202³ 190³ 180³ 170³ 160³ 151³ 143³ 135³ 127³ 120³ 113³
³ C-3³ C#3³ D-3³ D#3³ E-3³ F-3³ F#3³ G-3³ G#3³ A-3³ A#3³ B-3³
ÃÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄ´
³ 49³ 50³ 51³ 52³ 53³ 54³ 55³ 56³ 57³ 58³ 59³ 60³
³ 107³ 101³ 95³ 90³ 85³ 80³ 75³ 71³ 67³ 63³ 60³ 56³
³ C-4³ C#4³ D-4³ D#4³ E-4³ F-4³ F#4³ G-4³ G#4³ A-4³ A#4³ B-4³
ÀÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÙ
A zero is stored in the event a period was not found or approximated or when
there is not an actual period being played. The note field requires 6 bits.
Version 0 only handles 31 instruments. Thus, the instrument field requires
5 bits.
The special effect field can range from 0 to F in hexadecimal and requires
4 bits.
The special effects data field is a whole byte and can have 8 bits.
Thus, with this information, we are able to construct the following bitfields:
Byte 1 Byte 2 Byte 3
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
³ ³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÂÄÄÙ ÀÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
³ ³ Note ³ Effect Effect Data
³ À Bit 5 of instrument ÀÄÄ Bits 1-4 of the instrument
³
ÀÄÄ Follow previous line bit.
Reconstruction algorithms are as follows:
Get the ÚÄÄÄGet Byte 1
Note ÀÄÄÄAND it with binary 00111111b
ÚÄÄÄGet Byte 1 again.
³ AND it with binary 01000000b
³ Shift it right twice.
Get the ³ Store as result #1.
Instr. ³ Get Byte 2.
³ AND it with binary 11110000b
³ Shift it right four times.
ÀÄÄÄOR it with Result #1.
Get the ÚÄÄÄGet Byte 2 again.
Effect. ÀÄÄÄAND it with binary 00001111b
Efx DataÄÄÄÄGet Byte 3.
Bit 7 requires a bit of additional explanation. As aforementioned, patterns
can be a MINIMUM of 253 bytes smaller than their MOD counterparts. This is
due to three special compression methods.
One) Instead of ordering the patterns as Track 1, Track 2, Track 3, Track 4,
then Track 1, Track 2 again and so on until the end, the Tracks are
grouped together as all of Track 1 and all of Track 2 and so on.
Two) If a note appears on row 0 and another note appears on row 5 with
Three) nothing in between, why not get rid of the blank rows? For instance,
a situation such as this may appear as:
Module Track MOD Data PS16 Data
00 C-1 01 F06 0358 1F06 8D 1F 06
01 --- 00 000 0000 0000
02 --- 00 000 0000 0000
03 --- 00 000 0000 0000
04 --- 00 000 0000 0000
05 E-3 03 C40 00AA 3C40 05 29 3C 40
06 E-3 01 A01 00AA 1A01 A9 1A 01
07 --- 00 000 0000 0000
. .
. .
. .
63 --- 00 000 0000 0000 FF
ÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
1024 bytes 11 bytes
Two and three are combined for two reasons. As can be seen, MODs
store extra information for blank pattern lines. This was
remedied in PS16 by two methods. If the jump between one line
and another was greater than one, then the new line number was
written out (see row 5 of the PS16 Data, first byte). However,
if the two lines were right by each other (5 & 6), then the
pattern row was not written out.
Here's why. As you recall from the above diagrams of PS16 notes,
it can be seen that Bit 7 is named "Follow Previous Line." This
means that if the new PS16 line follows the previous line, there
is no need to store a row number in front. All that needs be
done is have this bit set.
Let's break down the PS16 data from above:
Row 0: 8D 1F 06 -- Bit 7 is set here. The first line of a pattern
is always assumed to follow Byte 255 (which is
what the line counter is initialized). A byte
of 255 plus 1 = 0. Otherwise, the 0Dh in 8Dh
specifies note 0Dh, which is C-1. The 1F 06
specifies instrument 1, special effect F (speed)
06.
Row 5: 05 29 3C 40 -- Since there was a large skip here, and row 5
does not immediately follow row 0, the 5 was
stored in first here. How does the interpreter
know the difference between a row number and
a note? A note ALWAYS follows a row number
and if a row number is not present, then bit 7
MUST be set in the note. Bit 7 is NEVER set
in a row except for the ONE exception below.
Row 6: A9 1A 01 -- Immediately follows Row 5, so bit 7 is set.
Final
Byte: FF -- This is a -1 which means terminate track.
A -1 always terminates the current track. Bear in mind that ALL 16 tracks
are stored per pattern, so if converting from a MOD, tracks 5-16 are
automatically set to -1.
The discussion thus far has been centered around the general pattern format.
Two other factors are introduced into the PS16 pattern. The format of a
pattern is this:
Byte Name Description
ÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
0-1 Size (Word) Size is the total size of the ENTIRE
pattern, INCLUDING bytes 0 through 2.
This number is paragraph aligned. This
means that if a pattern is 253 bytes
long, its actual size is 256. If the
size is 256, no change takes place.
2 NumLines (Byte) This is the number of pattern lines in
the pattern. If a pattern only uses
30 lines and the pattern must terminate
to the next pattern at this point,
store a 30 here. Otherwise, ALWAYS store
a 64 so the entire pattern will play.
3-?? Track This is Track 1, terminated with a -1.
The other tracks follow immediately after
this.
See routine MOD_LoadSavePatterns in MODLOAD.ASM.
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³ PS16 Sample Format, Version 0: ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
Only the digital sample format has been defined thus far. In order to appeal
to archivers more, the sample storage format has changed. Instead of being
stored as raw data as in all trackers I am aware of, the format was changed
to use "deltas." The algorithm for converting a sample to deltas is:
Get the number of sample bytes to process.
Call this SamplesLeft.
Set Delta counter to 0.
DO
Get a byte from the buffer.
Store the byte in Temp.
Subtract the Delta counter from the byte.
Store it in the buffer.
Move the Temp byte into the Delta Counter
Decrement SamplesLeft.
WHILE(SamplesLeft <> 0)
See routine MOD_ConvertSample in MODLOAD.ASM.
The technique for conversion back to the raw data is:
Get the number of sample bytes to process.
Call this SamplesLeft.
Set Delta counter to 0.
DO
Get a byte from the buffer.
Add onto the byte the Delta Counter.
Store the byte in Delta Counter.
Store the byte in Temp.
Decrement SamplesLeft.
WHILE(SamplesLeft <> 0)
ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͸
³ PS16 Comment Format, Version 0: ³
ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ;
This format resembles an ILBM format. Only two things are currently defined
in this format.
Signature Description
ÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
INST Immediately following this four character
identifier is a byte indicating the length of
each instrument name. After that is a byte
describing how many samples names are stored in
this text. Example for the MOD format:
I N S T [Chr 22] [Chr 2, normally 31]
[Instrument name #1 padded to 22 chars]
[Instrument name #2 padded to 22 chars]
See MOD_ConvertComments in MODLOAD.ASM.
TEXT Immediately following this four character
identifier is a WORD describing the length
of the upcoming text.