search

bharris6 / pytermvis

Python Terminal Audio Visualizer
MIT License
4 stars 0 forks source link

FFT Analysis #8

Open bharris6 opened 4 years ago

bharris6 commented 4 years ago

I'm not happy with how the visualizer looks. It'd be nice to have:

bharris6 commented 4 years ago

@dpayne do you have any advice?

One thing I haven't been able to figure out is how to know how to "scale" the output bars.

For example, if all frequencies in a certain sample have low amplitudes then I don't know how to set that upper-bound so right now I'm just scaling them against the relative max (of the current FFT frame, if that makes sense). Something that should look like 

|  
|  
| * * * * *

Ends up looking like 

| * * * * *  
| * * * * *  
| * * * * *

Is this something that has to be determined based on audio samples prior to FFT'ing?

https://0x0.st/iDDn.mp4

The top pane is pytermvis. The bottom pane is cli-visualizer.

bharris6 commented 1 week ago
  • Figure out why the frequencies are not as clearly distinguishable as other visualizers.

I addressed this by simplifying things a ton -- the samplers are now just generators that yield an instantaneous sample instead of managing deques of FFTs of samples or anything that requires historical knowledge. This lets me get rid of all the threading and queuing.

As part of this change, the renderers now do the FFT computation steps (depending on what mode the renderer is running in). I included three modes dealing with FFTs: "whole" FFT, binned FFT, and gamma-corrected-binned FFT.

The latter mode is the one that the improvement really came from. I found the post A better FFT-based audio visualization that describes setting bin edges based on "gamma-corrected" frequency ranges, and implemented a version of that within pytermvis.common.commonpy. The gfft mode looks much better and anecdotally matches the visualizer results in Winamp, which is pleasing as that is the benchmark I was comparing against.

  • Some smoothing across the bars
  • Some fallback averaging over time (so the bars aren't as jumpy)

These might be easier to implement now. The renderers could store the "n previous displayed" and average them against the most-recent sample/FFT prior to displaying anything.