New submission from Sebastian Kraft:
The wave module cannot read audio WAV files containing 32bit float values. This
is a very common file type for professional audio!
There has already been a patch some years ago which works fine but was finally
not applied. I can confirm that it does not
Sebastian Kraft added the comment:
Write support is no problem, I will add this.
>From reading the spec in the link you provided I think the implementation in
>general is OK.
Everything apart WAVE_FORMAT_PCM should have an extension size cbSize, that's
right. But only WAVE_FORMAT
Sebastian Kraft added the comment:
I will create a patch together with a testset of example files and also fill
out the agreement.
BTW: readframes() returns bad data for 24bit PCM if big_endian==True.
Furthermore IMO it doesn't make sense to return a byte stream in little endian
order
Sebastian Kraft added the comment:
Attached to this mail you find my patch for the implementation of support for
8, 16, 24, 32 bit signed int PCM and 32, 64 bit float.
24bit on big endian systems is buggy, but this will be reported in another
ticket.
The modified test checks all number
Sebastian Kraft added the comment:
Contribution agreement is now attached to my account. So the review can start ;)
--
___
Python tracker
<http://bugs.python.org/issue16
Sebastian Kraft added the comment:
Any news or feedback regarding my patch?
--
___
Python tracker
<http://bugs.python.org/issue16525>
___
___
Python-bugs-list m
Sebastian Kraft added the comment:
After the last changes in the development version of python 3.4 the patch
cannot be applied anymore. As the the other audio file readers and the wave
module share a common API it may be not desireable to simply enhance the wave
module with support for
Changes by Sebastian Kraft :
Removed file: http://bugs.python.org/file28122/wave_float_issue16525.patch
___
Python tracker
<http://bugs.python.org/issue16525>
___
___
Sebastian Kraft added the comment:
Thanks for the hint Harvey!
I have updated my patch to include your changes, but only applied the second
hunk for the following reasons:
Wave_read should not assume any wave format, as it is expected to open a file
during initialization. So actually the only
