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/hpr4608.txt
+280
View File
@@ -0,0 +1,280 @@
Episode: 4608
Title: Simple Podcasting - Episode 1 - Preparation and Recording
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4608/hpr4608.mp3
Transcribed: 2026-07-31 16:15:04 (official HPR transcript)
---
This is Hacker Public Radio Episode 4608, for 2026-04-01
Today's show is entitled, "Simple Podcasting - Episode 1 - Preparation and Recording"
The host is Whiskeyjack and the duration is 00:23:08
The flag is Clean, and the license is CC-BY-SA
The summary is "This episode is the first in an 4 part series on simple podcasting covering Preparation and Recordin"
This is the first episode in a four-part series on a simple way to create your own HPR
podcast episode.
If it sounds contradictory to have four episodes on a simple subject, you only actually
need the first episode to see how to create podcasts.
Through remaining episodes are on steadily more complex subjects, with the later ones being
more in the realm of gratuitous hackery for the fun of it.
I am fairly new to podcasting.
I have done an HPR episode on old tool, another on the UCSDP system, and an eight-part series
on nuclear power.
Prior to this, I have never done a podcast before.
Despite that, a number of people wrote into HPR to say that they really liked what I did.
This means that you two can make a first podcast and have other people find it very interesting.
Since I am fairly new to this, I thought I would document how I went about it for the
benefit of people who want to do the same.
This describes things from the perspective of someone who is very new to this sort of thing.
Later on, I will get into sport advanced topics, and the finish off with some blatant
gratuitous hackery, like how to use LibreOffice Calc or GNU Octave in place of an audio editor
for some things.
Initial hurdles.
There were several hurdles to get over before I could record an episode, though.
One was obvious one to me was that I'm not a sort of person who could simply babble into
a microphone.
That meant that I needed to have a way of recording things that would let me exclude
pauses and repeat sentences that I had best up.
However, since I was due to podcasting, I didn't know how to use an audio editor such
as audacity.
After a bit of thinking, though, I came up with a very simple solution to that, which
I will get into a bit later in this episode.
Taking a topic, with the recording process solved, the next thing to do was to find something
to talk about.
The key to this is to have some place to keep notes.
I use a note taking program for this called ZIM.
There are other programs which do something similar, but ZIM is the one that I use.
Whenever I come up with an idea of a topic, I would add a note for it.
When I come across any information relevant to one of the topics, I add it to the note.
You might think that you don't know of anything interesting, but the fact is that a lot
of us are fairly sad individuals who are just as boring as you are, and so find things
like verbal tours through obsolete and obscure operating systems to be quite fascinating.
I am sure that you too know something obscure but equally interesting.
Writing a script.
Once you have a topic, the next thing to do is to write a script.
If you are good at talking off the cuff, then all you may need is a note line.
If you are like me, however, then you need to write down exactly what it is you're going
to say in a way which you can read back later.
In this case, start with a note line and fill in the detail after the outline is written.
Again, I use ZIM for writing my scripts.
It provides a simple way of organizing my scripts as I am putting them together.
It also provides character and word counts so I can estimate how many minutes of material
that I have.
When I started, I decided that I should target about 10 to 20 minutes for the length of an
episode.
That's a personal decision and not something you need to follow for yourself, but it gives
me a guideline to work to.
As a rule of thumb, I find that if I multiply the character count by 0.0011, that gives
me the approximate number of minutes of audio when recorded.
Your own number may differ from this, but it's a good starting point to work from.
If you think the episode is getting too long, don't worry.
You can split it up into multiple episodes.
Once you have this script written and have if necessary, split it into separate episodes,
start numbering the paragraphs.
This is related to the recording method, which I will go into more detail later.
Each paragraph or section should be equivalent to 30 seconds to a minute of audio.
If you are just starting out in podcasting, this may be roughly how much you are comfortable
with recording without pausing to collect your thoughts or stumbling over what you are
saying.
We will knit these sections together with a very simple piece of software later.
Recording Equipment You will need some sort of recording equipment, while some people may
talk about using a phone or an MP3 player with a record function or something like that,
I'll stick with recording onto a PC.
My recording equipment consists of a Maxwell headset with headphones, boom mic, and USB connection.
There is no part number on it, and I can't identify it further than that.
The cost was probably around $20.
Similar one's cell for $5 to $35 depending on where you buy it.
I already had this, so I didn't have to go out and buy it when I decided to make a podcast.
A boom mic that is a microphone that is on an arm attached to the headset is good because
it keeps the microphone at a consistent distance from your mouth without any effort.
The disadvantage of the particular model that I have is that there is noise in the signal,
which you can hear in my first two podcast episodes.
Despite the noise, people still like the episodes, so don't get too hung up on audio quality.
I will talk later about how to fix noise issues like this by filtering.
However, at this point, I'm just going to stick to the basics.
Recording software.
For recording software, I used no more record on Ubuntu.
This is licensed under GPLV2 or later.
It is very basic.
The only options are to select the file format and select stereo or mono.
The sample rate for flag is fixed at 44.10 kHz, which is what HPR wants.
If you are using different software, possibly on another operating system, the principles are the same.
There are probably equivalents which you can find if you look for them.
Perhaps you or other listeners could make an HPR episode recommending one.
When using no more record, use the menu located in the upper right of the window bar,
which has three small horizontal lines as an icon.
Set the preferred format to flag that's FLAC, set the audio channel to mono.
Recording.
Get comfortable at your desk.
Get it a cup of tea ready as your throat may get dry.
Set up the hardware.
If using a boom mic on a headset, adjust the mic so that it is roughly at chin level.
Avoid putting a boom mic directly in front of your mouth.
You just speak over the top of the boom microphone, not directly at it.
This will prevent you from breathing on the microphone causing noise problems.
If you have a different type of microphone, you may have to experiment a bit using short
test recordings to find the optimal position.
Using your recording software, make a short test recording and listen to it.
If it is too quiet and the input volume is already all the way up,
we can adjust this later with software.
If the test recording sounds okay though, then you are ready to start.
Recording using no sound recorder.
I will now describe how to use no sound recorder.
If you are using different software, the details may be different, but the basic principles should be similar.
Using the mouse, click on the record button.
It will start recording, showing the waveform of the recording as it goes.
To stop recording, click on the square stop icon that appeared at the bottom.
Give the recording a name using the numbering system starting at 01.
To accept the recording, click on the check bar button on the right.
To save the recording, click on the down pointing arrow on the right.
The file name will default to the name of the recording which we just gave it.
The number should match the paragraph numbers in your script.
The recording will be saved as a flag file in your home directory.
There is no option to save it anywhere else and you will need to move it to refer destination manually.
You can now delete the copy of the recording which sound recorder keeps
by clicking on the garbage can on the left.
This does not affect the copy on your disk.
You will want to delete these extra copies as you go along,
as there is no easy way to do this later, and an extra copy of the recordings will accumulate
in a dot directory somewhere and take up space.
If you make a mistake or otherwise decide with that paragraph,
just delete the file and record it again.
Keep the pauses at the start and end of each audio segment equivalent to normal pauses between words.
This is actually fairly easy to do.
When you are done, you may have anywhere between two and four does a separate flag files.
Here are the two most useful keyboard shortcuts for normal sound recorder.
Press Ctrl R to start recording.
Press S to stop recording.
You will still need to use the mouse to click on the checkmark button to accept the recording.
There are supposedly keyboard shortcuts to save the recording to disk and to delete the recording,
but these don't seem to work, at least not on the version 43.beda on Ubuntu 24.04
Starting and stopping via shortcuts is still useful, however.
You can use other software, and I will talk later in another episode about using command line software,
such as FFMPEG to record.
Tips on recording.
If you are new to podcast, or just are not good at making long speeches,
keep each recording segment short, admitted or less being a good target.
If you stumble over what you're trying to say, don't worry, just repeat the recording for that section.
Talk eat clearly and even measure tones at a reasonably constant volume.
Remember who your audience are. There are people who are listening to your podcast
whether you're doing housework, or gardening, or driving a car, or walking down a street,
or taking some exercise.
Very few will be sitting at a desk in a quiet room like you are when you are recording.
Try to make sure that what you are saying comes across clearly.
If the loudness of your voice varies too much, they won't be able to hear you in the quiet parts.
The worst thing to do is to trail off into an imperceptible mumble at the end of each sentence.
This series will not be able to follow you if you do that, and may give up on trying to listen to your episode.
HDR audio file requirements, HDR episodes are mono, not stereo.
If you send in a stereo file, they will convert to mono.
However, you may wish to convert to mono yourself for the purposes of better duplicating the final result
when you review your own work.
The easiest way to create a mono recording is to record it as mono in the first place if your recording
software has this option. If you are using Nome Sound Recorder, there is a setting for this.
I described how to set the Nome Sound Recorder to mono just a few moments ago.
If your software doesn't have a mono option, or if you have already recorded it and now
wish to convert it to mono, you can use FFMPEG to do the conversion.
Here is the command line description.
FFMPEG space dash i space, then the name of the input file, then space
dash AC space, one space, then the name of the output file.
Alternatives to Nome Sound Recorder, an alternative to Nome Sound Recorder is KDE Recorder.
This is also available as a snap in a bunch too. The license is GPL 2.0 or later.
However, I found it to be a bit more difficult to use than Nome Sound Recorder.
Selecting the microphone source was difficult. It shows several different sources,
rather than just taking what the OS says is standard. This may be because it is a KDE app running
in Nome. Perhaps this is easier if you use KDE. Every time I unplugged my headset and plugged it back
in, it added more audio sources to its list. None of them worked, however, until I selected the
correct one, exited the program, and then started it back up. All files are saved in the music
directory, there is no choice offered. Audio format selection is more difficult, it being a two-step
process. There is no option for mono recordings only stereo. Flack file recordings were 48
killer Hertz rather than the HPR's preferred 44.1 killer Hertz. Converting this would require more
post-processing using audio software to change it. It seems to offer no advantages over Nome Sound
Recorder on Ubuntu while making selecting sound sources more difficult. If you're using a
Nome Desktop, you are better off with Nome Sound Recorder. However, it is all a matter of personal
preference, and if you find that you like KDE Recorder better, then go ahead and use it.
Other alternatives. There are of course still other alternatives. Many people recommend using
Adacity to record. However, I don't know how to do that, and the premise of this podcast
episode is that you have something you would like to make an HPR episode of, but are put off
by the difficulty of learning how to do so. However, Adacity is a very capable audio program,
and I have nothing against it. I will describe how to use a feature in Adacity to help
overcome an audio problem that I encountered, but I will save that for another episode.
As well as GUI programs, there are also programs which allow you to record audio from the command
line. I will describe a couple of these in another episode. If you're wondering why you may
wish to use a command line program for this purpose, one of the advantages of this is that let's
us write scripts which automate the recording process and eliminate some of the manual steps
that I outlined above. Combining the segments into a single audio file. At this point,
you will have recorded your podcast episode as a series of several dozen flag files.
We will now stitch these separate black files into a single file. We do this using either
FFMPEG or SOx. FFMPEG is a series of command line programs for converting and manipulating
audio and video files. Various parts are licensed under the LGPLV 2.1 or later, and
GPLV 2.0 or later. Sox is also a set of command line programs, but for audio only,
SOx stands for sound exchange. Sox, that's SOx, is licensed under similar terms as FFMPEG. In fact,
SOx actually uses FFMPEG for certain operations. For our purposes here, with one exception,
you can do everything audio related with either FFMPEG or SOx, except for one thing which I will
get into in another episode. That one thing is related to doing some gratuitous hackery when
analyzing audio files, so it may be irrelevant to anything you need to do. Since the two are
more or less equivalent for our purposes, I will be providing examples using both.
Combining audio segments. The best way to combine multiple audio segments is with a simple shell
script. A copy of this will be in the show notes. Doing this with FFMPEG requires just two lines.
First, create the list file. Print F, space, double quote, file, space, single quote,
percent S, single quote, backslash n, double quote, space, left square bracket, 0-9,
right square bracket, left square bracket, 0-9, right square bracket, dot FLAC, space,
then right angle bracket, or right arrow, however you want to describe it, space,
podseglist dot TXT. This first line creates a file called podseglist dot TXT,
which contains a list of all the two digit numbered flag files in the current directory,
together with some other necessary text. I have assumed you wish to give these files two digits.
Add more digits if you feel this is necessary. The file name podseglist dot TXT is
purely arbitrary and you can use whatever name you wish. Now we need to concatenate the files.
FFMPEG, space, dash F, space, concat, that's C-O-N-C-A-T, space, dash safe, that's S-A-F-E, space, 0, space, dash I, space,
podseglist dot TXT, space, full pod, dot FLAC. The second line calls FFMPEG,
does it to perform a concatenation operation, turning the multiple files listed in podseglist dot
TXT into one and saving it in a file called full pod, dot FLAC. Using socks, the socks
version is simpler. You do socks, the S-O-X, space, left square bracket, 0, dash 9, right square
bracket, left square bracket, 0, dash 9, right square bracket, dot FLAC, space, full pod, dot FLAC.
This will concatenate all the two digit numbered flag files in the current directory into one file
called full pod, dot FLAC. Revealing. Next you need to review your combined audio file.
Listen to the resulting file. If you are satisfied with it, you are done recording and are ready to upload.
If you're unhappy about some part of it, you can rerecord just that section and run the combining
script again. The numbers in your script will help you find the appropriate file.
The people running HPR will worry about adding your introductory and concluding music, converting
it to mono if it is currently stereo and adjusting the output level to make the volume consistent with
other HPR episodes. If there are noise problems that you want to try to correct, I will cover that
in another episode in this series. Prepare the show notes. You will need to have a few things
ready when you go to upload your episode. These are the title, summary, tags and show notes.
The title should be something short but descriptive. If this episode is part of a series,
you probably want to use a consistent title and include an episode number. Next you need a summary.
This is a brief description of what the episode is about. Try to be clear about what it is you
will be talking about. However, there are limits on the length of the summary. The limit was 100
characters at the time that I was writing this. The title in summary will be automatically added
by HPR to the beginning of your episode, so put some thought into what you're right here.
The title in summary are read out by a text to speech program, so avoid difficult abbreviations
or words at the software may not know how to pronounce. Next you will need to pick some tags.
These are used for search purposes. I will let someone else recommend how you should pick tags.
Next, you need to have show notes. If you have written a script, you can simply copy
based a whole thing into the show notes. At one time, there was a limit on the size of the show notes,
but that limit was removed recently. Uploading the episode, I will let someone else describe the
process of uploading the audio file and associated title summary and show notes. However,
you will need to have an email address ready to use as part of the process. So if you have
multiple email accounts, you need to set along which one will be used as your HPR contact address.
Conclusion. The preceding is how I created my first two podcast episodes,
which were on OAuth tool and the UCSDP system operating system. Plenty of people wrote in to say
that they liked them. Nobody complained about the quality of my narration or the technical quality
of the audio. You should be able to do the same. Further episodes in this series, I have covered
the basics, but there is more that we can do to improve the audio quality if you are so inclined,
or if you encounter an audio problem. In future episodes of this series, I will cover the following.
Basic filtering with FFMPEG and SOx to cover general cases. It's a good idea to use this sort of
basic filtering on your audio, whether you notice any problems or not. DSing to improve perceived
voice quality slightly in order to overcome sound artifacts inherent to using at least some microphones.
Normalizing audio to adjust the sound levels for easier reviewing.
Analyzing the audio signal with audacity to discover the characteristics of an E Noise Problems that
you may hear. Advanced filtering with FFMPEG and SOx to solve specific problems such as I had with
my headset, or which you may have with environmental noise such as fans. Command-line recording
and playing a audio using FFMPEG and SOx. This can help automate the process by automatically
numbering this small audio files, which are part of the recording process which I have described.
I promise some gratuitous hackery and I will provide it in the form of describing how to do
audio spectrum analysis using LibreOffice CalExpreadsheets and GNU Octave Mathematical Software
in place of audacity when troubleshooting audio problems. This concludes the first episode in a
4 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.