Reply to topic  [ 1 post ] 
The OptiMOD module format designed for fastest playback 
Author Message
Administrator

Joined: 31. May 2005 05:23
Posts: 70
Location: Liège
Post The OptiMOD module format designed for fastest playback
Code:
Informations about the OPTIMOD format
-------------------------------------
The OPTIMOD is a file format developed by Basty. This format was designed
to playback complex modules extremely fast. The main idea behind this format
is, that is just stores the output data to the mix routine, i.e. it doesn't
need the calculations which the trackers and MOD players need. That means,
that an OPTIMOD file just contains (like MIDI) a stream of output data to
the mix routine with samples associated at the end of file. The samples just
contain identical and required informations like bit depth and waveform
length. The sample rate isn't required, because that is passed in the output
stream. This also means that *ALL* note informations, etc. is lost. The output
stream just contains infos like this:
Playback channel 0: Frequency 8363, Sample 0, No repeat points, Forward, Vol
                    64, Panning left. If there would be an volume slide on
                    the next tick, the next block would contain the calculated
                    volume, i.e. a volume slide down with tempo 1 will have
                    in the next block a volume change to 63, and then to 62.
                    The same applies to portamento, vibrato, panning slides,
                    even global volumes. They're all precalculated (Please note
                    that OPTIMOD uses the same volume range as TuComposer (0 to
                    255), so the example given above is 1/4 of full volume)

You understand ? All pattern, order list, instrument data is lost, so this
format should only be used in intros/demos/games where the CPU power is
required for other things and makes also safety against rippers, because you
can't convert such a module easily back to it's origin. This is strongly true
for modules using the NNA mechanism, because the output stream only stores
the virtual channels. This player should take even on 64 channel MODs less
a rasterline. Of cause, the data is compressed so the files should not grow
too big. Coding a player for these files should also be pretty easy. I think
the scene people will welcome such a format. I had the idea, 'cos I noticed
that the TuComposer replay routines are extremely CPU intensive. Repeat points
in orders like in MODs are still possible but must be defined by yourself
before conversion. I think about the user effects in some trackers, i.e.
in TuComposer 7F-DEF1 (just a example). So you can skip forward/backwards
patterns like in MODs (but you can't watch 'em). I think this idea is great
and so I'll code a converter (and, of cause, a player) which will be supplied
with TuComposer and also separate. Because this requires, that the module is
played virtually (to get the values for the mix routine), the play time cal-
culation can be done on the fly. So it's no problem to store the playing time
in OPTIMOD's. The format will be rather simple and in most cases only contain
really required informations (unlike MODs, which contain lot of uninteresting
infos). Here's a description of the format (all relative offsets are to
file beginning):
ID: OPTIMOD^Z (^Z means CTRL-Z, ASCII 26)
0008 - UWORD = number of channels
000A - UWORD = number of samples
000C - UWORD = number of mark points
000E - UWORD = length of user defined text in longwords
0010 - ULONG = Length of stream output in bytes
0014 - ULONG = Restart of stream output in bytes (from start of the file)
0018 - ULONG = Relative offset to stream output
001C - ULONG = Relative offset to first sample
0020 - ULONG = Relative offset to mark points
0024 - ULONG = Relative offset to a text (copyright, etc.)
0028 - ULONG = Initial tempo in 1/655360 seconds
002C - ULONG = Duration of song in 1/100 seconds
0030 - ULONG = Special flags
0034 - ULONG = Reserved
0038 - ULONG = Reserved
003C - ULONG = Reserved

The stream output structure and the packing format:
The stream output is encryted with the text (optional). To get the crypt key,
init a counter to zero. Process the text with counter longword addition
(that's because the text length is always divideable by 4). An example:
Start:       moveq    #0,d0           ; Init. counter to zero
             move.l   OPTIMOD(pc),a0  ; OPTIMOD file begin to A0
             move.w   $000E(a0),d1    ; Length of text (in longwords) to D1
             add.l    $0024(a0),a0    ; Text to A0
GetCryptKey: add.l    (a0)+,d0        ; Add text code to D0
             subq.w   #1,d1           ; Next longword
             bne.s    GetCryptKey     ; Until done
             rts                      ; That's all !

To decode the stream output, use the crypt key as evaluated above.
Decrypt:     move.l   OPTIMOD(pc),a0  ; OPTIMOD file begin to A0
             move.l   $0010(a0),d0    ; Length of stream output
             move.l   CryptKey(pc),d1 ; Crypt key to D1
             add.l    $0018(a0),a0    ; Stream output start to A0
DecryptLoop: eor.b    d1,(a0)         ; First decode.
             ror.l    #8,d1           ; Rotate crypt key
             add.b    (a0)+,d1        ; Change crypt key
             subq.l   #1,d0           ; Decrease counter
             bne.s    DecryptLoop     ; Decode next value
             rts                      ; Done !

The mark format:
This is a list containing one ULONG for each entry:
xxxx - ULONG = Relative offset in output stream of mark 1...
The text format:
The text is normal IBM-ASCII, ANSI is allowed. Lines are ending with CR+LF,
as on normal IBM. If the text isn't divideable by 4, the rest is filled out
with zeroes, so that the text length with the zeroes is divideable by 4.

The sample format:
Each sample contains the following informations:
0000 - ULONG = Sample size in samples (in bytes is Samples*Bits/8)
0004 - ULONG = Repeat start in samples (not bytes)
0008 - ULONG = Repeat end in samples
000C - ULONG = Repeat count
0010 - ULONG = Start offset in samples
0014 - ULONG = Pointer to synth waveforms or NULL
0018 - UBYTE = Bit resolution (1 to 32 bits)
0019 - UBYTE = Flags
               Bit # | Meanings
                   0 | Delta packed
                   1 | Loop points used
                   2 | Backwards loop
                   3 | Pingpong loop
                   6 | Sample will be played backwards initially
001A - UWORD = Reserved
001C = ULONG = Reserved


1. June 2005 12:20
Profile ICQ WWW
Display posts from previous:  Sort by  
Reply to topic   [ 1 post ] 

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by STSoftware for PTF.