Support audio with frame rates over 48k

[jiaaro]

Related to: #129

Python (and by extension, pydub) cannot handle audio with frame rates over 48k. That's a bummer.

We could use ffmpeg to convert the framerate down to 48k in those cases, but users with 96k files on disk are probably not going to be happy with that solution.

I wonder if there is a way to solve this without reimplementing the functionality in audioop. Maybe if we just lie about the framerate to audioop it will work fine?

[fnielsen]

I am surprised that this limitation is in the standard wave module.

>>> import wave
>>> wave.open("tmp96k.wav")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/wave.py", line 509, in open
    return Wave_read(f)
  File "/usr/lib/python2.7/wave.py", line 164, in __init__
    self.initfp(f)
  File "/usr/lib/python2.7/wave.py", line 144, in initfp
    self._read_fmt_chunk(chunk)
  File "/usr/lib/python2.7/wave.py", line 273, in _read_fmt_chunk
    raise Error, 'unknown format: %r' % (wFormatTag,)
wave.Error: unknown format: 65534
>>> wave.open("tmp48k.wav")
<wave.Wave_read instance at 0x7fcc0ad647a0>

The reader of scipy has not the problem:

>>> import scipy.io.wavfile
>>> scipy.io.wavfile.read('tmp96k.wav')
(96000, array([[  55, -323],
       [  56, -328],
       [  61, -321],
       ..., 
       [ 198,  174],
       [ 203,  168],
       [ 202,  176]], dtype=int16))

But I suppose you do not want to have dependencies on scipy?

[fnielsen]

Has the problem anything to do with the frame rate? Isn't it due to WAVE_FORMAT_EXTENSIBLE (65534) for the format tag. That is what is being checked in line 269 of wave.py.

$ showriff tmp96k.wav | grep format
format       = 65534
$ showriff tmp48k.wav | grep format
format       = 1

It is unclear to me if monkey patching _read_fmt_chunk is sufficient to get around the issue.

[jiaaro]

@fnielsen Yeah, right now pydub can work on raw audio data (i.e., wave files) without needing to install any dependencies. That's a pretty nice deal and it's the main reason not to require scipy.

I'm not familiar with WAVE_FORMAT_EXTENSIBLE, have you tried the monkey patch?

[maelp]

I have the same bug, it seems some libraries exist which reimplement the whole .wav parsing, it might be possible to do something similar, or to give an option when loading pydub to monkey-patch the wav reading and writing with those libs or with scipy if the user has it installed already

https://github.com/tuffy/python-audio-tools/blob/master/audiotools/wav.py
https://github.com/melizalab/py-ewave/blob/master/ewave.py