lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update metadata and transcripts through end of July 2026

Browse Source 
Refreshed episodes/hosts/comments/series from hpr.sql, and added
official HPR transcripts for the 180 episodes aired since the last
sync (hpr4516-hpr4695).
This commit is contained in:
Lee Hanken
2026-07-31 16:18:57 +01:00
parent 37e8274bff
commit 087f80c44d
184 changed files with 61169 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hpr_transcripts/hpr4648.txt
+301
View File
@@ -0,0 +1,301 @@
Episode: 4648
Title: Simple Podcasting - Episode 4 - Audio Analysis Fun
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4648/hpr4648.mp3
Transcribed: 2026-07-31 16:15:58 (official HPR transcript)
---
This is Hacker Public Radio Episode 4648, for 2026-05-27
Today's show is entitled, "Simple Podcasting - Episode 4 - Audio Analysis Fun"
The host is Whiskeyjack and the duration is 00:26:09
The flag is Clean, and the license is CC-BY-SA
The summary is "This episode is the fourth in an 4 part series on simple podcasting covering Audio Analysis Fun with"
This is the fourth episode in a four-part series on simple podcasting.
Introduction.
In this episode, we will discuss alternatives to a
Dacity, but it comes analyzing audio spectrums
to find the sources of unwanted noise.
I previously promised some gratuitous accurate
and we will get into that in this episode.
Recall that with audacity, you first import the audio file
then select the part of the audio you wish to analyze
or control a for all and then select analyze
plus spectrum.
This is in fact the only feature of audacity that I know how to use.
I am definitely not an audio expert.
I do however have some background in processing and analyzing other signals,
so some of the basics are familiar to me.
We can accomplish the same thing that audacity does in this instance
provided we do the following.
First, we need to get the data out of the audio file
and into a form which we can import into other software.
Second, we need to perform certain mathematical operations on this data.
Finally, we need to be able to plot the results of these calculations
on a chart for a transforms.
First though, we need a bit of mathematical background.
What audacity is doing when it shows a plot of frequency versus amplitude
is that it is showing the results of a Fourier transform.
A Fourier transform is a mathematical operation
that converts the time domain into the frequency domain.
Any complex signal, audio, or otherwise,
can be broken down into a collection of sine waves of various frequencies.
For example, a simple square wave signal of say 100 hertz
can be represented as a sine wave of frequency 100 hertz
plus a collection of higher frequency sine waves
which add together to give the sharp corners.
A Fourier transform finds these sine waves
and sorts them out into separate bins
with each bin representing an individual frequency
or collection of closely related frequency
depending on how fine grain the sorting is.
This is exactly what we want when we are trying to figure out
how to filter out noise.
We call that earlier in this series
we had to solve a problem with a high pitch background noise
which was originating in my cheap microphone.
Analyzing this audio by frequency
showed that it was a series of individual tones
at one killer hertz intervals.
We were then able to use filters targeted
at those frequencies to get rid of that noise.
There are several optimized versions
of the Fourier transform algorithm.
A very common one is the fast Fourier transform
commonly abbreviated to just FFT.
This is so common that the term FFT is often used
to simply mean any Fourier transform
even though this is not technically correct.
Typical FFT algorithms require that the number of data samples
is exactly a power of two.
So the number of samples we need may be something like
4,096,8192, or 65,536
to give a few random examples.
When we transform from the time domain to the frequency
domain, each sample becomes a single frequency bin.
So the more samples we have to find a resolution
we get in terms of frequency.
If we assume we are dealing with
a couple of his dials recorded at 44.1 kilohertz sample rate
that is 44,100 samples per second
that if we have 32,768 samples,
each bin represents slightly more than one hertz.
If we have 65,536 samples,
then each bin represents a fraction of a hertz.
For our purposes, we will pick 65,536 samples
that would mean we need 1.48 seconds of data. For simplicity's sake, we will record
at least two seconds of data and then just discard the samples that we don't need.
There is a further complication here.
Fourier transforms normally work with complex numbers.
Recall from your school days that as well as integers and real numbers, there are complex numbers.
Each complex number consists of two parts, a real component and an imaginary component.
I won't go into the details of this, just accept that each sample needs to have two components.
Fortunately, if we don't have a complex number data, we can just set the imaginary component to zero and use that.
This is enough talking about the theory, let's get into the practical details.
We will extract data from audio files. First, we will look at how to extract the data from the audio files.
Fortunately, one of the programs we've already been using can do this.
To do this, we will use Sox. I'm not aware of an equivalent feature in FFMP.
Sox calls itself Sound Exchange, the Swiss Army Knife of Audio Manipulation.
Sox is free software and is licensed under the GPL V2 or later.
In this case, we want to use a feature which allows us to convert a binary audio signal file to a text data file.
To convert the file to text, we just give the output file a .dat file extension and Sox will do this for us.
Here is a command example. Sox, that's SOx, space, inputfile.flac, space, t-data.dat.
This gives us a file in the following format, assuming that this is a mono audio recording.
The first line states the sample frequency. The second line states that the data is for channel 1.
The data starts on the third line.
The following one is the time in seconds, column 2 is the waveform data point.
To analyze the data, we want a subset of these samples.
When we convert from a time domain to the frequency domain, our resolution will be determined by the number of samples.
We would like therefore to have at least as many samples as a sampling rate.
We also want the sample size to be an even multiple of two.
The number of points we want to have is equal to the next even multiple of two above our chosen sampling rate of 44,100 Hz.
This number would be 65,536.
To extract this data from the file, we can do the following.
Tail, space, t-data.dat, space, dash n plus 3, space, pipe symbol, space, head, space, dash n, 65, 536, space, pipe symbol, space, arc, space, single quote,
left curly bracket, printf, space, double quote, percent s, slash n, double quote, comma, space, dollar two, right curly bracket, single quote, space, then right angle bracket, or right arrow, however you want to describe it, space, t-data.csv.
We use tail to skip over the first three lines.
We use head to take the next 65,536 lines and discard the rest.
We use arc to extract the second column, which we will use as the real component.
We now have this data as a CSV file in one column, analyzing the data.
To analyze the data, we need software which can calculate FFTs.
I will now show two examples of this, a very simple case using Libra Office Calc, and a more complex but more complete one using GNU Octave.
Using Libra Office, we can do Fourier analysis and plot charts using Libra Office.
Take this CSV file of data that we previously created.
For this example, I use data from a recording of silence, so I could see what internal noise was being generated by the headset.
Open the CSV file and import it into Libra Office Calc.
Now select all 65,536 rows of column A.
The Fourier function will automatically fill the imaginary component with zeros if we don't provide a column of imaginary numbers, so we don't need to provide a column of zeros.
Then select data, statistics, Fourier analysis.
A window will open allowing you to select various parameters for results to enter D1.
Select grouped by columns, select OK.
New data should now appear starting in cell D1.
The first line will say Fourier transform.
The second line will state the input range.
The third line will state real in column D and imaginary in column E.
The data will start in row four.
For our simple example, we will ignore the imaginary data and just use the real data, which will form our Y component when we plot it on a chart.
We now need to create the X-axis data.
Each cell is a bin of frequencies.
Each cell, therefore, represents sample frequency divided by number of samples, which gives us hurts.
To create the X-axis data showing frequency, enter the following data into column C to the left of each D column number.
Equal sign, left bracket, left bracket, 44,100 divided by 65,536.
Right bracket, space, asterisk, space, left bracket, row in capital letters.
Left bracket, right bracket, space, minus, space, four, right bracket.
We can now create an X-Y chart showing the frequency analysis.
You may need to exclude the first couple dozen rows, as very low frequency components, which cannot be heard,
be otherwise overwhelmed the data we are interested in.
Also, you only need the first half of the chart.
The FFT mirrors the data from the first half of the array into the second half.
Because characterizing a sine wave requires a minimum of two points, although we have a sample frequency of 44.1 kilohertz,
we really only have sound waves up to a maximum of half that, or 22.05 kilohertz.
Create the chart with lines only.
If you follow the above instructions, you should see something resembling what we saw in a dacity,
except with each bin more sharply defined.
In the data that I had from a recording of unfiltered headset noise,
I could see a distinct noise spike every 1000 hertz.
However, we have taken several shortcuts.
First, the imaginary component of the data was ignored.
Second, the magnitude that is the y-axis has both positive and negative peaks.
Third, the data is not scaled to DB sound units, so we just have a relative measure.
However, that by itself is enough to tell us where the frequencies are that we need to construct filters to deal with.
We could refine the spreadsheet a bit more to deal with the above issues,
but I think we have demonstrated the basic principle, and working with the spreadsheet can be a bit awkward.
However, if working with the spreadsheet is what you want to do, then you can add more columns and more formula to improve upon it.
Other analysis software.
I will go on to GNU Octave in a moment, but I want to get a few other alternatives out of the way first.
I won't go into any detail on them other than to point them out to people who want to have a go at trying those themselves.
Grace.
There is math and plotting software called Grace.
That's GR-A-C-E.
This is free software released under the GPLV2.
According to the documentation, it seems to have the features we need, including an FFT function.
However, I could not get it to work properly on Ubuntu 24.04.
I could not get it to load a data file and plot data.
The error messages were vague and unhelpful.
The file navigation system didn't work.
There was no obvious path to success, and if it isn't easy to use, then there is no point to it.
This is fairly old software designed for X window and motif.
I gave up on it as not suitable for this series, as I am looking for some fairly low effort things for people to try themselves.
If someone else can get it to work on their PC, perhaps they could do an HPR episode on this themselves.
Command-line FFT packages.
There are several command-line FFT packages.
They were read data from standard in or from a file and output the FFT.
However, these are not packaged for Ubuntu, and appear to be distributed as C source code which you would download and compile.
You can experiment with those if you wish, but I felt there were a bit out of scope for discussion here, as I am looking at common tools that are ready to use.
Here are two examples.
One is command-line Fast Fourier Transform Utility.
It's at github.com.
The repository belongs to Greg F. Johnson and it's called FFT.
Another is CLI-FFT.
It is also at github.com.
The repository belongs to J-O-N-O-L-A-F-U-R.
And the project is called CLI-FFT.
I have not tried these and cannot say whether they are any good or not.
Similarly, there are a number of FFT packages that are libraries for languages such as Python.
If you want to take the time to write a short program to go with them, you can create a dedicated FFT command-line program.
However, I felt this was too out of scope for what I was trying to do here.
Doing it the hard way.
Hypothetically, it may be possible to write an FFT function in bash bc, which is your arbitrary precision calculator language, which is part of the standard shell package.
I say hypothetically because I have not tried it.
I think it would be an interesting challenge, but it don't have the time at the moment to try it.
If anyone feels motivated to give it a try, they are welcome to give it a go, and then do a podcast episode on it, and let us all know.
J-O-K-Tave.
We have seen that as well as using features built into audacity to analyze the audio spectrum to see the frequencies of audio-sired noises,
we were able to do the same using a deeper office spreadsheet.
Now we will look at another bit of software, J-O-K-Tave.
J-O-K-Tave is free software, licensed under the GPLV three or later.
It is a mathematical scripting language, very similar to MATLAB.
People use it for mathematical, engineering, and scientific work.
It can be found in most Linux distros, and is available for some other operating systems as well.
Octave has two features built in that we need for our purposes.
It does FFTs, and it has a plotting system built in to produce graphs.
We will take the same audio test file that we use with audacity and labor office, and use it here as well.
The bash script to convert the flag file to text data is essential to the same.
With the exception that the file extension on the output file is .txt instead of .csv,
this latter change with an arbitrary decision on my part.
As a quick review, this bash script uses socks to convert a flag file to a text .dat file.
Then it uses tail, head, and oc to extract the first 65,536 rows of data,
skipping over the header information, and ignoring the first column of time data.
This script will be in the show notes.
We now have a 1.1 megabyte file containing 65,536 samples of data in text format.
Now the next thing we need to do is create a short Octave script file.
I will just give a brief overview of the script here.
The full script will be in the show notes.
I put the script in a file called OctaveSpectrum.m.
I have never used Octave before now, but the convention seems to be to give this script a .m ending.
The shabangline is hashmark exclamation slash user slash bin slash ENV space Octave that's octavee.
If you make the file executable, you can run it like any other script, or you can type Octave,
and then the name of the script to run.
I won't read out the script in detail as that would be too hard to follow along in a podcast.
However, I pass several arguments to the script, including the name of the data file,
and then two integers that I use to limit the display area in the x and y axes,
so I can have the chart focus on the areas of interest that I want to see.
I also pass a string containing the name of the graphic file that I want the chart exported to.
This was an arbitrary decision on my part, and you can just hard code these values in if that is what you want to do.
The arguments are accessed by calling the args function, which returns in a ray of strings.
Next, it reads in the specified file using the dllmread function.
This reads all of the data into an array.
Next, it performs a hamming windowing function on the data.
I'll explain that briefly.
It is standard practice when doing FFT signal processing to window the signal.
Since the single sample is a finite length, it will stop at each end of the array.
Unless you are lucky enough for this to happen exactly at a zero crossing,
this would produce an abrupt transition to the data, which looks like noise to the FFT.
The solution is to taper the signal off gradually towards the ends, so that when it gets cut off,
the signal is fairly small at that point anyway.
There are variety of different windowing functions, but hamming seems to be the most commonly used.
Next, it does an FFT using the FFT function.
This gives us real and imaginary outputs.
These are combined by summing the squares of each corresponding real and imaginary element,
and then taking the square root of each and storing that in a new array.
This gives a single array of the same lengths as the originals, but combining the two output components.
If anyone wants to tell me that this isn't how things are done in the audio world,
they're welcome to make an HPR episode telling us all the right way to do things.
Then it does some scaling and selection of subsets of data, so we get the x-axis and Hertz,
and just the number of samples that we wish to look at.
If you're looking at the script, the first thing to keep in mind is that Octave will work on entire arrays of data in a single operation.
You don't need to write explicit loops for this.
The looping is handled implicitly as part of the syntax.
It also does various other things that make the chart easier to read.
The comments in the script describe these in more detail.
Since this is a script, it's easier to add these sort of refinements than it's in the case for a spreadsheet,
so I've made the effort to add them.
Finally, it calls the plot function.
If an output graphics file name was provided, it also creates a PNG file containing the same image using the save as function.
We now see the chart, and it looks more or less as expected.
However, this chart is interactive.
You can zoom and pan the data, something that you can't do with either audacity or liberal office.
The chart window doesn't have a function for exporting the resulting chart to a PNG file.
It will only save this to an olfig file.
The olfig file is not a standard graphics file.
It is a serialization of the chart data that can only be looked at using the Octave chart viewer.
Alternatively, you can just take a screenshot of the chart after you have interactively zoomed in pan to a point of interest.
At the bottom left of the chart window is a pair of XY coordinates which tell you the current position of the mouse pointer in chart units.
This is very handy as it can be used to get the exact or close to exact frequency of each noise spike.
The Y axis is not scaled in any particular unit such as DB, as I'm not sure how to do that, according to audio industry conventions.
On the other hand, I'm not sure that it's really necessary as I don't know what DB means in tangible terms anyways.
It does show relative sizes so it helps to determine whether you have one noise frequency or multiple frequencies to worry about.
If anyone is familiar with how to scale the raw data from a flack file as exported by socks into DB units according to audio industry convention,
then they're welcome to create an HDR episode telling us how to do it.
Comments on GNU Octave. I had never used GNU Octave before this, although I had heard of it, and it is quite a significant piece of software for a specific segment of users.
The syntax is a bit odd, especially in how it deals with array operations, but it was able to Google various examples and answers to eventually get this working.
If you other peculiarities are that uses the percent character to denote a comment and leaving out the semicolon at the end of the line causes it to print the answer to the console after executing the statement.
The GNU Octave solution was harder to get working than they leave her office method.
However, once it was working, it is easier to use repeatedly.
If I were to want to automatically generate audio files with different filtering or other options and wanted to script the creation of a large number of images showing the results, this would be the way to do it.
When you run the Octave script, you may get a warning which says something like Q socket notifier. You can only be used with threads started with Q thread.
This apparently is a routine warning message from the QT graphics system which has no real significance in this context and can be ignored for our purposes.
We now have a bash script which will use socks to extract the data from a flag file and a GNU Octave script which can be used to display the resulting frequency spectrum.
This does more or less the same thing as plot spectrum doesn't audacity but allows for zooming and panning to get a more detailed look at the data.
However, it doesn't give you an absolute reading of the sound levels in DB, something that audacity does provide.
What I wanted it for though was to find the frequencies of the audible noise and the signal, something that it does quite well.
Episode conclusion. In this episode, we covered the following topics. What Fourier transforms are, extracting data from audio files using socks, analyzing the data using Libra Office, analyzing the data using GNU Octave and several alternative analysis methods.
Series conclusion. This is the end of a four-part series on simple podcasting. In the first episode, we covered a simple podcast recording method. This first episode is all you really need to make a podcast.
In this up-and-up episode, we covered basic filtering and a few other simple topics. The methods used in that episode provide basic improvements to your audio if you feel the need for it.
In the third episode, we covered how to analyze audio noise problems using audacity and additional filtering techniques to deal with specific problems that we may find.
We also covered command line recording, playback, and getting information about an audio recording. In the fourth episode, we engaged in a bit of gratuitous hackery for the fun of it and showed how to use alternative software methods to analyze audio signals.
I hope that this series has been both useful and entertaining and that you will use the knowledge gained here to create and submit your own HPR podcast episodes.
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.