> So this is some sort of compromise to increase speed? Partially. The main purpose is to increase time domain accuracy on low frequency. If you want to do exp

> So this is some sort of compromise to increase speed? Partially. The main purpose is to increase time domain accuracy on low frequency. If you want to do experiment on window length (in time domain), use ffmpeg showcqt filter (https://ffmpeg.org/ffmpeg-filters.html#showcqt https://ffmpeg.org/ffmpeg-filters.html#showcqt). showcqt-js window length is hardcoded to tc=0.33 attack=0.033 and tlength='st(0,0.17); 384tc / (384 / ld(0) + tcf /(1-ld(0))) + 384tc / (tcf / ld(0) + 384 /(1-ld(0)))' (https://github.com/mfcc64/mpv-scripts/blob/a0cd87eeb974a4602c5d8086b4051b5ab72f42e1/visualizer.lua#L187 https://github.com/mfcc64/mpv-scripts/blob/a0cd87eeb974a4602...). > Have you thought about implementing in WASM? It is implemented in WASM. > Agreed, but for a visualisation, it could just be a parameter just for the user to mess with. If you want to do experiment on it, showcqt.js exposes intermediate color data cqt.color[]. It can be modified arbitrarily, including autocorrelation. If some day I do experiment on it and find that the result is satisfying, maybe I'll include it in YouTube Musical Spectrum.