I tried to create a 4 second file and only heard the first 2 seconds. The file size was correct for a 44.1 kHz, 16 bit mono file at 4 seconds, but both aplay and audactiy ignored the second half of the file. I went to this page https://ccrma.stanford.edu/courses/422/projects/WaveFormat/ and opened the output with a hex editor in little endian mode. I found that at offset 40, the data chunk size was wrong. It looked like it was just set to the number of samples. It should be the number of samples times bytes-per-sample (2) times number-of-channels (1 in my case). I manually set the number from 176400 to 352800 and that solved the problem for that wav file.

I'm guessing this was just an oversight and the fix will be simple.

I'll attach the code I used to generate the test tone. Just run python -i testTone.py and it will generate out.wav with the incorrect field.

I am using pything 2.6.4 in ubuntu.

Here's my fix. The left file is the original and the right file is my version. Perhaps someone should check this patch on a big endian machine to make sure there are no issues there. I do not anticipate any issues.

416c416
< nframes = len(data) // (self._sampwidth * self._nchannels)
---

    nframes = len(data) // self.\_nchannels

427c427
< self._datawritten = self._datawritten + len(data)
---

        self.\_datawritten = self.\_datawritten + len(data) * self.\_sampwidth

463c463
< self._nframes = initlength / (self._nchannels * self._sampwidth)
---

        self.\_nframes = initlength // self.\_nchannels

Any chance you could create a unit test for this? (The current set of tests is...pretty minimal.) Also, having the patch in unified diff format relative to the top of the source three would be helpful (although this one is small enough we could certainly apply it by hand, having a unified diff makes it more likely someone will test it).

It's because you write an array of integers while writeframes() expects a bytes object.

Here is a test.

Here is a patch for all three audio modules. After dropping support of string (which is meanless) in the audioop module (bpo-16685) it can be simplified.

I doubt that this should be applied in maintenance releases. Support of non-bytes arguments in writerawframes() is a new feature.

Here is simplified patch. Added versionchanged tags in the documentation.

Committed in changeset b96f4ee1b08b.

New changeset 932db179585d by Serhiy Storchaka in branch 'default':
Fixed issue number for issue bpo-8311.
http://hg.python.org/cpython/rev/932db179585d

New changeset b72615222c98 by R David Murray in branch 'default':
whatsnew: sunau/aifc/wave writeframes[raw] accept any bytes-like (bpo-8311)
http://hg.python.org/cpython/rev/b72615222c98