Update metadata and transcripts through end of July 2026

Refreshed episodes/hosts/comments/series from hpr.sql, and added
official HPR transcripts for the 180 episodes aired since the last
sync (hpr4516-hpr4695).

hpr_transcripts/hpr4618.txt

@@ -0,0 +1,340 @@
+Episode: 4618
+Title: Simple Podcasting - Episode 2 - Basic Filtering
+Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr4618/hpr4618.mp3
+Transcribed: 2026-07-31 16:15:15 (official HPR transcript)
+
+---
+
+This is Hacker Public Radio Episode 4618, for 2026-04-15
+Today's show is entitled, "Simple Podcasting - Episode 2 - Basic Filtering"
+The host is Whiskeyjack and the duration is 00:37:16
+The flag is Clean, and the license is CC-BY-SA
+The summary is "This episode is the second in an 4 part series on simple podcasting covering Basic Filtering"
+This is a second episode in a four-part series on a simple way to create your own HPR podcast episode.
+This episode will cover the following topics, basic filtering, DSing to improve voice quality,
+and normalizing to adjust audio levels for easier reviewing.
+Filtering is removing unwanted noise from an audio signal.
+There are several ways of doing this.
+It is possible to do this with audacity, but I don't know how,
+so I won't try to describe that method.
+It is possible, however, to filter using command line tools,
+such as FFM peg and socks.
+When assembled into shell scripts, these tools can become part of an automated process
+that you can use over and over again for each HPR episode that you record.
+In a later episode, I will discuss how to analyze audio signals to find the sources of noise
+that can be reduced or eliminated with filters.
+In this episode, however, I will discuss basic filtering that you can apply routinely
+without doing any analysis beforehand.
+Sources of noise.
+A question that you may have is, why is there noise in the recording?
+There are many sources of undesirable noise.
+A very common one that you may not be aware of is electrical noise that works its way into the electronic recording circuits
+and is imperceptible to you until you play back to recorded audio.
+The most common noise signal is what is commonly called line noise,
+and it is a low frequency hum at 50 or 60 Hz from the electric power lines
+and reflects the 50 or 60 Hz frequency of the AC power lines feeding your recording hardware.
+You may be familiar with this low frequency hum from when it emanates from the large electrical hardware such as transformers
+as it makes the lamination vibrate.
+However, it can also work its way indirectly into electronic equipment as well.
+Good quality audio hardware may filter out all or most of this noise,
+but it is present in a lot of consumer-grade hardware.
+Other sources of electrical noise may reflect specific problems in your recording hardware.
+I will discuss one such problem with my microphone that I had to address.
+Still other sources of noise may reflect actual physical audio noise around you, such as fans.
+Placing the microphone close to your face will help in dealing with a lot of these problems,
+but you may find filtering to be of some help here as well.
+Audio frequency range.
+Let's start with some basics.
+A good quality stereo of the type you may have at home is typically rated to perform between 20 Hz and 20 kHz.
+This is the widest possible range that we need to consider.
+In reality, this is a far wider range that is needed for a voice-oriented podcast.
+It is also well beyond the range of the hardware that many of your listeners will be using to listen to the podcast.
+For example, the speakers that I have connected to my PC and a number of headphones and earphones that I have tested,
+drop off drastically below 80 Hz or above 8 kHz or even above 6 kHz in many cases.
+This is not audio-file quality hardware, but it is representative of the sort of hardware that a lot of your listeners will be using when listening to podcasts.
+And to be honest here, a lot of people have difficulty hearing anything above 8 kHz even with the best quality audio hardware,
+duty hearing loss for environmental noise exposure or age.
+You can get a good idea of what different frequencies sound like by generating sine waves, either with FFMPEG or SOx.
+Here's the example of generating a 1 kHz sine wave using FFMPEG.
+A copy of this will be in the show notes.
+Go to FFMPEG, space, dash F, space, L-A-V-F-I, space, dash I, space, double quote, sine equals frequency equals 1000.
+Colen, sample underscore rate equals 44,100.
+Colen, duration equals 3, double quote, space 0, 1, 0, 0, 0, 0, H-Z dot flag.
+This creates a sine wave at 1 kHz and a sample rate of 44.1 kHz for a duration of 3 seconds,
+and saves it to a flag file named 0, 1, 0, 0, 0, H-Z dot flag.
+Here's the same thing using SOx.
+Sox, space, dash, N, space, dash, R, space, 44, 100, space, dash, B, space, 16, space, 0, 1, 0, 0, 0, H-Z dot flag.
+Sox, space, S-Y-N, T-H, space, 3, space, sine, space, 1,000.
+The dash B, 16 specifies using 16 bits, audio to encoded, and the sine 1000 element specifies the frequency in Hertz.
+You can test this out at different frequencies to get a feel for how your hardware responds.
+What the effective limits on typical hardware audio range means is that we can quite safely filter out a large part of what is considered to be the audio range,
+without any noticeable loss of quality.
+For the purposes of our discussion here, then, I will limit the frequency range to between 80 Hertz and 12 kHz, and that is being generous.
+You can probably narrow that, particularly at the top end, without any problems.
+At the low end, the typical rule of thumb recommended by most people seems to be that for the average male voice, you can set the lower threshold at 80 Hertz, and for the average female, you can set it at 160 Hertz.
+Note that you don't have to set the threshold higher for a female.
+Rather, it is just that you typically can set it higher if you wish.
+Note also that these are averages and may not reflect an actual individual.
+Simple filters.
+We will now create some simple filters using the same command line software mentioned in a previous episode in the series.
+These are FFMPEG and SOx.
+First, let's define some terminology.
+A high pass filter passes through frequencies, which fall above a certain threshold, and blocks frequencies, which are below that frequency.
+In reality, there isn't any abrupt cut-off in the filters.
+Instead, there is a gradual roll-off or sloping-off of amplitude, below above the specified filter frequency.
+This is for two reasons.
+One is that, if there was an abrupt cut-off, then it would risk introducing audible distortion in this signal for free.
+The other reason is that this is how hardware filters traditionally inherently worked when they are made out of electronic components, such as resistors, capacitors, and inductors.
+The sharpness of this cut-off can be adjusted, but we won't be filling with it in that sort of detail.
+You will sometimes see filters specified in terms of number of poles.
+This has to do with describing how filters were constructed using electronic components.
+Don't worry about it, it doesn't really matter.
+Here is a typical high pass filter using FFMPEG, which filters out frequencies below 80 Hz.
+FFMPEG, space-i, space input-file.flac, space-af, space, double-quote, high pass, that's h-i-g-h-p-a-s equals f equals 8-0, double-quote, output-file.flac.
+Here is a typical low pass filter using FFMPEG, which filters out frequencies above 12 Hz.
+FFMPEG, space-i, space input-file.flac, space-a-f, space, double-quote, low pass, that's l-o-w-p-a-s equals f equals 12,000, double-quote, space, output-file.
+Here is a filter which combines the two.
+FFMPEG, space-i, space input-file.flac, space-a-f, space, double-quote, high pass equals f equals 80, comma, low pass equals f equals 12,000, double-quote, space, output-file.flac.
+And here is the same thing using socks.
+Sox, space, input-file.flac, space, output-file.flac, space, high pass, space, 80, space, low pass, space, 12,000, filtering out specific frequencies.
+Recall that I mentioned that a common source of noise is the 50 or 60 Hz AC power line frequency, working its way through the electronics of your recording device.
+Because filters operate gradually and the 80 Hz lower filter threshold is close to 60 Hz, the high pass filter may not deal with this adequately.
+Now, it happens that your listeners may not be able to hear this 50 or 60 Hz noise anyway, because their audio hardware won't reproduce it.
+That, by the way, includes you not being able to hear it either, when you review your recording before uploading it.
+However, to maybe some HDR listeners who are sitting back, sipping a glass of wine, and listening to your episode on their stereo, who can hear it.
+That suggests we ought to do something about it, just in case.
+I will get into how to analyze audio signals in a later episode, but for now, just accept that it looked at the frequency spectrum of a sample recording using my hardware, and found a large 60 Hz noise spike, which I want to address.
+Experimenting with additional high pass frequencies up to 120 Hz did not improve things much, which we expect to these 60 Hz problems.
+There are other parameters which could be tweaked, but at this point it would seem most promising to attack the 60 Hz spike problem directly using a different filter method.
+To deal with this 60 Hz spike, we can use a band reject filter, which removes a specific band of frequencies.
+We can use this in combination with the filtering we have already done above.
+After a small amount of experimenting, I came up with the following.
+I also added in a 50 Hz filter while I was at it, for the benefit of those living in areas with 50 Hz electrical supply.
+These filters will be included in the show notes, so don't worry if you can't quite understand all the details from a verbal description.
+Here is the FFMPEG version. FFMPEG space-i space input dot flag space-af space double quote high pass equals f equals 80 comma low pass equals f equals 12,000 comma band reject that's b-a-n-d-r-e-j-e-c-t equals f equals six.
+F equals 60, colon with underscore type that's w-i-d-t-h underscore ty-pe equals h colon w equals 20 comma band reject that's b-a-n-d-r-e-j-e-c-t equals f equals 50 colon with type equals eight.
+With type equals h colon w equals 20 double quote output file dot flag.
+This has the following elements, a high pass filter at 80 Hz, a low pass filter at 12 kHz, a band reject filter centered at 60 Hz and with the width of 20 Hz, a similar band reject filter centered at 50 Hz.
+Here is the socks version socks space input dot flag space output dot flag space high pass space 80 space low pass space 12,000 space band reject space 60 space 20 space band reject space 50 space 20 note that with socks don't quote the filter
+definition strings or else it will result in error as socks doesn't see enough parameters. This is not a problem with ffm-peg.
+The band reject filter knocks the stuffing out of the 60 Hz line noise and the 50 Hz parameters should do the same with that frequency as well. This basic frequency should be able to be applied to any podcast audio recording without causing any problems.
+You can probably reduce the low pass frequency from 12 kHz down to 8 kHz without any problems, but I would suggest you test it with your voice before making that decision.
+I will come back to filtering out specific frequencies again later when I discuss how I solved a specific problem with the hardware that I am using.
+However, we have to discuss how to analyze audio signals before we can do that sort of technical troubleshooting and I will come back to that in a later episode.
+Dsing and additional type of filtering is Dsing.
+When recording audio the microphone or environment a result in S, S, H, C, H and possibly other sounds to be exaggerated.
+These are all higher frequency elements of voice recordings. Dsing attempts to soften these sounds by selectively reducing the volume on the frequency band which contains these sounds.
+Software filters. Dsing is accomplished via software filters. FFMPEG and SOx both have Dsing filters.
+For FFMPEG, the Dsing filter is built in. For SOx, however, we must install an additional plugin. I will cover this in more detail when I discuss using SOx for Dsing.
+Do you need Dsing? The first thing to make clear however is that you may not need to worry about this. If you think the audio sounds just fine the way it is, you don't need to do any Dsing to it.
+Dsing is a very subtle change and you would probably need to do some careful before and after comparisons of audio samples to tell the difference.
+I didn't know that such a thing called Dsing even existed before I started doing the research to make this podcast episode. However, at this point we are doing things more for the fun of it than out of a necessity, so I'll describe it anyway.
+Dsing with FFMPEG. Dsing with FFMPEG is relatively simple. The filters built in and there are just three values to adjust. On the other hand, it is not really obvious what these values mean in practical terms.
+I will however warn you to not rely on the AI search results from Google to understand this feature. The AI in my experience just makes stuff up about it and tells you to use options that don't exist and values that are not valid.
+I found that the only useful information came from FFMPEG's own website and from examples written by actual humans.
+I then experimented with different values to see what effects they had. Since the results were rather subtle, fine tuning isn't really that necessary and I found that I could arrive at some reasonable values fairly quickly.
+I will provide the parameters that I found useful for me and suspect they will probably work for you as well.
+Here is a typical DS in command. FFMPEG space-i space input file.flac space,
+Does filter complex, does f-i-l-t-e-r underscore,
+c-o-m-p-l-e-x space?
+Quote, d-s-r that's d-e-e-e-r equals i equals 0.5,
+colon m equals 0.5, colon f equals 0.5, colon s equals o,
+Quote, space, dash b, colon a, space,
+336k, space, dash sample format,
+does s-a-m-p-l-e underscore, f-m-t, space,
+s-16, space, output, dot-flac.
+The important arguments are i, m, and f.
+i is intensity for triggering d-s-ing.
+The allowed range is 0.1.
+The default is 0.
+By experimentation, I found that 0 means no d-s-ing,
+and 1 is maximum d-s-ing.
+I found that setting it to 0.5 gives that as factory results.
+m is the amount of what is referred to as
+ducking on the trouble part of sound.
+The allowed range is 0.1.
+The default is 0.5.
+By experimentation, I found that 1 means no d-s-ing,
+and 0 is maximum d-s-ing.
+I found that setting it to 0.5 gives that as factory results.
+f is how much of the original frequency content
+to keep when d-s-ing.
+The allowed range is 0.1.
+The default is 0.5.
+By experimentation, I found that 1 means no d-s-ing,
+and 0 is maximum d-s-ing.
+I found that setting it to 0.5 gives that as factory results.
+Setting m or f too high can result in distorted output
+as too much of the original sound is cut out.
+The defaults of 0.5 in both cases
+gave audible improvements without noticeable distortion.
+There is a additional parameter called s
+this controls whether the s-ing filter does anything.
+Setting it to s is a normal and default mode.
+Setting it to e causes it to output just
+the components that it normally would have filtered out.
+This is useful for testing purposes,
+so you can see what and how much is being filtered.
+You only use this when experimenting with different values.
+Setting it to i causes the input to be passed
+through without d-s-ing.
+This will be useful in scripts where you want to use a variable
+to control whether or not you use a d-s-er
+while still creating the expected output file.
+There are two other elements of the command,
+which were included, but are not strictly speaking,
+part of the d-s-ing filter itself.
+These are the dash b colon a space 336k
+and dash sample underscore fmt space s16.
+dash b colon a space 336k
+says the audio bit rate to 336k.
+dash sample underscore fmt space s16
+says the audio sample format to 16 bit.
+I found it necessary to specify these in order
+to prevent the d-s-ing filter from changing formats.
+These are not part of d-s-ing however.
+d-s-ing with socks.
+You can also d-s with socks.
+However, this is much more complex for several reasons.
+One reason is that socks does not have its own d-s-ing filters.
+Instead, it uses optional plugins and you must find and install these.
+The actual plugin may vary depending on what operating system you're using.
+The other reason is that it deals with the issue in fairly low-level parameters
+and so it is a bit more complex to describe.
+Because of this, I will skip over describing this in detail
+and just give a very brief overview.
+If anyone would like me to describe in more detail how to d-s with socks,
+then send in a comment and I will do a short episode on it later.
+Socks d-s-ing over view.
+To d-s with socks, you first need to install the plugins.
+On Linux, these will be the tap Ledspa plugins that's TAP
+and Ledspa is LADSPA.
+Tap stands for Tom's Audio Processing plugins.
+Ledspas stands for Linux Audio Developers Simple Plugin API.
+To install the tap plugins on Ubuntu, use the following command.
+Su-du, space, app, space, install, space, TAP-PLU-G-I-N-S.
+The plugin we need is called TAP underscore d-e-e-s-s-e-r.so.
+In order to use the plugins, you need to set the path as variable.
+On Ubuntu, this is export, space, capital LADSPA underscore P-A-T-H.
+So that's Ledspa path all in capitals.
+Equals double-quote slash user as U-S-R.
+Slash, lib slash, Ledspa, LADSPA, colon double-quote.
+I put the above of the shell script which calls the socks d-s-r.
+To use the socks d-s-r, you do the following.
+Socks, space, inputfile.flac, space, outputfile.flac, space, LADSPA, space, TAP underscore d-e-e-s-e-s-e-r.
+underscore d-e-e-s-e-r, space minus 30 space, 4,500.
+TAP DSR, TAP DSR tells it which plugin to use.
+We need to state TAP DSR twice because the first is the name of the dot s-o-file,
+and the second is the name of the plugin.
+A single-s-o-file can contain multiple filters, although in this case there's only one.
+Minus 30 is the threshold in d-b at which to start to apply the filter.
+4,500 is a frequency at hertz that the filter centers around in this case.
+The TAP web page has a table of recommended frequencies.
+These are for the male s-4,500 hertz, for the male s-h or sh- sound,
+3,400 hertz, female s-sound, 6,800 hertz, female s-h sound, 5,100 hertz.
+You will need to do some trial and error to find out what works best for you.
+2, DSing Summary DSing can be used to make minor improvements to voice quality
+by reducing certain harsh sounds which may be exaggerated by a microphone.
+If it sounds like a lot of work, you can probably simply not bother with it and not really miss it.
+Normalizing. Normalizing a signal means adjusting it to meet a specified level.
+For audio, it means adjusting the volume or sound level.
+You may wish to normalize the audio if you're recording to make it easier to listen to when reviewing it.
+The copy that you sent to HPR, however, should be the original, unnormalized version.
+Sound level is measured in two ways, d-b and l-u-f-s. I'll call the latter,
+l-f-s, although I don't know if that is the correct pronunciation for it.
+The latter is a more sophisticated way of measuring things,
+which takes into account how the human ear perceives loudness.
+I won't go into a lot of detail in that regard, other than to say that just except l-f-s as a unit of
+perceived loudness that is the international standard. L-f-s stands for loudness units reference to full scale,
+and that is part of the e-b-u-r-128 standard, where e-b-u stands for
+European broadcast union. In both cases, the measured value is a negative number,
+with number smaller and magnitude being louder, smaller magnitude being closer to zero.
+HPR will adjust the sound level for publication, but if you wish to check the audio before uploading it,
+it can help to adjust it to something close to what HPR will do, so you can listen to it
+at a volume, which most listeners will hear. In my case, full volume on the audio system input
+produced a sound level, which was much lower than a typical HPR episode. However, the volume
+level in the flag file itself can be adjusted using ff-m-peg, measuring volume level.
+First, we need to see what the volume level is for a typical HPR podcast. To do this,
+we use ff-m-peg. In this example, we are using an episode which we will simply call
+HPRpodcast.mp3. Pick an episode which you think is suitable and copy the file to the working
+directory. In the following script, we use a volume-detect filter. The text we want,
+normally outputs to standard error, so we have to do a bit of bashary to redirect this to standard
+output so that it will go through a pipe. We then grip for the string, i, colon.
+This will have the average volume level in loudness units or luffs. We then extract the number,
+giving us a target, luffs level. Ff-m-peg, space-i, space, HPRpodcast.mp3, space-filter, colon, a, space,
+e-b-u-r, 128, equals F-r-a-m-e-l-o-g, equal q-u-i-e-t, space, dash-f, space, null. That's n-u-l-l, space,
+slash-dev, slash-null, space-2, and then write angle bracket or write error, however you
+want to describe it. ampersand 1, space, pipe, symbol, space, grip, space, double quote, capital i,
+colon, double quote, space, pipe symbol, space, cut, that c-u-t, space, dash-d, colon, space,
+dash-f-2. Unfortunately, I can't find a socks feature, which handles e-b-u loudness,
+so we need to work in db instead. Here is the socks version. However, note this may not work on amp3s,
+if socks MP3 handling is not installed. socks, space, HPR podcast.mp3, space, dash-n, space,
+S-t-a-t-s, space, 2, write angle bracket or write error, however you want to describe it.
+ampersand 1, space, pipe, symbol, space, grip, space, double quote, capital r, capital m,
+capital s, space, lowercase, l-e-v, space, lowercase d, uppercase v, double quote, space,
+pipe symbol, space, r-e-v, space, pipe symbol, space, cut, that c-u-t, space, dash-d,
+double quote, space, double quote, space, dash-f-1, space, pipe symbol, space, r-e-v.
+You can use either of these for measuring the volume or sound level of an audio file. However,
+note that individual episodes from HPR may vary a bit in terms of loudness. In the samples
+that I looked at this, however, was less than 1 L-u-f-s or 1 db, while my own recording was roughly
+5 L-u-f-s lower in volume than a typical HPR episode. If you Google for the EBUR 128 standard,
+the AI result will confidently tell you to use a target of minus 23 L-u-f-s. However,
+this is wrong, and which shouldn't be of any surprise if you're familiar with using AI.
+The minus 23 L-u-f-s figure is for broadcast television. There is in fact no standard level
+for podcasts. However, there is apparently a general industry convention of using
+somewhere around minus 17 L-u-f-s. If I look at the first two HPR episodes that I did,
+HPR normalized them to minus 16.8 L-u-f-s and minus 17.8 L-u-f-s,
+while the original flag files that I submitted were minus 21.6 L-u-f-s and 22.3 L-u-f-s respectively.
+So HPR appeared to be targeting somewhere around minus 17 L-u-f-s as well. We will therefore use
+minus 17 L-u-f-s as our target for our own copy for review purposes. The nice thing about using
+the EBU filtering FMPEG is that this is very simple. Here is the FMPEG version.
+FMPEG space-i space input file dot flag space-a-f space L-u-u-d-n-o-r-m equal capital i equal minus 17
+colon T capital T T capital P equals minus 2.0 colon capital L capital R capital A equals 7.0
+space-a-r space 4.1k space output file dot flag capital i is the L-u-f-s target. L-r-a is the
+loudness range target. The default is 7.0, so I use that. T-p sets the maximum true peak.
+The default value is minus 2.0, so I use that. With socks, things are a bit more difficult.
+There is no direct method of setting the loudness that I am aware of, so we need to measure the
+current sound level in DBE, do some calculations, and then apply that as a gain factor to the output.
+First, we need to subtract the measured DBE level from our flag file from the target DBE level
+from the HPR episode we decided to use as a sample. Bash by itself, normally, just does integer math.
+However, we would like to have at least one decimal point of resolution to work with.
+The simplest solution is to do this calculation using BC to shell arbitrary precision calculator.
+Then take this new value and use it in a volume filter. The number which we give socks is the
+amount to increase or decrease the volume by socks will then output a new file with the new volume level.
+You can now listen to this file under conditions, or close the approximating,
+what it will be like after HPR have done their own audio adjustments and normalization on it.
+This helps when listening to the file for any problems before you upload it.
+Rather than reading five lines of complex shell script to you,
+I will put a copy of it in the show notes.
+Normalization should be the last thing you do to the file.
+It should be done after any noise filtering, such as low pass, high pass, band rejected, etc.
+If you normalize first, you will be amplifying the noise as well as the desired signal.
+The exact normalization level used for review purposes doesn't matter.
+As HPR will apply their own later.
+All we are doing at this point is adjusting the volume to something which approximates
+a normal episode so you can listen to it for final review.
+When you send your file to HPR send the original unnormalized version, not the normalized version.
+When you normalize an audio signal, if you are not careful, you may introduce things which
+cause problems with later additional processing.
+HPR probably do more things to the audio signal than just normalizing and so they need the
+unnormalized file so that they can do their own normalizing last.
+If at this point you are happy with recording as is, you are ready to send the unnormalized
+version to HPR. The script to implement the features discussed in this episode will be in the show notes.
+Conclusion. In this episode we covered basic filtering using FFM peg and socks.
+We discussed what noise was and some of the origins of noise.
+We talked about the audio frequency range and the limitations of common hardware used to
+record and list the podcast. We covered basic high and low pass filters used to limit the audio
+frequency range in order to remove possible low and high frequency noise.
+We discussed specific filters to eliminate 50 and 60 hertz electrical power noise.
+We talked about DSing, what it was, why you may wish to use it and some basic DSing filter
+implementation details. We discussed normalizing what it is, why you may wish to use it
+and how it relates to podcasting conventions. In the next episode we will discuss analyzing
+audio signals to help find the sources of noise problems. We will also discuss creating filters
+to eliminate any problems that we found. In my case I had a problem with the microphones that I use
+and I described how I used filters to deal with that problem. This has been the second 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.