`hann_window` does not obey COLA; therefore, it cannot be used with `istft`

🐛 Bug

In order to enable inversion of an STFT via the inverse STFT in istft, it is sufficient that the signal windowing obeys the constraint of “Constant OverLap Add” (COLA). This ensures that every point in the input data is equally weighted, thereby avoiding aliasing and allowing full reconstruction. https://docs.scipy.org/doc/scipy/reference/generated/scipy.signal.check_COLA.html

Learn more: https://ccrma.stanford.edu/~jos/sasp/Mathematical_Definition_STFT.html#19930

To Reproduce

>>> from scipy import signal
>>> import torch
>>> signal.check_COLA(signal.hann(1024, sym=False), 1024, 1024 - 256)
True
>>> signal.check_COLA(torch.hann_window(1024).numpy(), 1024, 1024 - 256)
False
>>> window = torch.hann_window(1024).numpy()
>>> window[0] *= 0.5
>>> window[-1] *= 0.5
>>> signal.check_COLA(window, 1024, 1024 - 256)
False

Expected behavior

The expected behavior is that the hann window is implemented such that it is useable with istft.

[f0k]

This seems to be a precision issue:

>>> import scipy.signal
>>> import torch
>>> w1 = scipy.signal.hann(1024, sym=False)
>>> w2 = torch.hann(1024)
>>> w3 = torch.hann(1024, dtype=torch.float64)
>>> scipy.signal.check_COLA(w1, 1024, 512)
True
>>> scipy.signal.check_COLA(w2.numpy(), 1024, 512)
False
>>> scipy.signal.check_COLA(w3.numpy(), 1024, 512)
True

So it works when letting Pytorch compute the window in double precision like scipy. It also works when converting back to single precision, for both:

>>> scipy.signal.check_COLA(w1.astype(np.float32), 1024, 512)
True
>>> scipy.signal.check_COLA(w3.numpy().astype(np.float32), 1024, 512)
True

I suppose the right modification would be to copy scipy and to test for COLA.

The scipy code is here: https://github.com/scipy/scipy/blob/6d576be/scipy/signal/windows/windows.py#L109-L118, called with a=(0.5, 0.5). The Pytorch code is here: https://github.com/pytorch/pytorch/blob/bca8280/aten/src/ATen/native/TensorFactories.cpp#L894-L899, called with alpha=0.5, beta=0.5. Not sure if there’s any way to get more accurate results in single precision? Otherwise what we could do in torchaudio would be to create the window in double precision and convert it to the target dtype afterwards.

@faroit The window is off by a minimum of 5e-3. That is a large difference, in my opinion. We’re not talking about 1^-10. (See the second comment)

@PetrochukM: It’s 5-e9 in your second comment. But that’s for the last coefficient; the maximum difference is around 1.2e-7. In any case, there’s a way to pass scipy’s COLA test with a float32 window, but not with the one produced by torch.hann_window(1024), so we could improve things a little.

[PetrochukM]

@f0k Thanks for looking into this! Also, I was totally wrong with the maximum difference, thanks for correcting me!

It sounds like there is a little bit of room for improvement. It also sounds like there is still room in replicating librosa and scripy’s behavior.