Yes, you need to detach the FFT audio analysis from real-world playback and treat this entirely as a non-realtime computation. If Processing’s audio library only lets you do realtime, then your animation will always be off from the music because you simply can’t analyze the audio, compute an animation, render it, and save out the images at full speed. The only way you would need to do so is if you are trying to play along with live audio such as in a live performance.
If you can use a better FFT library where you can fully analyze the audio independent of playback, then you can even add anticipatory animations such as a ball dropping that hits the ground on a drum beat or bass drop.
You don’t need to use x += 1 per frame. The built-in variable frameCount already does that for you. My point is just that if the animation you are producing will play back at 30 fps, then you want to analyze your audio in 1/30 second chunks and produce an animation that advances in 1/30 second chunks. Ignore Processing’s frameRate() or millis() and just use frameCount to index how far you are into the audio/animation.