GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — GH-60729: Add IEEE format wave audio support by mbeijen · Pull Request #145384 · python/cpython Conversation
|
| This is one of ``WAVE_FORMAT_PCM``, ``WAVE_FORMAT_IEEE_FLOAT``, or | ||
| ``WAVE_FORMAT_EXTENSIBLE``. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Could you document these using .. data::, and link to them using :data:?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
done
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| framerate, nframes, comptype, compname, format)``, equivalent to output | ||
| of the ``get*()`` methods. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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 an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sure, I reverted those changes now
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| 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.
The reason will be displayed to describe this comment to others. Learn more.
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 an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
(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 an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sure, they're exported now
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| 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.
The reason will be displayed to describe this comment to others. Learn more.
Hmm, what's the story about supporting files without tell?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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.
There was an error while loading. Please reload this page.
Co-authored-by: Petr Viktorin <[email protected]>
…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.
The reason will be displayed to describe this comment to others. Learn more.
What is the size of a sample? 32-bit? Or does it accept different sizes?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
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.
There was an error while loading. Please reload this page.
This is also similar to what libsndfile does
eeee8cd to
6d62e66
Compare
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thank you!
Will merge tomorrow if there are no objections.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
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.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
I put them on my list :) |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Unfortunately, the tests break on big-endian machines. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
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.
There was an error while loading. Please reload this page.
|
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.
There was an error while loading. Please reload this page.
Co-authored-by: Lionel Koenig <[email protected]>
…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.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.