wave file module does not support 32bit float format

[seebk]

BPO	16525
Nosy	@jcea, @mdickinson, @serhiy-storchaka, @jleedev
Files	wave_read_issue16525.patch wave_issue16525_updated.patch wave_issue16525_doc.patch: Documentation patch clearly defining the supported sample formats

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/serhiy-storchaka'
closed_at = None
created_at = <Date 2012-11-21.20:13:47.301>
labels = ['extension-modules', 'type-feature', 'expert-IO']
title = 'wave file module does not support 32bit float format'
updated_at = <Date 2020-10-15.18:42:18.176>
user = 'https://bugs.python.org/seebk'

bugs.python.org fields:

activity = <Date 2020-10-15.18:42:18.176>
actor = 'jleedev'
assignee = 'serhiy.storchaka'
closed = False
closed_date = None
closer = None
components = ['Extension Modules', 'IO']
creation = <Date 2012-11-21.20:13:47.301>
creator = 'seebk'
dependencies = []
files = ['29079', '29085', '34264']
hgrepos = []
issue_num = 16525
keywords = ['patch']
message_count = 14.0
messages = ['176077', '176085', '176086', '176284', '176291', '176292', '176293', '176374', '176741', '180132', '182150', '182217', '182316', '212542']
nosy_count = 6.0
nosy_names = ['jcea', 'mark.dickinson', 'serhiy.storchaka', 'seebk', 'jleedev', 'harveyormston']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue16525'
versions = ['Python 3.4']

Linked PRs

• gh-60729: Add support for floating point wave files. #102574

[seebk]

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

[jcea]

This is a new feature. Targeting Python 3.4.

[jcea]

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

[seebk]

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.

[jcea]

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/

[seebk]

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.

[jcea]

About the 24 bit PCM bug, please fill another bug.

[seebk]

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.

[seebk]

Contribution agreement is now attached to my account. So the review can start ;)

[seebk]

Any news or feedback regarding my patch?

[harveyormston]

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.

[seebk]

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?