home *** CD-ROM | disk | FTP | other *** search
/ gdead.berkeley.edu / gdead.berkeley.edu.tar / gdead.berkeley.edu / pub / gdead / sounds / AudioFormats.part2 < prev    next >
Text File  |  1993-04-19  |  42KB  |  1,064 lines

  1. Subject: FAQ: Audio File Formats (part 2 of 2)
  2. Newsgroups: alt.binaries.sounds.misc,alt.binaries.sounds.d,comp.dsp,news.answers,comp.answers
  3. Followup-to: alt.binaries.sounds.d,comp.dsp
  4. Reply-to: guido@cwi.nl
  5. Approved: news-answers-request@MIT.Edu
  6.  
  7. Archive-name: audio-fmts/part2
  8. Submitted-by: Guido van Rossum <guido@cwi.nl>
  9. Version: 3.01
  10. Last-modified: 22-Mar-1993
  11.  
  12. Appendices
  13. ==========
  14.  
  15. Here are some more detailed pieces of info that I received by e-mail.
  16. They are reproduced here virtually without much editing.
  17.  
  18. Table of contents
  19. -----------------
  20.  
  21. FTP access for non-internet sites
  22. AIFF Format (Audio IFF)
  23. The NeXT/Sun audio file format
  24. IFF/8SVX Format
  25. Playing sound on a PC
  26. The EA-IFF-85 documentation
  27. US Federal Standard 1016 availability
  28. Creative Voice (VOC) file format
  29. RIFF WAVE (.WAV) file format
  30. U-LAW and A-LAW definitions
  31. AVR File Format
  32. The Amiga MOD Format
  33.  
  34. ------------------------------------------------------------------------
  35. FTP access for non-internet sites
  36. ---------------------------------
  37.  
  38. From the sci.space FAQ:
  39.  
  40.     Sites not connected to the Internet cannot use FTP directly, but
  41.     there are a few automated FTP servers which operate via email.
  42.     Send mail containing only the word HELP to ftpmail@decwrl.dec.com
  43.     or bitftp@pucc.princeton.edu, and the servers will send you
  44.     instructions on how to make requests
  45.  
  46. Also:
  47.  
  48.     FAQ lists are available by anonymous FTP from pit-manager.mit.edu
  49.     (18.72.1.58) and by email from mail-server@pit-manager.mit.edu (send
  50.     a message containing "help" for instructions about the mail server).
  51.  
  52.  
  53. ------------------------------------------------------------------------
  54. AIFF Format (Audio IFF) and AIFC
  55. --------------------------------
  56.  
  57. This format was developed by Apple for storing high-quality sampled
  58. sound and musical instrument info; it is also used by SGI and several
  59. professional audio packages (sorry, I know no names).  An extension,
  60. called AIFC or AIFF-C, supports compression (see the last item below).
  61.  
  62. I've made a BinHex'ed MacWrite version of the AIFF spec (no idea if
  63. it's the same text as mentioned below) available by anonymous ftp from
  64. ftp.cwi.nl [192.16.184.180]; the file is /pub/audio/AudioIFF1.2.hqx.
  65. But you may be better off with the AIFF-C specs, see below.
  66.  
  67. Mike Brindley (brindley@ece.orst.edu) writes:
  68.  
  69. "The complete AIFF spec by Steve Milne, Matt Deatherage (Apple) is
  70. available in 'AMIGA ROM Kernal Reference Manual: Devices (3rd Edition)'
  71. 1991 by Commodore-Amiga, Inc.; Addison-Wesley Publishing Co.; 
  72. ISBN 0-201-56775-X, starting on page 435 (this edition has a charcoal
  73. grey cover).  It is available in most bookstores, and soon in many
  74. good librairies."
  75.  
  76. According to Mark Callow (msc@sgi.com):
  77.  
  78. A PostScript version of the AIFF-C specification is available via
  79. anonymous ftp on FTP.SGI.COM (192.48.153.1) as /sgi/aiff-c.9.26.91.ps.
  80.  
  81. ------------------------------------------------------------------------
  82. The NeXT/Sun audio file format
  83. ------------------------------
  84.  
  85. Here's the complete story on the file format, from the NeXT
  86. documentation.  (Note that the "magic" number is ((int)0x2e736e64),
  87. which equals ".snd".)  Also, at the end, I've added a litte document
  88. that someone posted to the net a couple of years ago, that describes
  89. the format in a bit-by-bit fashion rather than from C.
  90.  
  91. I received this from Doug Keislar, NeXT Computer.  This is also the
  92. Sun format, except that Sun doesn't recognize as many format codes.  I
  93. added the numeric codes to the table of formats and sorted it.
  94.  
  95.  
  96. SNDSoundStruct:  How a NeXT Computer Represents Sound
  97.  
  98. The NeXT sound software defines the SNDSoundStruct structure to  
  99. represent sound.  This structure defines the soundfile and Mach-O  
  100. sound segment formats and the sound pasteboard type.  It's also used  
  101. to describe sounds in Interface Builder.  In addition, each instance  
  102. of the Sound Kit's Sound class encapsulates a SNDSoundStruct and  
  103. provides methods to access and modify its attributes.
  104.  
  105. Basic sound operations, such as playing, recording, and cut-and-paste  
  106. editing, are most easily performed by a Sound object.  In many cases,  
  107. the Sound Kit obviates the need for in-depth understanding of the  
  108. SNDSoundStruct architecture.  For example, if you simply want to  
  109. incorporate sound effects into an application, or to provide a simple  
  110. graphic sound editor (such as the one in the Mail application), you  
  111. needn't be aware of the details of the SNDSoundStruct.  However, if  
  112. you want to closely examine or manipulate sound data you should be  
  113. familiar with this structure.
  114.  
  115. The SNDSoundStruct contains a header, information that describes the  
  116. attributes of a sound, followed by the data (usually samples) that  
  117. represents the sound.  The structure is defined (in  
  118. sound/soundstruct.h) as:
  119.  
  120. typedef struct {
  121.     int magic;               /* magic number SND_MAGIC */
  122.     int dataLocation;        /* offset or pointer to the data */
  123.     int dataSize;            /* number of bytes of data */
  124.     int dataFormat;          /* the data format code */
  125.     int samplingRate;        /* the sampling rate */
  126.     int channelCount;        /* the number of channels */
  127.     char info[4];            /* optional text information */
  128. } SNDSoundStruct;
  129.  
  130.  
  131.  
  132.  
  133. SNDSoundStruct Fields
  134.  
  135.  
  136.  
  137. magic
  138.  
  139. magic is a magic number that's used to identify the structure as a  
  140. SNDSoundStruct.  Keep in mind that the structure also defines the  
  141. soundfile and Mach-O sound segment formats, so the magic number is  
  142. also used to identify these entities as containing a sound.
  143.  
  144.  
  145.  
  146.  
  147.  
  148. dataLocation
  149.  
  150. It was mentioned above that the SNDSoundStruct contains a header  
  151. followed by sound data.  In reality, the structure only contains the  
  152. header; the data itself is external to, although usually contiguous  
  153. with, the structure.  (Nonetheless, it's often useful to speak of the  
  154. SNDSoundStruct as the header and the data.)  dataLocation is used to  
  155. point to the data.  Usually, this value is an offset (in bytes) from  
  156. the beginning of the SNDSoundStruct to the first byte of sound data.   
  157. The data, in this case, immediately follows the structure, so  
  158. dataLocation can also be thought of as the size of the structure's  
  159. header.  The other use of dataLocation, as an address that locates  
  160. data that isn't contiguous with the structure, is described in  
  161. "Format Codes," below.
  162.  
  163.  
  164.  
  165.  
  166.  
  167. dataSize, dataFormat, samplingRate, and channelCount
  168.  
  169. These fields describe the sound data.
  170.  
  171. dataSize is its size in bytes (not including the size of the  
  172. SNDSoundStruct).
  173.  
  174. dataFormat is a code that identifies the type of sound.  For sampled  
  175. sounds, this is the quantization format.  However, the data can also  
  176. be instructions for synthesizing a sound on the DSP.  The codes are  
  177. listed and explained in "Format Codes," below.
  178.  
  179. samplingRate is the sampling rate (if the data is samples).  Three  
  180. sampling rates, represented as integer constants, are supported by  
  181. the hardware:
  182.  
  183. Constant        Sampling Rate (samples/sec) 
  184.  
  185. SND_RATE_CODEC  8012.821        (CODEC input)
  186. SND_RATE_LOW    22050.0 (low sampling rate output)
  187. SND_RATE_HIGH   44100.0 (high sampling rate output)
  188.  
  189. channelCount is the number of channels of sampled sound.
  190.  
  191.  
  192.  
  193.  
  194.  
  195. info
  196.  
  197. info is a NULL-terminated string that you can supply to provide a  
  198. textual description of the sound.  The size of the info field is set  
  199. when the structure is created and thereafter can't be enlarged.  It's  
  200. at least four bytes long (even if it's unused).
  201.  
  202.  
  203.  
  204.  
  205.  
  206. Format Codes
  207.  
  208. A sound's format is represented as a positive 32-bit integer.  NeXT  
  209. reserves the integers 0 through 255; you can define your own format  
  210. and represent it with an integer greater than 255.  Most of the  
  211. formats defined by NeXT describe the amplitude quantization of  
  212. sampled sound data:
  213.  
  214. Value   Code    Format 
  215.  
  216. 0       SND_FORMAT_UNSPECIFIED  unspecified format 
  217. 1       SND_FORMAT_MULAW_8      8-bit mu-law samples
  218. 2       SND_FORMAT_LINEAR_8     8-bit linear samples
  219. 3       SND_FORMAT_LINEAR_16    16-bit linear samples
  220. 4       SND_FORMAT_LINEAR_24    24-bit linear samples
  221. 5       SND_FORMAT_LINEAR_32    32-bit linear samples
  222. 6       SND_FORMAT_FLOAT        floating-point samples
  223. 7       SND_FORMAT_DOUBLE       double-precision float samples
  224. 8       SND_FORMAT_INDIRECT     fragmented sampled data
  225. 9       SND_FORMAT_NESTED       ?
  226. 10      SND_FORMAT_DSP_CORE     DSP program
  227. 11      SND_FORMAT_DSP_DATA_8   8-bit fixed-point samples
  228. 12      SND_FORMAT_DSP_DATA_16  16-bit fixed-point samples
  229. 13      SND_FORMAT_DSP_DATA_24  24-bit fixed-point samples
  230. 14      SND_FORMAT_DSP_DATA_32  32-bit fixed-point samples
  231. 15      ?
  232. 16      SND_FORMAT_DISPLAY      non-audio display data
  233. 17      SND_FORMAT_MULAW_SQUELCH        ?
  234. 18      SND_FORMAT_EMPHASIZED   16-bit linear with emphasis
  235. 19      SND_FORMAT_COMPRESSED   16-bit linear with compression
  236. 20      SND_FORMAT_COMPRESSED_EMPHASIZED        A combination of the two above
  237. 21      SND_FORMAT_DSP_COMMANDS Music Kit DSP commands
  238. 22      SND_FORMAT_DSP_COMMANDS_SAMPLES         ?
  239. [Some new ones supported by Sun.  This is all I currently know. --GvR]
  240. 23      SND_FORMAT_ADPCM_G721
  241. 24      SND_FORMAT_ADPCM_G722
  242. 25      SND_FORMAT_ADPCM_G723_3
  243. 26      SND_FORMAT_ADPCM_G723_5
  244. 27      SND_FORMAT_ALAW_8
  245.  
  246.  
  247. Most formats identify different sizes and types of  
  248. sampled data.  Some deserve special note:  
  249.  
  250.  
  251. --      SND_FORMAT_DSP_CORE format contains data that represents a  
  252. loadable DSP core program.  Sounds in this format are required by the  
  253. SNDBootDSP() and SNDRunDSP() functions.  You create a  
  254. SND_FORMAT_DSP_CORE sound by reading a DSP load file (extension  
  255. ".lod") with the SNDReadDSPfile() function.
  256.  
  257. --      SND_FORMAT_DSP_COMMANDS is used to distinguish sounds that  
  258. contain DSP commands created by the Music Kit.  Sounds in this format  
  259. can only be created through the Music Kit's Orchestra class, but can  
  260. be played back through the SNDStartPlaying() function.
  261.  
  262. --      SND_FORMAT_DISPLAY format is used by the Sound Kit's  
  263. SoundView class.  Such sounds can't be played.  
  264.  
  265.  
  266. --      SND_FORMAT_INDIRECT indicates data that has become  
  267. fragmented, as described in a separate section, below.  
  268.  
  269.  
  270. --      SND_FORMAT_UNSPECIFIED is used for unrecognized formats.
  271.  
  272.  
  273.  
  274.  
  275.  
  276. Fragmented Sound Data
  277.  
  278. Sound data is usually stored in a contiguous block of memory.   
  279. However, when sampled sound data is edited (such that a portion of  
  280. the sound is deleted or a portion inserted), the data may become  
  281. discontiguous, or fragmented.  Each fragment of data is given its own  
  282. SNDSoundStruct header; thus, each fragment becomes a separate  
  283. SNDSoundStruct structure.  The addresses of these new structures are  
  284. collected into a contiguous, NULL-terminated block; the dataLocation  
  285. field of the original SNDSoundStruct is set to the address of this  
  286. block, while the original format, sampling rate, and channel count  
  287. are copied into the new SNDSoundStructs.  
  288.  
  289.  
  290. Fragmentation serves one purpose:  It avoids the high cost of moving  
  291. data when the sound is edited.  Playback of a fragmented sound is  
  292. transparent-you never need to know whether the sound is fragmented  
  293. before playing it.  However, playback of a heavily fragmented sound  
  294. is less efficient than that of a contiguous sound.  The  
  295. SNDCompactSamples() C function can be used to compact fragmented  
  296. sound data.
  297.  
  298. Sampled sound data is naturally unfragmented.  A sound that's freshly  
  299. recorded or retrieved from a soundfile, the Mach-O segment, or the  
  300. pasteboard won't be fragmented.  Keep in mind that only sampled data  
  301. can become fragmented.
  302.  
  303.  
  304.  
  305. _________________________
  306. >From mentor.cc.purdue.edu!purdue!decwrl!ucbvax!ziploc!eps Wed Apr  4  
  307. 23:56:23 EST 1990
  308. Article 5779 of comp.sys.next:
  309. Path: mentor.cc.purdue.edu!purdue!decwrl!ucbvax!ziploc!eps
  310. >From: eps@toaster.SFSU.EDU (Eric P. Scott)
  311. Newsgroups: comp.sys.next
  312. Subject: Re: Format of NeXT sndfile headers?
  313. Message-ID: <445@toaster.SFSU.EDU>
  314. Date: 31 Mar 90 21:36:17 GMT
  315. References: <14978@phoenix.Princeton.EDU>
  316. Reply-To: eps@cs.SFSU.EDU (Eric P. Scott)
  317. Organization: San Francisco State University
  318. Lines: 42
  319.  
  320. In article <14978@phoenix.Princeton.EDU>
  321.         bskendig@phoenix.Princeton.EDU (Brian Kendig) writes:
  322. >I'd like to take a program I have that converts Macintosh sound  
  323. files
  324. >to NeXT sndfiles and polish it up a bit to go the other direction as
  325. >well.
  326.  
  327. Two people have already submitted programs that do this
  328. (Christopher Lane and Robert Hood); check the various
  329. NeXT archive sites.
  330.  
  331. >       Could someone please give me the format of a NeXT sndfile
  332. >header?
  333.  
  334. "big-endian"
  335.         0       1       2       3
  336.         +-------+-------+-------+-------+
  337. 0       | 0x2e  | 0x73  | 0x6e  | 0x64  |       "magic" number
  338.         +-------+-------+-------+-------+
  339. 4       |                               |       data location
  340.         +-------+-------+-------+-------+
  341. 8       |                               |       data size
  342.         +-------+-------+-------+-------+
  343. 12      |                               |       data format (enum)
  344.         +-------+-------+-------+-------+
  345. 16      |                               |       sampling rate (int)
  346.         +-------+-------+-------+-------+
  347. 20      |                               |       channel count
  348.         +-------+-------+-------+-------+
  349. 24      |       |       |       |       |       (optional) info  
  350. string
  351.  
  352. 28 = minimum value for data location
  353.  
  354. data format values can be found in /usr/include/sound/soundstruct.h
  355.  
  356. Most common combinations:
  357.  
  358.          sampling  channel    data
  359.              rate    count  format              
  360. voice file   8012        1       1 =  8-bit mu-law
  361. system beep 22050        2       3 = 16-bit linear
  362. CD-quality  44100        2       3 = 16-bit linear
  363.  
  364. ------------------------------------------------------------------------
  365. IFF/8SVX Format
  366. ---------------
  367.  
  368. Newsgroups: alt.binaries.sounds.d,alt.sex.sounds
  369. Subject: Format of the IFF header (Amiga sounds)
  370. Message-ID: <2509@tardis.Tymnet.COM>
  371. From: jms@tardis.Tymnet.COM (Joe Smith)
  372. Date: 23 Oct 91 23:54:38 GMT
  373. Followup-To: alt.binaries.sounds.d
  374. Organization: BT North America (Tymnet)
  375.  
  376. The first 12 bytes of an IFF file are used to distinguish between an Amiga
  377. picture (FORM-ILBM), an Amiga sound sample (FORM-8SVX), or other file
  378. conforming to the IFF specification.  The middle 4 bytes is the count of
  379. bytes that follow the "FORM" and byte count longwords.  (Numbers are stored
  380. in M68000 form, high order byte first.)
  381.  
  382.                 ------------------------------------------
  383.  
  384. FutureSound audio file, 15000 samples at 10.000KHz, file is 15048 bytes long.
  385.  
  386. 0000: 464F524D 00003AC0 38535658 56484452    FORM..:.8SVXVHDR
  387.       F O R M     15040 8 S V X  V H D R
  388. 0010: 00000014 00003A98 00000000 00000000    ......:.........
  389.             20    15000        0        0
  390. 0020: 27100100 00010000 424F4459 00003A98    '.......BODY..:.
  391.      10000 1 0    1.0   B O D Y     15000
  392.  
  393. 0000000..03 = "FORM", identifies this as an IFF format file.
  394. FORM+00..03 (ULONG) = number of bytes that follow.  (Unsigned long int.)
  395. FORM+03..07 = "8SVX", identifies this as an 8-bit sampled voice.
  396.  
  397. ????+00..03 = "VHDR", Voice8Header, describes the parameters for the BODY.
  398. VHDR+00..03 (ULONG) = number of bytes to follow. 
  399. VHDR+04..07 (ULONG) = samples in the high octave 1-shot part.
  400. VHDR+08..0B (ULONG) = samples in the high octave repeat part.
  401. VHDR+0C..0F (ULONG) = samples per cycle in high octave (if repeating), else 0.
  402. VHDR+10..11 (UWORD) = samples per second.  (Unsigned 16-bit quantity.)
  403. VHDR+12     (UBYTE) = number of octaves of waveforms in sample.
  404. VHDR+13     (UBYTE) = data compression (0=none, 1=Fibonacci-delta encoding).
  405. VHDR+14..17 (FIXED) = volume.  (The number 65536 means 1.0 or full volume.)
  406.  
  407. ????+00..03 = "BODY", identifies the start of the audio data.
  408. BODY+00..03 (ULONG) = number of bytes to follow.
  409. BODY+04..NNNNN      = Data, signed bytes, from -128 to +127.
  410.  
  411. 0030: 04030201 02030303 04050605 05060605
  412. 0040: 06080806 07060505 04020202 01FF0000
  413. 0050: 00000000 FF00FFFF FFFEFDFD FDFEFFFF
  414. 0060: FDFDFF00 00FFFFFF 00000000 00FFFF00
  415. 0070: 00000000 00FF0000 00FFFEFF 00000000
  416. 0080: 00010000 000101FF FF0000FE FEFFFFFE
  417. 0090: FDFDFEFD FDFFFFFC FDFEFDFD FEFFFEFE
  418. 00A0: FFFEFEFE FEFEFEFF FFFFFEFF 00FFFF01
  419.  
  420. This small section of the audio sample shows the number ranging from -5 (0xFD)
  421. to +8 (0x08).  Warning: Do not assume that the BODY starts 48 bytes into the
  422. file.  In addition to "VHDR", chunks labeled "NAME", "AUTH", "ANNO", or 
  423. "(c) " may be present, and may be in any order.  You will have to check the
  424. byte count in each chunk to determine how many bytes to skip.
  425.  
  426. ------------------------------------------------------------------------
  427. Playing sound on a PC
  428. ---------------------
  429.  
  430. From: Eric A Rasmussen
  431.  
  432. Any turbo PC (8088 at 8 Mhz or greater)/286/386/486/etc. can produce a quality
  433. playback of single channel 8 bit sounds on the internal (1 bit, 1 channel)
  434. speaker by utilizing Pulse-Width-Modulation, which toggles the speaker faster
  435. than it can physically move to simulate positions between fully on and fully
  436. off.  There are several PD programs of this nature that I know of:
  437.  
  438. REMAC  - Plays MAC format sound files.  Files on the Macintosh, at least the
  439.          sound files that I've ripped apart, seem to contain 3 parts.  The
  440.          first two are info like what the file icon looks like and other
  441.          header type info.  The third part contains the raw sample data, and
  442.          it is this portion of the file which is saved to a seperate file,
  443.          often named with the .snd extension by PC users.  Personally, I like
  444.          to name the files .s1, .s2, .s3, or .s4 to indicate the sampling rate
  445.          of the file. (-s# is how to specify the playback rate in REMAC.)
  446.          REMAC provides playback rates of 5550hz, 7333hz, 11 khz, & 22 khz.
  447. REMAC2 - Same as REMAC, but sounds better on higher speed machines.
  448. REPLAY - Basically same as REMAC, but for playback of Atari ST sounds. 
  449.          Apparently, the Atari has two sound formats, one of which sounds like
  450.          garbage if played by REMAC or REPLAY in the incorrect mode.  The
  451.          other file format works fine with REMAC and so appears to be 'normal'
  452.          unsigned 8-bit data.  REPLAY provides playback rates of 11.5 khz,
  453.          12.5 khz, 14 khz, 16 khz, 18.5 khz, 22khz, & 27 khz.
  454.  
  455. These three programs are all by the same author, Richard E. Zobell who does
  456. not have an internet mail address to my knowledge, but does have a GEnie email
  457. address of R.ZOBELL. 
  458.  
  459. Additionally, there are various stand-alone demos which use the internal
  460. speaker, of which there is one called mushroom which plays a 30 second
  461. advertising jingle for magic mushroom room deoderizers which is pretty
  462. humerous.  I've used this player to playback samples that I ripped out of the
  463. commercial game program Mean Streets, which uses something they call RealSound
  464. (tm) to playback digital samples on the internal speaker. (Of course, I only do
  465. this on my own system, and since I own the game, I see no problems with it.)
  466.  
  467. For owners of 8 Mhz 286's and above, the option to play 4 channel 8 bit sounds
  468. (with decent quality) on the internal speaker is also a reality.  Quite a
  469. number of PD programs exist to do this, including, but not limited to:
  470.  
  471. ModEdit, ModPlay, ScreamTracker, STM, Star Trekker, Tetra, and probably a few
  472. more.  
  473.  
  474. All these programs basically make use of various sound formats used by the
  475. Amiga line of computers.  These include .stm files, .mod files
  476. [a.k.a. mod. files], and .nst files [really the same hing].  Also,
  477. these programs pretty much all have the option to playback the 
  478. sound to add-on hardware such as the SoundBlaster card, the Covox series of
  479. devices, and also to direct the data to either one or two (for stereo)
  480. parallel ports, which you could attach your own D/A's to.  (From what I have
  481. seen, the Covox is basically an small amplified speaker with a D/A which plugs
  482. into the parallel port.  This sounds very similiar to the Disney Sound System
  483. (DSS) which people have been talking about recently.)  
  484.  
  485. ------------------------------------------------------------------------
  486. The EA-IFF-85 documentation
  487. ---------------------------
  488.  
  489. From: dgc3@midway.uchicago.edu
  490.  
  491. As promised, here's an ftp location for the EA-IFF-85 documentation.  It's
  492. the November 1988 release as revised by Commodore (the last public release),
  493. with specifications for IFF FORMs for graphics, sound, formatted text, and
  494. more.  IFF FORMS now exist for other media, including structured drawing, and
  495. new documentation is now available only from Commodore.
  496.  
  497. The documentation is at grind.isca.uiowa.edu [128.255.19.233], in the
  498. directory /amiga/f1/ff185.  The complete file list is as follows:
  499.  
  500. DOCUMENTS.zoo    
  501. EXAMPLES.zoo     
  502. EXECUTABLE.zoo   
  503. INCLUDE.zoo      
  504. LINKER_INFO.zoo  
  505. OBJECT.zoo       
  506. SOURCE.zoo       
  507. TP_IFF_Specs.zoo 
  508.  
  509. All files except DOCUMENTS.zoo are Amiga-specific, but may be used as a basis
  510. for conversion to other platforms.  Well, I take that tentatively back.  I
  511. don't know what TP_IFF_Specs.zoo contains, so it might be non-Amiga-specific.
  512.  
  513. ------------------------------------------------------------------------
  514. US Federal Standard 1016 availability
  515. -------------------------------------
  516.  
  517. From: Joe Campbell  N3JBC  jpcampb@afterlife.ncsc.mil  74040.305@compuserve.com
  518.  
  519. The U.S. DoD's Federal-Standard-1016 4800 bps code excited linear prediction
  520. voice coder version 3.2 (CELP 3.2) Fortran and C simulation source codes are
  521. now available for worldwide distribution at no charge (on DOS diskettes,
  522. but configured to compile on Sun SPARC stations) from:
  523.  
  524. Bob Fenichel
  525. National Communications System
  526. Washington, D.C.  20305
  527. 1-703-692-2124
  528. 1-703-746-4960 (fax)
  529.  
  530. In addition to the source codes, example input and processed speech files
  531. are included along with a technical information bulletin to assist in
  532. implementation of FS-1016 CELP.  (An anonymous ftp site is being considered
  533. for future releases.)
  534.  
  535. Copies of the FS-1016 document are available for $2.50 each from:
  536.  
  537. GSA Rm 6654
  538. 7th & D St SW
  539. Washington, D.C.  20407
  540. 1-202-708-9205
  541.  
  542. The following articles describe the Federal-Standard-1016 4.8-kbps CELP
  543. coder (it's unnecessary to read more than one):
  544.  
  545. Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch,
  546. "The Federal Standard 1016 4800 bps CELP Voice Coder," Digital Signal
  547. Processing, Academic Press, 1991, Vol. 1, No. 3, p. 145-155.
  548.  
  549. Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch,
  550. "The DoD 4.8 kbps Standard (Proposed Federal Standard 1016),"
  551. in Advances in Speech Coding, ed. Atal, Cuperman and Gersho,
  552. Kluwer Academic Publishers, 1991, Chapter 12, p. 121-133.
  553.  
  554. Campbell, Joseph P. Jr., Thomas E. Tremain and Vanoy C. Welch, "The
  555. Proposed Federal Standard 1016 4800 bps Voice Coder:  CELP," Speech
  556. Technology Magazine, April/May 1990, p. 58-64.
  557.  
  558. For U.S. FED-STD-1016 (4800 bps CELP) _realtime_ DSP code
  559. and information about products using this code, contact:
  560.  
  561. John DellaMorte
  562. DSP Software Engineering
  563. 165 Middlesex Tpk, Suite 206
  564. Bedford, MA  01730
  565. 1-617-275-3733
  566. 1-617-275-4323 (fax)
  567. dspse.bedford@channel1.com
  568.  
  569. DSP Software Engineering's code can run on a DSP Research's Tiger 30 board
  570. (a PC board with a TMS320C3x and analog interface suited to development work)
  571. or on Intellibit's AE2000 TMS320C31 based 3" by 2.5" card.
  572.  
  573. DSP Research                Intellibit
  574. 1095 E. Duane Ave.          P.O. Box 9785
  575. Sunnyvale, CA  94086        McLean, VA  22102-0785
  576. (408)773-1042               (703)442-4781
  577. (408)736-3451 (fax)         (703)442-4784 (fax)
  578.  
  579. From: tobiasr@monolith.lrmsc.loral.com (Richard Tobias )
  580.  
  581. For U.S. FED-STD-1016 (4800 bps CELP) _realtime_ DSP code and
  582. information about products using this code using the AT&T DSP32C and
  583. AT&T DSP3210, contact:
  584.  
  585. White Eagle Systems Technology, Inc.
  586. 1123 Queensbridge Way
  587. San Jose, CA 95120
  588. (408) 997-2706
  589. (408) 997-3584 (fax)
  590. rjjt@netcom.com
  591.  
  592. Newsgroups: comp.dsp
  593. From: bae@hplsdrn.col.hp.com (Bruce Erickson)
  594. Subject: Re: FTP site for CELP audio compression source?
  595.  
  596. In comp.dsp (subj: FTP site for CELP audio compression source?), Joe
  597. Campbell writes:
  598. > I would like to mention that a document, that is a vital part of the CELP
  599. > release package, is not available in electronic form.  Therefore, I urge
  600. > anyone who is seriously interested in this coder to obtain this document:
  601. >  Details to Assist in Implementation of Federal Standard 1016 CELP.
  602. >  National Communications System, Office of Technology & Standards, 1992.
  603. >  Technical Information Bulletin 92-1.
  604. [Available for free from Bob Fenichel above --GvR]
  605.  
  606. I would also like to mention that when Bob gave me permission to put the
  607. CELP disks on wsmr-simutel he asked for people who fetch them to let
  608. him know that they have them.  
  609.  
  610. So if you grab the sources -- from whatever source -- please give him
  611. a call or send him USmail.
  612.  
  613. I am still waiting for wsmr-simutel to let me know how to upload the CELP
  614. disks -- I will be sure to post here & elsewhere when I upload them!
  615.  
  616.                      - Bruce Erickson
  617.                      bae@col.hp.com
  618.  
  619. ------------------------------------------------------------------------
  620. Creative Voice (VOC) file format
  621. --------------------------------
  622.  
  623. From: galt@dsd.es.com
  624.  
  625. (byte numbers are hex!)
  626.  
  627.     HEADER (bytes 00-19)
  628.     Series of DATA BLOCKS (bytes 1A+) [Must end w/ Terminator Block]
  629.  
  630. - ---------------------------------------------------------------
  631.  
  632. HEADER:
  633. =======
  634.      byte #     Description
  635.      ------     ------------------------------------------
  636.      00-12      "Creative Voice File"
  637.      13         1A (eof to abort printing of file)
  638.      14-15      Offset of first datablock in .voc file (std 1A 00
  639.                 in Intel Notation)
  640.      16-17      Version number (minor,major) (VOC-HDR puts 0A 01)
  641.      18-19      2's Comp of Ver. # + 1234h (VOC-HDR puts 29 11)
  642.  
  643. - ---------------------------------------------------------------
  644.  
  645. DATA BLOCK:
  646. ===========
  647.  
  648.    Data Block:  TYPE(1-byte), SIZE(3-bytes), INFO(0+ bytes)
  649.    NOTE: Terminator Block is an exception -- it has only the TYPE byte.
  650.  
  651.       TYPE   Description     Size (3-byte int)   Info
  652.       ----   -----------     -----------------   -----------------------
  653.       00     Terminator      (NONE)              (NONE)
  654.       01     Sound data      2+length of data    *
  655.       02     Sound continue  length of data      Voice Data
  656.       03     Silence         3                   **
  657.       04     Marker          2                   Marker# (2 bytes)
  658.       05     ASCII           length of string    null terminated string
  659.       06     Repeat          2                   Count# (2 bytes)
  660.       07     End repeat      0                   (NONE)
  661.  
  662.       *Sound Info Format:       **Silence Info Format:
  663.        ---------------------      ----------------------------
  664.        00   Sample Rate           00-01  Length of silence - 1
  665.        01   Compression Type      02     Sample Rate
  666.        02+  Voice Data
  667.  
  668.  
  669.   Marker#           -- Driver keeps the most recent marker in a status byte
  670.   Count#            -- Number of repetitions + 1
  671.                          Count# may be 1 to FFFE for 0 - FFFD repetitions
  672.                          or FFFF for endless repetitions
  673.   Sample Rate       -- SR byte = 256-(1000000/sample_rate)
  674.   Length of silence -- in units of sampling cycle
  675.   Compression Type  -- of voice data
  676.                          8-bits    = 0
  677.                          4-bits    = 1
  678.                          2.6-bits  = 2
  679.                          2-bits    = 3
  680.                          Multi DAC = 3+(# of channels) [interesting--
  681.                                        this isn't in the developer's manual]
  682.  
  683. ------------------------------------------------------------------------
  684. RIFF WAVE (.WAV) file format
  685. ----------------------------
  686.  
  687. RIFF is a format by Microsoft and IBM which is similar in spirit and
  688. functionality as EA-IFF-85, but not compatible (and it's in
  689. little-endian byte order, of course :-).  WAVE is RIFF's equivalent of
  690. AIFF, and its inclusion in Microsoft Windows 3.1 has suddenly made it
  691. important to know about.
  692.  
  693. Rob Ryan was kind enough to send me a description of the RIFF format.
  694. Unfortunately, it is too big to include here (27 k), but I've made it
  695. available for anonymous ftp as ftp.cwi.nl:/pub/audio/RIFF-format.
  696.  
  697. And here's a pointer to the official description from Matt Saettler,
  698. Microsoft Multimedia:
  699.  
  700. "The complete definition of the WAVE file format as defined by
  701. IBM/Microsoft is available for anon. FTP from ftp.uu.net in the
  702. vendor/microsoft/multimedia directory."
  703.  
  704. (Rob Ryan's version may actually be an extract from one of the files
  705. stored there.)
  706.  
  707. ------------------------------------------------------------------------
  708. U-LAW and A-LAW definitions
  709. ---------------------------
  710.  
  711. [Adapted from information provided by duggan@cc.gatech.edu (Rick
  712. Duggan) and davep@zenobia.phys.unsw.EDU.AU (David Perry)]
  713.  
  714. u-LAW (really mu-LAW) is
  715.  
  716.           sgn(m)   (     |m |)       |m |
  717.    y=    ------- ln( 1+ u|--|)       |--| =< 1
  718.          ln(1+u)   (     |mp|)       |mp|         
  719.  
  720. A-LAW is
  721.  
  722.      |     A    (m )                 |m |    1
  723.      |  ------- (--)                 |--| =< - 
  724.      |  1+ln A  (mp)                 |mp|    A     
  725.    y=|
  726.      | sgn(m) (        |m |)    1    |m |
  727.      | ------ ( 1+ ln A|--|)    - =< |--| =< 1
  728.      | 1+ln A (        |mp|)    A    |mp|         
  729.  
  730. Values of u=100 and 255, A=87.6, mp is the Peak message value, m is
  731. the current quantised message value.  (The formulae get simpler if you
  732. substitute x for m/mp and sgn(x) for sgn(m); then -1 <= x <= 1.)
  733.  
  734. Converting from u-LAW to A-LAW is in a sense "lossy" since there are
  735. quantizing errors introduced in the conversion.
  736.  
  737. "..the u-LAW used in North America and Japan, and the
  738. A-LAW used in Europe and the rest of the world and
  739. international routes.."
  740.  
  741. References:
  742.  
  743. Modern Digital and Analog Communication Systems, B.P.Lathi., 2nd ed.
  744. ISBN 0-03-027933-X
  745.  
  746. Transmission Systems for Communications
  747. Fifth Edition
  748. by Members of the Technical Staff at Bell Telephone Laboratories
  749. Bell Telephone Laboratories, Incorporated
  750. Copyright 1959, 1964, 1970, 1982
  751.  
  752. ------------------------------------------------------------------------
  753. AVR File Format
  754. ---------------
  755.  
  756. From: hyc@hanauma.Jpl.Nasa.Gov (Howard Chu)
  757.  
  758. A lot of PD software exists to play Mac .snd files on the ST. One other
  759. format that seems pretty popular (used by a number of commercial packages)
  760. is the AVR format (from Audio Visual Research). This format has a 128 byte
  761. header that looks like this:
  762.  
  763.         char magic[4]="2BIT";
  764.         char name[8];           /* null-padded sample name */
  765.         short mono;             /* 0 = mono, 0xffff = stereo */
  766.         short rez;              /* 8 = 8 bit, 16 = 16 bit */
  767.         short sign;             /* 0 = unsigned, 0xffff = signed */
  768.         short loop;             /* 0 = no loop, 0xffff = looping sample */
  769.         short midi;             /* 0xffff = no MIDI note assigned,
  770.                                    0xffXX = single key note assignment
  771.                                    0xLLHH = key split, low/hi note */
  772.         long rate;              /* sample frequency in hertz */
  773.         long size;              /* sample length in bytes or words (see rez) */
  774.         long lbeg;              /* offset to start of loop in bytes or words.
  775.                                    set to zero if unused. */
  776.         long lend;              /* offset to end of loop in bytes or words.
  777.                                    set to sample length if unused. */
  778.         short res1;             /* Reserved, MIDI keyboard split */
  779.         short res2;             /* Reserved, sample compression */
  780.         short res3;             /* Reserved */
  781.         char ext[20];           /* Additional filename space, used
  782.                                    if (name[7] != 0) */
  783.         char user[64];          /* User defined. Typically ASCII message. */
  784.  
  785. -----------------------------------------------------------------------
  786. The Amiga MOD Format
  787. --------------------
  788.  
  789. From: norlin@mailhost.ecn.uoknor.edu (Norman Lin)
  790.  
  791. MOD files are music files containing 2 parts:
  792.  
  793. (1) a bank of digitized samples
  794. (2) sequencing information describing how and when to play the samples
  795.  
  796. MOD files originated on the Amiga, but because of their flexibility
  797. and the extremely large number of MOD files available, MOD players
  798. are now available for a variety of machines (IBM PC, Mac, Sparc
  799. Station, etc.)
  800.  
  801. The samples in a MOD file are raw, 8 bit, signed, headerless, linear
  802. digital data.  There may be up to 31 distinct samples in a MOD file,
  803. each with a length of up to 128K (though most are much smaller; say,
  804. 10K - 60K).  An older MOD format only allowed for up to 15 samples in
  805. a MOD file; you don't see many of these anymore.  [The standard
  806. sampling rate is 10k, see below. --GvR]
  807.  
  808. The sequencing information in a MOD file contains 4 tracks of
  809. information describing which, when, for how long, and at what frequency
  810. samples should be played.  This means that a MOD file can have up
  811. to 31 distinct (digitized) instrument sounds, with up to 4 playing
  812. simultaneously at any given point.  This allows a wide variety
  813. of orchestrational possibilities, including use of voice samples
  814. or creation of one's own instruments (with appropriate sampling
  815. hardware/software).  The ability to use one's own samples as instruments
  816. is a flexibility that other music files/formats do not share, and
  817. is one of the reasons MOD files are so popular, numerous, and diverse.
  818.  
  819. 15 instrument MODs, as noted above, are somewhat older than 31
  820. instrument MODs and are not (at least not by me) seen very often
  821. anymore.  Their format is identical to that of 31 instrument MODs
  822. except:
  823.  
  824. (1) Since there are only 15 samples, the information for the last (15th)
  825.     sample starts at byte 440 and goes through byte 469.
  826. (2) The songlength is at byte 470 (contrast with byte 950 in 31 instrument
  827.     MOD)
  828. (3) Byte 471 appears to be ignored, but has been observed to be 127.
  829.     (Sorry, this is from observation only)
  830. (4) Byte 472 begins the pattern sequence table (contrast with byte 952
  831.     in a 31 instrument MOD)
  832. (5) Patterns start at byte 600 (contrast with byte 1084 in 31 instrument MOD)
  833.  
  834. "ProTracker," an Amiga MOD file creator/editor, is available for ftp
  835. everywhere as pt??.lzh.
  836.  
  837. From: Apollo Wong <apollo@ee.ualberta.ca>
  838.  
  839. From: M.J.H.Cox@bradford.ac.uk (Mark Cox)
  840. Newsgroups: alt.sb.programmer
  841. Subject: Re: Format for MOD files...
  842. Message-ID: <1992Mar18.103608.4061@bradford.ac.uk>
  843. Date: 18 Mar 92 10:36:08 GMT
  844. Organization: University of Bradford, UK
  845.  
  846. wdc50@DUTS.ccc.amdahl.com (Winthrop D Chan) writes:
  847. >I'd like to know if anyone has a reference document on the format of the
  848. >Amiga Sound/NoiseTracker (MOD) files. The author of Modplay said he was going
  849. >to release such a document sometime last year, but he never did. If anyone
  850.  
  851. I found this one, which covers it better than I can explain it - if you
  852. use this in conjunction with the documentation that comes with Norman
  853. Lin's Modedit program it should pretty much cover it.
  854.  
  855. Mark J Cox
  856.  
  857. /***********************************************************************
  858.  
  859. Protracker 1.1B Song/Module Format:
  860. -----------------------------------
  861.  
  862. Offset  Bytes  Description
  863. ------  -----  -----------
  864.    0     20    Songname. Remember to put trailing null bytes at the end...
  865.  
  866. Information for sample 1-31:
  867.  
  868. Offset  Bytes  Description
  869. ------  -----  -----------
  870.   20     22    Samplename for sample 1. Pad with null bytes.
  871.   42      2    Samplelength for sample 1. Stored as number of words.
  872.                Multiply by two to get real sample length in bytes.
  873.   44      1    Lower four bits are the finetune value, stored as a signed
  874.                four bit number. The upper four bits are not used, and
  875.                should be set to zero.
  876.                Value:  Finetune:
  877.                  0        0
  878.                  1       +1
  879.                  2       +2
  880.                  3       +3
  881.                  4       +4
  882.                  5       +5
  883.                  6       +6
  884.                  7       +7
  885.                  8       -8
  886.                  9       -7
  887.                  A       -6
  888.                  B       -5
  889.                  C       -4
  890.                  D       -3
  891.                  E       -2
  892.                  F       -1
  893.  
  894.   45      1    Volume for sample 1. Range is $00-$40, or 0-64 decimal.
  895.   46      2    Repeat point for sample 1. Stored as number of words offset
  896.                from start of sample. Multiply by two to get offset in bytes.
  897.   48      2    Repeat Length for sample 1. Stored as number of words in
  898.                loop. Multiply by two to get replen in bytes.
  899.  
  900. Information for the next 30 samples starts here. It's just like the info for
  901. sample 1.
  902.  
  903. Offset  Bytes  Description
  904. ------  -----  -----------
  905.   50     30    Sample 2...
  906.   80     30    Sample 3...
  907.    .
  908.    .
  909.    .
  910.  890     30    Sample 30...
  911.  920     30    Sample 31...
  912.  
  913. Offset  Bytes  Description
  914. ------  -----  -----------
  915.  950      1    Songlength. Range is 1-128.
  916.  951      1    Well... this little byte here is set to 127, so that old
  917.                trackers will search through all patterns when loading.
  918.                Noisetracker uses this byte for restart, but we don't.
  919.  952    128    Song positions 0-127. Each hold a number from 0-63 that
  920.                tells the tracker what pattern to play at that position.
  921. 1080      4    The four letters "M.K." - This is something Mahoney & Kaktus
  922.                inserted when they increased the number of samples from
  923.                15 to 31. If it's not there, the module/song uses 15 samples
  924.                or the text has been removed to make the module harder to
  925.                rip. Startrekker puts "FLT4" or "FLT8" there instead.
  926.  
  927. Offset  Bytes  Description
  928. ------  -----  -----------
  929. 1084    1024   Data for pattern 00.
  930.    .
  931.    .
  932.    .
  933. xxxx  Number of patterns stored is equal to the highest patternnumber
  934.       in the song position table (at offset 952-1079).
  935.  
  936. Each note is stored as 4 bytes, and all four notes at each position in
  937. the pattern are stored after each other.
  938.  
  939. 00 -  chan1  chan2  chan3  chan4
  940. 01 -  chan1  chan2  chan3  chan4
  941. 02 -  chan1  chan2  chan3  chan4
  942. etc.
  943.  
  944. Info for each note:
  945.  
  946.  _____byte 1_____   byte2_    _____byte 3_____   byte4_
  947. /                \ /      \  /                \ /      \
  948. 0000          0000-00000000  0000          0000-00000000
  949.  
  950. Upper four    12 bits for    Lower four    Effect command.
  951. bits of sam-  note period.   bits of sam-
  952. ple number.                  ple number.
  953.  
  954. Periodtable for Tuning 0, Normal
  955.   C-1 to B-1 : 856,808,762,720,678,640,604,570,538,508,480,453
  956.   C-2 to B-2 : 428,404,381,360,339,320,302,285,269,254,240,226
  957.   C-3 to B-3 : 214,202,190,180,170,160,151,143,135,127,120,113
  958.  
  959. To determine what note to show, scan through the table until you find
  960. the same period as the one stored in byte 1-2. Use the index to look
  961. up in a notenames table.
  962.  
  963. This is the data stored in a normal song. A packed song starts with the
  964. four letters "PACK", but i don't know how the song is packed: You can
  965. get the source code for the cruncher/decruncher from us if you need it,
  966. but I don't understand it; I've just ripped it from another tracker...
  967.  
  968. In a module, all the samples are stored right after the patterndata.
  969. To determine where a sample starts and stops, you use the sampleinfo
  970. structures in the beginning of the file (from offset 20). Take a look
  971. at the mt_init routine in the playroutine, and you'll see just how it
  972. is done.
  973.  
  974. Lars "ZAP" Hamre/Amiga Freelancers
  975.  
  976. ***********************************************************************/
  977.  
  978. -- 
  979. Mark J Cox -----
  980. Bradford, UK ---
  981.  
  982.  
  983. The MOD sampling rate
  984. ---------------------
  985.  
  986. From dgc3@midway.uchicago.edu:
  987.  
  988. The standard rate is 10k exactly.  Instrument files should be 10k,
  989. signed, 8-bit raw audio.  A lot of people ask how to create MOD
  990. samples on their own machine; the answer is:
  991.  
  992. [%>] sox mysound.foo -r10000 -sb sample.sam
  993.  
  994. I quite doubt that there are any deviations here, since the sample
  995. data is incorporated into the MOD file and cannot store its own format
  996. header.  The Amiga program MED uses a custom format for its MODs
  997. (often called MEDs because of name similarity), and does allow any
  998. 8SVX sample of any sampling rate to be used.
  999.  
  1000. David
  1001.  
  1002.  
  1003. FTP sites for MODs and MOD players
  1004. ----------------------------------
  1005.  
  1006. Subject: MODS AND PLAYERS!! **READ** info/where to get them
  1007. From: cjohnson@tartarus.uwa.edu.au (Christopher Johnson)
  1008. Newsgroups: alt.binaries.sounds.d
  1009. Message-ID: <1h32ivINNglu@uniwa.uwa.edu.au>
  1010. Date: 21 Dec 92 00:19:43 GMT
  1011. Organization: The University of Western Australia
  1012.  
  1013. Hello world,
  1014.  
  1015. For all those asking, here is where to get those mod players and mods.
  1016.  
  1017. SNAKE.MCS.KENT.EDU is the best site for general stuff.  look in /pub/SB-Adlib
  1018.  
  1019. Simtel-20 or archie.au(simtel mirror) in <msdos.sound>
  1020.  
  1021. for windows players ftp.cica.indiana.edu in pub/pc/win3/sound
  1022.  
  1023. here is a short list of players
  1024.  
  1025. mp or modplay   BEST OVERALL                    mp219b.zip      
  1026.         simtel and snake
  1027.  
  1028. wowii           best for vga/fast machines      wowii12b.zip    
  1029.         simtel and snake
  1030.  
  1031. trakblaster     best for compatability          trak-something  
  1032.         simtel and snake        two versions, old one for slow
  1033.         machines
  1034.  
  1035. ss              cute display(hifi)              have_sex.arj
  1036.         found on local BBS (western Australia White Ghost)
  1037.  
  1038. superpro player generally good                  ssp.zip or similar
  1039.         found on night owl 7 CD
  1040.  
  1041. player?         cute display(hifi)              player.zip or similar
  1042.         found on night owl 7 CD
  1043.  
  1044. WINDOWS
  1045.  
  1046. Winmod pro      does protracker                 wmp????.zip
  1047.         cica
  1048.  
  1049. winmod          more stable                     winmod12.zip or similar
  1050.         cica
  1051.  
  1052. Hope this helps, e-mail me if you find any more players and I will add them in for the next time mod player requests get a
  1053. little out of hand.
  1054.  
  1055. for mods ftp to wuarchive.wustl.edu and go to the amiga music directory (pub/amiga/music/ntsb ?????)  that should do you for
  1056. a while
  1057.  
  1058. see you soon
  1059.  
  1060. Chris.
  1061.  
  1062. -----------------------------------------------------------------------
  1063.