| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
This adds support for floating point wav files and fix python#60729.
'format' is the term used in the wave audio specification
Per the RIFF/WAVE Rev. 3 documentation, non-PCM formats require a fact chunk, while PCM does not. This is also what libsdnfile/audacity do Reference: https://mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html (see the 'fact Chunk' section and linked Rev. 3 RIFF docs).
These methods are public but were previously not documented. This caused the unit tests to fail when I mentioned changes to getparams() in the whats new ;-)
…CHTe.rst Co-authored-by: AN Long <aisk@users.noreply.github.com>
There was a problem hiding this comment.
Thanks for pushing that forward.
Sorry, something went wrong.
There was a problem hiding this comment.
Thank you for the PR!
I didn't finish reviewing today; sending the comments I have.
Sorry, something went wrong.
| This is one of ``WAVE_FORMAT_PCM``, ``WAVE_FORMAT_IEEE_FLOAT``, or | ||
| ``WAVE_FORMAT_EXTENSIBLE``. |
There was a problem hiding this comment.
Could you document these using .. data::, and link to them using :data:?
Sorry, something went wrong.
There was a problem hiding this comment.
done
Sorry, something went wrong.
| framerate, nframes, comptype, compname, format)``, equivalent to output | ||
| of the ``get*()`` methods. |
There was a problem hiding this comment.
This is a backwards-incompatible change: before someone could write:
nc, sw, fr, nf, ct, cn = wav.getparams()This could be solved by adding format as a named-only attribute (which, unfortunately, isn't easy with namedtuple), or maybe an argument to getparams.
You might want to leave getparams alone for now & tackle this in a focused follow-up PR.
Sorry, something went wrong.
There was a problem hiding this comment.
Sure, I reverted those changes now
Sorry, something went wrong.
| class MiscTestCase(unittest.TestCase): | ||
| def test__all__(self): | ||
| not_exported = {'WAVE_FORMAT_PCM', 'WAVE_FORMAT_EXTENSIBLE', 'KSDATAFORMAT_SUBTYPE_PCM'} | ||
| not_exported = {'WAVE_FORMAT_PCM', 'WAVE_FORMAT_IEEE_FLOAT', 'WAVE_FORMAT_EXTENSIBLE', 'KSDATAFORMAT_SUBTYPE_PCM'} |
There was a problem hiding this comment.
Please export the WAVE_FORMAT_ ones (add to __all__) instead, and remove them here.
No point in hiding them; they're needed for documented functionality.
Sorry, something went wrong.
There was a problem hiding this comment.
(I'd keep KSDATAFORMAT_SUBTYPE_PCM hidden until it's documented; that seems out of scope for this PR.)
Sorry, something went wrong.
There was a problem hiding this comment.
Sure, they're exported now
Sorry, something went wrong.
| try: | ||
| self._fact_sample_count_pos = self._file.tell() | ||
| except (AttributeError, OSError): | ||
| self._fact_sample_count_pos = None |
There was a problem hiding this comment.
Hmm, what's the story about supporting files without tell?
Sorry, something went wrong.
There was a problem hiding this comment.
I’m not trying to extend unseekable support in this PR. I’m keeping the existing behavior: if output is seekable, header fields (including fact) are patched as needed; for unseekable outputs, writing works when header values are already final, and mismatches can still fail as before.
Sorry, something went wrong.
Co-authored-by: Petr Viktorin <encukou@gmail.com>
…ieee-wave-audio-support # Conflicts: # Doc/library/wave.rst
|
|
||
| .. data:: WAVE_FORMAT_IEEE_FLOAT | ||
|
|
||
| Format code for IEEE floating-point audio. |
There was a problem hiding this comment.
What is the size of a sample? 32-bit? Or does it accept different sizes?
Sorry, something went wrong.
There was a problem hiding this comment.
for IEEE Float it can only be 32-bit or 64-bit. I've amended the documentation and added raising errors in case of setting sampwidth to different values for IEEE or setting format to IEEE if sampwidth is incorrect values
Sorry, something went wrong.
This is also similar to what libsndfile does
There was a problem hiding this comment.
Looks good to me, thank you!
Will merge tomorrow if there are no objections.
Sorry, something went wrong.
|
awesome and thanks in advance! While you're at it I'd like to ask you to also consider these (smaller) PRs I made for wave.py that did not get much attention yet:
There's also this but it might warrant some rework after this IEEE PR is merged, I might want to make a new one for that |
Sorry, something went wrong.
|
I put them on my list :) |
Sorry, something went wrong.
|
Unfortunately, the tests break on big-endian machines. |
Sorry, something went wrong.
|
That is a shame. So how should I proceed? Since this is merged already, new PR with this code plus fixes? Also why these did not fail before? I will try to locate my sun 3/60 and run unit tests. Oh no I will get my amiga. Or maybe my Mac PPC? Oh I do not own any of these machines anymore. I will just set up QEMU then |
Sorry, something went wrong.
|
Yeah, new PR with this plus fixes. It's all squashed anyway.
They're not on GitHub Actions; they're slow so they don't run on every commit. Here's the failure, for the record: https://buildbot.python.org/#/builders/1636/builds/2307/steps/6/logs/stdio |
Sorry, something went wrong.
Co-authored-by: Lionel Koenig <lionelk@google.com>
…145384)" (pythonGH-145928) Revert "pythonGH-60729: Add IEEE format wave audio support (pythonGH-145384)" This reverts commit 61f2a1a for now; as tests fail on big-endian machines.
| Back | FazBrowse Home | New Git URL |
This is an updated version of #102574, the original PR where @lkoenig added support for IEEE Wave Audio.
As requested by @encukou
I've
Closes: #102574
📚 Documentation preview 📚: https://cpython-previews--145384.org.readthedocs.build/