hpr-knowledge-base/hpr_transcripts/hpr4638.txt

Episode: 4638
Title: Simple Podcasting - Episode 3 - Analyzing and Filtering
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4638/hpr4638.mp3
Transcribed: 2026-07-31 16:15:40 (official HPR transcript)

---

This is Hacker Public Radio Episode 4638, for 2026-05-13
Today's show is entitled, "Simple Podcasting - Episode 3 - Analyzing and Filtering"
The host is Whiskeyjack and the duration is 00:19:39
The flag is Clean, and the license is CC-BY-SA
The summary is "This episode is the third in an 4 part series on simple podcasting covering Analyzing and Filtering"
This is the third in a four-part series on simple podcasting.
In this episode, we will cover the following topics,
analysis of audio problems and filtering methods used to do with specific problems that we may find,
command line recording,
command line playback,
and getting information about an audio recording.
Introduction
When I did my first couple of podcasts, I didn't notice that there was a
quiet, high-pitched line or buzz in the background.
Nobody complained about it, but I thought I could do better in subsequent episodes.
Creating an audio sample.
If you have a similar problem,
the first step is to find out where it is coming from.
If there is no audible noise where you are recording,
there is a good chance that the problem is in the microphone,
or another part of the audio system.
Plug in your microphone
and record two or three seconds of quiet audio
or you do not speak into the microphone or make other noise.
You will need a minimum amount of data in order to analyze it.
For a flat file, sample that 44.1 kHz,
two to three seconds of data should be enough.
To get a sample of just electronic noise,
you can put the microphone in a drawer or somewhere like that
if you want to be sure of getting it quiet signal.
Any sound recorded in this way should be mainly from the microphone
or other electronic elements in the analog pathway.
To get a sample of possible ambient noise such as fans,
make sure the phone is in the open air in an area which is representative
of where it will be when you are recording.
Analyzing using Fourier transforms.
Next, you need to look at the waveform.
At this point, I will describe this using audacity.
Other ways later, but audacity is the easiest if you are starting from nothing.
You don't need to become an expert in audacity to use it,
just follow the steps I will describe.
I myself don't know how to use audacity
beyond using this one feature.
We are going to analyze the sound spectrum in our sample.
The technique being used is a Fourier transform.
A Fourier transform often called an FFT
for fast Fourier transform is a mathematical method of showing a signal
in terms of frequency along the x-axis instead of time.
This allows us to spot troublesome noise frequencies
which appear when we don't want them to.
The FFT is a very common mathematical technique
which is widely used in signal processing, not just an audio.
There is other software which will create pretty
color animations or sound waves, but this is not what you want.
These are simply decorative patterns
and won't tell us what we want to know.
Using audacity, install audacity if you haven't already.
Start audacity, select file, then import, then audio,
then navigate to your sample and select open.
The file should load.
In the waveform part of the window, click anywhere
and type control as to select all data points.
The chart should turn a slightly darker color.
From the menu, select analyze and then plot spectrum.
A new window will open, showing magnitude and dB on the y-axis
and frequency and hertz on the x-axis.
For algorithm, be sure it is set to spectrum.
There are now two settings we need to play with
while we look for problems.
One is size, the default for this is 1,024.
The other is axis.
The default for this is log frequency.
What to look for?
What we are looking for are large obvious spikes that stand out in the data.
Since our test signal has very little to no actual audio data,
any spikes should represent electrical or other noise that doesn't belong there.
I have found two combinations of settings to be of most helpful
in finding problems.
These are size, 2,048,
axis, linear frequency.
And the other is size 32,768
and axis log frequency.
A small size value can help very narrow spikes
to stand out from the background more.
Will a large size value can help separate spikes from surrounding noise.
A linear frequency axis can help with seeing all spikes across the full frequency range.
While a log frequency axis can help to better see
what is happening at the often very crowded lowest frequency range.
A real example of an audio problem.
If you have good audio equipment, you may find nothing obvious.
If you cannot hear any noise in the signal,
there may be none of any consequence and there is nothing for you to do.
However, in my case, I found two main problems and one lesser one.
One problem was a spike at 60 Hz, which is a AC line frequency.
There is also a lesser problem of a collection of a broad frequency range of noise below 60 Hz.
Both of these, however, will be taken care of by the basic filtering
that we looked at earlier, so we need not worry about them here.
The other main problem is a had a large spike at every 1 kHz interval from 1 kHz to 19 kHz.
This was noise generated within the headset electronics or the result of noise on the USB power supply.
This is a product of a cheap headset.
These spikes are not very large compared to the volume of my voice,
but if I do the same sort of analysis of samples where I am speaking,
they appear in the intervals between words.
This resulted in a high-pitched line or buzz.
This was the source of the background noise or buzz in my first two podcast episodes.
I need to get rid of this.
One option would be to get a better microphone,
but well, that wouldn't be any fun would it.
It would also cost money, and I don't want to spend any of that if I don't have to.
If you analyze your own signal, you may find a different pattern,
or even no noise at all.
If you did not find anything when shielding your microphone from ambient audio noise,
repeat the same test, but with the microphone exposed to acoustic noise in the room.
Advanced filtering.
The next step is to figure out how to get rid of this noise.
I have called this section advanced filtering,
but we are actually just making use of a deck geek that was already covered in basic filtering.
To deal with remaining spikes, we can use additional band reject filters,
each of it removes a specific frequency at 1 KHz intervals from 1 KHz to 12 KHz.
We will use this in combination with the filtering we have already done previously,
so we don't need to worry about anything about 12 KHz
as we already removed that with a low pass filter.
After a small amount of experimenting, I came up with the following.
Because I am applying a total of 16 filters,
for for basic filtering, and 12 to deal with the specific microphone problems that I have,
I have broken up the filters into separate strings.
I then generate the 12-do band reject filters from a template.
Note that I don't show the DSer filter here.
I would recommend adding it as a separate step after doing this sort of filtering we are talking about here.
Rather than reading out multiple lines of bass script, I will post them in the show notes.
I will give a brief description of them here, which you can refer to when reading the show notes.
The FFM peg and Sox versions are very similar in concept,
so I don't need to go over the Sox version in detail, see the show notes for it.
There are a total of 5 lines of bass script.
In the first line, we create a string called HLP Fill, which is a C-high and low pass filters copied from our previous discussion on basic filtering.
In the second line, we create a string called Line Fill, which is just a simple band reject filters
to cover 50 and 60Hz AC line noise filters, also from basic filtering.
In the third and fourth lines, we create a string called Kilo Spike Fill, containing the new filters.
The F parameter represents the frequency we are targeting.
The W parameter represents the width of the frequency range we are filtering in terms of Hertz.
The filter is applied gradually rather than with a sharp cut off, so to get more filtering action, we need to have a larger width.
In this case, I decided to hammer this spike quite aggressively, and so use a relatively wide width of about a hundred Hertz.
Testing with a voice file did not show any noticeable distortion, so it's an acceptable solution.
For this filter, we need to create a dozen filter commands, so we use the Shell SEQ command to generate a sequence of numbers from 1 to 12.
We then pipe that into the X-Args command, which applies each number to the next command.
The next command is PrintF, which takes the number it gets from X-Args, and applies it to the F template string template,
and a manner very similar to C programming, PrintF string templates.
We also have a comma in there to separate each of the individual filters.
We then surround this with a dollar sign in brackets so we can run the command and capture the output to a variable.
Then we call FFMPEG, and pass it to filters we created, but putting the variable names inside a double quoted string separated by commas.
All of this will be in the show notes, so don't worry about trying to get the exact details right now.
The Sox version is very similar, with the exception that the command arguments representing the filters must not be in quoted strings, as Sox wants to see them as separate arguments instead of parsing a string.
Confirping the effect.
If we apply the above filters and look at the headset noise output file in the Adacity Spectrum Analyzer, we can see that these noise spikes are now almost completely gone.
We can now confirm how well this works by using a test audio file.
Any normal short audio voice file will do for this.
Just talk into the microphone normally and create a voice sample that is 5 or 10 seconds long or whatever you feel comfortable with.
With the original unfiltered voice audio, I can hear a distinct, high-pitched line overlaying the voice.
With the filtered audio, that whiner hum is not detectable.
If we look at the voice file in the Adacity Spectrum Analyzer, we can see the distinct notches at the 50 and 60 Hertz frequency, and every 1 KHz from 1 KHz to 12 KHz.
These notches are narrow enough that they won't cause a noticeable problem with voice signals.
If we apply this filter to voice samples, the buzz or wine is gone, and the voice signal sounds fine.
Despite using a very cheap microphone, I now have an acceptable quality audio for a podcast.
Again, I want to emphasize that in this instance, I am dealing with deficiencies in my hardware instead of buying a better microphone.
These additional filters are intended to deal with the specific hardware problem that I am facing.
You don't need these additional filters if you cannot detect an audible problem.
On the other hand, if you have a different problem, you may wish to deal with a different set of frequencies.
Finding these problems is the reason for using a Spectrum Analyzer.
FFMPEG has other filtering methods as well.
However, as I didn't end up using them, I can't really do an adequate job of describing them.
If anyone has used them successfully, they're welcome to make a podcast on the subject.
Completing the process.
With these new filters added into the middle of the processing steps, you can now complete the processing by doing that DSing, normalizing, and review steps described in the previous episode.
Command Line Recording
I will now cover a separate topic which is recording using command line programs.
I'm covering it in this episode as it is a short topic, and it is convenient to talk about it here.
As well as using GUI-based recording programs such as Nome Sound Recorder, it is possible to record podcast episodes using command line tools such as FFMPEG.
As for why you may wish to use command line tools to record audio, there are several reasons.
One is that you may simply prefer to do it this way because it pleases you to do so.
Another is that it allows the recording step to be included in a script that encompasses other parts of the process,
automating what may have otherwise been separate manual steps.
However, if you don't find these arguments particularly compelling, then I'm not going to attempt to persuade you to use the command line to record audio.
I'm doing this part of this episode out of a desire to have a bit of fun, and I probably won't be using it much myself.
I will, however, use one of these methods to record this part of this episode.
Recording with FFMPEG, the basics.
One of the most common command line tools you can use is FFMPEG.
A package which I have previously mentioned with respect to filtering audio files.
Here is an example of how to record using FFMPEG.
We call FFMPEG specifying the audio input system as the FFMPEG input, and then specify a file to output to.
FFMPEG, space, dash, f, space, pulse that's p-u-l-e, space, dash, i, space, default, space, ff, dot, flag.
Press Q to stop.
This uses pulse audio on Linux for input that's the dash, f, space, pulse, and the default input that's dash, i, space, default.
However, this does not specify the sample rate or mono recording.
To do that, we need to add a few more parameters as in the following.
FFMPEG, space, dash, f, space, pulse, space, dash, i, space, default, space, dash, a, c, space, one, space, dash, a, r, space,
44,100, space, ff, dot, flag.
dash, a, c, space, one, specifies mono output.
dash, a, r, space, 44,100, specifies 44.1 kilohertz bit rate.
Playback with FFMPEG, the basics.
FFMPEG can also playback music.
In this case, however, we need to call the FF play program that's FFPL-a-y, rather than FFMPEG itself.
To play an audio file, simply call FF play and give it the name of the audio file as an argument to the command.
For example, FF play, space, podcast, dot, flag.
We can also call it with the auto exit option, which tells FFPL to automatically exit when the audio file has finished playing.
For that, we do FFPL, space, dash, auto exit that's a, u, t, o, e, x, i, t, space, FF, dot, flag.
dash, auto exit means exit when the audio file is done playing.
To exit in the middle of the recording, press q or escape.
To pause the playback, press p or the space bar.
To decrease the volume, press 9 or slash.
To increase the volume, press 0 or asterisk.
To seek forward 10 seconds, press the right cursor button.
To seek backward 10 seconds, press the left cursor button.
To seek forward 1 minute, press the up cursor button.
To seek backward 1 minute, press the down cursor button.
The 0 and 9 keys mentioned above are those on the top row of the keyboard, not the ones on the separate numeric pad.
While the recording is playing, a graphical window will open, which shows a cascading waveform based on the current content.
This is purely decorative and does not serve any particularly useful purpose.
Socks, not so good.
I did not find the recording or playback features of socks to be as useful as those of FFM peg, so we'll bother to cover them here.
Getting information about an audio recording.
There are also command line tools which can be used to retrieve information about audio recordings.
FFM peg version.
With FFM peg, this is called FF probe.
That's FFPR OBE.
For example, FF probe, space, HPR, 4566.MP3.
This will print out a lot of information about FFM peg itself.
Let's skip that.
Use the Hyde Banner option.
That's HIDE underscore B-A-N-N-E-R.
FF probe, space, dash, Hyde Banner, space, HPR, 4566.MP3.
This will print out information about the audio recording.
This will include things like the duration, bitrate, sample rate, stereo, or mono, etc.
If the author added metadata tags to the file, it will also show those.
HPR added things like the title, author, copyright license, comment, etc.
You can extract the ones you want using something like grip and cut.
Socks has a similar feature called Socks I, that's SOXI.
For example, Socks I, space, FF, dot flag.
However, it may not work on MP3 files if you do not have an MP3 handler for it installed.
Conclusion.
In this episode, we took a brief look at an example of how to solve an audio problem through filtering.
We looked at how to use a Dacity to find where the problems were.
We then looked at how to apply filters to remove these sources of noise.
We also looked at how to record podcasts and get information about audio files using command line tools.
In the next episode, we will look at alternatives to a Dacity for analyzing audio.
While a Dacity works just fine, this is an opportunity to have a bit of fun with some gratuitous hackery.
This has been the third episode in a four-part series on simple podcasting.
You have been listening to the Hacker Public Radio podcast, at hackerpublicradio.org.
Today's show was contributed by a HPR listener like yourself.
If you ever thought of recording a podcast, then visit the HPR site to find out how easy it really is.
Hosting for HPR has been kindly provided by anhonesthost.com, the Internet Archive, rsync.net, and the HPR Community Content Delivery Network.
Unless otherwise stated, today's show is released under a Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.