Idea: Spectrogram Analyzer

[jota726]

Hi @DRAZY!
I hope you're doing well!
​I had an idea for a standalone tool focused exclusively on audio analysis and verification. It would be great to have a lightweight utility dedicated to showing true audio quality, helping users verify the authenticity of their audio files.
​Key features that would make this tool extremely useful:
​True Spectrogram View: An unaltered, 100% accurate frequency spectrogram (similar to Spek or visual spectrum analyzers) to check for actual frequency cutoffs.
​Bitrate and Encoding Details: Clear indication of whether a file is CBR or VBR, along with authentic bitrates and exact sampling rates.
​Loudness and Dynamics: Peak volume levels in dB and RMS values to inspect dynamic range and loudness.
​Channel Configuration: Detailed channel information (stereo, mono, etc.).
​Having a fast, dedicated tool like this to verify downloads without relying on third-party analyzers would be an incredible addition to the ecosystem.
​Let me know what you think when you have a moment, and thanks as always for all your work on these projects!

[jota726]

​Hi @DRAZY!
​Just checking in on this to see if you had a chance to take a look at the idea. No rush at all—I know you're busy!
​Let me know what you think whenever you have a free moment. Thanks again!

[DRAZY]

Hi @jota726, and sorry for the slow reply. There is a reason for it.

I built it: Audio-V. Latest release is the latest release, macOS and Windows.

Honestly, I had no plans to make anything like this. You posted this idea on the 26th and it got under my skin, and the first commit on Audio-V is from that same evening. So the reason you did not hear back is that I was busy building the thing instead of answering you.

Against your list:

True spectrogram view. A measured STFT spectrogram that shows bandwidth and cutoff patterns. One deliberate difference from what you asked for, and I think you will prefer it: Audio-V does not claim any spectrogram is "100% accurate" or unaltered. Every spectrogram is a rendering choice, so it discloses the FFT size, window, channel mode, frequency range, display floor, scale, and palette used to draw it. Those settings change what the picture looks like, and not showing them is how spectrograms end up being used to prove things they cannot prove. Exposing them makes the view reproducible rather than authoritative.

Bitrate and encoding details. Format, real encoded bitrate, exact sample rate, CBR versus VBR, and the encoded MP3 channel mode. Worth being precise about how the CBR/VBR call is made, because I described it loosely at first: it is not read from a declared header or tag field at all. Audio-V probes every audio packet, builds the per-packet bitrate distribution, and classifies from its spread, calling it CBR only when the P05 to P95 spread and the coefficient of variation are both within 3% of the mean. That means it works for any codec FFmpeg can demux rather than MP3 alone, and a file whose tags claim one mode while its packets say another is reported as what the packets actually are. The distribution ships with the result so you can check the call instead of trusting it. MPEG version, layer, and the encoded channel mode are separately parsed straight from the MP3 frame headers.

Loudness and dynamics. EBU R128 integrated loudness and loudness range, true peak, sample peak, RMS, crest factor, DR descriptors, clipping percentage with per-channel counts and a timeline, plus ReplayGain.

Channel configuration. Channel mode, per-channel measurements, stereo correlation, and dual mono and near mono detection, which catches files that claim stereo but are not really stereo.

There is a Quick Inspect mode that is the lightweight single-file path you described: one file, one screen, verdict and format and signal and spectrum together. It is not a cut-down scan. It runs the same complete-stream analysis as the deep views and simply shows less of it.

The reliability part is where most of the work went. The analysis engine is validated against a format matrix and a real-world corpus, and the verdicts are deliberately conservative: anything that cannot be established from the audio alone is marked for review instead of being asserted as fact. A spectrogram can show you a cutoff. It cannot tell you a file's history, and the app will not pretend otherwise.

Issues and feedback belong in that repository now. Given where the idea came from, I would genuinely like your read on it.

[DRAZY]

One practical note so you are not hunting for the starting point.

You are on Windows x64, so either of these works:

• Windows installer for a normal guided install, the Audio-V-<version>-win-x64.exe asset
• Portable executable if you would rather not install anything, the Audio-V-Portable-<version>-x64.exe asset, which is probably the faster way to just try it

Heads up on one thing before you click: these builds are not code signed. I have not bought Apple and Microsoft certificates for this yet, so Windows SmartScreen will warn you and you will need "More info" then "Run anyway" to get past it. That warning is about the absence of a paid certificate, not about anything detected in the file. If you would rather verify before trusting me on that, SHA256SUMS.txt is published with the release and there is an unsigned installation guide covering it. Given that the whole point of this app is verifying what a file really is, it would be odd of me to ask you to skip verifying the app itself.

Then the first run is three steps:

1. Choose files for one track, or Choose folder to walk a folder and its subfolders.
2. Pick Full Oracle audit. The other mode, Metadata inventory, deliberately does not decode the audio, so it returns "Not analyzed" rather than a verdict. For what you described you want the full audit.
3. Read the verdict, then open the evidence behind it.

If you want the fastest possible first impression, point it at a single file you already know well and use Quick Inspect. One file, one screen, verdict and format and bitrate mode and signal and spectrum together.

One expectation to set: verdicts are Clear, Review, or Failed, and Review is used far more than you might expect. That is deliberate. Anything that cannot be established from the audio alone gets marked for review rather than asserted, so Review means "this needs a human", not "this file is bad". If you hit one you disagree with, that is the most useful thing you could send me.