Frequently Asked Questions
оглавление | demo party в ex-СССР | infused bytes e-mag | новости от ib/news | другие проекты | письмо | win koi lat

следующий фpагмент (2)
D00 format description! ======================= My last post of this one was a little messed up, so here is a repost with some typos fixed, better word wrapping and some extended characters removed. The older version of the document can be gotten at the Hornet archive. But I will upload this version soon, too. One or two weeks ago, I finally got around to decipher the D00 AdLib music format used by JCH's famous player routines and saved by EdLib. So, for everybody who's interested in this, here follows a (more or less :) complete description of the format! -$-snip--8<------ *** THE D00 FORMAT EXPLAINED *** *** BY JOACHIM FENKES *** This document describes the D00 music format (used by the AdLib player v4.01 coded by JCH/Vibrants) in more detail than the docs of EdLib (the respective tracker, also coded by JCH) do. This document assumes that you already own EdLib and have some experience with it. Also, the availability of the EdLib docs as well as of the docs for the player included with EdLib is assumed. You should know some basics about AdLib programming and data formats (byte, word etc.) as well as the EdLib structures (Instruments, SpFX etc.) and hexadecimal notation. CONTENTS ======== 1. The D00 header 2. The Instrument data 3. The SpFX data 4. The arrangement data 5. The pattern data 6. Some more infos 7. Closing words 1. The D00 header ================= A description of the D00 header can be found in the player's docs. So I won't show it again here. But JCH gives very cryptic names to the other file structures, so I'll call them differently: JCH's names | My names TPoin tables = Arrangment data SeqPointer tables = Sequence data Instrument data = Instrument data DataInfo text = Song description Special tables = SpFX data Also, I should mention that all the pointers to these tables are meant relative to the beginning of the D00 file. 2. The Instrument data ====================== The instrument data simply consists of all instruments used in the song. Since the number of instruments is stored nowhere inside the file, loaders should the start offset of the next structure for determining if they have read enough data. The data for each instrument consists of 16 bytes, which occur in the same order as the corresponding bytes in the EdLib Instrument table: xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx \------------/ \------------/ | | | | | | Carrier data Modulator data | | | | \--\Unused | | | \Hard restart SR value | | \Hard restart timer | \Fine-tune \AM/FM + Feedback For the exact meaning of these bytes, read the EdLib manual. Note that in the Carrier and Modulator data the ADSR parts are not stored word-oriented, but byte-oriented. That means, they are NOT stored as a word whose high byte is the AD part and whose low byte is the SR part (although the display in EdLib creates that assumption). Instead they're simply stored as two bytes of which the first one's the AD part and the second one's the SR part. 3. The SpFX data ================ The SpFX data ist stored more or less like the Instrument data, but one single table entry consists of only 8 bytes arranged like this: xxxx xx xx xx xx xxxx (note xx's are BYTES and xxxx's are WORDS!) | | | | | | | | | | | \Pointer to next SpFX entry | | | | \Duration of SpFX entry in Frames | | | \Modulator Level add | | \New Modulator level | \Note add value \Instrument to use Again, to really understand the meaning of these parts, you should read the EdLib docs. 4. The Arrangement data ======================= The arrangement data determines which sequence is to be played on which channel at which moment and in which way, if you understand what I mean :) It consists of two parts: The Pointer part and the Data part (I simply call them that way now :). The Pointer part consists of 16 word pointers and one endmark (all endmarks are FFFFh, by the way). Only the first nine pointers are used at the moment: one for each of the nine AdLib channels. Each one of these nine pointers points to the part of the Data part which belongs to its channel. The Data part consists, as you'd have guessed before, of nine independent arrangement streams. Each one of tese streams has the following format: First comes a word telling the speed of that stream. Since this information is stored at the beginning of EVERY stream, I assume that every channel may have its own unique speed, and EdLib simply doesn't support this. After that, the real arrangement data is stored. This data is organized like this: If a word below 8000h is read, it's the number of a sequence to be played. In that case, the saved transpose data is used. But if a word 8XYYh is read, with X and YY being any value, the transpose data is updated to X and YY (see the EdLib docs for information on the meaning of X and YY). I have found out that the first arrangement entry for an arrangement stream that contains at least one sequence is always such a command to set the internal transpose data. So no default value is required to be loaded into the transpose data before playing. And looping the arrangement stream becomes easier. If the word FFFFh is read, the arrangement stream has arrived at its looping point. The word following the FFFFh is an offset into the arrangement stream telling at which position the stream should be restarted. If the word FFFEh is read, the arrangement stream has reached its end. Unlike the Loop command (FFFFh), the stream mustn't get restarted but halted. Also, there is no word following the FFFEh command. 5. The Sequence data ==================== (I guess you have been waiting for this :) The Sequence data again consists of a pointer part and a data part. But this time these two parts aren't stored in different parts of the file, the data part is stored directly after the pointer part. Therefore, a reference to a specific pattern should be seen as a reference to a word counted from the beginning of the Sequence data. This word (e.g. the first word for Pattern 0000h) then points to the offset of the actual sequence data inside the file. I hope you got my point... Then, each sequence is stored as follows: Read a word. If its high byte is below 20h, then it's a note. Note that RESTs and HOLDs are also counted as notes. In this case, the low byte can contain the following values: 00h = REST - The high byte tells the number of rests to insert minus one! e.g. a REST with a high byte of 01h means "Two RESTs" 01h - 7Dh = Note - The value of this note byte tells the amount of halfnotes to add to C-0 (e.g. 01h would mean C#0). In this case, the high byte tells the number of HOLDs to insert after the note. 7Fh = HOLD - The high byte tells the number of HOLDs minus one again! If the high byte is 20h or above, but below 40h, it's a note again, but this time with Tienote switched on. The high byte is used as repetition count again, but don't forget to substract 20h before evaluating it!! If the high byte is 40h or above, it's an effect. In this case, the complete word can simply be interpreted like any EdLib effect (set instrument, set volume etc.). See the EdLib docs for a list of them. The note word this effect refers to follows directly after the effect word. If the read word is FFFFh, it indicates the end of that sequence. In that case, the next sequence to be played should be determined and loaded and the first effect/note of it should be played. 6. Some more infos ================== The Song description (which is referred to as "DataInfo" by JCH) can contain simply any kind of data, but it's mostly used as a container for a descriptive text. This data is also terminated by an endmark (FFFFh), even if it contains no other data. Also, the data blocks don't necessarily appear in the same order as the respective pointers do in the header. 7. Closing words ================ Okay, this was it. Now you should know as much about the D00 format as I do. I hope that you understood my way of describing things and wish you best luck with your own tracker/player, maybe both... I hope that someone finds this text interesting and useful for his purposes. I will most probably base my own tracker format (if I code a tracker some day :) on a mixture of D00 and TFMX (which is pretty much the same), maybe with some bits of XM... In my opinion JCH's sequence system is far superior to all of the other pattern-oriented tracker formats I know. Even XM can't compete with this system in terms of pattern size. I hope that someone will introduce a sequence-based sample tracker system some day (Hope JCH is reading this... ;). Greetings go to: -Christoph Brzozowski - Greatest Amiga warrior around -Akintunde Omitowoju - Pushed me to make this description -Jens Christian Huus alias JCH/Vibrants - Maker of EdLib -Chris Huelsbeck - Maker of SidPlay on the C64 and TFMX on the Amiga If you wanna contact me, send me an E-Mail: *** *** May the Force be with you, Joachim Fenkes -$-snap--8<------

Всего 1 фpагмент(а/ов) |пpедыдущий фpагмент (1)

Если вы хотите дополнить FAQ - пожалуйста пишите.

design/collection/some content by Frog,
DEMO DESIGN FAQ (C) Realm Of Illusion 1994-2000,
При перепечатке материалов этой страницы пожалуйста ссылайтесь на источник: "DEMO.DESIGN FAQ,".