-- Leo's gemini proxy
-- Connecting to gemini.techrights.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Gemini version available ♊︎
Posted in Free/Libre Software, GNU/Linux at 5:44 pm by Dr. Roy Schestowitz
Image: noisetorch and glfer
Summary: When you are recording something and cannot be entirely sure that input from the microphone is indeed being registered/saved it can be helpful to use a spectrogram; today’s data loss was a motivator for exploring what’s out there for GNU/Linux users
Earlier today I recorded a video, which about third-way from the start simply stopped getting any sound (only video/screen persisted). I did not even notice this until half a day after the upload (someone reported it to me) because I don’t double-check whole videos, I only do a sanity check on the edges (start and finish). I had 3 video files left from this whole process and they seem to indicate the error had nothing to do with conversions/transcoding. It happened at the time of recording.
This didn’t upset me as much as previous incidents of this kind, probably because that was just 13 minutes in total (lost audio). Prior to that I lost the sound of very long videos (about an hour long). It happened several in the past, so I became more pedantic about testing stuff before recording. It’s just really frustrating trying to redo or recreate things from memory, not to mention that this whole experience can be a bit boring.
> “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. █
Share in other sites/networks: These icons link to social bookmarking sites where readers can share and discover new web pages.
Permalink > Image: Mail
Send this to a friend
----------
➮ Sharing is caring. Content is available under CC-BY-SA.
-- Response ended
-- Page fetched on Mon May 13 10:07:55 2024