# (Possible Bug) JUCE FFT produces small Nyquist signal during Inverse Transform **URL:** \ **Category:** General JUCE discussion\ **Created:** [June 29, 2022, 6:45pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007 "2022-06-29T18:45:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![officialnsa](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@officialnsa](https://forum.juce.com/u/officialnsa)\ **Post date:** [June 29, 2022, 6:45pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007/1 "2022-06-29T18:45:48Z")
Hi all! I’ve been working with juce::dsp::FFT recently and I’ve encountered what may possibly be a bug. At first I attributed it to a floating-point rounding error, but I’m beginning to believe there may be something more fundamental going on here. ### Behavior: When passed a fully-zeroed buffer of FFT data, the JUCE FFT returns time-domain data with a small, but non-negligible _(?)_ Nyquist frequency signal present. ### Example: All values were read during an LLDB debugging session. These readings are from the same buffer, before and after a single call to `performRealOnlyInverseTransform()`. Buffer size is 2048. ```auto // buffer: pre-transform (float) [0] = 0 (float) [1] = 0 (float) [2] = 0 (float) [3] = 0 ... ``` ```auto // buffer: post-transform (float) [0] = 0.000221714377 (float) [1] = -0.000221714377 (float) [2] = 0.000221714377 (float) [3] = -0.000221714377 ... // this pattern repeats to the end of the buffer ``` The value in this repeating nyquist signal (i.e. its amplitude) seem to be different every time I run this, but the pattern is always the same — one number, alternating positive and negative every sample. Is this enough to chock up to floating point rounding error? I’m not familiar enough with the vDSP implementation of the FFT algorithm to know where such errors could crop up. This could also easily be from a simple oversight on my part, hence this being a _possible_ bug report. Thank you in advance for any help you can provide with this! ---
**Author:** ![PeterRoos](https://avatars.discourse-cdn.com/v4/letter/p/7ab992/32.png) [@PeterRoos](https://forum.juce.com/u/PeterRoos)\ **Post date:** [June 29, 2022, 7:08pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007/2 "2022-06-29T19:08:41Z")
My first reaction is to take these number seriously, they are certainly not small enough to neglect. Maybe this is related to some tweaks in the class related to DC and Nyquist, where and how they are stored in the forward result and the input for the inverse? Wouldn’t surprise me, as there are some confusing tweaks in the code for this. I am not using this class for FFTs. ---
**Author:** ![officialnsa](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@officialnsa](https://forum.juce.com/u/officialnsa)\ **Post date:** [June 29, 2022, 7:23pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007/3 "2022-06-29T19:23:06Z")
Because I’m on Mac, dsp::FFT is defaulting to the vDSP engine—I did notice in the code for that, the Nyquist bin (or specifically just the magnitude) is shuffled to the float index `[1]` as vDSP uses the same tactic as PFFFT, i.e. storing the Nyquist amplitude where the DC phase would be stored if it wasn’t always 0. Looking back at it again, I’m realizing this shuffling of the Nyquist amplitude only occurs in the code for the inverse transform, which either means this is a bug or there’s some quirk of how vDSP accepts/returns data that I’m not understanding. Thank you so much for the advice! ---
**Author:** ![PeterRoos](https://avatars.discourse-cdn.com/v4/letter/p/7ab992/32.png) [@PeterRoos](https://forum.juce.com/u/PeterRoos)\ **Post date:** [June 29, 2022, 7:51pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007/4 "2022-06-29T19:51:32Z")
A step forward, great 🙂 The API for vDSP can be confusing, also with the strides, etc. I believe the API also goes back some 30-40 years, back into Fortran years. ---
**Author:** ![officialnsa](https://avatars.discourse-cdn.com/v4/letter/o/ecb155/32.png) [@officialnsa](https://forum.juce.com/u/officialnsa)\ **Post date:** [July 21, 2022, 8:59pm UTC](https://forum.juce.com/t/possible-bug-juce-fft-produces-small-nyquist-signal-during-inverse-transform/52007/5 "2022-07-21T20:59:26Z")
For any who come to this post with a similar issue, it ended up being user error — we were passing a buffer of size N and not 2\*N, meaning the nyquist bin and above technically outside our allocated heap block. If you’re having a similar issue and also getting a lot of `Incorrect checksum for freed object` crashes, check your buffer sizes!!!