hytheaway

since i started working on it, i've been using ggh&sf really consistently.
for me, it's proved to be exactly what i need in a number of instances. sometimes, things just aren't lining up, and it's great to have such an easy way to take a closer look.

of course, there are two relevant major shortcomings in that tool.

1. mono files can't be used as the filter for operations that employ fourier transforms, including the non-spectrogram graphs.
   • the workflow is pretty single minded, but it doesn't have a lot of guardrails making sure that you use it that way.
   • this is kind of intentional, or maybe it's more correct to say that i intentionally only expect stereo files for those calculations. after all, it's meant for analyzing files that are inherently representative of stereo listening.
2. even if i were to directly incorporate mono audio file analysis, the user interface is not well-designed enough to easily allow for that.
   • while this is definitely on my to-do list, i'm not a user interface designer, nor do i trust user design convention when creating a tool for a particularly technical audience.

a "not bad" way to resolve this and prevent any individual software suite from becoming an utterly bloated mess is to just create a dedicated tool for it. enter shikari ggamir.

ok, dude, but what use is this, really?

well, i can tell you the use-case that i built it for: evaluating perceptual encoders.
obviously, it can be used for a number of things beyond that (room IRs from different microphones, audio file frequency analysis, etc.), but i specifically wanted a tool that made it easy to see how different perceptual encoders did their perceptual encoding.

i encoded a unit impulse using mpeg-1 layer iii (mp3) and advanced audio coding (aac). with this tool, it took no time for me to open each of the resulting .wav files, capture graphs of their outputs, and cross reference them.
in the time domain, transformer-based artifacts like pre-echo and temporal smearing were pretty easy to zoom in on and see, and this is expected because both mp3 and aac are heavily based on the mdct.

of course, this isn't the most robust tool it could be for evaluating perceptual encoders - it's very surface level. more specialized tools might be able to provide more information on, say, what content of the input is classified as noise by the encoder. the benefit of this simplicity, however, is that the tool isn't so specific to one use-case that it becomes impossible for anyone to use it for anything else.

so, uh, go forth and enjoy it.