using 2.5 on osx 10.4
the sndhdr.what() function fails to recognize some wav headers.
however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes.

We'd need some more information about these specific wave files in order to improve sndhdr.what().

Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like?

Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz
You can play it, ask either OSX or XP to show the properties.
Yet sndhdr.what() returns None


File Added: Audio01.rar

Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start.

I see. The problem is, as the "bext" chunk can be arbitrarily long, the test function would need more than 512 bytes to read the "fmt " chunk, or it could return that it cannot read the format details.

Would you like to work on a patch?

this could be a start. 
however the initial 512 bytes might be too short.
i don't see (yet) how to increase that in a snazzy way. 
i just changed it into a read(1024)

def test_wav_test( h ):
    if h[:4] != 'RIFF' or h[8:12] != 'WAVE':
        return None
    if h[12:16] == 'fmt ':
        style = get_short_le(h[20:22])
        nchannels = get_short_le(h[22:24])
        rate = get_long_le(h[24:28])
        sample_bits = get_short_le(h[34:36])
        return 'wav', rate, nchannels, -1, sample_bits
    elif h[12:16] == 'bext':
        offset = 12
        while True:
            try:
                if h[offset:offset+4] == 'fmt ':
                    nchannels =  get_short_le( h[offset+10:offset+12] )
                    rate = get_long_le( h[offset+12:offset+16] )
                    sample_bits =  get_short_le( h[offset+22:offset+24] )
                    return 'wav', rate, nchannels, -1, sample_bits
                offset += ( get_long_le( h[offset+4:offset+8] ) + 8 )
            except IndexError:
                print 'header buffer too short'
                return None

I've written a new patch, which works a bit better. You can find the new
patch attached.

I've restructed the patch to prevent code duplication. Also, it now
works with other chunks than bext (I had a file with a list chunk which
triggered my interest in this bug). This is done with a hardcoded list
of valid chunks. However, it seems that there is no complete list of
valid chunk types, so it might be better to remove the chunk type check
alltogether.

Also, this patch explicitly checks for overflow, since taking a slice of
a sequence does not seem to trigger an IndexError, but just return an
empty sequence.