Brian McFee

> I believe the issue may be with calling `audioread.available_backends()`: Ah! Excellent sleuthing. Yes, I agree that this is probably the culprit. > Perhaps it would be better to cache...

I hacked out a quick test of the backend cache idea, and it does bring timing down considerably (~3µs from tens of milliseconds). Raised an issue over at beetbox/audioread#125 -...

~~https://github.com/beetbox/audioread/pull/126 is merged and should fix this issue for you, if you're willing to run on a development version of audioread.~~ scratch that, audioread 3.0 is out, so no dev...

Sorry, but I don't see how this constitutes a "numeric stability" issue. Is it not just a difference in phase, and if so, wouldn't this lead magnitudes (and relative phase...

> By "standard formulation" I mean standard mathematical formula, which is indeed this: Yes, that is a common definition, but I would not consider it a "standard" since A) most...

> Adjacent rows have similar values but opposite signs, and nearly cancel in sum, so inclusion or exclusion of a single row can drastically sway the end result. Yes, but...

Ok, I've turned this over a bit in my head, and have a couple more thoughts on this: 1. Sticking an `fftshift` inside the stft function will work, but it's...

> 1. Implementing a `util.frame(.., modulated=True)` so values are seated correctly the first time, then `fftshift(fft_window)`, seems most efficient. I don't think this is true. In typical cases, `frame` does...

> We'd only fftshift `fft_window`, which is a 1D array, not `y_frames`, which is `n_fft` times bigger in size. Your code example does both: > Just added below to work...

> That's just simple code for those willing to try on their local `librosa`s; the goal with `frame(modulated=True)` will be to achieve `ifftshift(frame(modulated=False))` upon very first write, so changing indexing/stride...