🚀 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.

In a previous article, thinman@netcom.com (Lance Norskog) says:

>
>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)
Sorry, you got these two wrong. This is 0x005622L
which reps 22.05 khz sampling rate.
>  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.
>  


PCH
-- 
Peter C. Haller				|	'If you do what you 
Imagination Processing Systems		|	have always done,
aa596@cleveland.Freenet.Edu 		|	expect what you have
"Are we having fun yet?"		|	always recieved.'

In article <7nsj0za.thinman@netcom.com>, thinman@netcom.com (Lance Norskog) writes:
|   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

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

| 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.

This is correct, RIFF was modelled after the IFF format.  The blocks are
called "chunks".  Any software reading the WAVE format should (to remain
upward compatible with future iterations) skip chunk ID's that it
doesn't recognize, made easy by having the length of the chunk following
the tag.  Don't just assume that chunks will appear only in the specified
sequence.

-Russell Williams