# Backporting support for \`wave\` formats **URL:** \ **Category:** Core Development\ **Created:** [September 20, 2022, 2:24pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305 "2022-09-20T14:24:05Z")\ **Posts on this page:** 19\ **Page:** 1
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 20, 2022, 2:24pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/1 "2022-09-20T14:24:05Z")
See [gh-96777](https://github.com/python/cpython/pull/96777) for what is kind-of an enhancement to the `wave` module, allowing it to open `WAVE_FORMAT_EXTENSIBLE` files that specify their format as PCM, as well as `WAVE_FORMAT_PCM` files. In other words, there are two different header formats for identically formatted data, but we would reject one and accept the other. Python 3.12 will accept both header formats, but I’m unsure whether we ought to backport it? I got involved in the issue because I hit it a few years back, though eventually solved my own problem using `ffmpeg` and shell scripts instead of Python. Currently I’m very 50/50 on whether it makes sense as a bugfix (“wave module rejects standard PCM headers”) or an enhancement (“support wave files using extensible header format”). I’m confident in the fix’s logic and don’t have real concerns there, but don’t feel strongly enough about it to EAFP the backport. Any thoughts? ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [September 20, 2022, 2:52pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/2 "2022-09-20T14:52:11Z")
Maybe it helps to think about how this would be documented? What do you write in the Wnat’s New guide? What phrasing do you use in the docs for the `wave` module? Are you thinking of just 3.11 (it would go in 3.11.1) or also older releases? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 20, 2022, 3:50pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/3 "2022-09-20T15:50:25Z")
Thanking about that didn’t help me decide 🙂 So I’m looking for additional opinions. The NEWS entry for the PR in 3.12 reads “Support reading wave files with the `WAVE_FORMAT_EXTENSIBLE` format in the `wave` module” which is suitably neutral. And the docs say nothing about supported formats, so I could still argue either way. ---
**Author:** ![Jelle](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jelle/32/1049_2.png) [@Jelle](https://discuss.python.org/u/Jelle)\ **Post date:** [September 20, 2022, 4:34pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/4 "2022-09-20T16:34:35Z")
I know nothing about wave formats, but what you say here sounds to me like a new feature, not a bug fix, which means we shouldn’t backport it. ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [September 20, 2022, 4:46pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/5 "2022-09-20T16:46:32Z")
I also know nothing about wave formats, but I agree. I can imagine someone getting weird bugs because their code won’t process `WAVE_FORMAT_EXTENSIBLE` files when run in 3.11.0 and will when run in 3.11.1. To an extent, it probably depends on whether people think of both of these file formats as “the same”. Are they both given the same file extension? ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 20, 2022, 5:19pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/6 "2022-09-20T17:19:16Z")
> [@pf\_moore](#): > > To an extent, it probably depends on whether people think of both of these file formats as “the same”. Are they both given the same file extension? Most people don’t think about different wave file encodings - they’re all `.wav` or `.wave` files, and usually PCM, which basically means uncompressed. So yeah, I’d say people usually consider them to be the same. > [@pf\_moore](#): > > I can imagine someone getting weird bugs because their code won’t process `WAVE_FORMAT_EXTENSIBLE` files when run in 3.11.0 and will when run in 3.11.1. This is the most compelling reason so far to not backport. It seems that [scipy has a better implementation](https://docs.scipy.org/doc/scipy/reference/generated/scipy.io.wavfile.read.html) anyway, so probably people who need it will go there. (A reasonably sized wave file is going to be really slow to process without numpy.) ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [September 20, 2022, 7:27pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/7 "2022-09-20T19:27:14Z")
If you wanted a reason not to backport, why didn’t you say so? 🙂 ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 20, 2022, 7:36pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/8 "2022-09-20T19:36:29Z")
Because I have both kinds of reasons, and still aren’t fully convinced which one I want to use 😉 I’m sympathetic to the “it always ought to have worked” position on this one. But maybe the “why does this file work here (3.11.0) but not there (3.11.1)” issue outweighs that… ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [September 20, 2022, 8:13pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/9 "2022-09-20T20:13:58Z")
But that would argue against fixing any bugs in bugfix releases… 🙂 If you had backported this I wouldn’t have challenged it. And telling people the fix for some problem they have is to upgrade to a new bugfix release is much easier than to tell them to upgrade to a new feature release. ---
**Author:** ![stoneleaf](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/stoneleaf/32/88_2.png) [@stoneleaf](https://discuss.python.org/u/stoneleaf)\ **Post date:** [September 20, 2022, 8:48pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/10 "2022-09-20T20:48:01Z")
> [@steve.dower](#): > > Most people don’t think about different wave file encodings - they’re all `.wav` or `.wave` files, and usually PCM, which basically means uncompressed. So yeah, I’d say people usually consider them to be the same. If the filenames look the same, I would consider it a bug fix and backport to 3.11. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 20, 2022, 9:16pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/11 "2022-09-20T21:16:14Z")
After chatting with Eric, have decided not to backport. Users who hit this prior to 3.12 can use [pedalboard](https://pypi.org/project/pedalboard/), which has much better file support anyway. ---
**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\ **Post date:** [September 21, 2022, 3:45pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/12 "2022-09-21T15:45:41Z")
Interesting that the arguments against the backport are essentially arguments for the deprecation of the whole module, and could easily have been taken as arguments for rejecting the patch in the first place. I’m sure this is not the first time such a thing has happened – wasn’t the `wave` module on the initial list of modules to deprecate and delete? It seems to be in a somewhat precarious state. ---
**Author:** ![tjreedy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tjreedy/32/137_2.png) [@tjreedy](https://discuss.python.org/u/tjreedy)\ **Post date:** [September 21, 2022, 11:46pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/13 "2022-09-21T23:46:52Z")
> [@guido](#): > > Maybe it helps to think about how this would be documented The current wave module doc says that it works with uncompressed .wav files that are readable or writable but not both. There is no mention of requiring a particular internal header format for such files, which I suspect many users would not know about. (What error message is given when the ‘wrong’ one is encountered.) gh-96777 does not change the doc, as it brings the code into conformance with the doc as written. This is normally called a bugfix. I know nothing of when the more flexible header was introduced and its occurrence in the wild, but If its support is considered an enhancement, then perhaps the 3.11/10 docs should document its non-support. To me, 3rd party modules are not especially relevant to out patch classification. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 22, 2022, 5:03pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/14 "2022-09-22T17:03:38Z")
> [@tjreedy](#): > > gh-96777 does not change the doc, as it brings the code into conformance with the doc as written. This is normally called a bugfix. This seems like a pretty good rule of thumb. I’d missed that the docs already said “uncompressed”, so if that equates to `WAVE_FORMAT_PCM`, then it _should_ be backported. However, I think if we’ve missed a range of uncompressed formats, it’s probably better to just update the older docs to clarify that only simple PCM formats are supported. One example that isn’t supported is `WAVE_FORMAT_IEEE_FLOAT` floating-point data, which is also uncompressed.\[1\] So it seems like the right time to draw the line on what additional formats would be backported, and if it’s a narrow line, then we should stop before the most recent one. (I’d certainly not be opposed to someone taking up the module and adding all the formats they can, though only for new releases.) * * * 1. Interestingly, the `audioop` module includes decompression functions for typical compressed wave files, even though `wave` won’t open them. ---
**Author:** ![tjreedy](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/tjreedy/32/137_2.png) [@tjreedy](https://discuss.python.org/u/tjreedy)\ **Post date:** [September 22, 2022, 6:29pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/15 "2022-09-22T18:29:44Z")
A discrepancy between code and doc can be fixed by revising either. I agree here with the simpler solution of revising the doc to only promise what the code does (I would include main). Then add a doc patch to your PR that includes a New in 3.12 note. I agree than any further format additions should be 3.x.0 releases, with doc revision and a ‘New in’ note. ---
**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\ **Post date:** [September 23, 2022, 12:23pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/16 "2022-09-23T12:23:10Z")
Joyfully,\[1\] the extra attention helped me find a bug in the patch. So now 3.12 gets a bugfix and 3.11 and 3.10 get doc clarifications. * * * 1. This is sarcasm 🙂 ---
**Author:** ![mbeijen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mbeijen/32/19394_2.png) [@mbeijen](https://discuss.python.org/u/mbeijen)\ **Post date:** [February 15, 2026, 7:29pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/17 "2026-02-15T19:29:54Z")
I understand I’m bumping a very old thread here; but at work we are using wave.py to generate 6 channel audio from lab equipment and I found out the headers were wrong, when converting them to FLAC. It turns out 3.12 got support for _reading_ `WAVE_FORMAT_EXTENSIBLE` which is great, but it does not _write_ that format, it writes the header for `WAVE_FORMAT_PCM` which according to the spec is limited to 2 channel 16-bit. So `wave.py` will write files with 6 channels or 24 bits or so happily, only the result will have invalid headers. I’ve created [michielb/newwave: Python module to handle WAVE audio files. Drop-in replacement for Pythons wave.py - Codeberg.org](https://codeberg.org/michielb/newwave) (also on pypi as ‘newwave’) which is: - Backport of cpython version of wave, including fixes for handling `bytes` and pathlike objects that are currently targeted for python 3.15 - Support for reading the `WAVE_FORMAT_EXTENSIBLE` that is introduced in 3.12, but you can install `newwave` all the way back to python 3.10 - Support for _writing_ `WAVE_FORMAT_EXTENSIBLE` - Support for reading and writing IEEE-formatted WAVs ([GH-60729](https://github.com/python/cpython/issues/60729)) - Support for handling WAVE metadata plus some more bug fixes, plus more documentation. In general, the wave module is very old and did not see much love. I would like to provide it some TLC but I’m unsure to what extent this is desired! Is there any guidance on this topic? ---
**Author:** ![gpshead](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gpshead/32/54_2.png) [@gpshead](https://discuss.python.org/u/gpshead)\ **Post date:** [February 15, 2026, 8:13pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/18 "2026-02-15T20:13:09Z")
> [@mbeijen](#): > > So `wave.py` will write files with 6 channels or 24 bits or so happily, only the result will have invalid headers. Producing invalid output feels like a normal bug, file a cpython issue and we should fix it regardless - even if the only viable stdlib fix were to raise an error rather than silently generating an invalid file. Such a fix is viable as a backport to bugfix releases (3.13 and 3.14) if it doesn’t require changing APIs. The rest of what you are doing in `newwave` _(ironically actually appropriate name!)_ are features, while we could might to accept some of those in the future, initially developing and iterating upon them in the PyPI project first makes more sense before we consider adding anything. That way they’re already available to existing Python users regardless of version. ---
**Author:** ![mbeijen](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mbeijen/32/19394_2.png) [@mbeijen](https://discuss.python.org/u/mbeijen)\ **Post date:** [February 15, 2026, 9:04pm UTC](https://discuss.python.org/t/backporting-support-for-wave-formats/19305/19 "2026-02-15T21:04:07Z")
Thanks, I also _really_ like the name 😄 yeah I specifically would like newwave to be a place where we can add functionality before it gets upstreamed to cpython. I am going to be filing bugs and pushing fixes for cpython in the coming period. The problem with invalid headers is that it needs a little more changes than just a header. For 6 channel audio you must also specify more parameters for each channel, one channel is automatically mono, two is stereo, but beyond that the spec mandates a channel configuration to understand which channel is what. So the API will need to be adjusted. my company has been writing 6 channel audio files with invalid headers using python for years at this point. If python will stop accepting it - or even if it will start writing CORRECT headers - those will be breaking changes. So I think cpython should be reluctant with these kind of changes…