The comp.sys.apple2 Usenet newsgroup Apple II FAQs originate from the Ground Apple II archive. Administrator: Steve Nelson Csa2 FAQs-on-Ground resource file: R011SNDFMTS.TXT Audio File Formats Guide Notes: This is a pure Text file which has no Font, Color, etc. formatting and no set line length. For best viewing on-line, set browser Word Wrap to ON or copy to your favorite Text viewer and set Word Wrap. Ex: On PC use WordPad with Options set to "Wrap to Window". To correctly view tables and diagrams on a super-res display, use a mono-spaced Font such as CoPilot or PCMononspaced. ____________________________ AUDIO FILE FORMAT RESOURCE GUIDE (Version 1.1) by Dave Huizing 1 TABLE OF CONTENTS 2 GENERAL INFORMATION 2.1 Foreword 2.2 Printed Version 2.3 Copyrights 2.4 Disclaimer 2.5 Contributrors 3 TX WAVE FORMAT 4 YAMAHA TYPHOON WAVE FILE FORMAT 4.1 DWVW v1.2 compression 4.2 DWVW sample delta bit frame 5 D009 5.1 The D00 header 5.2 The Instrument data 5.3 The SpFX data 5.4 The Arrangement data 5.5 The Sequence data 6 MIDI SAMPLE DUMP STANDARD 6.1 INTRODUCTION 6.2 SPEC: SAMPLE DUMP FORMATS 6.3 SPEC: SAMPLE DUMP MESSAGES 6.4 HANDSHAKING MESSAGES: 6.5 DUMP PROCEDURE: MASTER (DUMP SOURCE) 6.6 DUMP PROCEDURE: SLAVE (DUMP DESTINATION) 6.7 SDS OVERVIEW 7 ROL 7.1 Structure of .ROL files 7.2 Notes 8 8SVX 8.1 FORMblock [VHDR] 8.2 FORMblock [BODY] 9 AIFF 10 AU 11 FSM 12 GF1 PATCH 13 S3I 14 UWF 15 WAVE 15.1 RiffBLOCK [data] 15.2 RiffBLOCK [fmt ] 15.3 RiffBLOCK [loop] 16 ZYXEL 17 CREATIVE LABS FILE FORMATS 17.1 Sound Blaster Instrument File Format (SBI) 17.2 Creative Music File Format (CMF) 17.3 The CMF Instrument Block 17.4 The CMF Music Block 17.5 Sound Blaster Instrument Bank File Format (IBK) 18 CREATIVE VOICE (VOC) FILE FORMAT 19 REVISION HISTORY 2 General information 2.1 Foreword I started to compile this document after I thought there was a need for it. By surfing all around the web I collected these descriptions and brought them to this document.I have planed to keep this document updated so if theres any file format description thats not in this document, or you have any comments on this document please send me an email message at: stallion@worldonline.nl. Happy developping, Dave Huizing 2.2 Printed Version If you need a printed version send an email. 2.3 Copyrights Only the title and the compilation is copyrighted by Dave Huizing. As far as I know all this information is free for use. See the disclaimer part for more details. All trademarks, technical information and file extensions belong to their respectfull owners. 2.4 Disclaimer This document is provided on a as is base. The information has been verified as far as possible, but I cannot be held responsible for any problems caused by use or misuse of the information. All due I think I wont happen I am also not responseble for any damage to any knid of computer system after or while using parts form this documentation. Use this document on your own risk. 2.5 Contributrors Dave Huizing, stallion@worldonline.nl DJ, Producer, DTP designer, etc muki pakesch, mpakesch@t0.or.at Maintainer of the TX16W mailinglist Markus - Jvnsson , f93-maj@nada.kth.se Author of the Awave sample convertor 3 TX Wave Format The file consists of a 32 byte header followed by the actual waveform (the first 16 bytes only identifies the file type). In C syntax the header would look like this: char filetype[6] = "LM8953" char nulls[10] char dummy_aeg[6] space for the AEG (never mind this char format 0x49 = looped, 0xC9 = non-looped char sample_rate 1 = 33 kHz, 2 = 50 kHz, 3 = 16 kHz char atc_length[3] I'll get to this... char rpt_length[3] char unused[2] set these to null, to be on the safe side The "atc_length" and "rpt_length" fields are quite complex. First of all you should know that there is no such thing as a looping point in a TX wave. Instead a wave is split into two parts, the attack part and the repeat part (of course the actual wave data isn't split, this is just a logical definition). As you might guess, the attack part is played first and the repeat part is looped until the key is released. Each of these parts are limited to a maximum of 128k words in length. That is the reason why waves can't be longer than 256k words (4096 blocks). The length of a part is stored LSB first (Intel). And only the least significant _bit_ of the third byte (bit 0) is used (representing the most significant bit of the length). Are you confused yet? Then hold your breath. It seems that Yamaha has chosen to squeeze in the sample rate(!) of the wave in the unused _bits_ of these last bytes. Although they already have a separate byte for the sample rate, this isn't enough. I won't go into details on this now (or you would be even more confused). You only need to know that the possible values are: 0x06, 0x52 = 33 kHz 0x10, 0x00 = 50 kHz 0xF6, 0x52 = 16 kHz (The first value is located in byte three of "atc_length" and the second value is located in byte three of "rpt_length".) To wrap it up, this is the format of the two length fields on a bit level: [0] [1] [2] atc_length AAAAAAAA BBBBBBBB DDDDDDDC rpt_length EEEEEEEE FFFFFFFF HHHHHHHG A LSB of the attack length B MSB of the attack length (except for one bit) C the utterly most significant _bit_ of the attack length D the first value of the magic sample rate constant (0x06, 0x10 or 0xF6) E LSB of the repeat length F MSB of the repeat length (except for one bit) G the utterly most significant _bit_ of the repeat length H the second value of the magic sample rate constant (0x52, 0x00) Now for the most important (and probably most interesting) part. The waveform data. As you certainly know the TX uses 12-bit sampling resolution, and this requires some kind of encoding if we are not willing to waste one fourth of our disk space. Yamaha has chosen to group the samples two by two, making three bytes of data in the file for each pair. I'll illustrate this on a bit level (as with the lengths above): AA CD BB A MSB of the first sample B MSB of the second sample C least significant nybble (oh, is that the correct spelling?) of the first sample D least signiticant nybble of the second sample 4 Yamaha Typhoon wave file format This specification describes the compression algorithm for Typhoon format waves. It does not cover the file format, which is AIFF-C. The documentation for AIFF-C is available at the site ftp.sgi.com in the directory /sgi/aiff-c.9.26.91.ps.Z (compressed Postscript file). 4.1 DWVW v1.2 compression DWVW was invented 1991 by Magnus Lidstrom and is copyright 1993 by NuEdge Development. You have the right to use the algorithm freely as long as you make no false claims on its origin. DWVW is a lossless (or bit faithful) compression method for digital audio data. Lossless means that the exact original data will be preserved when compressing and decompressing. The compression utilize the fact that the delta between the sample points is generally less than the full dynamic width. Each sample point is subtracted from the previous one and the difference is enthropy encoded in a special format. Therefore the compression works best on low frequency sounds with low noise ratio, where the difference between each sample is small. DWVW can be applied on samples of any bit resolution and with any number of channels. As opposed to AIFF standard, sample bits are not "left justified". Instead the necessary translation should be done when decompressing. Also, while AIFF interleaves multichannel sounds, DWVW doesn't as this complicates compression and decompression. Each channel follows one another with only a slight break in the bit run. The first delta for each channel should be put at an even 16-bit word position. The encoding stores the delta points with only as many bits as is required (hence the name "variable word width"). Thus, the number of bits used by each delta has to be stored as well. Since this count varies very little we apply a (simpler) delta encoding on this information. To wrap it up, each compressed sample point consists of two values: the delta from the last sample and the difference in word width of this delta from the last delta (hereby referred to as "the WWM" - the word width modifier). Even though the word width modifier is stored first in each delta frame we will describe the delta information first. The delta is always stored as an absolute difference (i.e. unsigned) in a varible number of bits. An extra bit follows that tells the sign (if the delta isn't zero). The number of bits required for the delta (i.e. the word width) is decided by the position of the most significant high bit in the absolut value. One bit less than this is actually stored since the first bit is always high. For instance, the delta 11 (binary 1011) has a required word width of four bits ,but only the least significant three bits are stored. A zero delta will have a zero word width and consequently requires neither delta bits nor sign bit. A delta of one will require only a sign bit. One special case requires attention. A normal two's complement number's lowest negative number is one less than the highest positive number. Treating zero as a positive value this gives exactly as many negative as positive numbers. The delta encoding on the other hand does not consider zero to be of any sign and does therefore not include the one extra negative value. If this value is encountered in the delta stream it is encoded as one greater than it actually is (putting it within the expressable range of values). To distinguish it from the next lowest value one extra bit is inserted after the sign bit. The bit is high for the lowest value and low for the next lowest value. For ex...
y4r05l4v