When you write sound files wav sunau of aifc and you are using 16 bits
samples. The number of frames in the files is incorrect. close function
which updates the headers makes a mistake I assume. For the sunau type I
had to double the number of frames in the close function to make it correct.

If you do not correctg number of frames a 10 second file will play 5 seconds

What software do you use to play the sample?  Is it perhaps ignoring the
nchannels value from the header?

I played using winsound.PlaySound function for the wav. I used VLC and windows media player for wav,au and aiff after that

All had the same problem. It was solved for sunau by doubling the nframes number written by the close function in the sunau module. I assume something similar should be done for the wav and aiff modules.

This is what I changed in sunau I am not sure if adding *self._sampwidth breaks something else. It works for me now when I create 16bit stereo files.

def _patchheader(self):
        self._file.seek(8)
        # jjk added * sampwidth otherwise for 16 bit you get wrong nframes
        _write_u32(self._file, self._datawritten*self._sampwidth)
        self._datalength = self._datawritten
        self._file.seek(0, 2)

Hope this helps.
greetings

Crys, since you apparently have working sound on Windows, could you have
a look at this?  There's also an (unrelated) issue with sunau.py on
Py3k, it doesn't work (but the unittests aren't strong enough to
discover that :-).

Is this still valid?

as far as I know. But i have not use or tested it since a long time

On Sat, Sep 18, 2010 at 4:34 PM, Mark Lawrence <report@bugs.python.org>wrote:

>
> Mark Lawrence <breamoreboy@yahoo.co.uk> added the comment:
>
> Is this still valid?
>
> ----------
> nosy: +BreamoreBoy -gvanrossum
> versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1423>
> _______________________________________
>

Is somebody interested in this bug?

This is a duplicate of issue8311. Was fixed in 3.4. In 2.7 you should first convert your data to str, bytearray, array('B') or buffer.