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

[lkoenig]

This adds support for floating point wav files and fix #60729.

• Issue: wave file module does not support 32bit float format #60729

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[ghost]

All commit authors signed the Contributor License Agreement.

[lkoenig]

I want to update the documentation also but want to get a sense if I am out of my mind first.

[mbeijen]

Hi @lkoenig ! I know it's been a long time since you submitted this PR. Right now it no longer applies because sunaudio and aifc have been removed from python stdlib.!

I've recently published newwave, a drop-in replacement for stdlib wave. I've added your patch to it, thanks!! But I also changed it a little bit; I renamed 'encoding' to 'format' which I think makes more sense in the case of wave files. What do you think?

Also, in IEEE wave files, a 'fact' chunk is required as per the spec. Audacity would load any wave files without a fact chunk but it will generate fact chunks in IEEE wave audio files when writing. So, this should be added to your PR. In my module I've added this for any non-PCM wave files, see https://codeberg.org/michielb/newwave/commit/b0429ba553ba039966c79a5e21ee027cbd3f5194

To cpython maintainers: I think in general this addition seems to make sense, and if @lkoenig might or might not be available I'd be willing to also help a little getting this into shape!

[encukou]

This looks like a reasonably simple to try. Personally, not knowing much about the wave format, I can't yet promise I'll merge it, but if you're willing to explain things we can get there.

As it's been a few years, it's probably best if you do the merge in your own branch and open a new PR. Ideally, preserve the original commit.

Also, in IEEE wave files, a 'fact' chunk is required as per the spec.

Could you link to the place where this is specified?

[mbeijen]

Sure, I'll create a PR with my proposal, including @lkoenig original commit. I did that also in my newwave module :-)

My main problem is actually that in my opinion support for writing WAVE_FORMAT EXTENSIBLE is more desirable than the IEEE format. Somehow Python 3.12 got support for reading the extensible format in #96777 but never got support for writing. I've also implemented that, in the newwave module, and would like to upstream it into cpython wave.py. And I'll open a bug for that as well. But because both formats need slight changes to the same code, it might make more sense to first add support for writing WAVE_FORMAT_EXTENSIBLE and only then adding support for the IEEE format?

[encukou]

I'd suggest doing the simpler change first :)

[lkoenig]

Hi @mbeijen!
Nice to see this small piece getting used :) I even forgot I wrote this PR.

Feel free to reuse it. I skimmed the change I made some times ago and it still feel ok to me. I'll try to update the PR to the up to date code.