| msg176077 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2012-11-21 20:13 |
| 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 break anything and only adds support for a new number format. http://bugs.python.org/issue1144504 |
|
|
| msg176085 - (view) |
Author: Jesús Cea Avión (jcea) *  |
Date: 2012-11-22 01:03 |
| This is a new feature. Targeting Python 3.4. |
|
|
| msg176086 - (view) |
Author: Jesús Cea Avión (jcea) * |
Date: 2012-11-22 01:12 |
| Can somebody point to a floating point WAVE specification?. I think the issues raised in the original bug still stands. Also, support for writing should be provided too. http://web.archive.org/web/20080924064943/http://ccrma.stanford.edu/CCRMA/Courses/422/projects/WaveFormat/ http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html |
|
|
| msg176284 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2012-11-24 12:50 |
| 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_EXTENSIBLE sets cbSize=22. So for read access it is not mandatory to check the value when WAVE_FORMAT_IEEE_FLOAT, but for writing files I would set this to zero. There are several other wave formats which also use float data, but most important is WAVE_FORMAT_IEEE_FLOAT, and that can be suppoted quite easily without many changes. |
|
|
| msg176291 - (view) |
Author: Jesús Cea Avión (jcea) * |
Date: 2012-11-24 15:26 |
| Sebastian, Could you possibly write a patch with a test?. Could you possibly fill a contributor agreement? Details in http://www.python.org/psf/contrib/ |
|
|
| msg176292 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2012-11-24 15:40 |
| 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 on a big endian system... What do you think? At least the waves doc doesn't mention or specify the endianess which will cause trouble. |
|
|
| msg176293 - (view) |
Author: Jesús Cea Avión (jcea) * |
Date: 2012-11-24 16:01 |
| About the 24 bit PCM bug, please fill another bug. |
|
|
| msg176374 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2012-11-25 17:05 |
| 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 formats apart form 24bit int. If the patch is fine and will be accepted I will also update the doc and send a seperate patch for this. |
|
|
| msg176741 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2012-12-01 11:55 |
| Contribution agreement is now attached to my account. So the review can start ;) |
|
|
| msg180132 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2013-01-17 14:02 |
| Any news or feedback regarding my patch? |
|
|
| msg182150 - (view) |
Author: Harvey Ormston (harveyormston) |
Date: 2013-02-15 17:22 |
| I see that this issue applies to Python 3.4. Nevertheless, I am now using the submitted patch (http://bugs.python.org/file28122/wave_float_issue16525.patch) with Python 2.7. I find that the patched module fails when calling getwavformat(), becuase the _wavformat attribute is not set. I attach wave_read_issue16525.patch, which properly sets the _wavformat attribute and allows getwavformat() to succeed. Apologies if I have not followed the proper process here. I found this patch a while ago while looking for a solution to the limitations in the standard wave module and, upon using the patch, identified this potential issue which I have attampted to fix. I thought it would be best to share that fix. |
|
|
| msg182217 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2013-02-16 11:15 |
| 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 missing thing was the assignment of the wave format during the reading of the format chunk. setparams() in Wave_write already sets the wavformat a few lines later together with the other parameters. So no need to set it twice... Can you please check if the updated patch works for you? |
|
|
| msg182316 - (view) |
Author: Harvey Ormston (harveyormston) |
Date: 2013-02-18 12:10 |
| Thanks Sebastian. That makes sense. I've tried the updated patch and it works just fine for me. |
|
|
| msg212542 - (view) |
Author: Sebastian Kraft (seebk) * |
Date: 2014-03-02 08:57 |
| 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 floating point data. In particular the underlying audiooop module is designed ro only work with integer data. Therefore, and taking into account that this patch and its predecessor has not been reviewed in the last 2 years, I will not take the time to modify the patch again. At least please consider to apply the documentation patch I have uploaded now. This will clearly state in the documentation what sample formats are supported by the wave module. |
|
|