"It happened several in the past, so I became more pedantic about testing stuff before recording."Spectrograms, which are not to be mistaken for spectrometers (confusing terminology that may deceive people outside those professional fields), can be implemented easily in software and as it turns out many implementations already existed a decade ago. Many are freely available also for GNU/Linux. Many studios like the platform.
They say the best way to improve is by learning from past mistakes and prevention of disaster is better than trying to mitigate (typically an impossibility in this context). I've tried alsa
tools, hoping to find something handy (command line software) to no avail and later on I found a couple of different programs which are Free software. One did not work (friture
, latest build), whereas the other one did (glfer
). Picking up its input from noisetorch, it helps display the microphone's input in waves or heat maps. It still assumes one uses older sound systems, so for pulseaudio
a compatibility redirection is needed: padsp glfer
glfer
is in the Debian repositories and also in Ubuntu's. Maybe it'll turn out to be a waste of time and CPU; but if there's a chance it can prevent disaster or salvage lost work (the latter is unlikely), then it's probably worth a try. I'll have a go at it. I'm trying to record videos every day (Daily Links and general articles take up a lot of time too), so anything that can make the process smoother will be added to the workflow/pipeline. Much of this is automated or semi-automated already. Extra sanity checks cannot hurt. ⬆