NEEDed: well formed stereo .wav file

I need a "well formed" test file with following characteristics:
  1. *STRICT* conformance to "wav" file format
     { In another field, I've seen 20 mA current loop working with
       RS-232C "compliant" receiver choke CHOKE *CHOKE* ;o
  2. Exactly two channels
  3. Would prefer very different 'sounds' on each channel
  4. short - 30 seconds or so would be fine

I've written a little routine to analyze the spectrum of a
  1 or 2 channel audio recording.

Everything works fine in mono case.

The 2-channel case crashes spectacularly with a SPECIFIC test case.

Note Bene: I said "2-channel" *NOT* "stereo".
I *KNOW* that the "2-channel" case has taken liberties with SOP ;/

I wish to establish that my code is not at fault.

This is chance to:
    "TELL ME WHERE TO GO"
                                                  please

Richard Owlett wrote:

> I need a "well formed" test file with following characteristics:
..

There is a very wide range of possible well-formed WAVE files. I don't 
know of any commercial-grade applications that fail to write them these 
days. Some old unix software assumes a fixed minimal header, and will be 
broken by legal WAVE files with extended headers (e.g. with extra 
optional chunks).

Are you doing your own WAVE file parsing (many a slip etc...), or are 
you using a library such as libsndfile?


> Note Bene: I said "2-channel" *NOT* "stereo".

All that plain WAVE describes is a 1 or 2 channel stream. We refer to 
the latter by convention as stereo, as that is the most common use.

> I *KNOW* that the "2-channel" case has taken liberties with SOP ;/
> 

Don't know what you mean here.


Anyway, one possible route:

Step 1:
     Download Audacity, and use that to generate one or more test files.
   (Or: use any similar application that offers the means to generate 
files - something like Csound will give you much more scope)

Optional Step 2:
  Audacity does add a few extra chunks to the WAVE header, above and 
beyond the absolute minimum, which may be the source of your problem, so 
you may need the CDP Multi-Channel Toolkit  by yours truly, here:

	http://people.bath.ac.uk/masrwd/mctools.html

There is a build for Windows, and one for OS X.

Use the program "copysfx" with the following flag to read whatever 
2-channel file you generated in Step 1, and copy it to a new file with a 
minimum-size WAVE header:

copysfx -h0 step1.wav  step1min.wav

There are other conversion options therein if you need them.

Richard Dobson

Richard Dobson wrote:

> Richard Owlett wrote:
> 
>> I need a "well formed" test file with following characteristics:
> 
> ..
> 
> There is a very wide range of possible well-formed WAVE files. I don't 
> know of any commercial-grade applications that fail to write them these 
> days. Some old unix software assumes a fixed minimal header, and will be 
> broken by legal WAVE files with extended headers (e.g. with extra 
> optional chunks).
> 

I need the *MOST* restrictive case ;<

Mr. Dobson went on to detail a *MINIMALLY* restrictive case,.

Richard Owlett wrote:
..
> 
> I need the *MOST* restrictive case ;<
> 
> Mr. Dobson went on to detail a *MINIMALLY* restrictive case,.
> 


No, I referred to the smallest possible legal WAVE header, where the 
audio samples start at byte 44. Nothing to do with "restriction", which 
is your term, which you have yet to define. This is a file format, not a 
  BDSM technique.  WAVE is a chunked format, and there is a smallest 
legal header, and many possible larger possible headers. The choice is 
up to what users need, and applications decide.  The original WAVE 
format supports rates up to 48000, nchans up to 2, and integer sample 
sizes  up to 16. 32bit float needs the 18-byte format chunk, so audio 
samples start at byte 46.  Higher sample rates, larger channel counts, 
and larger sample sizes need the  WAVEFORMATEXTENSIBLE format based on 
WAVE, and a still large format chunk.

Let me guess - you are doing your own WAVE parsing?


Richard Dobson

On Dec 16, 4:05 pm, Richard Dobson <richarddob...@blueyonder.co.uk>
wrote:

> ...
> Let me guess - you are doing your own WAVE parsing?
>
> Richard Dobson

If he is doing his own .wav parsing, he needs better information on
RIFF files than the bits and pieces and net myths given in this
thread.

Dale B. Dalrymple

On Dec 16, 1:34 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
> I need a "well formed" test file with following characteristics:
>   1. *STRICT* conformance to "wav" file format
>      { In another field, I've seen 20 mA current loop working with
>        RS-232C "compliant" receiver choke CHOKE *CHOKE* ;o
>   2. Exactly two channels
>   3. Would prefer very different 'sounds' on each channel
>   4. short - 30 seconds or so would be fine
>  ...

Richard,

The basic problem here is that any version of "well formed ... .wav
file" is an oxymoron.

I would suggest you take a look at Octave/Matlab  and use the
wavread.m wavwrite.m and perhaps wavinfo.m routines. Not that they are
magic, but they are simple implementations and documented, which is
about as good as it gets. Also, you can see examples of the sources to
see exactly what they do.

Dale B. Dalrymple.

dbd wrote:
> On Dec 16, 4:05 pm, Richard Dobson <richarddob...@blueyonder.co.uk>
> wrote:
> 
> 
>>...
>>Let me guess - you are doing your own WAVE parsing?
>>
>>Richard Dobson
> 
> 
> If he is doing his own .wav parsing, he needs better information on
> RIFF files than the bits and pieces and net myths given in this
> thread.
> 
> Dale B. Dalrymple

Even worse ;/
I'm trying to use canned routines which I don't understand.

dbd wrote:

> On Dec 16, 1:34 pm, Richard Owlett <rowl...@atlascomm.net> wrote:
> 
>>I need a "well formed" test file with following characteristics:
>>  1. *STRICT* conformance to "wav" file format
>>     { In another field, I've seen 20 mA current loop working with
>>       RS-232C "compliant" receiver choke CHOKE *CHOKE* ;o
>>  2. Exactly two channels
>>  3. Would prefer very different 'sounds' on each channel
>>  4. short - 30 seconds or so would be fine
>> ...
> 
> 
> Richard,
> 
> The basic problem here is that any version of "well formed ... .wav
> file" is an oxymoron.

Normally that would rate a *ROFL*
but the "L" should be "C" for "crying" :/

> 
> I would suggest you take a look at Octave/Matlab  and use the
> wavread.m wavwrite.m and perhaps wavinfo.m routines. Not that they are
> magic, but they are simple implementations and documented, which is
> about as good as it gets. Also, you can see examples of the sources to
> see exactly what they do.

*LOL*
I'm using canned routines.

I need "good" input to determine whether "routines defective" or "I'm 
misapplying". The later likely :<

I'm using a tool I don't understand yet ;/

Given known good data, I'll know how/where I messed up :)

Get the idea that I do not take my skills too seriously.

> 
> Dale B. Dalrymple.
> 
> 
> 

Richard Owlett wrote:
..
> 
> Even worse ;/
> I'm trying to use canned routines which I don't understand.
> 

OK; what language are you using? If you using C (or C++), by far the 
best solution is to use libsndfile. My first action on discovering any 
other published WAVE parsing code is to take a look to see if they know 
what they are doing.  Unfortunately I have come across too many cases 
where they don't, or are simply out of date.


But if your canned routines are successfully parsing a mono file, it 
would truly weird if they did not parse a stereo file equally 
successfully, as the chunk stuff itself is essentially identical - the 
difference will be in the values of a couple of fields in the format 
chunk, which describe the size of the sample ~frame~. It is always 
possible to read the interleaved audio data incorrectly of course, 
something well worth checking.

Richard Dobson

Richard Dobson wrote:
> Richard Owlett wrote:
> ..
> 
>>
>> Even worse ;/
>> I'm trying to use canned routines which I don't understand.
>>
> 
> OK; what language are you using? 

SNACK module for TCL


> If you using C (or C++), by far the 
> best solution is to use libsndfile. My first action on discovering any 
> other published WAVE parsing code is to take a look to see if they know 
> what they are doing.  Unfortunately I have come across too many cases 
> where they don't, or are simply out of date.
> 
> 
> But if your canned routines are successfully parsing a mono file, it 
> would truly weird if they did not parse a stereo file equally 
> successfully, as the chunk stuff itself is essentially identical - the 
> difference will be in the values of a couple of fields in the format 
> chunk, which describe the size of the sample ~frame~. It is always 
> possible to read the interleaved audio data incorrectly of course, 
> something well worth checking.
> 
> Richard Dobson

Problem turned out to be understanding the documentation.