🚀 go-pugleaf

This is in response to Sue Raisty's posting about .WAV files.
  
  The book says (on Pg. 8-40)
  <WAVE-form>  ->  RIFF(  'WAVE'			//Form type
  			<fmt-ck>		// Waveform format
  			<data-ck> )		// Waveform data
  
  <fmt-ck>  -> 	fmt(	<wave-format>		// WaveFormat Structure
  			<format-specific>	// Dependent on format category
  
  <wave-format> -> struct {WORD formatTag;		// Format Category
  			 WORD nChannels;		// No. channels
  			 DWORD nSamplesPerSec;   // Sampling Rate
  			 DWORD nAvgBytesPerSec;  // For buffering
  			 WORD  nBlockAlign;}	// Block alignments
  
  <PCM-format-specific> ->  struct {WORD   nBitsPerSample;}  //Sample Size
  
  <data-ck> -> data( <wave-data> )
  ----------------

Guess: Parenthesis in the above grammar means "new block",
which gets its own 4-byte length field.

  ding
  52 49 46 46 			RIFF
  46 2D 0 0 			11590 bytes long
  57 41 56 45 			WAVE
  66 6D 74 20			fmt <space>
  10 0 0 0 			16 bytes long
  1 0 				format type #1
  1 0 				1 channel (mono)
  22 56 0 0 			8790 samples
  22 56 0 0 			8790 bytes/sec on average
  1 0 				1 block align ???
		note that we have now used up our 16 bytes for the 'fmt '
  8 0 				8 bits per sample
  64 61 74 61 			data
  22 2D 0 0 			8749 bytes long
  80 80 80 80 80 80....		dead time.  Since it's 128,
				that means these are unsigned bytes.
				This may be what 'format type #1' means.
  
Look at the rest of the file and count out the bytes.
I'm sure you'll find that they agree with the two section
length fields at the beginning.

This seems to be compatible with Electronic Arts' IFF format.

Lance Norskog
-- 
----------------Lance Norskog---------------
  ((lambda (lambda) `(,lambda ',lambda)) 
   '(lambda (lambda) `(,lambda ',lambda)))
Ah don't know, Jim, Ah thank it's some kahnd of vahrus.