Audio 4.94 - Over 11,000 Files

home *** CD-ROM | disk | FTP | other *** search

/ Audio 4.94 - Over 11,000 Files / audio-11000.iso / unix / convrtrs / mod-info < prev next >

Wrap

Internet Message Format | 1994-04-11 | 26KB

From: Lars Hamre <larsha@lise.unit.no> To: guido@cwi.nl Date: Tue, 23 Mar 1993 19:38:04 +0100 There are _NO_ standard sample rate for the samples used in modules. But most often the samples are done on the rate called C-3 (which is about 16574 Hz if you have a PAL machine). Sometimes drums are sampled at A-3 (around 28 kHz), and some sounds are at ~8 kHz or anything else to save space. The sample rate on each of the channels can be selected by a period value, which tells the hardware how many ~3.5 MHz clocks to count down before playing the next sample. If you have a 16 kHz sample you simply play it at a note that gives you 16 kHz sample rate. If you play it one octave lower, you get a 8 kHz sample rate (and a double period value). Here are the magic formulas: 7093789.2 SampleRate = -------------- (For a PAL machine) Period * 2 7159090.5 SampleRate = -------------- (For a NTSC machine) Period * 2 So, the most normal rate is (C-3, period 214): 7093789.2 ----------- = 16574.27 Hz 214 * 2 (16726.8 Hz if you use the NTSC formula, but i have a PAL machine) The Amiga has four channels with independent sample rates, so there are no such thing as a common rate for all channels, and there are no mixing going on. For a list of period values and what notes they are supposed to correspond to, see the list of period values in the MOD format below. Also note that finetuning are actually done by switching between 16 different period tables (not included here, but get the Amiga Protracker Playroutine). --- Lars Hamre larsha@lise.unit.no [ A description of the mod format follows: -Lars] Newsgroups: comp.sys.amiga.audio From: steinarm@ifi.uio.no (Steinar Midtskogen) Subject: Old MOD. format + PowerPacking Summary: Description of the MOD format and powerpacking Keywords: MOD, Powerpacker Organization: University of Oslo, Norway Date: Sun, 14 Mar 1993 23:49:00 GMT Since everybody seem to ask about the module format, here it comes. I will post this information every forthnight, at least for a period (pun intended). I have put together most of the documentation about the module format from PT2.3, edited it heavily (all credit to the original authors, but I take responsibility for all errors) and added information about powerpacking and how the Amiga volume work. The reason for not using documentation following PT3.0, which is written by my group, is that there is no docmentation on the MOD format following that. Our reason for not distributing the documentation of the MOD. format with the tracker is that we try to discourage the usage of the MOD. format; a new format is coming up soon. So don't write a revolutionary piece of code based on the information presented herein; it will hopefully be outdated in only another month. [ Outdated? I don't think so... -Lars] (The "I" in this file refer to Vishnu of Cryptoburners, the "we" refer to respectively Amiga Freelancers and Cryptoburners; it should be obvious from the context which of them) Credits for original doc files: Lars "ZAP" Hamre /Amiga Freelancers The documentation to the song/module format. The information about how to calculate BMPs from the Amiga CIA timings. Peter "CRAYON" Hanning /Mushroom Studios/Noxious Updates to the song/module format information. (I thought that it looked pretty similar to the one from PT1.3, but he had put his name under, so...) The table of effect commands. [ Hrm. Both files are mine. I can see no big changes. -Lars] I have updated the information in the song/module format text, and added information on how the finetuning work. *********************************************************************** Protracker 2.3A Song/Module Format: ----------------------------------- Offset Bytes Description ------ ----- ----------- 0 20 Songname. Remember to put trailing null bytes at the end... When written by ProTracker this will be only uppercase; there are only historical reasons for this. (And the historical reason is that Karsten Obarski, who made the first SoundTracker, was stupid.) Information for sample 1-31: Offset Bytes Description ------ ----- ----------- 20 22 Samplename for sample 1. Pad with null bytes. Will only be uppercase. The samplenames are often used for storing messages from the author; in particular, samplenames starting with a '#' sign will generally be a message. This convention is a result of a player called IntuiTracker displaying all samples starting with # as a message to the person playing the module. 42 2 A WORD with samplelength for sample 1. Stored as number of words. Multiply by two to get real sample length in bytes. This is a big-endian number; for all PC programmers out there, this means that to get your 8-bit-orginated format, you have to swap the two bytes. 44 1 Lower four bits are the finetune value, stored as a signed four bit number. The upper four bits are not used, and should be set to zero. They should also be masked out reading; you can never be sure what some stupid program could have stored here... 45 1 Volume for sample 1. Range is $00-$40, or 0-64 decimal. 46 2 Repeat point for sample 1. Stored as number of words offset from start of sample. Multiply by two to get offset in bytes. 48 2 Repeat Length for sample 1. Stored as number of words in loop. Multiply by two to get replen in bytes. Information for the next 30 samples starts here. It's just like the info for sample 1. Offset Bytes Description ------ ----- ----------- 50 30 Sample 2... 80 30 Sample 3... . . . 890 30 Sample 30... 920 30 Sample 31... Offset Bytes Description ------ ----- ----------- 950 1 Songlength. Range is 1-128. 951 1 This byte is set to 127, so that old trackers will search through all patterns when loading. Noisetracker uses this byte for restart, ProTracker doesn't. 952 128 Song positions 0-127. Each hold a number from 0-63 (or 0-127) that tells the tracker what pattern to play at that position. 1080 4 The four letters "M.K." - This is something Mahoney & Kaktus inserted when they increased the number of samples from 15 to 31. If it's not there, the module/song uses 15 samples or the text has been removed to make the module harder to rip. Startrekker puts "FLT4" or "FLT8" there instead. If there are more than 64 patterns, PT2.3 will insert M!K! here. (Hey - Noxious - why didn't you document the part here relating to YOUR OWN PROGRAM? -Vishnu) Offset Bytes Description ------ ----- ----------- 1084 1024 Data for pattern 00. . . . xxxx Number of patterns stored is equal to the highest patternnumber in the song position table (at offset 952-1079). Each note is stored as 4 bytes, and all four notes at each position in the pattern are stored after each other. 00 - chan1 chan2 chan3 chan4 01 - chan1 chan2 chan3 chan4 02 - chan1 chan2 chan3 chan4 etc. Info for each note: _____byte 1_____ byte2_ _____byte 3_____ byte4_ / \ / \ / \ / \ 0000 0000-00000000 0000 0000-00000000 Upper four 12 bits for Lower four Effect command. bits of sam- note period. bits of sam- ple number. ple number. To separate out the different parts of the note, something like this would be used (C to have it a bit portable; I like assembler and Pascal better myself): int samplenum,effectcommand,effectdata,extendedcommand; char notename[]; ... void ProcessNote(byte notedata[]) { extendedcommand=-1; samplenum=(*notedata&0xF0)|(*(notedata+2)>>4); switch(((*notedata<<8)|(*notedata))&0xfff) { case 856: notename="C-1"; break; case 808: notename="C#1"; break; case 762: notename="D-1"; break; case 856: notename="D#1"; break; /* etc */ default: notename="???"; /* This should NOT occur; if it do, it is */ /* not a ProTracker module! */ } effectcommand=*(notedata+2)&0xF; effectdata=*(notedata+3); if effectcommand==0xE then /* Extended command */ { extendedcommand=effectdata>>4; effectdata&=0xf; /* Only one nibble data for extended command */ } } Probably this isn't 100% valid C code, but I think you catch my drift... Periodtable for Tuning 0, Normal C-1 to B-1 : 856,808,762,720,678,640,604,570,538,508,480,453 C-2 to B-2 : 428,404,381,360,339,320,302,285,269,254,240,226 C-3 to B-3 : 214,202,190,180,170,160,151,143,135,127,120,113 To determine what note to show, scan through the table until you find the same period as the one stored in byte 1-2. Use the index to look up in a notenames table. If you have a bit of memory, it is probably smarter to use an 744 byte block to store the indexes relating to the different periods (ie: at position 808 in the block you store 1, as 1 is the index of period 808. Then you use the block as a look up table) This is the data stored in a normal song. A packed song starts with the four letters "PACK", and then comes the packed data. It is somewhat unclear to me what kind of packing that is referred to here. One thing is clear though - it is NOT powerpacked or LHAed modules! I belive somebody (Probably Amiga Freelancers) was planning to install some form of direct packing into ProTracker, reserved this ID, and then it never came... -Vishnu [No. We never intended to install any packing here. This is an older invention :) Songs (modules WITHOUT the samples) can be packed by this method, and it will put the "PACK" tag at the beginning of the file. But since everyone saves modules with samples instead of songs, I wouldn't care about it. The packer/depacker for PACK'ed files are in the PT source code, available on aminet sites. -Lars Hamre] In a module, all the samples are stored right after the patterndata. To determine where a sample starts and stops, you use the sampleinfo structures in the beginning of the file (from offset 20). Take a look at the mt_init routine in the playroutine, and you'll see just how it is done. The data for a sample must _ALWAYS_ start with two zeros, as it is used for repeating is the sample is to be terminated. [ Well, the playroutine will clear these two bytes anyway... -Lars] *********************************************************************** Finetuning Value: 0 1 2 3 4 5 6 7 8 9 A B C D E F Finetune: 0 +1 +2 +3 +4 +5 +6 +7 -8 -7 -6 -5 -4 -3 -2 -1 Finetuning are done by multiplying the frequency of the playback by X^(finetune), where X ~= 1.0072382087 This means that Amiga PERIODS, which represent delay times before fetching the next sample, should be multiplied by X^(-finetune) Vishnu of Cryptoburners [ This should be 2^(finetune/12/8). And 2^(1/12/8) is 1.007246412 on my calculator... (12 notes per octave and 1/8 of this) -Lars Hamre ] *********************************************************************** Decibel Values and Volume Ranges Volume Decibel Value Volume Decibel Value 64 0.0 32 -6.0 63 -0.1 31 -6.3 62 -0.3 30 -6.6 61 -0.4 29 -6.9 60 -0.6 28 -7.2 59 -0.7 27 -7.5 58 -0.9 26 -7.8 57 -1.0 25 -8.2 56 -1.2 24 -8.5 55 -1.3 23 -8.9 54 -1.5 22 -9.3 53 -1.6 21 -9.7 52 -1.8 20 -10.1 51 -2.0 19 -10.5 50 -2.1 18 -11.0 49 -2.3 17 -11.5 48 -2.5 16 -12.0 47 -2.7 15 -12.6 46 -2.9 14 -13.2 45 -3.1 13 -13.8 44 -3.3 12 -14.5 43 -3.5 11 -15.3 42 -3.7 10 -16.1 41 -3.9 9 -17.0 40 -4.1 8 -18.1 39 -4.3 7 -19.2 38 -4.5 6 -20.6 37 -4.8 5 -22.1 36 -5.0 4 -24.1 35 -5.2 3 -26.6 34 -5.5 2 -30.1 33 -5.8 1 -36.1 0 Minus infinity The reason for the table starting at 0 dB as the convention from taperecorders of having 0 dB as the optimal recording condition, and displaying anything worse as a negative number. Decibel is a logrithmical unit, just like we feel sound intensity. It represent the ratio between two intensities. On the other hand, the Amiga volumes represent the linear difference between sound intensities; this mean that you have less accuracy between the low volumes than between the high ones. If you need to, you can safely remove volume 64 and replace it with volume 63; but you can NOT remove volume 0 and replace it with volume 1. If you are implementing a MOD player for another sound-device, then remember to check whether it has linear or logarithmic volume control. The above table can be calculated from the formula dB=20*log10(Volume/64) To go the other way, from dB to Amiga volumes, do Volume=64*10^(dB/20) The dB here have to do with ratios of sound, not absolute sound power. This is the way it is used in recording equipment etc, and not the for measuring absolute ear-destroying capability. If you need to implement volume artificially, just multiply by the volume and shift right 6 times. If you need to mix samples on-the-fly to lower the amount of voices used, your best bet is probably doing a DCT (Convert the samples to sums of cosines) on small blocks of the sample (64 bytes?) before playing, and mixing with the exact position in which you generate a sample. This is the only way I can think of to give adequate quality, at least. -Vishnu of Cryptoburners *********************************************************************** Protracker V2.3A/3.01 Effect Commands ---------------------------------------------------------------------------- 0 - Normal play or Arpeggio 0xy : x-first halfnote add, y-second 1 - Slide Up 1xx : upspeed 2 - Slide Down 2xx : downspeed 3 - Tone Portamento 3xx : up/down speed 4 - Vibrato 4xy : x-speed, y-depth 5 - Tone Portamento + Volume Slide 5xy : x-upspeed, y-downspeed 6 - Vibrato + Volume Slide 6xy : x-upspeed, y-downspeed 7 - Tremolo 7xy : x-speed, y-depth 8 - NOT USED 9 - Set SampleOffset 9xx : offset (23 -> 2300) A - VolumeSlide Axy : x-upspeed, y-downspeed B - Position Jump Bxx : songposition C - Set Volume Cxx : volume, 00-40 D - Pattern Break Dxx : break position in next patt E - E-Commands Exy : see below... F - Set Speed Fxx : speed (00-1F) / tempo (20-FF) ---------------------------------------------------------------------------- E0- Set Filter E0x : 0-filter on, 1-filter off E1- FineSlide Up E1x : value E2- FineSlide Down E2x : value E3- Glissando Control E3x : 0-off, 1-on (use with tonep.) E4- Set Vibrato Waveform E4x : 0-sine, 1-ramp down, 2-square E5- Set Loop E5x : set loop point E6- Jump to Loop E6x : jump to loop, play x times E7- Set Tremolo Waveform E7x : 0-sine, 1-ramp down. 2-square E8- NOT USED E9- Retrig Note E9x : retrig from note + x vblanks EA- Fine VolumeSlide Up EAx : add x to volume EB- Fine VolumeSlide Down EBx : subtract x from volume EC- NoteCut ECx : cut from note + x vblanks ED- NoteDelay EDx : delay note x vblanks EE- PatternDelay EEx : delay pattern x notes EF- Invert Loop EFx : speed ---------------------------------------------------------------------------- Peter "CRAYON" Hanning /Mushroom Studios/Noxious For a more complete description see my previous post about the new format. This format also allow you to have more effects, and several effects on the same note. Hopefully, it will soon replace the module format. - Vishnu *********************************************************************** Protracker CIA (Complex Interface Adapter) Timer Tempo Calculations: -------------------------------------------------------------------- Fcolor = 4.43361825 MHz (PAL color carrier frequency) CPU Clock = Fcolor * 1.6 = 7.0937892 MHz CIA Clock = Cpu Clock / 10 = 709.37892 kHz 50 Hz Timer = CIA Clock / 50 = 14187.5784 Tempo num. = 50 Hz Timer*125 = 1773447 For NTSC: CPU Clock = 7.1590905 MHz --> Tempo num. = 1789773 To calculate tempo we use the formula: TimerValue = 1773447 / Tempo The timer is only a word, so the available tempo range is 28-255 (++). Tempo 125 will give a normal 50 Hz timer (VBlank). A normal Protracker VBlank song tempo can be calculated as follows: We want to know the tempo in BPM (Beats Per Minute), or rather quarter- notes per minute. Four notes makes up a quarternote. First find interrupts per minute: 60 seconds * 50 per second = 3000 Divide by interrupts per quarter note = 4 notes * speed This gives: Tempo = 3000/(4*speed) simplified: Tempo = 750/speed For a normal song in speed 6 this formula gives: 750/6 = 125 BPM Lars "ZAP" Hamre/Amiga Freelancers 1990 *********************************************************************** The "PowerPacker" crunching algorithm: Powerpacker use a variant of Lemel-Ziv compression. This mean that it in some cases store strings of bytes as only an offset from the current position and a counter. (How LZ could get a patent on this is beyond me!) A PowerPacked file has the following format: dc.b 'PP20' ; Identifier dc.l Efficiency ... crunched data ... dc.l (Length*256)+NumOfBitsToDiscard The Efficiency is 4 bytes representing the length of offset from the current position for different runs of equal bytes. The first three are used for runs of from 2 to 4 bytes; the last is used for all runs of 5 bytes and over. The length is the length of the original, UNcrunched file. The bits to be discarded are discarded off the END of the crunched data. All bits in the crunched data are stored in reverse order, to permit decrunching in a buffer where the crunched data are loaded at the start (An 8 byte margin between the start of the file and the decrunching position is needed, though). This mean you have to get bits in the reverse order when decrunching, and when I refer to "Get A Bit" or Get Eight Bits" or something, that is the LAST bit or bits from the source. Kinda obvious isn't it? ;-) This means that also when a full set of 8 bits are read from the file, their bit order are reversed. The varying efficiencies used by PowerPacker are as follows: Fast: 9, 9, 9, 9 Medicore: 9,10,10,10 Good: 9,10,11,11 Very Good: 9,10,12,12 Best: 9,10,12,13 The Decrunching Algorithm WritePointer is a pointer to the position in memory where decrunched bytes are currently written. Decrunch: REPEAT Get A Bit (X); IF X=0 THEN Copy bytes from source; Copy string from already decrunched part of file; (* Done no matter what the state of X *) UNTIL WritePointer<=Start Of Decrunchbuffer; END. Copy bytes from source: BEGIN n:=0; REPEAT Get Two Bits (X); n:=n+X; UNTIL X<>3; Copy n+1 bytes as bits from Crunched Data to WritePointer; (* At this stage, the bytes get their order of bits reversed; and WritePointer DECREASES *) END; Copy string from already decrunched part of file: BEGIN Get Two Bits(n); OffsetLen:=Efficiency[n]; IF n<>3 THEN Get OffsetLen Bits (X) ELSE BEGIN Get One Bit (X); IF X=0 THEN Get Seven Bits (X) ELSE Get OffsetLen Bits (X); REPEAT Get Three Bits (Y); n:=n+Y; UNTIL Y<>7; END; Copy n+2 bytes from WritePointer+X; (* Here it is copied reversely through memory; X is constant, while WritePointer decreases. *) END; If you can't read this, the original decrunchroutine follows here, in 68000 assembler. It was NOT commented before I cleared it up with macros... So complaints about the comments must go to me, too! Registers used are (in the main decrunch routine): d0 - Counter for number of bits to fetch with the READD1 macro. d1 - Return register for the READBIT macros. d2 - Used as counter register for the copy routines. d3 - Used as offset for the oldstring copy routine. d5 - Used to store the longword currently read bits from. d7 - Used for storing the number of bits left in d5. 0 means one bit left, read new longword to d5 when d7 wraps to negative. a0 - Pointer to current longword of source (the one in d5). a1 - Current position in the buffer to decrunch to. a2 - Start of buffer to decrunch to. Used only for checking whether the decrunching is through. a5 - Pointer to efficiency array. Things to consider: Bits are shifted from d5 to d1 with code like this lsr.l #1,d5 addx.l d1,d1 shifting bits from the BOTTOM of d5 into the BOTTOM of d1, reversing the order of the bits as they go from d5 to d1. The predecrement mode, as in move.b d1,-(a1) decrement a1 BEFORE writing d1. *********************************************************************** ; ; PowerPacker Decrunch assembler subroutine V1.1 ; ; call as: ; DecrunchBuffer (endcrun, buffer, efficiency); ; a0 a1 d0 ; with: ; endcrun : UBYTE * just after last byte of crunched file ; buffer : UBYTE * to memory block to decrunch in ; efficiency: Longword defining efficiency with wich file was crunched ; ; NOTE: ; Decrunch a few bytes higher (safety margin) than the crunched file ; to decrunch in the same memory space. (64 bytes suffice) ; Decrunch: lea myBitsTable(pc),a5 ; Efficiency array move.l d0,(a5) ; Store efficiency for this file. move.l a1,a2 ; Store start of decrunch memory. move.l -(a0),d5 ; Get length & number of bits to moveq #0,d1 ; trash... move.b d5,d1 ; Copy number of bits to trash... lsr.l #8,d5 ; Find length of decrunched file... add.l d5,a1 ; And end of decrunch buffer. move.l -(a0),d5 ; First longword of crunched data. lsr.l d1,d5 ; Skip unused bits... moveq #32-1,d7 ; Number of bits in longword... sub.b d1,d7 ; And be sure to read another when ; d5 is spent! LoopCheckCrunch: ; The decrunch loop. READBIT ; State of bit is returned in d1 bne.s CrunchedBytes ; and Z flag NormalBytes: moveq #0,d2 Read2BitsRow: READBITS #2,d1 ; Get length of run-1 add.w d1,d2 ; Loop until not %11, increasing cmp.w #3,d1 ; all the time... (Sort of Huffman beq.s Read2BitsRow ; on the run lengths...) .ReadNormalByte: ; REPEAT READBITS #8,d1 ; Get from crunched data... move.b d1,-(a1) ; Store... dbf d2,.ReadNormalByte ; UNTIL d2<0 cmp.l a1,a2 ; End of crunch? bcs.s CrunchedBytes ; Nope, now do crunched bytes... rts ; Chicken out - FINITO! CrunchedBytes: READBITS #2,d1 ; Get 2 bits of runlength-2 moveq #0,d0 move.b (a5,d1.w),d0 ; Get number of bits offset for move.w d1,d2 ; this runlength addq.w #1,d2 ; Runlength always 2+ cmp.w #3+1,d2 ; Did data indicate longer run? bne.s ReadOffset ; Nope.... READBIT ; Is the longer run with offsetlen bne.s .LongBlockOffset ; from Efficiency? moveq #7,d0 ; Nope, hard code length 7 .LongBlockOffset: READD1 ; Get offset... move.w d1,d3 Read3BitsRow: READBITS #3,d1 ; Get more string length... add.w d1,d2 ; Increase until stop indicated... cmp.w #7,d1 ; By not having the max value. beq.s Read3BitsRow bra.s DecrunchBlock ; And start the copying. ReadOffset: READD1 ; Get offset for short run... move.w d1,d3 ; and use it! DecrunchBlock: move.b (a1,d3.w),-(a1) ; Loop the copy... dbf d2,DecrunchBlock ; One time more than the initial d2 EndOfLoop: _pp_DecrunchColor: move.w a1,$dff1a2 ; Set colour cmp.l a1,a2 ; Check if we have reached/passed bcs LoopCheckCrunch ; lower limit... rts ; Yeah - chicken out! myBitsTable: dc.b $09,$0a,$0b,$0b ; Efficiency table *********************************************************************** That's all for now - hope you don't mind... If you want to use the PowerPacker decrunching routine, I suggest instead using powerpacker.library if you are on the Amiga; if it is for a demo, I suggest using another cruncher, for instance CrunchMaster. It has better compression ratios than PowerPacker. Vishnu CRB Feel free to e-mail me. steinarm@ifi.uio.no "...all the modern inconveniences..." (Mark Twain)