i don’t think you should crop the spectrogram exactly. i think the best thing to do is something like what Audacity does. it displays a default spectrogram frequency range up to ~20kHz (since human hearing is generally described as 20Hz to 20kHz) and allows the user to “zoom” in an out on that range, up to the frequency range captured in the file.
so in my mind, the ideal interface would allow the user to specify the min and max frequency (with default 0 to 20000 Hz) and the type of scaling (i.e. linear, logarithmic, etc.). this kind of interface would be dynamic, showing you the detailed spectrogram for a given window of audio, and that window would move as the audio was played. something like this:
if you need to save default snapshots of the spectrograms so that you can deliver visual previews of the sounds easily, then i think the best thing is to have a handful of standard configurations, similar to how you have a handful of standard configurations for delivering photos. these preview spectrogram images could all be the same height and width – say 150px by 50px. and your standard configurations could be something like:
- human hearing range (20Hz to 20kHz), logarithmic scale
- human hearing range (20Hz to 20kHz), linear scale
- full range of audio file, logarithmic scale
- full range of audio file, linear scale
then if the user needs to see more detail, then they could look at the observation detail, and the player there would dynamically provide more detail, as described above.
…
unfortunately, it doesn’t look there are many easily found modules that would generate dynamic spectrograms for a given window of time. so in the absence of something like that, i don’t know if it makes sense given limited resources to approach the interface the way i’m thinking.
this looks interesting, but it looks like it’s no longer in development: https://github.com/miguelmota/spectrogram
this looks interesting, but it generates spectrograms from the microphone: https://github.com/borismus/spectrogram.