Podcasts about hpr

This show has been flagged as Clean by the host. In this episode Kevie does a step-by-step approach to record an episode of HPR using the FFMPEG tool on the Linux command line. Before beginning please ensure that FFMPEG is installed, it is available in the vast majority of Linux repositories. Start by making a new folder to keep all your files in and move into the new folder (these will be numerous by the end of your recording): mkdir Podcast cd Podcast To start recording audio use the command: ffmpeg -f pulse -i default file01.flac and finish the recording by pressing ctrl+c. I would recommend recording a test piece of audio to ensure that you are recording from your desired microphone and that the levels are to your liking. To listen to the audio file we use ffplay: ffplay file01.flac Once all of the files have been recorded, to reduce the need for editing I would recommend recording several short segments, we need to put these together using: ffmpeg -i file01.flac -i file02.flac -i file03.flac -i file04.flac -i file05.flac -filter_complex "[0:a][1:a][2:a][3:a][4:a]concat=n=5:v=0:a=1" filedone.flac Not that the number of sets squared brackets [] should be the same as the number of files (these start at zero) and the number after n= should be the actual number of files you wish to combine. To remove any extended periods of silence then we can use: ffmpeg -i filedone.flac -af silenceremove=stop_periods=-1:stop_duration=1:stop_threshold=-45dB filefinished.flac Please note that this is a bit flaky at the time of recording (my results have been mixed) and it will re-encode the audio file so never do this with a lossy file such as ogg or mp3 as this will reduce the quality, keep this for lossless versions such as flac or wav files. If you want to spend a bit more time editing the files and getting a better final audio file then the most effective way (but not quick) is to trim the audio from the end and beginning. Listen to the audio files and note the times of any periods of silence. As these normally are at the beginning and end, especially when we are recording in short segments then I will limit the instructions to avoid these becoming silly in length. Firstly clip off the end silences first, if you start with the beginning then it will change the starting position of the end silences. To remove audio from the end of a track use: ffmpeg -i file01.flac -vn -acodec copy -to 00:01:30 file01cut.flac In this example anything after 1 minute and 30 seconds will be removed. The edited audio file will then be saved as file01cut.flac. This method does not re-encode the audio so there is no loss of quality. To remove audio from the start of a track use: ffmpeg -ss 30 -i file01.flac -c copy file01cut.flac In the above example the first 30 seconds of the file will be removed and saved as file01cut.flac Once you have edited each audio file then they will need to be merged together again to make a complete show. Provide feedback on this episode.

This show has been flagged as Clean by the host. 01 Introduction This is a follow up to my 4 part series on simple podcasting. In this episode I will discuss a number of experiments with audio filtering. These experiments were inspired by comments by listeners and by other discussions about audio on HPR. I am not an audio expert, so I am doing this partly in order to learn something, but mainly in order to have a bit of fun. I hope that you find this entertaining as well. In a comment on the first episode a listener mentioned something called Solocast and said that the method bore a resemblance to the method that I was using. Here is his comment -------------------- 02 Comment #3 posted on 2026-04-03 07:49:58 by Reto It reminds me about Solocast Hi Whiskeyjack, I really liked your podcast and the topic. I cannot remember about your last, but the sound quality of this one was good on my mobile speakers :) The concept reminded me about the program from Norrist (another host on HPR), while similar does it have some differences HPR 3496 https://hackerpublicradio.org/eps.php?id=3496 As I am not on the future feed, I look forward to your next episode. Cheers, Reto -------------------- 03 End of comment. I did not recall having heard the episode on Solocast, but this sounded very interesting. Solocast was in HPR episode 3496 and was released by norrist on the 27th of December 2021. I listened to that episode and does indeed use use the same basic concept of recording short segments of audio and combining them later instead of creating one big recording and editing it with an audio editor. 04 The main difference is that the work flow that I described involves a lot of manual steps, while Solocast is a short Python program that automates the entire process of presenting your script, recording the segments, combining the segments, and filtering and normalizing the result. I won't try to describe Solocast in detail, instead I would recommend just listening to HPR episode 3496 to get norrist's explanation directly. -------------------- 05 While I wanted to make sure that I credited norrist with having come up with this concept four years before I did, this won't be the focus of this episode. Instead I will talk about audio filtering and various experiments that I ran on several different methods. 06 While looking at the source code for Solocast I noticed that it used a filtering method that resembled one used by Jivetalk, a podcast production program that caught the attention of one of the HPR community news presenters. This method involves taking a sample of quiet audio where there is no speaking taking place, and then using this as input to a noise reduction filter which is applied to the voice recording. The filter subtracts the quiet sample from the voice audio, which should theoretically remove the ambient noise. 07 I decided to apply this method to a number of different audio test recordings which were recorded under different circumstances using different hardware. In this way I could see if the method worked equally well under all circumstances or if there were some sorts of noise which it was suited to and some sorts that were not. 08 While I was at it, I also picked several other filter methods to see how they worked as well. Potentially, some methods may be better under some conditions while other methods were better suited to others. -------------------- 09 I won't present all of my experiments, as that would be a bit dull to listen to. Instead I will describe each method and then present audio samples which illustrate my conclusions. There are two pieces of audio software involved, both of which were also used in my series on simple podcasting. 10 The first is Sox, spelled s o x , and which is short for Sound Exchange. Sox is a command line program for audio manipulation. Sox is Free Software, released under the GPLv2 or later. The other is FFMPEG, which is also a command line program. FFMPEG is also Free Software, released under the LGPL V 2.1 or later, and GPL v 2 or later. Sox actually uses FFMPEG for certain operations. -------------------- 11 Audio Hardware For recording hardware I used the following. 12 Maxwell Headset The first is a cheap Maxwell headset that has an electrical noise problem. Unfortunately I don't have a model number for this headset. I described this hardware, the noise problems that I had with it, and how I created filters to deal with the noise in my series on simple podcasting. Briefly though, this is a headset that has a build in microphone on a boom which allows the microphone to be positioned close to the mouth. It connects with a USB cable. 13 Borne Earpiece and In-line Microphone This is a set of earplugs that go in your ears and connected by wires and a very small microphone built into a small bulge in the cable. It connects using a 3.5mm jack. The model number seems to be BUD250-BL. 14 XTrike Headset This is a gaming headset similar to the Maxwell headset described above. The model number is GH-510 It uses a USB connection. 15 Yanmai Condenser Microphone This is a microphone that comes with a small tripod stand. The model number is SF-910 It uses a 3.5mm audio jack. -------------------- 16 This is not a review of the hardware. Rather, I was trying to create audio problems so that I could test ways to fix them. Therefore, do not take the above list as a recommendation of what to buy. However, you can see that I am not using any expensive audio hardware. If you want to make an HPR podcast, you do not need professional level hardware. -------------------- 17 Audio Samples The audio samples are as follows 18 Quiet This was recorded in a quiet environment at my desk. This is my normal podcasting environment and represents optimal conditions. The main reason for this method is to see how the various filter methods perform when dealing with the electrical noise from the Maxwell headset. 19 Small fan This is a small USB powered table fan approximately 10 cm in diameter. It was located roughly 40 cm or less to the left of the microphone, although this varies depending on the microphone. 20 Traffic This was along a busy street with traffic noise in the background. -------------------- 21 Filter Methods Sox noisered Filter with Audio Profile This method uses the Sox noisered filter. Here is a brief quote from the Sox documentation on this filter. Quote Reduce noise in the audio signal by profiling and filtering. This effect is moderately effective at removing consistent background noise such as hiss or hum. To use it, first run SoX with the noiseprof effect on a section of audio that ideally would contain silence but in fact contains noise - such sections are typically found at the beginning or the end of a recording. End of quote For these tests I recorded a separate noise profile to go with each test. -------------------- 22 Basic Manual Filter This is a basic high and low pass filter pair based on the work I had done in my previous series on simple podcasting. However, based on the tests that I have done for this episode, I decided to get a bit more aggressive in terms of filtering. I use a high pass filter of 120 Hz, and low pass filter of 8 kHz. The each filter is then applied twice to increase its effect. I also added band reject filters to deal specifically with 50 and 60 Hz line noise. -------------------- 23 Complex Manual Filter This uses the manually constructed filter described in my series on simple podcasting. This uses the basic manual filter plus a series of custom bandreject filters to fix specific noise problems with the Maxwell headset. -------------------- 24 FFMPEG afftdn Filter The documentation describes this as "Denoise audio samples with FFT." -------------------- 25 FFMPEG arnndn Filter The documentation describes this as "Reduce noise from speech using Recurrent Neural Networks." -------------------- 26 FFMPEG agate Filter I will pronounce this as "agate" for convenience. The documentation describes this as "A gate is mainly used to reduce lower parts of a signal. This kind of signal processing reduces disturbing noise between useful signals." -------------------- 27 Method The experimental method used was to take each noise sample and apply the different filter methods to it. Where there are parameters which can be adjusted, a script was used to generate a series of different sample files with different parameter values. Not all possible parameters were experimented with, as the goal is to see which method produces what sorts of results under different circumstances, not to get the best possible result for the samples that I happen to have. The method in each case was as follows 28 Step 1 Convert the audio file to FLAC if it is not already in that format. 29 Step 2 Apply a basic high and low pass filter described previously to each sample. The reason for this basic filtering is that it eliminates at least some undesired noise in a fairly fool proof manner, leaving less for the more advanced filter to deal with. This should allow for a better test of the filter under realistic conditions. 30 Step 3 Apply the noise reduction filter being tested. 31 Step 4 Normalize the filtered sample to 17 LUFS according to the EBU R128 standard. The EBU standard is described in my series on simple podcasting. Normalizing adjusts the audio signal to a desired loudness level. This allows for more more consistent sound levels and allows us to hear the results under realistic conditions. I normalize the audio individually for each sample as different recording hardware requires different amounts of loudness adjustment. This is different from the typical podcast process where normalizing takes place as the very last step in the process, but it was necessary in this case. 32 Step 5 Concatenate selected sample audio files to one another to allow for better review and comparing. -------------------- 33 Results The results are grouped according to the type of noise which is being mitigated. This allows for easier comparison of the effectiveness of each technique under different circumstances. I have only picked a few examples of interest out of the numerous experiments that I conducted. -------------------- 34 Quiet Recording Environment with Maxwell Headset This compares how well the various filtering methods work on the noise induced by the electronics in the Maxwell headset. This electronic noise consisted of a noise spike every 1 kHz. This should be representative of electronic noise caused by problems in recording hardware. 35 Manual Filter The manual filter applied a narrow band reject filter every 1 kHz from 1 kHz to 12 kHz. This completely removed the otherwise audible whine caused by the noise. 36 FFMPEG afftdn This method allows for setting a noise floor and then specifying how much the noise floor should be reduced by. The method is very sensitive to getting the noise floor correct for that recording. Set the floor too low and nothing happens. Set it too high, and some distortion results. However it seemed to be moderately effective, but it would seem to require checking it and possibly adjusting it each time it is used. 37 FFMPEG agate This method allows setting a noise floor and then suppressing all sound which falls below that level. This method is very sensitive to getting the noise floor correct for that recording. If set too low (or quiet), it is ineffective. If set too high (or loud), it distorts words which come after a pause, which would typically be between sentences. 38 When set correctly, it completely removes noise in the silences between sentences. However, the noise is still audible during speech. This is because the noise in this case is a higher frequency than normal speech, and so stands out more. It may not be a significant problem for noise which is closer to the main vocal frequency band. Overall, this method is not suitable for this particular problem. 39 FFMPEG arnndn This method used the standard model. A variety of different noise reduction models are available. I only tested it with one, std.rnnn It does not seem to introduce much distortion in the voice signal even with a high amount of mix parameter. 40 However, it is only slightly effective at removing the whine from the signal, even with a high amount of mix parameter. Overall, this method does not appear to be useful for this sort of noise problem. 41 Sox noisered Filter This was effective in removing noise between words, but noise can be heard while words are being spoken. It was better than agate however. 42 Overall Conclusion for the Maxwell Headset Noise When dealing with narrow noise bands that occur at known frequencies, the manual filter is leagues ahead of any of the other tested alternatives. 43 Sample Audio Here is a sample audio recording showing the best overall results The sample is repeated, first with only basic low and high pass filtering, and then with the manually constructed filtering. In the first sample you should hear a high pitched background whine. In the second sample, the high pitched whine is completely removed. 44 (Audio sample inserted here.) -------------------- 45 Traffic Noise This was recorded using the Borne in-line microphone connected to a mobile phone while walking along beside a busy street. This was in dry cool spring weather, and the road was paved with asphalt. This should be reasonably representative of podcasting while walking outdoors in a noisy environment. 46 Basic Manual Filter This used the basic manual filter with high and low pass filters. This did nothing very useful in this case as the signal was already filtered within those limits by the recording hardware anyway. The low sample rate of 8 kHz in the phone limited the upper frequency to 4 kHz. Recall that the sample rate has to be twice the highest frequency that you want to detect. Overall, this is not suitable for this sort of problem. 47 FFMPEG afftdn With a high noise floor, background noise is reduced, but not eliminated. There was not much distortion in the voice. This is only slightly useful for this sort of problem. 48 FFMPEG agate With a high threshhold, background noise is reduced, but not eliminated. There was some distortion in the voice. The background noise could also be heard when speaking, but because the frequency of the background signal was similar to the louder voice signal, it was not as noticeable as it would have been if the two were very different. This is moderately useful for this sort of problem. It may be more useful in situations where the background noise was not quite as loud. 49 FFMPEG arnndn With high amounts of noise reduction, much of the background noise is suppressed, but there is not a lot of distortion in the voice. The background traffic noise is still present, but is significantly less. This offers only a moderate improvement. 50 Sox noisered Filter With small amounts of noise reduction voice is clear but traffic noise is present as a very significant continuous warbling sound in the background. This is no improvement on the original and in fact could be seen as making it worse. With moderate amounts of noise reduction, traffic noise is mostly gone, but there are still various squeaks present. Voice is noticeably distorted. With large amounts of noise reduction, traffic noise is gone but voice is highly distorted. This is moderately useful for this sort of problem, but requires careful adjustment. 51 FFMPEG arnndn Followed by FFMPEG agate This combined two different filters. First, it used arnndn to suppress the background noise to a lower level without much voice distortion. Then it applied the agate filter to suppress the noise levels between words still further. This used the same amount of mix and threshold as was found to be most effective when each of these filters was used on its own. The background noise is almost completely gone while distortion of the voice signal is low. 52 Overall Conclusion for Traffic Noise The arnndn combined with agate filters was the most successful at suppressing background noise while limiting the amount of voice signal distortion. 53 Sample Audio Here is an audio sample for what I felt to be the best overall results, the arnndn filter combined with the agate filter. First is the original audio with basic filtering. This is followed with the same audio after being passed through the arnndn and agate filters. 54 (Insert arnndn plus agate audio sample here) 55 Another Sample Here is a second audio sample showing the Sox noisered profile based filter. I have included this to show how a profile based filter can make things worse if you are not careful how you use it. This repeats the test audio 4 times. The first is with basic filtering only. The second uses low amounts of noise reduction. The third uses moderate amounts of noise reduction. The fourth uses high amounts of noise reduction. 56 (Insert noisered audio sample here) -------------------- 57 Small Fan Noise with Yanmai Microphone This was recorded using the Yanmai condenser microphone. A small fan was set up behind and to the left of the microphone. This is intended to represent situations where someone may have a fan or air conditioner running in the background due to hot weather, or has a loud computer fan. 58 A condenser microphone was used for this test as they are more prone to picking up unwanted noise. However, for practical recording purposes, this sort of microphone is unsuitable for this type of environment. 59 Basic Manual Filter This used the basic manual filter with high and low pass filters. This did nothing useful as the fan noise was in the same frequency range as the voice signal. This may be of more help in cases where the noise is below the 120 Hz cut off used in the low pass filter. 60 FFMPEG afftdn With high amounts of noise reduction, much of the background noise is suppressed, but there is some distortion in the voice. The background fan noise is still present, but is significantly less. Overall this is moderately effective. 61 FFMPEG agate This was effective in removing noise between words, but noise can be heard while words are being spoken. However, this was a small voice sample and it is possible that more problems could occur. With less fan noise than was in this sample this technique may work much better. 62 FFMPEG arnndn With high amounts of noise reduction, much of the background noise is suppressed, but there is not a lot of distortion in the voice. The background fan noise is still present, but is significantly less. Overall this was fairly effective. 63 Sox noisered Filter With small amounts of noise reduction voice is clear but fan noise is present as a slight warbling sound in the background. With moderate amounts of noise reduction, fan noise is gone, but voice is somewhat distorted. With large amounts of noise reduction, fan noise is gone but voice is very distorted. 64 In general this method is fairly successful at dealing with this sort of problem. However, there is a trade off between background noise and voice quality. Getting that trade off correct takes experiment and judgment for each specific situation. 65 FFMPEG arnndn Followed by FFMPEG agate This combined two different filters. First, it used arnndn to suppress the background noise to a lower level without much voice distortion. Then it applied the agate filter to suppress the noise levels between words still further. This got rid of virtually all of the background noise between words. If you listen carefully however, there is a slight buzzing sound in the voice signal. 66 Overall Conclusion for Fan Noise with Yanmai Microphone. Of the methods tested, the arnndn followed by agate filter seemed to offer the most improvement for the least effort and least voice distortion. The arnndn filter on its own seemed the next most preferable to me despite leaving some fan noise in the background. 67 Audio Sample Here is an audio sample for what I felt to be the best overall results, the arnndn filter combined with the agate filter. First is the original audio with basic filtering. This is followed with the same audio after being passed through the arnndn and agate filters. 68 (Insert audio sample here) -------------------- 69 Small Fan Noise Recorded with Headset The following is an observation rather than a filtering technique. When a recording was made using the Maxwell headset and listened to on the headset later or with speakers, the fan was virtually inaudible. When the same recording was listened to with the XTrike headset, it was barely audible with careful listening and only identifiable as a fan because I knew it was there. 70 In situations where there is ambient noise, the best noise reduction technique is probably to move the microphone as close to your mouth as possible, although not directly in front of it, and reduce the gain if there is a gain adjustment in the microphone. This will work far better than trying to remove the noise later. If you are recording an HPR episode at a desk, then an inexpensive headset with boom mike may do the job just fine with minimal effort and expense. -------------------- 71 Conclusions I have tested three noise scenarios - Electronic noise in the audio hardware at specific frequencies. Recording outdoors with an inline microphone in a noisy traffic environment. A noisy fan creating background noise in an office. My conclusions on these are as follows. 72 Electronic Noise in the Audio Hardware at Specific Frequencies If you can use Audacity or some other means to find the frequencies which are causing the noise, the best solution, assuming you don't just replace the hardware, is to manually construct filters to remove those specific frequencies. This is the safest solution in terms of only doing what you tell it to and not producing unexpected surprises some time down the road when something changed in the environment. 73 If you are looking for a fairly automatic filtering method, the Sox noisered profile based filter seems to work fairly well. There is an equivalent filter in ffmpeg, but I did not include that in my experiments as it is harder to use in a script because it does not use a separate noise profile file. 74 Recording Outdoors with an Inline Microphone in a Noisy Traffic Environment. In this situation, the FFMPEG arnndn combined with agate filters seem to be the most successful. The Sox noisered filter may work, but at the cost of more distortion in the voice than is seen in the other methods. 75 An inherent problem with any profile based noise reduction method is that if the background noise is not constant, which it seldom is in that sort of environment, the profile may not represent the background noise which is present later on in the recording. This risks adding more distortion in the voice as the profile and later environments diverge. 76 However, for this application a different microphone that provided a better recording would appear to be advisable. A solution which brought the microphone much closer to the mouth and so resulted in a better ratio of voice signal compared to background noise would appear to be necessary, after which the question of what sort of noise reduction to use would need to be re-evaluated. 77 A Noisy Fan Creating Background Noise in an Office. The Sox noisered filter and the FFMPEG arnndn, afftdn, and agate methods all work to some degree. However, they all need correct selection of parameters to achieve the proper results. When I compared all four methods side by side, I found the arnndn combined with the agate filter to be preferable in terms of the trade off between background noise reduction and distortion of the voice signal. The arnndn filter on its own seemed the next most preferable to me despite leaving some fan noise in the background. 78 However, that is a subjective judgment of a specific noise sample when recorded using a specific microphone. Keep in mind though that many listeners will not be listening in an idea environment. They may be doing things where background noise is present rather than in a very quiet room and so may find a small amount of background noise in the recording to be less of a problem than distortion in the voice signal which may make some words harder to understand. 79 When I conducted the same experiment recorded with the XTrike headset I found that arnndn seemed to offer no noticeable improvement. This may be because the amount of audible fan noise was far less with the XTrike headset to begin with. In other words, there is no single best solution here, and you may have to be prepared to try different options to see which one works in your situation. The important thing is to avoid making things worse by applying filtering that is not appropriate for that situation. The best method may be to use a recording method that doesn't pick up the fan noise to begin with. This can include just using a gaming headset with boom mic. 80 I have one final observation on this point regarding headsets. The Maxwell headset has a foam cover over the microphone while the XTrike headset does not. There was some slight audible wind buffeting noise picked up by the XTrike headset that was not observed with the Maxwell. This seemed to cause particular problems with the Sox noisered profile based filter, as this noise was irregular and after filtering would show up as a warbling sound. If you use a headset and plan to use it in conjunction with a fan, it may be advisable to apply some sort of wind cover over it. 81 Combining Complex Filters In several cases I found that combining several complex filters offered better results than using any single one on its own. The basic strategy though is to first use a method which is good at reducing undesirable noise without introducing excessive voice distortion. Then apply a different filter which is good at reducing small levels of background noise to an even lower level while affecting the voice signal as little as possible. This uses the relative strengths of different filter types to compensate for the weaknesses of the other. 82 Different combinations of filters were most effective for different types of problems. I did not try all possible combinations however. Perhaps a further exploration of this would be worth doing in a later podcast. -------------------- 83 Case Study - Noise in Another HPR Episode Audio In the comments to my second episode on Simple Podcasting (which is HPR4618) where I discussed basic filtering, a couple of listeners brought up an interesting point. Antoine mentioned "declicking" in a post. -------------------- Vance replied 84 Antoine, thanks for mentioning the click removal capability in Audacity! While I already knew about its noise removal filter, I wasn't aware it also had click removal. It might have helped me for HPR4637, where some sort of electromagnetic signal was picked up by my microphone/recorder, a Zoom H2 (the tapping sound was *not* present in the room where I recorded). While click removal does seem to distort speech when applied to it (though to my ears, it doesn't sound as weird as when noise removal is done with speech), I could have applied the filter only to the pauses, where the "tapping" is most noticeable. I will consider doing this in the event that I'm not able to eliminate the source of interference in the future, which would be the best way to go. -------------------- 85 End of quote. I found this interesting as it sounded like another audio problem that could be experimented with. I found a sample of the episode which had the clicks and cut a copy of that segment out to experiment with. These sounds are a series of clicks, or "ticks" would be another way to describe them, in the quiet part of the audio between sentences or phrases. 86 Next I used Audacity to study the sound spectrum. I found a massive 60 Hz noise spike. However, my speakers won't reproduce sound that low, and filtering this out didn't reduce the clicks. The clicks turned out to be bursts of noise across the 100 to 800 Hz band, which is right where the main vocal band also is. This makes it difficult to filter based on frequency. The most promising approach would seem to be to filter based on sound level. 87 I tried all of the individual audio filter techniques mentioned in the other experiments above. None produced satisfactory results except for agate, which makes quiet audio quieter. This completely suppressed the clicks. However, when applied to the entire episode it also distorted the start of a few sentences which began with single short syllables. 88 The agate filter has a number of parameters which could be adjusted to try to deal with these cases, although I did not spend the time to do so. Another solution to this distortion problem is to simply not apply the filter to those parts of the audio which are affected. If you record the audio as a series of small individual files, it would be easy enough to filter before concatenating the files together while skipping those files which contain audio which is not suited to this method. Here are the results of the experiments. 89 FFMPEG afftdn This reduces the size of of the ticks, but they are still present. However, they may be reduced to a level which is considered acceptable. 90 FFMPEG agate This was very effective in removing ticks with the right parameters. However, it can introduce some voice distortion in the form of cutting out the start of a few sentences which began with single short syllables. This can be corrected with a very short "attack" parameter to turn off the filter when it detects sound above a set threshhold. 91 FFMPEG arnndn This was relatively ineffective. 92 Sox noisered This was effective in removing the sounds between phrases. However, it introduces some distortion in the voice signal. 93 I also tried combining filters. FFMPEG afftdn Followed by agate This combined two different filters. First, it used afftdn to suppress the background noise to a lower level without much voice distortion. Then it applied the agate filter to suppress the noise levels between words still further. This got rid of virtually all of the background noise between words. 94 Here is a short audio sample from HPR4637. First is the unfiltered audio. Second is the filtered audio using the combined afftdn plus agate filters. Since the "clicks" are very quiet, you may not hear them unless you are in quiet environment. Quite a few listeners would probably not be aware of the perceived audio problem in this episode if it had not been discussed here. None the less, it makes for an interesting experiment. Here it is: 95 (Insert sample audio here) 96 Overall Conclusion for Noise "Ticks" The afftdn combined with agate filters seemed to offer the best overall results when used with the right parameters. However, the author, Vance, speaks very clearly and evenly, and so his voice is ideally suited for use with this filter. Another author's voice may not be as suited to this filter. 97 The Sox noisered profile based filter offers various degrees of trade off between suppressing noise and distorting the voice signal. As to whether this is an acceptable trade off depends on the particular voice in question and how easily understood it is under normal circumstances with out additional distortion. The afftdn filter may be a fairly safe filter to use on its own while producing acceptable if not perfect output. -------------------- 98 Overall Conclusions I have presented only a few of the experiments that I conducted. My overall conclusion after all of this is that there is no universal audio filtering method that works best in all circumstances. There are instead a number of tools in the toolbox, and picking the right one for the job takes a bit of trial and error. 99 However, if you have a repeatable recording environment, then once you have decided what tool you need you should create a script for it so you can have a repeatable processing setup. These conclusions apply to voice podcasting. Music has a different set of criteria and techniques that work well with basic voice podcasting may produce poor results when applied to music which has a broader range of frequency and just as importantly, a broad range of loudness. 100 If you are used to using filters and effects in Audacity, many of the settings on those correspond to arguments in the command line version of ffmpeg. It is worth learning how to use ffmpeg directly to automate your recording process. 101 The experiments that I conducted were greatly assisted by writing scripts which created multiple versions of audio files with different settings, thereby allowing me to try many different alternatives relatively easily. It also allowed me to concatenate different audio samples into a single audio file and so listen to different versions in quick succession, making subjective listening judgments more reliable. 102 It is important to keep in mind in all this that I am playing with audio filtering mainly to have fun. It is not necessary to do any of this if you think your podcast episode sounds just fine without it. So, don't let any of what I have talked about in all this discourage you from simply recording a podcast and sending it in as is. I will include copies of the filters I have described here in the show notes. -------------------- 103 Related Matters Hardware Characterization Using Audio Signals I found it useful to characterize the hardware that I had in order to understand its limitations better before starting the experiments. This involved playing a signal out through a set of speakers and then recording it through a microphone. 104 I used two types of signal for this. One is type of signal is known as a "chirp" signal. This is a sine wave that steadily increases in frequency as it sweeps across the audio spectrum. The standard audio range is 20 Hz to 20 kHz, but for my purposes I limited the upper frequency to 15 kHz to save time as anything beyond that is not very useful for voice podcasts. 105 By recording the chirp signal with a microphone and analyzing it with a Fourier transform, I could quickly see what each device was capable of. See my previous series on simple podcasting for an explanation of what a Fourier transform is and what software to use to see the results of it. Here is a chirp signal. 106 (Insert Audio Sample Here) 107 In addition to a chirp signal, I also used a series of simple tones of specific frequencies. By using these tones of known frequency I could gain an understanding of the limitations of my speakers and headphones, and just as importantly, my own ears. By understanding these limitations I was able to narrow the range of frequencies that I need to deal with quite considerably and set the high and low pass filters accordingly. These tones are a series of flac files generated with ffmpeg. 108 Here is a a sample audio tone at a 2 kHz frequency. 109 (Insert Audio Sample Here) 110 Copies of the script to create the chirp signal and the tones are in the show notes. -------------------- 111 A "Not a Review" of some of the Hardware that I Used I said that I would not do a review of the hardware that I used. However, some of it deserves mention for either how good or bad it was. I will record each section using the hardware being described. 112 Maxwell Headset This is my original recording hardware. This is a headset with boom mic and USB connection. There is no model number on it, so I don't know the model. This probably cost somewhere between 10 and 25 dollars. The earpieces sit on the ears and do not fully enclose them. This makes it light weight and comfortable to wear for extended periods of time. It has a problem however with electronic noise consisting of a noise spike every 1 kHz. I was able to fix this with a series of filters using FFMPEG. Fixing this problem is what got me started in understanding audio. I will probably continue to use this headset to make podcasts. 113 XTrike Headset, Model GH-510 This is also a headset with boom mic and USB connection. I purchased this headset for the purposes of experimentation for this podcast episode. It cost $12.88. I found it to be surprisingly good for the price. It has fully enclosed ear pieces however, which may make it uncomfortable to wear in hot weather. I may try doing some of my future podcasting using this headset. 114 Borne Earpiece and In-line Microphone This is a set of earplugs that go in your ears and connected by wires and a very small microphone built into a small bulge in the cable. It connects using a 3.5mm jack. The model number seems to be BUD250-BL. It cost approximately $3.00. I bought several sets of these and use them for listening to podcasts from an MP3 player. The ear pieces are pretty good for listening with. The microphone works reasonably well when used in a quiet location. It is less good when in a noisy environment. It is very important however to secure the microphone to your lapel or other location reasonably near your mouth and to point the microphone (that is the small hole) outwards and not simply let it dangle freely. If you let it just hang, you will get poor quality and inconsistent audio. 115 Yanmai Condenser Microphone, Model SF-910 I purchased this microphone for the purposes of experimentation for this podcast episode. It cost $3.88. As it is a condenser microphone, it is prone to picking up background noise more and as such is probably not a good choice for podcasting by single person sitting at a desk. However, it is none the less a surprisingly good microphone for surprisingly little money. 116 iCan USB Microphone, Model M-306 I purchased this microphone for the purposes of experimentation for this podcast episode. This has a USB connection. This was also relatively inexpensive at $7.99, or roughly twice the price of the Yanmai microphone. Unlike the Yanmai however, it is absolutely wretched. There was such a high degree of distortion when recording through it that I found I could not use it in the fan experiments which I had bought it for. I ended up buying the Yanmai microphone for that instead. -------------------- 117 Easy Effects Software The techniques described so far all involve recording audio files and then processing them later to produce the desired result. This is probably the simplest and most straightforward way of doing things if you are making a typical podcast. However, there may be instances where you want to apply filtering or other effects on the "live" signal immediately and not after the fact. 118 There is audio software which can hook into your computer's audio system and do this with a live signal. For Linux, there is a package called "Easy Effects". This is Free Software and comes under a GPL V3 or later license. I installed it from the Debian repository under Ubuntu 24.04. 119 You can create various filters and even chain them together to combine them. I played with it a bit but do not know enough about it to discuss it seriously at this time. However, I thought it would be worth mentioning for the sake of those who may wish to try it out themselves. -------------------- 120 Episode Conclusion After having had some fun with audio and listening to other HPR members talk about audio, I thought I would have some more fun by playing with noise reduction filters. I have no intention of becoming an audio professional, but by doing some experiments I learned a few things and had some fun doing it. I hope that the rest of you found this interest as well. I will see you all again later in another episode of Hacker Public Radio. -------------------- Scripts Basic Filter This shows basic high and low pass filters ( 120 Hz and 8 kHz respectively) and band reject filters for 50 and 60 Hz. # The high and low pass filters. hlpfil="highpass=f=120, highpass=f=120, lowpass=f=8000, lowpass=f=8000" # Band reject filters filter for 60Hz and another for 50Hz. linefil="bandreject=f=60:width_type=h:w=20, bandreject=f=50:width_type=h:w=20" # Filter using ffmpeg. ffmpeg -i inputfile.flac -af "$hlpfil, $linefil" outputname.flac # ====================================================================== afftdn Filter # noisefloor should be between 20 and 80. noisefloor=$1 # Run the noise reduction. ffmpeg -i testrec-filtered.flac -af "afftdn=nr=10:nf=-""$noisefloor" tmptestrec.flac # ====================================================================== agate Filter # threshold shoud be between 10 and 80. threshold=$1 # Run the noise reduction. ffmpeg -i testrec-filtered.flac -af "agate=threshold=-"$threshold"dB:range=-60dB" tmptestrec.flac # ====================================================================== arnndn Filter # mix should be between 0 and 1. mix=$1 # Run the noise reduction. ffmpeg -i testrec-filtered.flac -af 'arnndn=model=std.rnnn:mix='"$mix" tmptestrec.flac # ====================================================================== sox noisered Filter # Generate the noise profile from a sample of background noise. sox silencefiltered.flac -n noiseprof noise.prof # nramount shoudl be between 0 and 1 sox testrec-filtered.flac noiseout-testrec.flac noisered noise.prof "$nramount" # ====================================================================== Manual Filter for Maxwell Headset Noise # Create a series of band reject filters, from 1 kHz to 11 kHz. ftemplate="bandreject=f=%s000:width_type=h:w=100" kilospikefil=$( seq 1 11 | xargs printf "$ftemplate," ) # Using ffmpeg ffmpeg -i testrec-filtered.flac -af "$kilospikefil" tmptestrec.flac # ====================================================================== Create a "chirp" signal # Start frequency. f0=20 # End frequency. f1=15000 # Duration of signal. duration=10 ffmpeg -f lavfi -i "aevalsrc=sin(2 * PI * (0.5 * ($f1 - $f0)/$duration * t^2 + ($f0 * t))):s=44100:d=$duration" -c:a flac -af "aformat=sample_fmts=s16" chirp.flac # ====================================================================== Generate Audio Tones toneout () { printf -v freqval "%05d" $1 ffmpeg -f lavfi -i "sine=frequency=$freqval:duration=3" tmptone.flac # Normalize ffmpeg -i tmptone.flac -af loudnorm=I=-17:TP=-2.0:LRA=4.0 -ar 44.1k -sample_fmt s16 tone$freqval.flac rm tmptone.flac } # List of frequencies in hertz. freqlist="50 60 100 120 130 140 150 160 170 200 500 1000 2000 3000 4000 5000 6000 7000 8000 9000" for freq in $( echo $freqlist ); do toneout $freq done # ====================================================================== Provide feedback on this episode.

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. Most users of UNIX-like systems are probably familiar with the diff utility. It is widely used with source code to compare two files and see what the differences are between them. Non-programmers, like me, also use it to examine what has changed in different versions of scripts or configuration files. Quite a few pieces of newer software can compare different versions of data and express changes in a format either identical to or similar to diff output. However, there are two other long-standing tools for this purpose that are far less known and deserve in my view to be termed UNIX Curios. The first of these is cmp 1 . While diff is primarily intended to be used on text files and compares them line by line, cmp compares files byte by byte. In my experience, its main use is to see whether two binary files are in fact identical—if they are, cmp outputs nothing and returns an exit status of 0. Back when methods of transferring files were not as reliable as they are today, this was a tool I would reach for sometimes. For example, you could use it to confirm that the data on a CD-ROM you burned was the same as the original. If there is a difference between the files, cmp will return an exit status of 1. By default, it will also print the location (byte and line number) of the first differing byte. When used with the -l option, it will print the location and value of every byte that differs. There is one exception to these: if the files are the same except that one is shorter than the other, it will print a message to that effect. The exit status will still be 1 in that case. Using the -s option with cmp will cause it to be totally silent and output nothing. Only the exit status will indicate whether the files are the same, different, or if the exit status is greater than 1, that an error occurred. This makes it useful for scripting, for example in case you wanted to confirm that a file copied to another location arrived fully intact. It is worth noting that diff is also capable of comparing binary files—however, it is not required by POSIX to report what is actually different or where differences occur. The same exit status as in cmp is returned: 0 if the files are the same, 1 if they are different, or greater than 1 if an error occurred. While many implementations offer an option to suppress the output, this is not in the standard 2 so the most portable method would be to instead redirect output to /dev/null . On my system the diff utility is three times the size of cmp , so if you don't need its extra capabilities, it is a less efficient way of doing the job. The other UNIX Curio for today is comm , and this utility 3 is also intended to compare two files to see what is common between them. Ken Fallon briefly talked about it a few years ago in HPR episode 3889 . Compared to the others, it has a much more specific use case. The two files are expected to be text files that are already sorted. What comm will do is print a tab-separated list of all the lines appearing in either or both files. Lines only in the first file will appear in the first column, lines only in the second file will be in the second column, and lines in both files will be in the third column. Any combination of the options -1 , -2 , and -3 can be used with comm to suppress printing of the first, second, or third column respectively. Using all three options at the same time is supported but it results in no output, so that isn't very useful. Unlike the other utilities, the exit status of comm doesn't tell you anything about the two files. It will be 0 if the program ran successfully, and greater than 0 if it didn't. I'm not sure if I have ever actually used comm for anything practical. I find its default output a bit difficult to meaningfully interpret, plus you need to ensure the two files are already sorted. It seems to be best suited to comparing lists, and one use case that Ken Fallon mentioned would be comparing two lists of files to see if any are missing. The command comm -3 listA listB would print files that only appear in listA in the first column and those only in listB in the second column. This would let you ignore all the filenames that appear in both and focus on those that were absent from one or the other. If on the other hand you only wanted to see the filenames that are on both lists, comm -12 listA listB would give you that. Some more frivolous potential uses also come to mind. If for some reason the cat utility is broken on your system, you could use comm listA /dev/null to print the file listA instead. If you want to insert tab characters before every line of a file but have an aversion to using sed or awk , then comm /dev/null listA would output listA with one tab before each line, and comm listA listA would insert two tabs. A bit silly, but it would work. The GNU implementation of comm even lets you choose something other than a tab to separate the columns 4 , so you could go wild with that. According to the POSIX specifications for cmp and comm , one of the two filenames given as arguments, but not both, can be a " - ", in which case standard input will be used for that "file" in the comparison. Also, the results are undefined if both arguments are the same FIFO special, character special, or block special file. Some implementations might not have these limitations, but you shouldn't rely on that everywhere. All three of these were developed quite early. The cmp utility appeared in 1971's First Edition UNIX 5 , while comm and diff seem to have made their debut in Fourth Edition UNIX 6,7 from 1973. The original versions might not have behaved exactly like their modern counterparts, and newer implementations (especially of the diff utility) have acquired additional options and capabilities, but the basic operation of each has stayed the same. The next time you need to compare files against each other, consider whether cmp or comm might be appropriate before automatically reaching for diff . They all have their uses in different situations. References: Cmp specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/cmp.html Diff specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/diff.html Comm specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/comm.html GNU coreutils manual: comm https://www.gnu.org/software/coreutils/manual/html_node/comm-invocation.html First Edition UNIX cmp manual page http://man.cat-v.org/unix-1st/1/cmp Fourth Edition UNIX comm manual page https://www.tuhs.org/cgi-bin/utree.pl?file=V4/usr/man/man1/comm.1 Fourth Edition UNIX diff source https://www.tuhs.org/cgi-bin/utree.pl?file=V4/usr/source/s1/diff1.c Provide feedback on this episode.

This show has been flagged as Clean by the host. HPR and Glasses HPR community members are nerds We know from movies that nerds wear glasses We can conclude that HPR community members wear glasses Cleaning Background I have very oily skin and am constantly smudging my glasses All lenses wipes are too small. I accidentally touch the lenses with my fingers when I am trying to clean them And smudge them up again I heard an eye doctor say, the best way to clean glasses is with dish soap and dry with a microfiber cloth I tried this method It is a great solution because you wash glasses and fingers tips at the same time Cleaning Method Hand soap is OK to use on glasses. get the soap on you fingertips Then hold your glasses one of the lenses Use your thumb and finger tips to clean the glasses the soap removes the excess oil from your fingertips no smudges when you dry with the microfiber cloth Progressives With regular progressives the top of the lenses is for distance vision and the bottom of the lenses is for up close vision There is a zone in the middle for medium distance, but it is very narrow Using a computer at work I kept having to move my head up and down to find the best position for working. Computer Glasses have more space for intermediate distances From https://iotlenses.com/blog/eight-types-of-progressive-lenses.html Computer progressive lenses, also known as occupational designs or enhanced readers, are optimized for intermediate and near vision, making them ideal for tasks like prolonged computer work or activities at mid-range distance Provide feedback on this episode.

This show has been flagged as Explicit by the host. New hosts There were no new hosts this month. Last Month's Shows Id Day Date Title Host 4630 Fri 2026-05-01 Playing Civilization V, Part 11 Ahuka 4631 Mon 2026-05-04 HPR Community News for April 2026 HPR Volunteers 4632 Tue 2026-05-05 Hackerpublic Radio New Years Eve Show 2026 Episode 6 Honkeymagoo 4633 Wed 2026-05-06 Ham Radio Licence Lee 4634 Thu 2026-05-07 Upgrade Failsause operat0r 4635 Fri 2026-05-08 What did I do at work today? Part 3 Section 1 Lee 4636 Mon 2026-05-11 7 seconds memory Antoine 4637 Tue 2026-05-12 UNIX Curio #6 - at and batch Vance 4638 Wed 2026-05-13 Simple Podcasting - Episode 3 - Analyzing and Filtering Whiskeyjack 4639 Thu 2026-05-14 NLUUG Spring Conference 2026 Ken Fallon 4640 Fri 2026-05-15 Robert A. Heinlein Ahuka 4641 Mon 2026-05-18 Technical Dutch Open Source Event (T-DOSE) Ken Fallon 4642 Tue 2026-05-19 Hackerpublic Radio New Years Eve Show 2026 Episode 7 Honkeymagoo 4643 Wed 2026-05-20 HPR Beer Garden 13 - Triple IPA Kevie 4644 Thu 2026-05-21 Response to comments on HPR4424: Newsboat... Archer72 4645 Fri 2026-05-22 ZERO HOUR: FRIDAY AFTERNOON APK HACKING operat0r 4646 Mon 2026-05-25 Mobile Gaming Elsbeth 4647 Tue 2026-05-26 UNIX Curio #7 - Compression Vance 4648 Wed 2026-05-27 Simple Podcasting - Episode 4 - Audio Analysis Fun Whiskeyjack 4649 Thu 2026-05-28 What did I do at work today? Part 3 Section 2 Lee 4650 Fri 2026-05-29 Playing Civilization V, Part 12 Ahuka Comments this month Past shows hpr4424 (2025-07-17) "How I use Newsboat for Podcasts and Reddit" by Archer72. أحمد المحمودي said: "How did I find HPR" (2026-05-12 17:16:07) candycanearter07 said: "Re: How did I find HPR" (2026-05-12 19:36:04) hpr4502 (2025-11-04) "Cheap Yellow Display Project Part 3: Reverse beacon network " by Trey. Archer72 said: "Morse code" (2026-05-19 15:00:39) hpr4567 (2026-02-03) "Movie Recommendations for Hackers" by Deltaray. Antoine said: "Some watched!" (2026-05-27 03:33:12) hpr4587 (2026-03-03) "UNIX Curio #1 - Shell Archives" by Vance. Dave Morriss said: "Great reminder! I had forgotten shar" (2026-05-07 18:18:05) Vance said: "Color printing" (2026-05-08 22:02:23) hpr4607 (2026-03-31) "UNIX Curio #3 - basename and dirname" by Vance. Vance said: "Correction" (2026-05-12 01:03:12) hpr4618 (2026-04-15) "Simple Podcasting - Episode 2 - Basic Filtering" by Whiskeyjack. Henrik Hemrin said: "Generating sine wave" (2026-05-14 19:59:46) Whiskeyjack said: "Reply to Henrik Hemrin on Sine Waves in HPR4618" (2026-05-15 15:22:16) hpr4627 (2026-04-28) "UNIX Curio #5 - Faster, Pussycat! Kill! Kill!" by Vance. Steve Barnes said: "Thanks for the context!" (2026-05-21 05:28:05) hpr4628 (2026-04-29) "Nuclear Power Technology Follow Up" by Whiskeyjack. Antoine said: "o/" (2026-05-17 00:24:23) Whiskeyjack said: "Reply to Antoine on HPR4628" (2026-05-17 18:08:18) This month's shows hpr4631 (2026-05-04) "HPR Community News for April 2026" by HPR Volunteers. Whiskeyjack said: "Response to Ken Fallon in HPR4631 Community News" (2026-05-04 05:13:02) candycanearter07 said: "new episodes" (2026-05-04 18:47:39) Ken Fallon said: "new candycanearter07 episodes" (2026-05-05 09:00:00) أحمد المحمودي said: "Thanks for the encouragement" (2026-05-12 17:18:20) hpr4634 (2026-05-07) "Upgrade Failsause" by operat0r. YourName said: "Why is the audio so bad OMG sorry" (2026-05-06 20:05:43) Ken Fallon said: "Already reported and fixed" (2026-05-06 20:35:49) hpr4637 (2026-05-12) "UNIX Curio #6 - at and batch" by Vance. candycanearter07 said: "still useful!" (2026-05-13 03:43:37) norrist said: "at for scheduled reboots" (2026-05-16 19:41:04) Vance said: "Good points" (2026-05-17 03:03:47) Whiskeyjack said: "At and batch in HPR4637" (2026-05-17 18:35:11) hpr4640 (2026-05-15) "Robert A. Heinlein" by Ahuka. Antoine said: "Nice tips" (2026-05-17 00:22:01) Kevin O'Brien said: "I enjoyed doing it" (2026-05-17 19:14:19) hpr4646 (2026-05-25) "Mobile Gaming" by Elsbeth. candycanearter07 said: "my opinion of mobile gaming" (2026-05-27 00:24:58) hpr4647 (2026-05-26) "UNIX Curio #7 - Compression" by Vance. xmanmonk said: "Great Series" (2026-05-27 00:29:32) candycanearter07 said: "thoughts" (2026-05-27 13:20:13) Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2026-May/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Provide feedback on this episode.

This show has been flagged as Clean by the host. 01 This is the fourth episode in a four part series on simple podcasting. 02 Introduction In this episode we will discuss alternatives to Audacity when it comes to analyzing audio spectrums to find the sources of unwanted noise. I previously promised some gratuitous hackery, and we will get into that in this episode. 03 Recall that with Audacity you first import the audio file, then select the part of the audio you wish to analyze (or ctrl-A for all), and then select analyze > plot 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. 04 We can accomplish the same thing that Audacity does in this instance provided we can 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. -------------------- 05 Fourier 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 Transforms 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. 06 A Fourier Transform finds these sine waves and sorts them out into separate bins, with each bin representing an individual frequency or a collection of closely related frequencies, depending on how fine grained the sorting is. 07 This is exactly what we want when we are trying to figure out how to filter out noise. Recall that earlier in this series we had to solve a problem with a high pitched background noise which was originating in my cheap microphone. Analyzing this audio by frequency showed that it was a series of individual tones at 1 kHz intervals. We were then able to use filters targeted at those frequencies to get rid of that noise. 08 There are several optimized versions of the Fourier Transform algorithm. A very common one is the Fast Fourier Transform, common 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. 09 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 4096, 8192, or 65536, 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, the finer the resolution we get in terms of frequency. 10 If we assume we are dealing with flac files recorded at a 44.1 kHz sample rate, that is, 44100 samples per second, then if we have 32768 samples, each "bin" represents slightly more than 1 hertz. If we have 65536 samples, then each "bin" represents a fraction of a hertz. For our purposes we will pick 65536 samples. That means we need 1.48 seconds of data. For simplicity's sake we will record at least 2 seconds of data and then just discard the samples that we don't need. 11 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 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. -------------------- 12 Extracting Data from Audio Files First we will look at how to extract the data from the audio files. Fortunately, one of the programs which we have already been using can do this. To do this we will use Sox. I am not aware of an equivalent feature in ffmpeg. 13 Sox calls itself "SoX - Sound eXchange, the Swiss Army knife of audio manipulation" Sox is free software and is licensed under the GPLV2 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 data we just give the output file a ".dat" file extension and Sox will do this for us. 14 Here is a command example. sox inputfile.flac tdata.dat 15 This gives us a file in the following format, assuming this is a mono audio recording. ; Sample Rate 44100 ; Channels 1 0 0.045471191406 2.2675737e-05 0.055023193359 4.5351474e-05 0.048217773438 6.8027211e-05 0.053192138672 etc. 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. Column 1 is the time in seconds. Column 2 is the waveform data point. 16 To analyze the data we want a subset of these samples. When we convert from the 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 the sampling rate. We also want the samples 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, 44,100 Hz. This number would be 65536. 17 To extract this data from the file we can do the following. tail tdata.dat -n+3 | head -n65536 | awk '{printf "%sn", $2}' > tdata.csv 18 We use tail to skip over the first three lines. We use head to take the next 65536 lines and discard the rest. We use awk 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. -------------------- 19 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 Libre Office Calc, and a more complex but more complete one using GNU Octave. 20 Using Libre Office We can do fourier analysis and plot charts using Libre Office. Take the csv file of data that we previously created. For this example I used data from a recording of silence so that I could see what internal noise was being generated by the headset. Open the csv file and import it into Libre Office Calc. 21 Now select all 65536 rows of column A. The Fourier function will automatically fill the imaginary component with zeros if we don't provide an column of imaginary numbers, so we don't need to provide a column of zeros. Then select Data > Statistics > Fourier Analysis. 22 A window will open allowing you to select various parameters. For Results to:, enter "D1". Grouped by Columns. Select OK. 23 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 4. 24 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. 25 Each cell is a "bin" of frequencies. Each cell therefore represents (sample frequency) / (Number of samples) Hz. 26 To create the X axis data showing frequency, enter the following formula in to column C to the left of each D column number. =((44100/65536) * (ROW() - 4) 27 We can now create an XY chart showing the frequency analysis. You may need to exclude the first couple of dozen rows as very low frequency components which cannot be heard may otherwise overwhelm 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. 28 Because characterizing a sine wave requires a minimum of 2 points, although we have a sample frequency of 44.1 kHz, we really only have sound waves up to a maximum of half that, or 22.05 kHz. Create the chart with lines only. If you followed the above instructions, you should see something resembling what we saw in Audacity, except with each bin more sharply defined. 29 In the data that I had from a recording of unfiltered headset noise, I could see a distinct noise spike every 1000 hertz. 30 However, we have taken several shortcuts. First, the imaginary component of the data was ignored. Second, the magnitude (that is, 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. 31 We could refine this spreadsheet a bit more to deal with the above issues, but I think we have demonstrated the basic principle, and working with a spreadsheet can be a bit awkward. However, if working with a spreadsheet is what you want to do, then you can add more columns and more formulae to improve on it. -------------------- 32 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 these themselves. 33 Grace There is math and plotting software called Grace. This is free software, released under the GPL V2. 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. 34 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. 35 Command Line FFT Packages There are several command line FFT packages. They will read data from std 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 they were a bit out of scope for discussion here as I am looking at common tools that are ready to use. 36 Here are two examples. One is Command-line Fast Fourier Transform utility https://github.com/gregfjohnson/fft Another is cli-fft https://github.com/jonolafur/cli-fft 37 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 that this too was out of scope for what I was trying to do here. 38 Doing it the Hard Way Hypothetically, it may be possible to write an FFT function in bash bc, which is the 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 I don't have the time at the moment to try it. If anyone feels motivated to give it a try, they're welcome to give it a go and then do a podcast episode on it. -------------------- 39 GNU Octave We have seen that as well as using features built into Audacity to analyze the audio spectrum to see the frequencies of undesired noises, we were able to do the same using a Libre Office spreadsheet. 40 Now we'll look at another bit of software, GNU Octave. GNU Octave is free software, licensed under the GPL V3 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. 41 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. -------------------- 42 We will take the same audio test file that we used with Audacity and Libre Office and use it here as well. The bash script to convert the flac file to text data is essentially the same, with the exception that file extension on the output file as is ".txt" instead of ".csv". This latter change was an arbitrary decision on my part. 43 As a quick review, this bash script uses sox to convert a flac file to a text ".dat" file. Then it uses tail, head, and awk to extract the first 65536 rows of data, skipping over the header information and ignoring the first column of time data. This script will be in the show notes. -------------------- #!/bin/bash # This version is for use with the GNU Octave script. sox hsnoisemono.flac hsnoisemono.dat tail hsnoisemono.dat -n+3 | head -n65536 | awk '{printf "%sn", $2}' > hsnoisemono.txt -------------------- 44 We now have a 1.1 MB file containing 65536 samples of data in text format. Now the next thing we need to do is to 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. 45 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 the script a ".m" ending. The "she-bang" line is "#!/usr/bin/env octave". 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. 46 I won't read out the script in detail, as that would be too hard to following 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 Y and X 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. 47 The arguments are accessed by calling the "args()" function, which returns an array of strings. Next, it reads in the specified file using the "dlmread()" function. This reads all of the data into an array. 48 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 signal sample is of finite length, it will stop at each end of the array. 49 Unless you were lucky enough for this to happen exactly at a zero crossing, this would produced an abrupt transition in 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 a variety of different windowing functions, but "hamming" seems to be the most commonly used. 50 Next, it does an FFT using the "fft()" function. 51 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 length 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. 52 Then it does some scaling and selection of subsets of data so we get the X axis in hertz and just the number of samples that we wish to look at. If you are looking at the script, the 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. 53 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 sorts of refinements than is the case for a spreadsheet so I have 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 "saveas" function. 54 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 Libre Office. The chart window doesn't have a function for exporting the resulting chart to a "png" file, it will only save to an ".ofig" file. The ofig 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. 55 Alternatively, you can just take a screenshot of the chart after you have interactively zoomed and panned to a point of interest. At the bottom left of the chart window is a pair of x-y 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. 56 The Y axis is not scaled in any particular units 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 anyway. It does show relative sizes, so it helps to determine whether you have one noise frequency or multiple frequencies to worry about. 57 If anyone is familiar with how to scale the raw data from a flac file as exported by Sox into dB units according to audio industry convention, then they are welcome to create an HPR episode telling us how to do it. -------------------- 58 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. 59 The syntax is a bit odd especially in how it deals with array operations, but I was able to google various examples and answers to eventually get this working. A few other peculiarities are that it uses the percent "%" character to denote a comment, and leaving out the semi-colon at the end of the line causes it to print the answer to the console after executing the statement. 60 The GNU Octave solution was harder to get working than the Libre 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. 61 When your run the Octave script you may get a warning which says something like "QSocketNotifier: Can only be used with threads started with QThread". This is apparently a routine warning message from the Qt graphics system which has no real significance in this context and can be ignored for our purposes. -------------------- 62 We now have a bash script which will use sox to extract the data from a flac 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" does in Audacity, but allows for zooming and panning to get a more detailed look at the data. 63 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 in the signal, something that it does quite well. -------------------- #!/usr/bin/env octave % Perform an FFT on the data in a file and plot the results. % ====================================================================== % The sampling frequency. This must be changed to accommodate the % actual sampling frequency if it was something else. samplefreq = 44100; % Thickness of line on plot. linewidth = 2; % ====================================================================== % The name of the data file is passed as a argument. args = argv(); if length(args) < 3 quit endif % File name. fname = args{1}; % Clip the peak values. peakclip = str2double(args{2}); % How much data to show, in kHz. rbound = str2double(args{3}) * 1000; % The optional file name to save a chart image to. if length(args) > 3 chartfile = args{4}; else chartfile = ""; endif % ====================================================================== % Read the data in from the file. sampledata = dlmread(fname); % Number of samples. samplecount = length(sampledata); % ====================================================================== % Window the data. This helps deal with the discontinuity of data at % each end of the array and the effects this has on introducing apparent % noise into the signal. windoweddata = (hamming(samplecount) .* sampledata); % ====================================================================== % Do the actual FFT. fftresults = fft(windoweddata); % Get real component. r = real(fftresults); % Get the imaginary component. i = imag(fftresults); % Combine the real and imaginary. In order to square each element of each % array, we must use the ".^" operator, not just "^". rfft = sqrt(r.^2 + i.^2); realfft = rfft(1:samplecount); % ====================================================================== % Scale factor for frequency. fscale = samplefreq / samplecount; % X axis scale, scaled to frequency. f = (0:samplefreq/2) * fscale; % Take a subset of the data if specified. rbound has to be re-scaled % from kHz to array increments. freq = f(1:min(rbound / fscale,length(f))); % y axis. We take the absolute value and then limit (clip) the peaks % so that a few large peaks don't obscure the smaller ones. mag = min(abs(realfft(1: length(freq))), peakclip); % Plot the results. figure; whandle = plot(freq, mag, 'LineWidth', linewidth); title(["Audio Spectrum of ", fname]); xlabel("Frequency (Hz)"); ylabel("Unscaled Magnitude"); grid on; % If the appropriate optional argument was specified, save the chart % to a file of that name. if length(chartfile) > 4 saveas(gcf, chartfile, "png"); endif % Need this so the plot window stays open. waitfor(whandle); % ====================================================================== -------------------- This is the shell script used with the above Octave script. The arguments are 1 - the file name for the input data file. 2 - The value to clip the peaks at. 3 - The upper frequency bound in kHz. 4 - The output graphics file name. #!/bin/bash octave octavespectrum.m hsnoisemono.txt 10 12 hsnoisemono.png -------------------- 64 Episode Conclusion In this episode we covered the following topics. What Fourier transforms are. Extracting data from audio files using Sox. Analyzing the data using Libre Office. Analyzing the data using GNU Octave. And, several alternative analysis methods. 65 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. 66 In the second episode we covered basic filtering and a few other simple topics. The methods discussed in that episode provide basic improvements to your audio if you feel the need for it. 67 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. 68 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. 69 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. -------------------- -------------------- Provide feedback on this episode.

Members of the US Coast Guard share weather precautions for the upcoming hurricane season; HPR speaks to one of seven high-achieving Lānaʻi graduates who earned both high school diplomas and associate's degrees.

This show has been flagged as Clean by the host. This series is dedicated to exploring little-known—and occasionally useful—trinkets lurking in the dusty corners of UNIX-like operating systems. In UNIX Curio #4 ( HPR episode 4617 ), I teased the subject of file compression. Today I'm circling back to that. The history of data compression goes back at least to the 1970s, and in contexts outside UNIX and computers, probably even earlier. Somehow, it is refreshing to learn that humans have always struggled to have enough storage space to keep all the data they want to hang on to. One way around this limitation is to use some form of compression. I am only going to dive into lossless compression for this episode—that is, a compression method that can be reversed and will spit out the original data bit for bit. Lossy compression methods also have their places: you might be familiar with their use for audio (such as Ogg Vorbis or MP3); it's also used for images (such as JPEG). Lossy compression allows some of the original data to be thrown away, resulting in a smaller file than is possible with lossless compression, but the intent is for the result to still sound or look "good enough" to a human observer. Also, I am going to limit my discussion to generic methods used for many types of data; while FLAC does lossless compression, it is specifically designed just for audio. I should make clear that I have never studied computer science or information theory, so this episode will not get into the science behind various types of compression algorithms and how they differ. But in general, these methods take advantage of the fact that many types of data have recurring patterns. English text mostly consists of words that often re-appear many times—source code similarly has keywords and variable names that recur. Compression is accomplished by representing a piece of data that occurs multiple times with a symbol that is shorter in length. The first compression program in the UNIX world I could find is called pack , from 1978 1 . It was shortly followed in 1979 by a similar program called compact 2 . Both of these used a technique called Huffman coding, but with some differences between them. Files compressed with pack were given a .z extension and compact gave filenames a .C extension. Roughly every five or ten years after this, a new program would come along and achieve lasting popularity. There were, and still are, two opposing forces facing any new form of compression. Working in favor was the advantages it provided—first among these was achieving a better compression ratio, but performance improvements such as speed or reduced memory usage could also be compelling. The force against any new method was the fact that it was not yet widely supported—it doesn't much help to have a smaller file if the people you share it with cannot decompress it. The next major advance in compression arose out of three scientific papers: two in 1977 and 1978 by Abraham Lempel and Jacob Ziv (called LZ77 and LZ78), and one by Terry Welch in 1984 which built on LZ78. This last method is typically referred to as LZW. Our UNIX Curio for today is a program called compress 3 that implements the LZW method. Files compressed this way are named with the extension .Z . I had always assumed that this was to honor Jacob Ziv, but now that I've researched the history, it seems more likely to be a follow-on from how files compressed by pack were named. Since pack did not use any of the Lempel-Ziv methods, I would guess that it used .z because that wasn't already taken by anything else, but that's pure speculation. I do recall encountering .Z files in the wild, but feel certain that hasn't happened in the last 25 years, maybe longer. If you need to expand one of these, uncompress 4 is the program to use ( GNU's gunzip can also handle them 5 ). However, there was a serious problem that arose with the LZ78 and LZW compression methods. Both of them were patented, and the owner became aggressive in seeking payment from developers and users. The compress utility was developed within two months of the publication of Welch's 1984 paper and was included in Bell Laboratories' Eighth Edition UNIX before these shakedowns started. The paper did not disclose that a patent had been filed, and apparently Spencer Thomas and the other developers of compress were unaware of it. The utility became popular for a while, and was even standardized by POSIX, but people moved away from LZW once the legal threats started. Another important advance came in 1991 and was called the DEFLATE compression method. It combined the un-patented LZ77 method with Huffman coding to achieve a similar level of compression as LZW (actually, often better) without the legal trouble. DEFLATE was developed for PKZIP and was soon adopted by the GNU project's gzip compressor. While Phil Katz (the "PK" in PKZIP ) patented one way of implementing the DEFLATE method, it was possible to write a compressor and decompressor without infringing 6 ; also, he apparently never tried to enforce the patent 7 . As I mentioned in UNIX Curio #4, .zip is both an archive and a compression format. Each archive member can be compressed with one of several possible methods (or stored without compression). Unlike a tar file where compression can be applied to the entire archive, in .zip each archive member is compressed individually. This often means a .zip file will be slightly bigger than a tar file with the same contents compressed with gzip , because the .zip format cannot take advantage of duplication that occurs among more than one member of the archive. The vast majority of .zip files use only the DEFLATE and uncompressed storage methods and these are the only options if you want to follow the profile standardized in ISO/IEC 21320-1. Actually, since they both use DEFLATE, gzip is able to extract a .zip file in the special case where it only holds one member compressed with that method. From the 1990s onward, people paid significant attention to avoiding patent landmines, so only methods that didn't have that problem became broadly popular. While the patents on LZ78 and LZW have since expired, I feel like their most successful legacy was in discouraging people from using those methods, leading to DEFLATE taking the popularity crown. The next step came in 1996 and 1997 with the development of bzip and bzip2 by Julian Seward. The original method was quickly followed by bzip2 , which was the version that achieved true popularity. They use the Burrows-Wheeler transform, which does not itself compress data but re-arranges it to make it more compressible; this is combined with other techniques 8 . (At least, that's my understanding. I told you, I'm not up on information theory.) This provides a significant reduction in the compressed size of the data compared to earlier methods—however, it is slower than DEFLATE both during compression and decompression. Separate projects have developed parallel versions of gzip and bzip2 that can take advantage of multi-processor machines, but the original utilities run single-threaded. Another five years later, in 2001, Igor Pavlov added the Lempel-Ziv-Markov chain algorithm (LZMA), an enhancement to LZ77, to his 7-Zip compression tool. This was followed a few years later by LZMA2, a container format that allowed for LZMA compression to be split between multiple threads. Broad LZMA2 support came to the UNIX world in 2009 with the xz utility 9 . It offers roughly similar compression ratios to bzip2 , though it can be better or worse depending on the data to be compressed. While compression generally takes even longer than bzip2 , decompression is significantly faster (though still not as fast as gzip ). The Linux kernel relatively quickly supported booting from xz-compressed images 10 because it was a good match for that use case—compression, the time-consuming activity, only has to be done once while the more frequent decompression during boot happens relatively fast. The last method I will cover is Zstandard 11 , often written as zstd . This came about in 2015, and is another variation on LZ77 that uses finite-state entropy (which means nothing to me, but you might understand it). It performs about as well as DEFLATE in terms of compression ratios, but is much faster both when compressing and decompressing data. I should say that these statements are true with the typical default settings—depending on the compression level selected, it can compress more slowly, but compress the data smaller. However, decompression is always speedier than DEFLATE. This makes it attractive for some uses, and it is heavily promoted by Meta/Facebook, where Yann Collet developed it. For example, shipping large amounts of actively-used data between machines in a data center can go more quickly when the size is reduced; however, if the compression and decompression steps take too long that benefit is lost. A speedy method can be valuable even if it doesn't result in the greatest reduction in size. This use case stands in contrast to, say, a compressed backup file which might only be accessed in a disaster recovery scenario or never accessed at all, making size more important than speed. Both the xz and zstd utilities have some built-in support for multi-threading, but the default is to run in a single thread. While xz can use multiple threads for decompression (but only if the file was compressed in multi-thread mode), the reference zstd utility can only use more than one thread for compression, not decompression. There are many other methods of lossless compression that have been developed over the decades, but I believe these are the ones you are most likely to encounter in the world of UNIX-like systems. This is a personal opinion, and others might choose a different set. As mentioned, it can be tough for a new method to gain popularity and 35-year-old DEFLATE is still probably the most commonly used despite not being the fastest or offering the greatest reduction in size. Even systems like FreeBSD, NetBSD, and OpenBSD that do not like to include GNU tools supported it by developing their own version of gzip based on the permissively-licensed zlib library. Technically, the LZW method used by the compress utility is still standardized by POSIX, so one might expect it to have the widest support. However, aggressive patent enforcement discouraged adoption, especially by Free and Open Source Software systems—even though the patent has expired, it is still out of favor compared to DEFLATE. For this reason, I feel justified in calling it a curio. References: Eighth Edition UNIX pack.c https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/src/cmd/pack/pack.c 2.9BSD compact.c https://www.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/ucb/compact/compact.c Compress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/compress.html Uncompress specification https://pubs.opengroup.org/onlinepubs/009695399/utilities/uncompress.html GNU Gzip manual https://www.gnu.org/software/gzip/manual/gzip.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 https://tools.ietf.org/html/rfc1951 History of Lossless Data Compression Algorithms: The Rise of Deflate https://ethw.org/History_of_Lossless_Data_Compression_Algorithms#The_Rise_of_Deflate bzip2 https://en.wikipedia.org/wiki/Bzip2 XZ Utils https://en.wikipedia.org/wiki/XZ_Utils 2.6.38 merge window part 2 https://lwn.net/Articles/423541/ zstd https://en.wikipedia.org/wiki/Zstd Appendix The table below demonstrates the results of compressing different types of data using tools described in this episode. While not totally rigorous, I did run each compression and decompression multiple times to ensure I was getting consistent results. The laptop I used has an Intel Core i5-6200U CPU running at 2.30GHz, and the system had at least 5 GB of free memory for each run. While this processor has two cores and can run four simultaneous threads, all utilities were run single-threaded. The term "best" means the highest level of compression available (the exact level used is shown). For bzip2 , the default is the best. For zstd , "best" is -19, which is the highest "normal" level, but "ultra" levels that are even higher also exist. Ratios are the percentage of the original size that the file was reduced to (other sources might instead express the compression ratio as the reduction in size achieved). In all results, smaller numbers are better. ┌────────────────────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┬─────────────┐ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ ├──────────────┬─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 22,036,508 │ 21,891,623 │ 15,795,698 │ 13,487,768 │ 12,938,464 │ 20,454,657 │ 13,709,078 │ │ │ │ (24%) │ (24%) │ (17%) │ (15%) │ (14%) │ (23%) │ (15%) │ │English Text ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(90,532,092 │Compression │ 4.8s │ 7.6s │ 8.5s │ 49.8s │ 58.8s │ 0.6s │ 65.2s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 0.7s │ 0.8s │ 3.7s │ 1.2s │ 1.2s │ 0.4s │ 0.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 125,291,122 │ 124,189,544 │ 98,016,512 │ 84,882,492 │ 81,954,344 │ 120,604,855 │ 87,298,645 │ │ │ │ (21%) │ (21%) │ (17%) │ (14%) │ (14%) │ (20%) │ (15%) │ │Source Code ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(590,008,320 │Compression │ 22.0s │ 39.3s │ 54.8s │ 241s │ 298s │ 3.7s │ 348s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 5.1s │ 5.1s │ 20.3s │ 8.1s │ 7.8s │ 2.4s │ 2.4s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 32,830,905 │ 32,371,241 │ 26,856,579 │ 20,717,288 │ 20,352,880 │ 28,538,810 │ 23,154,582 │ │ │ │ (19%) │ (19%) │ (16%) │ (12%) │ (12%) │ (17%) │ (13%) │ │Binary Program├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(171,972,264 │Compression │ 6.4s │ 22.4s │ 18.6s │ 62.2s │ 67.8s │ 0.8s │ 111s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 1.5s │ 1.5s │ 5.6s │ 2.3s │ 2.3s │ 0.7s │ 0.7s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Size (ratio) │ 146,397,772 │ 146,397,757 │ 144,485,451 │ 131,950,232 │ 130,926,780 │ 147,154,979 │ 145,703,840 │ │ │ │ (89%) │ (89%) │ (88%) │ (80%) │ (80%) │ (90%) │ (89%) │ │WAVE Audio ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │(164,396,302 │Compression │ 9.2s │ 9.2s │ 25.1s │ 70.4s │ 97.7s │ 0.7s │ 58.3s │ │bytes │time │ │ │ │ │ │ │ │ │uncompressed) ├─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │Decompression│ 2.0s │ 2.0s │ 13.5s │ 12.2s │ 12.1s │ 0.6s │ 0.8s │ │ │time │ │ │ │ │ │ │ │ ├──────────────┴─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┼─────────────┤ │ │ gzip │ gzip │ bzip2 │ xz │ xz │ zstd │ zstd │ │ │(default -6) │ (best -9) │ (-9) │(default -6) │ (best -9) │(default -3) │ (best -19) │ └────────────────────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┴─────────────┘ English text consists of Titles 1 through 10 of the 2020 U.S. Code of Federal Regulations . Source code consists of a tar file containing the Linux kernel source, version 4.0. Binary program consists of an ELF-format executable of the pandoc application, version 2.17.1.1 found on Debian 12. Audio consists of a 24-bit Signed Integer PCM WAVE file with 2 channels at 44.1kHz, about 10:21 in length. For comparison, the audio-specific flac lossless compression utility reduced this file to 97,962,711 bytes (60%) in 2.6 seconds at the default (-5) level and to 97,714,876 bytes (59%) in 5.4 seconds at the highest (-8) level. Provide feedback on this episode.

This show has been flagged as Clean by the host. Hi this is your host, Archer72 for Hacker Public Radio. In this episode I share some of my findings about a problem with the Newsboat naming of the HPR feeds, which was brought up in comments about my Newsboat show, HPR4424. hpr4424: How I use Newsboat for Podcasts: comment #6 : download-filename-format for HPR podcasts Ken already had some findings of his own about the ccdn.php extension in the feed. hpr4424: comment #10 : Summary of findings I thought that this might be able to be fixed on an invididual basis, and set out to ask Claude.ai a few questions. But first, some colaboration from Dave Morriss about a good renaming format. This was definitely more on Dave's side than mine, but came up with this. You can tell Dave's handywork from the short variable names, which stems from his extensive experience on Unix type machines in the University days. exif-rename-hpr-dave.sh #!/bin/bash URL="$(cat /tmp/hpr-url.txt)" echo "DEBUG URL: $URL" >> /tmp/hpr-debug.log AUDIO_URL="$(curl -s "$URL" | grep -Eo 'https?://[^"]*.(ogg|mp3)' | head -1)" echo "DEBUG AUDIO: $AUDIO_URL" >> /tmp/hpr-debug.log if [[ -z "$AUDIO_URL" ]]; then echo "ERROR: Could not find audio URL from: $URL" >> /tmp/hpr-debug.log exit 1 fi # Changed destination to HPR-queue DEST=~/podcasts/hub.hackerpublicradio.org/HPR-queue/ # Record files present before download BEFORE="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" wget -nc --content-disposition -P "$DEST" "$AUDIO_URL" cd "$DEST" # Record filename just downloaded (new file not in BEFORE) AFTER="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" DOWNLOADED="$(comm -13 /dev/null | sort)" RENAMED="$(comm -13 /tmp/hpr-url.txt && ~/bin/download-and-rename-hpr.sh"; open-in-browser ; set browser "your-normal-browser" A few Claude questions later… After asking to add a function to the macro in order to add the resulting downloaded file to the queue, the file name hpr1234.ogg was being added to the queue instead of the renamed file. Two things to fix: The renamed file isn't being found because ls -t runs before the rename has fully settled, or the glob isn't matching the new filename format (which includes spaces and semicolons) The existing queue entries show the correct format: "url" "path" downloaded — we need to match that, with downloaded status and the full renamed path including extension Exif rename script #!/bin/bash # ~/bin/download-and-rename-hpr.sh URL="$(cat /tmp/hpr-url.txt)" echo "DEBUG URL: $URL" >> /tmp/hpr-debug.log AUDIO_URL="$(curl -s "$URL" | grep -Eo 'https?://[^"]*.(ogg|mp3)' | head -1)" echo "DEBUG AUDIO: $AUDIO_URL" >> /tmp/hpr-debug.log if [[ -z "$AUDIO_URL" ]]; then echo "ERROR: Could not find audio URL from: $URL" >> /tmp/hpr-debug.log exit 1 fi DEST=~/podcasts/hub.hackerpublicradio.org/HPR-newsboat-test/ # Record files present before download BEFORE="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" wget -nc --content-disposition -P "$DEST" "$AUDIO_URL" cd "$DEST" # Record filename just downloaded (new file not in BEFORE) AFTER="$(ls "$DEST"*.{ogg,mp3} 2>/dev/null | sort)" DOWNLOADED="$(comm -13 /dev/null | sort)" RENAMED="$(comm -13 /tmp/hpr-url.txt && ~/bin/download-and-rename-hpr.sh"; open-in-browser ; set browser lynx Provide feedback on this episode.

HPR's Bill Dorman reports on the historic summit between President Donald Trump and China's Xi Jinping; UH Mānoa's eSports team discusses their recent championship win.

HPR's Savannah Harriman-Pote reports on the state's decision to cut tax credits for renewable energy; muralist Todd “Estria” Johnson shares more about his murals help enrich keiki and the community.

This show has been flagged as Clean by the host. NLUUG Spring Conference 2026 "NLUUG is the association of (professional) Open Source and Open Standards users in the Netherlands" You can follow them on @nluug@nluug.social on Mastodon. I was particularly interested to attend their 2026 Spring Conference 2026 as our own Jeroen Baten was giving a talk on "Getting started with CI/CD using Forgejo Actions and why this is important AF" He assures me he will post it as a show. cough owes me a show cough . While there the urge to record came upon me, so I was able to snag a few interviews. Ronny Lam representing NLUUG NLUUG is the association for (professional) developers, administrators and users of UNIX/Linux, Open Source, Open Source, Open Systems and Open Standards in the Netherlands. The NLUUG community includes, system administrators, programmers and network specialists. If you are working as an open professional, then NLUUG is the excellent association where you can keep track of your technical knowledge, for example during our six-monthly conferences. The aim of NLUUG is to disseminate the application and knowledge of open standards and UNIX/Linux. NLUUG maintains close ties with many organizations and individuals who pursue the open mind. https://nluug.nl/organisatie/personen/ronny-lam/ https://nl.wikipedia.org/wiki/NLUUG https://nluug.nl/ Nico Rikken representing the FSFE The Free Software Foundation Europe is a charity that empowers users to control technology. Software is deeply involved in all aspects of our lives. Free Software gives everybody the rights to use, understand, adapt, and share software. These rights help support other fundamental rights like freedom of speech, freedom of press, and privacy. Learn more While we are no strangers to chatting with the Free Software Foundation Europe ( hpr857 , hpr1957 , hpr2223 , hpr2945 , hpr2946 , hpr3388 , hpr3407 , hpr3833 ), this was the first time we had a chance to interview Nico Rikken . We chat about freedom and Ada and Zangemann - A Tale of Software, Skateboards, and Raspberry Ice Cream by Matthias Kirschner and Sandra Brandstätter . Geert-Jan Meewisse representing Coalition for Fair Digital Education The Coalition for Fair Digital Education (CEDO) is a group of concerned parents, IT professionals, teachers, and privacy advocates committed to enabling fair and sovereign digital education. The coalition operates as a working group within Internet Society Netherlands (ISOC). We have drafted a manifesto calling for improvements in digital education. Today, children in education receive an online account from a foreign Big Tech company at an early age. Through this account, data can be collected, profiles can be built, and personal information can be used and exploited by these companies. This profiling leads to children being categorized and receiving tailored content that companies deem relevant—before they even discover things for themselves. And that's not the only issue. Since schools exclusively use “standard” Big Tech solutions, children do not learn about alternative programs or tools. As a result, real digital skills and critical thinking are not developed, making children dependent on a company that profits from their data. The privacy and sovereignty of digital education are under severe pressure, affecting not only students but also teachers and parents, who are forced to use the same systems. Other countries are already ahead in this regard: in Denmark, Google products have been banned in schools in Helsingør municipality, and the German state of Baden-Württemberg has prohibited Microsoft 365. We advocate for the development of an open-source digital infrastructure for learning and educational tools, based on public values such as autonomy, equality, sovereignty, democracy, transparency, accessibility, academic freedom, and privacy-by-design. To achieve this, raising awareness among students, parents, teachers, and school boards is crucial. Additionally, we aim to involve policymakers by presenting our manifesto. https://eerlijkdigitaalonderwijs.nl/english/ A working group of the Internet Society , Geert-Jan was here to tell us of their work to build a FLOSS alternative for Education. You can get in touch with him at gj -at- eerlijkdigitaalonderwijs .nl , or @geert-jan:matrix.org Conclusion I had great conversations with the sponsors who were a little shy about doing an interview. They do have a range of jobs available for those of us with Dutch nationality, and have lived in the Netherlands for the last 10 years. The event was fantastic, professional, held in a great venue, and the closest thing to real life xkcd: Shibboleet as you are likely to get. I would like to thank the NLUUG team, volunteers, venue staff and of course the attendees for a wonderful day. With any luck this will not be the last time you hear about this team on HPR. The recordings will be available on the NLUUG FTP Server Provide feedback on this episode.

This show has been flagged as Clean by the host. 01 This is the third in a four part series on simple podcasting. 02 In this episode we will cover the following topics: Analysis of audio noise problems and filtering methods used to deal with specific problems that we may find. Command line recording. Command line playback. Getting information about an audio recording. 03 Introduction When I did my first couple of podcasts I didn't notice that there was a quiet high pitched whine or buzz in the background. Nobody complained about it, but I thought I could do better in subsequent episodes. 04 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 the problem is in the microphone or another part of the audio system. Plug in your microphone and record 2 or 3 seconds of quiet audio where you do not speak into the microphone or make other noise. 05 You will need a minimum amount of data in order to analyze it. For a flac file sampled at 44.1 kHz, 2 to 3 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 a quiet signal. Any sound recorded in this way should be mainly from the microphone or other electronic elements in the analogue pathway. To get a sample of possible ambient noise, such as fans, make sure the microphone is in the open air in an area which is representative of where it will be when you are recording. -------------------- 06 Analyzing using Fourier Transforms Next you need to look at the wave form. At this point I will describe this using Audacity. I will show other ways later, but Audacity is actually 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. 07 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 in audio. 08 There is software which will create pretty coloured animations of sound waves, but this is not what you want. These are simply decorative patterns and won't tell us what we want to know. -------------------- 09 Using Audacity Install Audacity if you haven't already. Start Audacity. Select file > import > audio, then navigate to your sample and select "open". The file should load. 10 In the wave form part of the window, click anywhere and then type Ctrl-S to select all data points. The chart should turn a slightly darker colour. From the menu, select Analyze > Plot Spectrum. A new window will open, showing magnitude in db on the Y axis, and frequency in hertz on the x axis. For "algorithm" be sure it is set to "spectrum" 11 There are now two settings that we need to play with while we look for problems. One is "size" The default for this is 1024. The other is "axis". The default for this is "log frequency". -------------------- 12 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. 13 I have found two combinations of settings to be most helpful in finding problems. These are Size 2048, axis linear frequency. Size 32768, axis log frequency. 14 A small size value can help very narrow spikes stand out from the background more, while 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 in the often very crowded lowest frequency range. -------------------- 15 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. 16 However, in my case I found two main problems and one lesser one. One problem was a spike at 60 Hz, which is the AC line frequency. There is also a lesser problem of a collection of a broad frequency range of noise below 60Hz. Both of these however will be taken care of by the basic filtering that we looked at earlier so we do not need to worry about them here. 17 The other main problem is I had a large spike at every 1 kHz interval from 1 kHz to 19 KHz. This was noise generated within the head set electronics, or the result of noise on the USB power supply. This is the product of a cheap headset. 18 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 results in a high pitched whine 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. 19 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. -------------------- 20 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 technique that was already covered in basic filtering. 21 To deal with the remaining spikes we can use additional "band reject" filters, each of which removes a specific frequency at 1 kHz intervals from 1 kHz to 12 kHz. We will use this in combination with the filtering that we have already done previously, so we don't need to worry about anything above 12 kHz as we already remove that with a low pass filter. After a small amount of experimenting I came up with the following. 22 Because I am applying a total of 16 filters, 4 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 new band reject filters from a template. Note that I don't show the "de-esser" filter here. I would recommend adding it as a separate step after doing the sort of filtering we are talking about here. 23 Rather than reading out multiple lines of bash 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 FFMPEG 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. FFMPEG Version Here's the FFMPEG version. # The high and low pass filters. hlpfil="highpass=f=80, lowpass=f=12000" # Band reject filters filter for 60Hz and another for 50Hz. linefil="bandreject=f=60:width_type=h:w=20, bandreject=f=50:width_type=h:w=20" # Create a series of band reject filters, from 1 kHz to 12 kHz. # Change or remove this part if your recording hardware does not require it. ftemplate="bandreject=f=%s000:width_type=h:w=100" kilospikefil=$( seq 1 12 | xargs printf "$ftemplate," ) # Using ffmpeg ffmpeg -i input.flac -af "$hlpfil, $linefil, $kilospikefil" output.flac 24 There are a total of 5 lines of bash script. In the first line, we create a string called "hlpfil" which is just the high and low pass filters copied from our previous discussion on basic filtering. In the second line, we create a string called "linefil" which is just the simple bandreject filters to cover 50 and 60 hertz AC line noise filters also from basic filtering. 25 In the third and fourth lines, we create a string called "kilospikefil" 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 larger width. In this case I decided to hammer the spike quite aggressively and so used a relatively wide width of 100 hertz. Testing with a voice file did not show any noticeable distortion, so it's an acceptable solution. 26 For this filter we need to create a dozen filter command so we use the shell "seq" command to generate a sequence of numbers from 1 to 12. We then pipe that into the xargs command which applies each number to the next command. The next command is "printf", which takes the number it gets from xargs and applies it to the "ftemplate" string template in a manner very similar to C programming printf string templates. 27 We also have a comma in there to separate each of the individual filters. We then surround this with a $ and () so we can run the command and capture the output into a variable. Then we call ffmpeg and pass it the filters we created by 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. Sox Version Here's the Sox version. # The high and low pass filters. sxhlpfil="highpass 80 lowpass 12000" # Band reject filters filter for 60Hz and another for 50Hz. sxfilter="$sxhlpfil $sxkilospikefil bandreject 60 20 bandreject 50 20" # Create a series of reject filters filters, from 1 kHz to 12 kHz. sxftemplate="bandreject %s000 100" sxkilospikefil=$( seq 1 12 | xargs printf "$sxftemplate " ) # Using SOX. sox input.flac output.flac $sxhlpfil $sxfilter $sxkilospikefil 28 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. -------------------- 29 Confirming the Effect If we apply the above filters and look at this headset noise output file in the Audacity spectrum analyzer we will now see that these noise spikes are almost completely gone. We can now confirm how well this works by using a test audio file. Any normal short voice audio file will do for this. Just talk into the microphone normally and create a voice sample file that is 5 or 10 seconds long, or whatever you feel comfortable with. 30 With the original unfiltered voice audio I can hear a distinct high pitched whine overlaying the voice. With the filtered audio that whine or hum is not detectable. If we then look at the voice file in the Audacity spectrum analyzer, we can see distinct "notches" at the 50 Hz and 60 Hz frequencies, and at 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 whine is gone and the voice signal sounds fine. Despite using a very cheap microphone, I now have acceptable quality audio for a podcast. 31 Again I want to emphasize that in this instance I am dealing with deficiencies with my hardware instead of buying a better microphone. These additional filters are intended to deal with the specific hardware problem 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. 32 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 are welcome to make a podcast on the subject. -------------------- 33 Completing the Process With these new filters added into the middle of the processing steps, you can now complete the processing by doing the de-essing, normalizing, and review steps as described in the previous episode. -------------------- 34 Command Line Recording I will now cover a separate topic, which is recording using command line programs. I am covering it in this episode as it is a short topic and it is convenient to talk about it here. 35 As well as using GUI based recording programs such as Gnome 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. 36 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 am 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. 37 Recording with FFMPEG - The Basics One of the 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. 38 # Record audio. ffmpeg -f pulse -i default ff.flac 39 Press 'q' to stop. This uses pulse audio on Linux for input "-f pulse", and the default input "-i default". However, this does not specify the the sample rate or mono recording. To do that we need to add a few more parameters as in the following 40 ffmpeg -f pulse -i default -ac 1 -ar 44100 ff.flac 41 "-ac 1" specifies mono output "-ar 44100" specifies 44.1 khz bit rate. 42 Playback with FFMPEG - The Basics FFMPEG can also play back music. In this case however we need to call the "ffplay" program rather than FFMPEG itself. To play an audio file, simply call ffplay and give it the name of the audio file as an argument to the command. For example: 43 # Play an audio file. ffplay podcast.flac 44 We can also call it with the "autoexit" option, which tells ffplay to automatically exit when the audio file has finished playing. ffplay -autoexit ff.flac 45 -autoexit means Exit when the audio file is done playing. 46 To exit in the middle of the recording, press "q' or ESC. To pause the playback, press "p" or space bar. To decrease the volume press "9" or "/". To increase the volume press "0" or "*". 47 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. 48 The "0" and "9" keys mentioned above are those on the top row of the keyboard, not the ones on the separate numeric pad. 49 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. -------------------- #!/bin/bash # Record a podcast episode segment. # Get the next file name. # First we check if any matching file patterns exist. If they don't, # then we create the first one starting counting at 1. fcount=$( ls [0-9][0-9].flac 2>/dev/null | wc -l ) if (( $fcount < 1 )); then fname="01.flac" else # If there are any matching file patterns, we find the highest number # and increment it by 1. filenum=$( ls [0-9][0-9].flac 2>&1 | cut -d. -f1 | sort | tail -1 ) newfilecount=$(( 10#$filenum + 1 )) fname=$( printf "%02d.flac" $newfilecount ) fi echo "Recording to: $fname" # Record using ffmpeg. # This makes use of pulse audio and the input is the default audio input. # The sample rate is set to 44.1 kHz, and it is recorded as mono (1 channel). ffmpeg -f pulse -i default -ar 44100 -ac 1 $fname echo "Recorded audio to: $fname" # Report on basic information about the audio file that was just recorded. ffprobe -hide_banner $fname -------------------- 50 Sox - Not so Good I did not find the recording or playback features of Sox to be as useful as those of FFMPEG, so I won't bother to cover them here. -------------------- 51 Getting Information About an Audio Recording There are also command line tools which can be used to retrieve information about audio recordings. 52 FFMPEG Version With FFMPEG this is called "ffprobe". For example: 53 ffprobe hpr4566.mp3 54 This will print out a lot of information about FFMPEG itself. To skip that use the hide_banner option. 55 ffprobe -hide_banner hpr4566.mp3 56 This will print out information about the audio recording. This will include things like the duration, bit rate, sample rate, stereo or mono, etc. If the author added metadata tags to the file, it will also show those. HPR add things like the title, author, copyright license, comment, etc. You can extract the ones you want using something like grep and cut. 57 Sox Version Sox has a similar feature, called "soxi". 58 soxi ff.flac 59 However, it may not work on mp3 files if you do not have an mp3 handler for it installed. -------------------- 60 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 Audacity 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. 61 In the next episode we will look at alternatives to Audacity for analyzing audio. While Audacity works just fine, this is an opportunity to have a bit fun with some gratuitous hackery. 62 This has been the third episode in a four part series on simple podcasting. -------------------- -------------------- Full Audio Processing Pipeline This version includes the special filters used to fix my headset problems. Use the version from the previous episode if you do not have the same audio hardware problems. #!/bin/bash # Full processing pipeline for making simple podcasts. # ====================================================================== # Concatenate multiple flac files into a single flac file. # This is used to combine podcast recorded segments into a single # flac file for uploading to HPR. concataudio () { outputname="$1" # First create the list file. printf "file '%s'n" [0-9][0-9].flac > podseglist.txt # Now concatenate them ffmpeg -f concat -safe 0 -i podseglist.txt "$outputname" rm podseglist.txt } # ====================================================================== # Basic and advanced filters. filter () { inputfile=$1 outputname=$2 # Using ffmpeg. # The high and low pass filters. hlpfil="highpass=f=80, lowpass=f=12000" # Band reject filters filter for 60Hz and another for 50Hz. linefil="bandreject=f=60:width_type=h:w=20, bandreject=f=50:width_type=h:w=20" # Create a series of band reject filters, from 1 kHz to 11 kHz. ftemplate="bandreject=f=%s000:width_type=h:w=100" kilospikefil=$( seq 1 11 | xargs printf "$ftemplate," ) # Using ffmpeg ffmpeg -i $inputfile -af "$hlpfil, $linefil, $kilospikefil" $outputname } # ====================================================================== # De-Essing. deessing () { inputfile=$1 outputname=$2 option=$3 # De-essing filter. ffmpeg -i $inputfile -filter_complex "deesser=i=0.5:m=0.5:f=0.5:s=$option" -b:a 336k -sample_fmt s16 $outputname } # ====================================================================== # Normalizing the audio to EBU R128 standard for review using ffmpeg. normffmpeg () { inputfile=$1 outputname=$2 # Normalize to EBU R128 standard. ffmpeg -i $inputfile -af loudnorm=I=-17:TP=-2.0:LRA=4.0 -ar 44.1k $outputname } # ====================================================================== # Output an MP3 version to help with reviewing. mp3convert () { inputfile=$1 # Get the name of the file and then create the output file name. j=$( basename $inputfile ".flac" ) outputname="$j"".mp3" # Convert to MP3. ffmpeg -i $inputfile $outputname } # ====================================================================== # Concatenate the separate audio files. concataudio fullpod-unfiltered.flac # Basic filtering. filter fullpod-unfiltered.flac filtered.flac # De-essing. This is the version to send for publishing. # The third argument should be "o" for de-essing, or "i" for pass through without de-essing. deessing filtered.flac fullpod.flac o # Normalized for review. normffmpeg fullpod.flac fullpod-norm.flac # Output an MP3 copy for review. mp3convert fullpod-norm.flac -------------------- -------------------- Provide feedback on this episode.

HPR's Cassie Ordonio reports on the status of Chuuk's Super Typhoon Sinlaku recovery efforts; local record shop and label owner Roger Bong responds to the use of AI-generated music at Honolulu International Airport.

Jim Kelly, Hawaiian Electric Company, on rising electric bills; HPRʻs Ashley Mizuo reports on how it's the first year lawmakers had to decide how to spend revenue from The Green Fee

This show has been flagged as Explicit by the host. New hosts There were no new hosts this month. Last Month's Shows Id Day Date Title Host 4608 Wed 2026-04-01 Simple Podcasting - Episode 1 - Preparation and Recording Whiskeyjack 4609 Thu 2026-04-02 Proper Date Format Ahuka 4610 Fri 2026-04-03 Playing Civilization V, Part 10 Ahuka 4611 Mon 2026-04-06 HPR Community News for March 2026 HPR Volunteers 4612 Tue 2026-04-07 Hackerpublic Radio New Years Eve Show 2026 Episode 4 Honkeymagoo 4613 Wed 2026-04-08 Adding functionality to an Odoo installation Jeroen Baten 4614 Thu 2026-04-09 Dauug|18: Faster Than a '286, but Inspectable Like a Soroban Marc W. Abel 4615 Fri 2026-04-10 Clicking through an audit Lee 4616 Mon 2026-04-13 Thoughts about age control and further suggestions Trollercoaster 4617 Tue 2026-04-14 UNIX Curio #4 - Archiving Files Vance 4618 Wed 2026-04-15 Simple Podcasting - Episode 2 - Basic Filtering Whiskeyjack 4619 Thu 2026-04-16 HPR Beer Garden 12 - Baltic Porter Kevie 4620 Fri 2026-04-17 The Second Doctor, Part 1 Ahuka 4621 Mon 2026-04-20 Android volume control help operat0r 4622 Tue 2026-04-21 Hackerpublic Radio New Years Eve Show 2026 Episode 5 Honkeymagoo 4623 Wed 2026-04-22 A brief infodump on the Broadcast Address and Routing Jon The Nice Guy 4624 Thu 2026-04-23 Cheap Yellow Display Project Part 7: GUI Trying a Simple Hello World Trey 4625 Fri 2026-04-24 Site Specific Browsers Lee 4626 Mon 2026-04-27 Cable Management / PC Speakers operat0r 4627 Tue 2026-04-28 UNIX Curio #5 - Faster, Pussycat! Kill! Kill! Vance 4628 Wed 2026-04-29 Nuclear Power Technology Follow Up Whiskeyjack 4629 Thu 2026-04-30 What did I do at work today? Part 2 Lee Comments this month Past shows hpr4424 (2025-07-17) "How I use Newsboat for Podcasts and Reddit" by Archer72. Ken Fallon said: "Summary of findings" (2026-04-05 14:09:24) Archer72 said: "Not fixed from أحمد المحمودي" (2026-04-25 11:02:26) hpr4569 (2026-02-05) "Kiosk with guest mode on Linux" by Klaatu. 0xf10e said: "Preconfiguring browsers profiles? and re-replies ;)" (2026-04-17 09:56:49) hpr4585 (2026-02-27) "mpv util scripts" by candycanearter. candycanearter07 said: "perpetually updated script(s)" (2026-04-14 20:41:28) hpr4596 (2026-03-16) "Adding voice-over audio track created using text to speech on the movie subtitles" by Ken Fallon. Windigo said: "Great usability win" (2026-04-24 19:33:03) hpr4600 (2026-03-20) "The First Doctor, Part 5" by Ahuka. Kevin O'Brien said: "Maybe I will" (2026-04-12 16:16:00) hpr4603 (2026-03-25) "On the Erosion of Freedom in Open Source Software" by HopperMCS. Trollercoaster said: "Hopper did time traveling!" (2026-04-09 05:46:52) hpr4605 (2026-03-27) "Lee locks down his wifey poo" by Elsbeth. Lee said: "Quotation" (2026-04-05 15:59:54) Paulj said: "Thanks!" (2026-04-06 16:44:28) hpr4606 (2026-03-30) "My Nerdy Childhood: From Floppy Disks to Dial-Up Dreams" by Trollercoaster. Trollercoaster said: "Damn you Nerdy Nostaliga!" (2026-04-06 15:28:34) This month's shows hpr4608 (2026-04-01) "Simple Podcasting - Episode 1 - Preparation and Recording" by Whiskeyjack. Archer72 said: "Listening ahead" (2026-04-01 10:06:46) Whiskeyjack said: "Reply to Archer72 on HPR4608" (2026-04-01 12:27:46) Reto said: "It reminds me about Solocast" (2026-04-03 07:49:58) Whiskeyjack said: "Response to Reto comment on HPR4608" (2026-04-04 18:19:25) Whiskeyjack said: "Further response to Reto comment on HPR4608" (2026-04-04 22:21:38) hpr4609 (2026-04-02) "Proper Date Format" by Ahuka. Jim DeVore said: "It is the only proper date format" (2026-04-04 14:19:15) candycanearter07 said: "sensical date format" (2026-04-06 09:37:47) hpr4611 (2026-04-06) "HPR Community News for March 2026" by HPR Volunteers. candycanearter07 said: "misattributed comment" (2026-04-06 03:24:30) Ken Fallon said: "Fixed" (2026-04-06 13:50:17) hpr4614 (2026-04-09) "Dauug|18: Faster Than a '286, but Inspectable Like a Soroban" by Marc W. Abel. Jim DeVore said: "Is this the best approach for privacy?" (2026-04-12 03:15:44) candycanearter07 said: "interesting!" (2026-04-13 16:43:22) hpr4616 (2026-04-13) "Thoughts about age control and further suggestions" by Trollercoaster. Antoine said: "'Jus'do the age verification'" (2026-04-20 01:37:33) candycanearter07 said: "good strategy" (2026-04-22 13:24:48) Trollercoaster said: "Looking forward at next steps" (2026-04-25 15:37:22) Antoine said: "Our State. The Invitation." (2026-04-26 23:55:45) hpr4618 (2026-04-15) "Simple Podcasting - Episode 2 - Basic Filtering" by Whiskeyjack. Antoine said: "Applying filters - exp. with declicking - Compression?" (2026-04-20 12:50:09) Whiskeyjack said: "Response to Antoine on de-essing in HPR 4618" (2026-04-22 15:59:57) Vance said: "Click removal" (2026-04-25 14:31:40) Whiskeyjack said: "Reply to Vance in HPR4618 - Click Removal" (2026-04-27 00:48:11) Vance said: "To Whiskeyjack - Click Removal" (2026-04-28 00:43:11) Whiskeyjack said: "Reply to Vance on Click Removal in HPR4618" (2026-04-28 17:16:54) hpr4619 (2026-04-16) "HPR Beer Garden 12 - Baltic Porter" by Kevie. Gan Ainm said: "Störtebeker - again" (2026-04-17 16:37:29) hpr4621 (2026-04-20) "Android volume control help" by operat0r. candycanearter07 said: "intended double entendre?" (2026-04-21 18:58:54) hpr4624 (2026-04-23) "Cheap Yellow Display Project Part 7: GUI Trying a Simple Hello World " by Trey. Ken Fallon said: "Great to hear your success" (2026-04-23 08:36:28) hpr4625 (2026-04-24) "Site Specific Browsers" by Lee. candycanearter07 said: "electron charged opinion" (2026-04-24 03:38:13) hpr4627 (2026-04-28) "UNIX Curio #5 - Faster, Pussycat! Kill! Kill!" by Vance. Antoine said: "kill and killall" (2026-04-29 11:57:27) candycanearter07 said: "killer episode" (2026-04-29 15:14:31) Vance said: "Glad you enjoyed it" (2026-04-29 20:58:44) candycanearter07 said: "Re: Glad you enjoyed it" (2026-04-30 18:58:50) Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2026-April/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Provide feedback on this episode.

This show has been flagged as Clean by the host. -------------------- 01 Introduction This is a follow up to my 8 part series on nuclear power. In this episode I will answer questions posed by listeners in the comments to the series. I would like to start by thanking these people for taking the time to submit interesting questions. -------------------- Costs of Small Versus Large Reactors 02 brian-in-ohio asked two questions The first was for a cost comparison between large and small reactors. The second was for nuclear plant safety compared to conventional power plants. 03 Answer I think that any answer to the second question is going to be perceived by some people as politically controversial, so it's probably not a good topic for HPR to address. 04 The first question though about cost of small versus large reactors is an interesting one, although not one that is easy to give an answer to. I will restrict the answer to just grid scale electric power production and ignore use cases such as industrial process heat or power for remote mines and communities. 05 This question comes down to economies of scale versus economies of replication. Economies of scale centre around increased efficiencies of use of materials and labour when making something bigger. For example, the amount of steel used by a pipe increases linearly with its diameter, but the amount of fluid that it transports increases with the square. 06 Economies of replication come from increasing efficiencies which result from serial production. As you repeat the same design over and over again, you learn how to do things better and make fewer mistakes. 07 The exact same principles apply to shipbuilding. Indeed, a lot of the inspiration for Small Modular Reactors comes from the shipbuilding industry. If you build a series of identical ships, then each subsequent ship will cost less and be built faster. There are of course diminishing returns to this process, so the improvements are less with each additional unit and after a sufficient number of units the cost and time reductions level off. 08 However, this doesn't discount the benefits of economies of scale. What it does mean is that there are two ways of approaching the problem, and which way works in any given scenario depends on such conditions as how big the local electricity market is how fast the demand for electricity is growing, the ownership and financing structure of the electricity market, and the geography of the area, which may pose limits on the number of sites. 09 According to the finance people who have crunched the numbers, there are two sizes of reactor which make the most sense in the above context. These are 300 MW and 1000 MW. However, take those as very rough numbers rather than immutable laws of nature and other sizes may work as well. 10 The key point is that there are cases to be made for both small and large reactors, with the large reactor being several times the size of the small one. 11 An additional factor is that building only one reactor does not reap the benefits of efficiency of replication. You need to build a series of them on the same site. So if you are building a power plant, you don't build a power plant that has just one reactor unless you are in a small market which can only use that much power. Instead, you should build between 4 and 6 reactors in sequence next to one another. 12 If you are supply a large population with a growing demand for electricity, then 4 or 6 large 1000 MW reactors gains both economies of scale and economies of replication. If you are supplying a smaller population with slow growth in demand for electricity, then 4 or 6 300 MW reactors at least gets you economies of replication. 13 There is what could be viewed as an interesting example in terms of the above taking place just east of Toronto. There they are building four 300 MW SMRs on a site next to an existing nuclear power plant. 14 Here are the cost estimates from the Government of Ontario. All costs are in Canadian dollars. Unit 1 is $6.1 billion, plus $1.6 billion in costs which are shared by all four unit.s Unit 2 is $4.9 billion. Unit 3 is $4.2 billion. Unit 4 is $4.1 billion. 15 As you can see, building a series of reactors sequentially on the same site results in declining overall costs. They are very confident in these costs as they used data from a series of major nuclear power plant refurbishment projects in Ontario which have been coming in on time and on budget. 16 Construction began last year and the plant is expected to have a 65 year operating life. 17 However, the province of Ontario also has plans for expansion of electrical generation by about 15,000 MW by 2050 in order to meet net zero targets. 18 Given the heavy concentration of population in the Toronto region, and the very high cost and difficulty of building long distance transmission lines, and the limited number of sites which could host new power generation facilities of any sort, I suspect it is quite likely that subsequent reactors will be large 1,000 MW ones rather than SMRs. 19 The Wesleyville site (which is further east of Toronto) is tentatively scheduled for a 10,000 MW nuclear power plant. That would seem to make ten 1,000 MW reactors more likely than 34 300 MW reactors. 20 I don't have a comparable set of numbers for building large reactors to give an exact apples to apples comparison of costs. Different countries use different accounting and financing systems, and finance makes a huge difference to overall costs for nuclear power as operating costs are a relatively small share of the total. 21 Now to look at another side of this equation, the provinces of Saskatchewan and New Brunswick wish to replace their coal fired power plants with nuclear power plants. The populations of these provinces are too small to absorb a large new power plant into their grids, and studies assuming large reactors have foundered on this issue. 22 New Brunswick already have a nuclear power plant, but it was build in the days when reactors were much smaller. Both provinces however are very interested in small reactors, even individual ones, in order to replace the coal fired plants that are of similar size. 23 I think this covers the cost versus size issue. The more I look into it, the more it becomes apparent that there is no simple one size fits all answer but rather there are a series of trade-offs which must be taken in light of local circumstances. -------------------- MOX Fuel in the USA 24 The next question comes from mnw who asked about the use of MOX fuel in the USA. 25 mnw asked I am enjoying and look forward to the rest of the series. Do you think the US will ever wake up and start recycling its spent fuel? It seems like such a huge waste just to try and keep a small amount of fuel away from"the bad guys" or whatever they are imagining. Answer 26 My answer to this is as follows. I think I've addressed this in the original series, although not directly with respect to the US so I can provide some more detail on that aspect of it. 27 First though I will review what plutonium-uranium mixed oxide (MOX) fuel is. As mentioned in previous episodes, military grade plutonium is not the same as the plutonium which comes out of commercial power reactors. Just as military grade uranium requires nearly pure U-235 isotope, military grade plutonium requires nearly pure Pu-239 isotope. 28 What comes out of a commercial power reactor as spent fuel is not usable for weapons purposes as the proportion of Pu-239 is much too low. However, plutonium recovered from spent fuel can be used as fuel for nuclear reactors in place of uranium 235 when mixed with uranium 238 either left over from enrichment or extracted from spent fuel. This is what is known as MOX fuel. 29 To look at the US history of this however, here's the sequence of events. The US banned fuel reprocessing in 1976. However, this ban was repealed in 1981. 30 In 2005, the US began building a mixed-oxide (MOX) fuel plant at Savannah River in the state of South Carolina. However, this plant was not intended as a normal commercial operation and it was not intended to recycle commercial nuclear power plant fuel. It was instead intended to convert surplus military grade plutonium into commercial fuel in order to get rid of it as part of an arms control program. 31 The program was suspended in 2018. There were apparently many complex political issues involved in these on-again off-again decisions and I won't pretend to have the time or interest to explore all the details nor do I think most listeners would be interested in hearing abou them. 32 As of March 2026, the US are looking at reviving part of the Savannah River plant to produce limited amounts of fuel for testing of advanced reactors. The issue driving this is the shortage of uranium enriched to just below 20%. This fuel is used in certain types of small SMR. 33 The main commercial supplier of this material was a plant in Russia, but "certain events in Europe in recent years" shall we say, have resulted in that supply no longer being available to commercial operations in the US. MOX fuel based on surplus weapons grade plutonium is intended as a short term quick fix for that problem. 34 Another driving force is legal requirements following from domestic commitments for the US government to dispose of certain stockpiles of weapons grade plutonium from certain sites in the US where it is "temporarily" stored, and the solution to that is seen as burning it up in power reactors. 35 So the history is the US banned fuel reprocessing. Then a few years later they un-banned it. Then the US government started building a MOX plant which was intended to get rid of surplus weapons grade material by burning it up in power reactors. Then they decided they didn't want to do that. Then they decided they may want to make MOX fuel after all to replace supplies of special grades of fuel for experimental or prototype reactors. 36 What is missing from the above history is any actual interest from the US commercial nuclear industry in MOX fuel. The reason for this is, as mentioned in the previous episodes, uranium is so cheap and abundant that fuel made from fresh uranium is cheaper than MOX fuel. 37 Some countries such as France wish to recycle spent fuel to reduce their dependence upon imports. Recall that France's drive to build nuclear power plants was in response to the 1970s era energy crisis when oil imports from the Middle East were suddenly cut off. However, the US are not concerned about this issue and so do not make it national security policy as France did. 38 As a result, US commercial demand is for cheaper fuel made from fresh uranium rather than for MOX fuel. Until such time as fresh uranium greatly increases in price there is little economic incentive for the use of MOX fuel in the US. 39 However, there is another aspect to this. If you recall in previous episodes I described molten salt reactors which used dissolved uranium fuel. These reactors inherently reprocess fuel as part of their normal operation. They just do it as part of maintaining the molten salt chemistry at the correct values rather than doing it as a separate process. 40 If these types of reactors become widely used then they would be achieving the same thing as creating MOX fuel, but without an explicit separate step. 41 As a final footnote to the above, the US has almost exclusively use enriched uranium light water reactors. As mentioned in previous episodes, there are ways of recycling spent fuel from light water reactors which do not involve chemically reprocessing it to make MOX fuel. 42 Experiments have been done involving South Korea, China, and Canada which take spent fuel from light water reactors and repackage it to fit it into natural uranium heavy water reactors. What is used up or "spent" fuel for a light water reactor is high grade fuel to a natural uranium reactor. However, the US has, for whatever reason, never built commercial natural uranium reactors such as are used in a number of other countries around the world. 43 If they were to do so, then nuclear fuel could be used twice, once in a light water reactor, and again in a natural uranium reactor, all without having to turn it into MOX fuel in a separate reprocessing step. However, this particular alternative would likely face the same issue in the sense that fresh fuel would still be cheaper than reusing spent fuel. -------------------- A Variety of Questions from Clinton 44 Next we have a variety of questions from Clinton. Clinton asked I would like some commentary in the current situation, why has hinkley gone off the rails, the new american approach, the odd things done after fukushima, the new radiation rules in the states. 45 Question 1 why has hinkley gone off the rails, 46 Answer The question refers to cost overruns at the Hinkley Point nuclear power project in the UK. The UK government looked into this issue in a more general sense in 2025. They published a report on it titled Nuclear Regulatory Review 2025 Enabling nuclear delivery through regulatory reform John Fingleton There is a link to the report in the show notes. https://assets.publishing.service.gov.uk/media/692080f75c394e481336ab89/nuclear-regulatory-review-2025.pdf 47 As the report is 162 pages long, I won't try to cover it all in this answer. I will however give a few simple examples. The report focuses on civilian nuclear power and the defence nuclear industry as well. However it also draws examples from outside the nuclear industry to show that the problem is not limited to nuclear. It shows that the same problems exist in the offshore wind industry, and in the HS2 High Speed Rail project. 48 In the view of the authors of the report, the essence of the problem seems to be a lack of any degree of proportionality in terms of mitigating negative effects from any project. Big nuclear projects make the headlines because they are inherently big projects, but as I have just mentioned, they affect things like wind power development and rail transport as well. 49 I will pick one example from Hinkley Point specifically. This is "Case Study: Hinkley Point C Fish Protection" A summary of this is that they spent £700 million of additional money on the cooling water intakes to protect an estimated 0.083 salmon per year, along with 0.028 sea trout, 6 river lamprey, 18 Allis shad, and somewhere between 100 and 528 twaite shad. The report points out that there are ways to protect far more fish for far less money by spending it in other areas, and gives some examples. Again, this problem is not limited to nuclear power, and they give similar examples connected with offshore wind development and HS2 High Speed Rail. 50 I would like to emphasize that I am not expressing an opinion on whether or not any of these decisions were good or bad ones or whether the money was well spent. I am just summarizing the report's explanation of why large projects of all sorts initiated and approved by the UK parliament were not turning out as initially expected. I will leave it up to people in the UK to decide whether or not they are satisfied with the current situation. 51 Question 2 the new american approach, 52 Answer The US have apparently announced changes to their regulatory system. I don't know enough about the subject to really judge the practical effects of regulation within the US. However, I have read and listened to many interviews of people from both the industry and the regulatory side of things who are from outside the US but are familiar with it. They generally contrast two different approaches to regulation. On the one hand there is the US approach, which they see as being more of a box ticking exercise than an in depth safety review. This makes it very hard to get a design other than a traditional PWR or BWR approved in the US. 53 It has the advantage from the regulator side of things though in that it reduces the amount of work required as it primarily requires just following a set of defined procedures. These people then contrast that approach with the one used in the UK and in Canada, both of which they see as being very similar to one another. In those two countries, regulators work with industry to review designs from basic principles rather than just seeing if it meets a pre-defined list of criteria. This is a results oriented system rather than a process oriented system as used in the US. 54 As a result of this, designers of new nuclear reactors are going to the UK and Canada first to go through preliminary review there, and only going to the US later. What designers are looking for is feedback on their design as they go along in order to align the design with what safety regulators see as being required from their standpoint. They want to go into a review process before the design is finalized so they can get guidance on how they should approach things rather than trying to add safety as additional features on top of a finished design. 55 It would take someone with deep familiarity with nuclear regulation systems to understand the practical effects of recent changes in US regulatory systems, but it is quite possible that people within the regulatory structure in the US have been taking the above on board and trying to adapt to current circumstances. However, I can only speculate on that. This is about the best answer that I can give. 56 Question 3 the odd things done after fukushima, 57 Answer This covers a lot of topics, some of which are probably political and so are not suited to HPR. I will try to list a few events however. As a brief summary if the Fukushima events go however, a historic scale earthquake and tsunami in Japan in 2011 caused huge loss of life and widespread damage. About 20,000 people were killed by the earthquake and tsunami. Three nuclear reactors based on 1960s era GE BWR designs were seriously damaged by hydrogen explosions caused by loss of power to backup generators when they were flooded by the tsunami. However, there were no radiation related deaths or cases of radiation sickness. 58 Following events in Japan was a general review of designs around the world, with various improvements made in some areas, particularly backup generators and hydrogen management. It seems to be conventional wisdom that the Fukushima event caused a number of countries to decide to phase out nuclear power. 59 However, when I tried to make a list of such countries for this episode I found things were not as is often heard. The countries which decided to get rid of nuclear power had largely started down that road at least a decade before then and generally for reasons unrelated to any specific events outside of their own country. In other cases they reversed that decision or are in the process of doing so. Japan itself has restarted many of their nuclear power plants and plant to replace decommissioned nuclear power plants with new ones, although many of the older and smaller ones were considered not economically worth upgrading at this point in their life to restart them. 60 The one possible exception to this may be Taiwan which decided to phase out nuclear power in 2016. However, I don't know enough about Taiwanese politics to state with any confidence that their decision in 2016 was based on anything related to events in Japan, or whether in fact they were a byproduct of other political changes within Taiwan and the shut down of nuclear plants happened to be carried along with those. Currently Taiwan get their electricity primarily from natural gas and coal. 61 Meanwhile across mainland Asia from Turkey to China, large numbers of nuclear power plants were built or are under construction. Taken together on a global scale, did anything really change after Fukushima, or did the countries which had already decided to close down their nuclear power plants simply continue to do so, and those countries who decided they wanted more of them continue to build them? That's a good question for which I don't think anyone has the perspective to answer at this point. 62 Another side of this which is hard to disentangle from it though is the increased use of natural gas for electric power generation which was happening at around the same time. Increased use of fracking in a number of countries, plus increased supplies from Russia and LNG from the Middle East and other places resulted in falls in natural gas prices in many places. Since combined cycle natural gas turbines form the main competitor to nuclear power, anything which improves the economics of natural gas will act to reduce demand for nuclear power. This makes it hard to decide to what degree the reduction in the number of reactors being built was due to the political effects of the earthquake and tsunami and to what degree it was due to cheaper natural gas through fracking and other means. I'll leave that question at that. 63 Question 4 the new radiation rules in the states. 64 Answer I'm not deeply familiar with US radiation rules, but I will attempt to answer the question. Apparently there are wide variety of different things being addressed, only some of which have any relevance to the nuclear power industry. One of these is an epidemiological study on the current exposure limits for workers in the nuclear industry. This study will take place over about 5 years. In the end it may not result in any changes. This is for a number of reasons. 65 One is that US exposure thresholds for workers are currently aligned with international standards. It would be difficult for the US industry to operate on a different basis than the rest of the world when supply chains are global and kit is designed to meet currently recognized standards. Another is that apparently the nuclear industry are not, so far as I can discern, asking for any changes to limits. They instead are looking for changes to how some of the details are being applied, such as for example the criteria for deciding when respirators are required in low risk environments. 66 Some point to recent changes in UK regulations as an example of what they are looking for. I will post a link to the new (November of 2025) UK regulations in the show notes. https://www.gov.uk/government/publications/nuclear-industry-principles-to-guide-the-application-of-as-low-as-reasonably-practicable-alarp-and-best-available-techniques-bat/ways-of-working-principles-to-guide-the-application-of-alarp-and-bat-in-the-nuclear-industry-accessible-webpage This is about as much detail as I think I can comment on when it comes to this question, as I think it is a subject that requires a fair bit more practical knowledge of than I have in order to give a thorough and balanced answer. -------------------- 67 Question from Antoine Were/are the designs patented? Hi, Whiskeyjack. Nice ep. You said AGR, based on Magnox, was a nuclear reactor type that did not sell well outside the UK. I then started thinking if it were (is) possible to another countries to develop by themselves based on that project, or if it had (has) a commercial restriction for exploration of the technology. I have yet to listen to the following episodes (doing little by little) and may learn better on the choices, but I felt free to present the question by now... Thanks! 68 Answer This is a very good question because it offers the opportunity to talk about a number of interesting things that haven't been touched on yet. Let's cover a bit of background first. 69 A patent is a time limited right to exploit a defined bit of valuable technical knowledge. Patents were involved from the very earliest days of commercial nuclear power, and I will give an example of this later. A key point to keep in mind though is that the nuclear power field moves very slowly and it takes a long time for new knowledge to make it from the lab to commercial application. Patents will often expire before they reach the point where they can be used. 70 Contracts on the other hand are legally enforceable agreements between two parties. A contract may have a time limited life, but that is an arrangement between the parties. A commercial nuclear power plant is a very large and complex bit of kit and not easily copied in detail. It can be far more effective to cover designs under contracts and licenses than to rely on patents. If a country wished to build their own nuclear power plants rather than buying them from someone else, there are a large number of companies who have commercial designs they are willing to license to third parties for them to build themselves. Indeed a number of these companies base their business around licensing of designs or have other reasons for wishing to do so. 71 From a licensee perspective, it could take decades of work and hundreds of millions or even billions of dollars to take a design from first principle to the ready to build state, wheras licensing a design give you a proven design right away. As mentioned in previous episodes, there many types of reactor in the world. The selection of what sort of reactor a country decides to buy often depends more on commercial considerations revolving around licensing terms and conditions than it does with respect to any technical considerations. Here's an example which shows how South Korea decided to license a design, build it for themselves, and then export it to other countries. 72 KunMo Chung - Professor at the Korea Advanced Institute of Science and Technology, stated in an interview in 2019 that South Korea wanted to standardize on a single reactor technology in the early 1980s. They had reactors from multiple different vendors, but wanted to license an existing successful design to produce for themselves and for the export market. One of the major factors in deciding to standardize was to allow them to improve operator training by focusing on one design. Professor Chung stated that one of the key factors in selecting a design from ABB-Combustion Engineering was that he personally knew and had a good relationship with the Chief Technical Officer of ABB-Combustion Engineering going back to a time when Professor Chung had been studying and working in the USA. 73 On their side, ABB-Combustion Engineering were having financial problems and they needed a partner to help further develop their new PWR design. Also they stood to gain revenue from this partnership as well. Based on this relationship, the two sides came to a business agreement and South Korea began producing reactors based on this design, while also continuing to develop and improve it further. 74 Here's an example of a case where the developers of a promising technology decided that they had more to gain by not patenting their technology. Instead they decided to freely share their information in order to get other researchers elsewhere to help to advance the technology so that all could benefit from it. 75 In an interview Wacław Gudowski - Prof. Emeritus, Royal Institute of Technology KTH Stockholm stated that the Soviets and later the Russian were the leaders in lead-bismuth cooled reactors. These reactors use lead-bismuth liquid metal alloy as a coolant. In the 1990s the Russian institute working on commercializing this technology were working with Western partners on nuclear technology in general. They considered patenting this technology, but in the end decided to simply publish it openly. 76 Professor Gudowski had even smuggled $60,000 in cash into Russia to finance the patent application in order to get the Russian institute to publish their technology, but the money was not needed. They based this decision on the judgment that it would take 20 years of R&D before the technology was ready for the commercial market, so they wouldn't see a penny on any patents anyway. They were right on this, as it was another 20 years of R&D in Europe, Russia, China, and Korea before lead-bismuth technology was ready for commercial use. 77 It had already seen use in submarine reactors, but the commercial market demanded a more thoroughly developed technology to satisfy commercial needs. By deciding to not patent the technology, the original developers gained from shared R&D rather than chasing the illusary gains from patent licenses on technology that was not ready for the commercial market anyway. 78 I said that patents were involved in nuclear technology from the very earliest days, and I will now turn to that story. When I say the earliest days, I mean probably earlier than you are imaging. I am talking about before WWII. 79 First though I need to give some background information. France and Britain were working on nuclear weapons from the very earliest days of WWII. In Britain's case this was called Tube Alloys. Canada also was conducting nuclear experiments, including building an "atomic pile", but it's not clear if this had any clear practical goals or was done to understand the physics better. 80 If you read the Wikipedia version of history, it states that Tube Alloys was merged into the Manhattan Project. However, participants have stated in interviews that this was not the case, and the Quebec Agreement which supposedly merged them makes no such mention of any merger of the projects, just the setting up of a board to coordinate efforts between the three countries, that is the US, UK, and Canada. In fact the two projects didn't get along that well, and as we shall see below, a big part of that was disputes over patents. ### 81 The following is based on a paper written by Bertrand Goldschmidt, a French nuclear scientist. Two of his colleagues, Hans Halban and Lew Kowarski played a critical role in early nuclear research. Halban in particular was one of the greatest scientific names in nuclear fission. In March of 1939 Halban conducted an experiment showing that neutrons were emitted by the fissioning of uranium. 82 In April Joliot, Halban, Kowarski and Perrin had a pretty good idea of how to use nuclear fission to produce energy and to make an explosive device and decided to file patents on their invention. Each of the four would receive a 5% share of any benefits and the other 80% would go to the research instittute they worked at in Paris. I will now quote from Goldschmidt's paper. 83 The first two patents concerned energy production and were entitled "Device for energy production" and "Method for stabilizing a device for energy production." They roughly defined the principles of the main components of our present power reactors: moderator in heterogeneous or homogeneous arrangements, cooling fluid, control rods, protection shield. The third patent called "Method for perfecting explosive charges" was less brilliant from a foresight point of view though it proposed valid solutions for the trigger, the tamper, and the rapid obtainment of the critical assembly of a possible explosive device. Finally, nearly a year later, after Alfred Nier's experimental confirmation in March 1940 of Niels Bohr's theoretical prediction that uranium 235, the rare isotope of the mixture in natural uranium, was responsible for fission by slow neutrons, the French took out an additional patent on the advantage of using enriched uranium for the chain reaction. End of quote. 84 In May of 1940, the CNRS, the French research institute in Paris, negotiated an agreement with Belgian mining company Union Miniere, who were the world's biggest producer of uranium, at the time a byproduct of radium mining, about a partnership for the world wide exploitation of these patents. However the agreement was not finalized due to the ongoing events in the war. At the beginning of the war, the French government had approved the development of an energy generator - or a nuclear reactor as we would say today, with the intention of creating an engine for submarines. 85 With the fall of France, Halban and Kowarski travelled to the UK with their supply of heavy water where they were received by their UK counterparts, James Chadwick and John Cockroft. The British were already working on an atomic bomb. In the UK the two conducted an experiment showing that it was possible to create nuclear energy using natural uranium and heavy water. In 1941 the British nuclear project was reorganized and given the name Tube Alloys. In 1942 it was decided to move the work on a plutonium bomb to Canada, and Canada would pay for the project. A lab was set up in Montreal and Halban was put in charge of the project. 86 Halban had negotiated this arrangement by offering to arrange to have the French patents for world wide rights outside of France and the French empire transferred to the UK. In return the French team were to be given a key role in the British nuclear project. The author of the paper I am referencing, Bertrand Goldschmidt, was a section leader in Montreal and a colleague of Halban from France. The Montreal group cooperated with the American Manhattan Project and the two shared information and exchanged visits. 87 However, relations between the two began to break down, with a major cause of this being the Americans being unhappy about the French patents and Halban's arrangement to give the British world wide rights to them. The postwar commercial potential for nuclear power was seen to be huge, and this was a major bone of contention. The extensive participation of ICI (Imperial Chemical Industries) engineers in the Tube Alloys project was also objectionable to the Americans. Presumably this had something to do with potential for ICI being involved in future commercialization of the technology. The American Dupont company, a commercial rival of ICI, was also heavily involved in the American atomic bomb project. The eventual result of this was that the US cut off cooperation with the UK-Canada nuclear project. 88 Finally Halban was forced out of the project at the insistence of the Americans, and he was replaced by John Cockroft who moved to Montreal to take charge of the project. The Americans now restore limited cooperation. Kowarski was put in charge of building a heavy water moderated natural uranium reactor at a new site north of Ottawa at Chalk River. This reactor was turned on on the 5th of September, 1945, three days after Japan's surrender. So in what was supposedly a titanic war for survival, key allies were falling out with respect to their ultimate weapon over issues of patents covering post war commercialization. 89 With the end of the war, the nuclear weapons project in Montreal and Chalk River was wound up. Halban, Kowarski, and Goldschmidt returned to France and Cockroft to the UK where they all played senior roles in the nuclear programs of their respective countries. John Cockroft played an important role in the development of the Magnox reactors which Antoine asked about. The Chalk River Site remains as Canada's main nuclear research centre to this day, and Canada was to continue development of heavy water moderated natural uranium reactors. 90 The first commercial nuclear power plant was commissioned in the UK in 1956, roughly 17 years after the original French nuclear patents. At that time, UK patents had a term of 16 years. While I am not a patent lawyer, it would appear that these patents would likely have expired before nuclear power was ever commercialized. So to answer the question about patents, the first patents on nuclear energy date to before WWII started, and the very first two were about nuclear power plants and it was only the third one which covered nuclear weapons. -------------------- 91 Thanks to other listeners. A number of other listeners made comments saying they were really enjoying the series. I would like to thank the following for their kind words of encouragement. They helped make the work required to do this worthwhile. They are brian-in-ohio mnw Clinton Antoine bjb Kevin O'Brien Trey L'andrew Archer72 Jim DeVore If you have commented but I have forgotten your name, or if the show was recorded before I got a chance to read your comment, I would still like to thank you. 92 Conclusion I would like to thank all the listeners for their kind comments and insightful questions. I hope that I have answered these questions to the satisfaction of everyone. I look forward to hearing from all of you in future podcast episodes including those on other topics. -------------------- Proceedings of the 29th annual conference of the Canadian Nuclear Association and 10th annual conference of the Canadian Nuclear Society. V. 1-3 https://inis.iaea.org/records/m2s41-40917 This has a paper by Bertrand Goldschmidt about the work of the French scientists in Canada. -------------------- Provide feedback on this episode.

HPR's Ashley Mizuo reports on a target letter sent by the State Attorney General to Lt. Gov. Sylvia Luke as part of their investigation; Santana bassist Benny Rietveld presents a new stage production about a Hawaiʻi jazz saxophonist from The Cavalier, an old Honolulu jazz hotspot.

HPR's Savannah Harriman-Pote reports on increased wildfire risks caused by the recent rains; grassroots organization Kupaʻa Kuilima files a lawsuit against a proposed second resort on Turtle Bay.

Former Hawaiʻi Governor George Ariyoshi passes away at 100; HPR reports on the current status of CRB on Molokaʻi.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our membership campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from The Wailers' Aston Barrett Jr. and Joshua David Barrett in an excerpt of a 2019 conversation.

This show has been flagged as Clean by the host. Basic-Filtering 01 Introduction This is the second episode in a four part series on a simple way to create your own HPR podcast episode. 02 This episode will cover the following topics: Basic filtering.. De-essing to improve voice quality. And normalizing to adjust audio levels for easier reviewing. 03 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 FFMPEG and Sox. 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. 04 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. 05 Sources of Noise A question that you may have is "why is there noise in the recording?" There are many sources of undesirable noise. 06 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 the recorded audio. The most common noise signal is what is commonly called "line noise" and 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. 07 You may be familiar with this low frequency hum from when it emanates from large electrical hardware such as transformers as it makes the laminations vibrate. However, it can also work its way indirectly into electronic equipment as well. Good quality audio hardware may filter all or most of this out, but it is present in a lot of consumer grade hardware. 08 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. 09 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 than 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. 10 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 audiophile 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 will have difficulty hearing anything above 8 kHz even with the best quality audio hardware due to hearing loss from environmental noise exposure or age. 11 You can get a good idea of what different frequencies sound like by generating sine waves using either FFMPEG or Sox. Here's an example of generating a 1 kHz sine wave using FFMPEG. A copy of this will be in the show notes. ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=44100:duration=3" 01000hz.flac This creates a sine wave at 1 kHz and at a sample rate of 44.1 kHz for a duration of 3 seconds and saves it to a flac file named 01000hz.flac 12 Here's the same using Sox. sox -n -r 44100 -b 16 01000hz.flac synth 3 sine 1000 The -b 16 specifies using 16 bit audio to encode it, and the "sine 1000" element specifies the frequency in hertz. 13 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 Hz and 12 kHz, and that is being generous. You can probably narrow that, particularly at the top end, without any problems. 14 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 Hz, and for the average female you can set it at 160 Hz. 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. 15 Simple Filters We will now create some simple filters using the same command line software mentioned in a previous episode in this series. These are FFMPEG and Sox. 16 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. A low pass filter passes through frequencies which fall below a certain threshold and blocks frequencies which are above that frequency. 17 In reality there isn't an abrupt cut-off in the filters. Instead there is a gradual roll off or sloping off of amplitude below or 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 the signal for frequencies on the margin. 18 The other reason is that this is how hardware filters traditionally inherently worked when they were 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 fiddling with it in that sort of detail. You will sometimes see filters specified in terms 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. 19 Here is a typical high pass filter using ffmpeg which filters out frequencies below 80 hertz. # High pass filter. ffmpeg -i inputfile.flac -af "highpass=f=80" outputfile.flac Here is a typical low pass filter using ffmpeg which filters out frequencies above 12 kHz. # Low pass filter. ffmpeg -i inputfile.flac -af "lowpass=f=12000" outputfile.flac 20 Here is a filter which combines the two. # Combined filters. ffmpeg -i inputfile.flac -af "highpass=f=80, lowpass=f=12000" outputfile.flac And here is the same thing using Sox. sox inputfile.flac outputfile.flac highpass 80 lowpass 12000 21 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. 22 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, there may be some HPR listeners who are sitting back sipping a glass of wine and listening to your episode on their stereo and who can hear it. That suggests that we ought to do something about it just in case. 23 I will get into how to analyze audio signals in a later episode, but for now just accept that I looked at the frequency spectrum of a sample recording using my hardware and found a large 60 Hz noise spike which I wanted to address. 24 Experimenting with additional high pass frequencies up to 120 Hz did not improve things much with respect to the 60 Hz problem. 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 the this 60 Hz spike we can use a "band reject" filter, which removes a specific band of frequencies. We will use this in combination with the filtering that we have already done above. 25 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. 26 Here's the FFMPEG version. # Using ffmpeg ffmpeg -i input.flac -af "highpass=f=80, lowpass=f=12000, bandreject=f=60:width_type=h:w=20, bandreject=f=50:width_type=h:w=20" output.flac 27 This as the following elements A high pass filter at 80 Hz, A low pass filter at 12 kHz, A band reject filter centred at 60 Hz and with a width of 20 hertz. A similar band reject filter centred at 50 Hz. 28 Here's the Sox version. # Sox version. sox input.flac output.flac highpass 80 lowpass 12000 bandreject 60 20 bandreject 50 20 Note that with sox, don't quote the filter definition strings or else it will result in an error as sox doesn't see enough parameters. This is not a problem with ffmpeg. 29 The band reject filter knocks the stuffing out of the 60 Hz line noise, and the 50 Hz parameter should do the same for that frequency as well. This basic filter 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 that you test it with your voice before making that decision. 30 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 cover that in a later episode. -------------------- 31 De-Essing An additional type of filtering is "de-essing". When recording audio, the microphone or environment may result in "s", "sh", "ch" and possibly other sounds to be exaggerated. These are all higher frequency elements of voice recordings. "De-essing" attempts to soften these sounds by selectively reducing the volume on the frequency band which contains these sounds. 32 Software Filters De-essing is accomplished via software filters. FFMPEG and Sox both have de-essing filters. For FFMPEG, the de-essing filter is built in. For Sox however, we must install an optional plug-in. I will cover this is more detail when I discuss using Sox for de-essing. 33 Do You Need De-Essing? 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 de-essing to it. De-essing 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 a thing called de-essing even existed before I started doing the research to make this podcast episode. However, at this point we are doing things more for fun than out of necessity, so I'll describe it anyway. 34 De-Essing with FFMPEG De-essing with FFMPEG is relatively simple. The filter is 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. 35 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 web site, and from examples written by actual humans. 36 I then experimented with different values to see what effects they had. Since the results are 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 I suspect they would probably work for you as well. 37 Here is a typical de-essing command. ffmpeg -i inputfile.flac -filter_complex "deesser=i=0.5:m=0.5:f=0.5:s=o" -b:a 336k -sample_fmt s16 outputfile.flac 38 The important arguments are i, m, and f. i is intensity for triggering de-essing. The allowed range is 0 to 1. The default is 0. By experimentation I found that "0" means no de-essing, and "1" is maximum de-essing. I found that setting it to "0.5" gave satisfactory results. 39 m is the amount of "ducking on the treble part of sound". The allowed range is 0 to 1. The default is 0.5. By experimentation I found that "1" means no de-essing, and "0" is maximum de-essing. I found that setting it to "0.5" gave satisfactory results. 40 f is how much of the original frequency content to keep when de-essing. The allowed range is 0 to 1. The default is 0.5. By experimentation I found that "1" means no de-essing, and "0" is maximum de-essing. I found that setting it to "0.5" gave satisfactory results. 41 Setting "m" or "f" too high can result in a 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. 42 There is an additional parameter called "s". This controls whether the de-essing filter does anything. Setting it to "o" is the normal and default mode. Setting it to "e" causes it to output just the components that it would normally 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 de-essing. This would be useful in scripts where you want to use a variable to control whether or not to use the de-esser while still creating the expected output file. 43 There are two other elements of the command which were included but are not strictly speaking part of the de-essing filter itself . These are " -b:a 336k" and "-sample_fmt s16". " -b:a 336k" sets the audio bit rate to 336k. "-sample_fmt s16" sets the audio sample format to 16 bit. I found it necessary to specify these in order to prevent the de-essing filter from changing formats. They are not part of de-essing however. 44 De-Essing with Sox You can also de-ess with Sox. However, this is more complex for several reasons. One reason is that Sox does not have its own de-essing filters. Instead it uses optional plug-ins, and you must find and install these. The actual plug in may vary depending on what operating system you are using. The other reason is that it deals with the issue in fairly low level parameters, and so 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 de-ess with Sox, then send in a comment and I will do a short episode on it later. 45 Sox De-Essing Overview To de-ess with Sox, you first need to install the plug-ins. On Linux, these will be the TAP ladspa plug-ins. TAP stands for "Tom's Audio Processing" plugins. ladspa stands for "Linux Audio Developer's Simple Plugin API" To install the TAP plugins on Ubuntu, using the following command. sudo apt install tap-plugins The plug-in we need is called "tap_deesser.so". 46 In order to use the plug-ins, you need to set the path as a variable. On Ubuntu this is. export LADSPA_PATH="/usr/lib/ladspa:" I put the above in the shell script which calls the Sox de-esser. 47 To use the Sox de-esser, you do the following: sox inputfile.flac outputfile.flac ladspa tap_deesser tap_deesser -30 4500 48 tap_deesser tap_deesser tells it which plugin to use. We need to state tap_deesser twice because the first is the name of the ".so" file and the second is the name of the plugin. A single "so" file can contain multiple filters, although in this case there is only one. -30 is the threshold in dB at which to start to apply the filter. 4500 is the frequency in Hz that the filter centres around. 49 The TAP web page has a table of recommended frequencies. These are: Male 'ess' 4500 Hz Male 'ssh' 3400 Hz Female 'ess' 6800 Hz Female 'ssh' 5100 Hz You will need to do some trial and error to find what works best for you. 50 De-Essing Summary De-essing 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. -------------------- 51 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 of your recording to make it easier to listen to when reviewing it. The copy that you send to HPR however should be the original un-normalized version. 52 Sound level is measured in two ways, dB and LUFS. 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 regards, other than to say that just accept LUFS as a unit of perceived loudness that is the international standard. LUFS stands for "Loudness Units referenced to Full Scale", and is part of the EBU R128 standard, where EBU stands for European Broadcast Union. In both cases the measured value is a negative number, with numbers smaller in magnitude being louder. Smaller in magnitude means closer to zero. 53 HPR will adjust the sound level for publication, but if you wish to check the audio before uploading it can help to adjust it to something close to what HPR will do so that 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 flac file itself can be adjusted using ffmpeg. 54 Measuring Volume Level First we need to see what the volume level is for a typical HPR podcast. To do this we use ffmpeg. In this example we are using an episode named "hprpodcast.mp3". Pick an episode which you think is suitable and copy the file to the working directory. 55 In the following script we use a volumedetect filter. The text we want normally outputs to standard error, so we have to do a bit of bashery to redirect this to standard output so it will go through a pipe. We then grep for the string "I:". This will have the average volume level in "loudness units" (LUFS). Then we extract the number, giving us a target LUFS level. 56 ffmpeg -i hprpodcast.mp3 -filter:a ebur128=framelog=quiet -f null /dev/null 2>&1 | grep "I:" | cut -d: -f2 57 Unfortunately I can't find a Sox feature which handles EBU loudness, so we need to work in dB instead. Here is the sox version. However, note that this may not work on mp3s if sox mp3 handing is not installed. 58 sox hprpodcast.mp3 -n stats 2>&1 | grep "RMS lev dB" | rev | cut -d" " -f1 | rev 59 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 LUFS or dB while my own recording was roughly 5 LUFS lower in volume than a typical HPR episode. -------------------- 60 If you Google for the EBU R128 standard the AI result will confidently tell you to use a target of -23 LUFS. However, this is wrong, which shouldn't be of any surprise if you are familiar with using AI. 61 The -23 LUFS 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 -17 LUFS. If I look at the first two HPR episodes that I did, HPR normalized them to -16.8 LUFS and -17.8 LUFS, while the original FLAC files that I submitted were -21.6 LUFS and -22.3 LUFS respectively. 62 So HRP appear to be targeting somewhere around -17 LUFS as well. We will therefore use -17 LUFS as our target for our own copy for review. -------------------- 63 The nice thing about using the EBU filter in FFMPEG is that this is very simple. Here is the FFMPEG version. 64 ffmpeg -i inputfile.flac -af loudnorm=I=-17:TP=-2.0:LRA=7.0 -ar 44.1k outputfile.flac 65 "I" is the LUFS target. LRA is the loudness range target. The default value is 7.0 so I used that. TP sets the maximum true peak. The default value is -2.0. so I used that. -------------------- 66 With Sox 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 dB, do some calculations, and then apply that as a gain factor to the output. 67 First we need to subtract the measured db level from our flac file from the target db 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 simple solution is to do this calculation using bc, the shell arbitrary precision calculator. 68 Then take this new value and use it in a "volume" filter. The number which we give sox is the amount to increase or decrease the volume by. Sox will then output a new file with the new volume level. You can now listen to this file under conditions more closely approximating what it will be like after HPR have done their own audio adjustments and normalizaton on it This helps when listening to the file for any problems before you upload it. 69 Rather than reading 5 lines of complex shell script to you, I will put a copy of it in the show notes. level=$( sox $inputfile -n stats 2>&1 | grep "RMS lev dB" ) leveldb=$( echo "$level" | rev | cut -d" " -f1 | rev ) targetdb="-18.9" volumechange=$(echo "scale=2 ; $targetdb - $leveldb" | bc ) sox $inputfile $outputname gain "$volumechange" -------------------- 70 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, bandreject, etc. If you normalize first, you will be amplifying the noise as well as the desired signal. 71 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. 72 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 than just normalizing and so they need the unnormalized file so that they can do their own normalizing last. -------------------- 73 If at this point you are happy with the recording as is, you are ready to send the *unnormalized* version to HPR. The scripts to implement the features discussed in this episode will be in the show notes. 74 Conclusion In this episode we covered basic filtering using ffmpeg and sox. 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 listen to podcasts. 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. 75 We discussed specific filters to eliminate 50 and 60 Hz electrical power noise. We talked about de-essing, what it was, why you may wish to use it, and some basic de-essing filter implementation details. We discussed normalizing, what it is, why you may wish to use it, and how it relates to podcasting conventions. 76 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 microphone that I use, and I describe how I used filters to deal with that problem. 77 This has been the second episode in a four part series on simple podcasting. -------------------- EBU R128 Loudness Measurement using FFMPEG #!/bin/bash echo "EBU r128 loudness measurement using FFMPEG" for inputfile in *.flac *.mp3 ; do level=$( ffmpeg -i $inputfile -filter:a ebur128=framelog=quiet -f null /dev/null 2>&1 | grep "I:" | cut -d: -f2 ) echo $inputfile $level done -------------------- DB Sound Level Measurement using Sox #!/bin/bash # Sox version. May not work for mp3 if an mp3 format handling is not installed. echo "dB sound level measurement using Sox." for inputfile in *.flac *.mp3 ; do level=$( sox $inputfile -n stats 2>&1 | grep "RMS lev dB" ) leveldb=$( echo "$level" | rev | cut -d" " -f1 | rev ) echo $inputfile $leveldb done -------------------- EBU R128 Loudness Normalization using FFMPEG #!/bin/bash # Adjust the volume to a desired level. for inputfile in *.flac ; do j=$( basename $inputfile ".flac" ) outputname="$j""-normff.flac" ffmpeg -i $inputfile -af loudnorm=I=-17:TP=-2.0:LRA=4.0 -ar 44.1k $outputname echo $outputname done -------------------- DB Sound Level Normalization using Sox #!/bin/bash # Adjust the volume to a desired level. for inputfile in *.flac ; do j=$( basename $inputfile ".flac" ) outputname="$j""-normff.flac" # Measure the volume level and extract the mean volume. level=$( sox $inputfile -n stats 2>&1 | grep "RMS lev dB" ) leveldb=$( echo "$level" | rev | cut -d" " -f1 | rev ) # Calculate the difference in dB desired. Scale specifies the number of decimal places. # Target db is the volume measured on hpr4506 (UCSD-P-System). targetdb="-18.9" volumechange=$(echo "scale=2 ; $targetdb - $leveldb" | bc ) echo "Using sox: File: $inputfile Original level: $leveldb Change by: $volumechange" # Adjust the volume. sox $inputfile $outputname gain "$volumechange" done -------------------- Full processing pipeline for making simple podcasts using FFMPEG #!/bin/bash #!/bin/bash # Full processing pipeline for making simple podcasts. # ====================================================================== # Concatenate multiple flac files into a single flac file. # This is used to combine podcast recorded segments into a single # flac file for uploading to HPR. concataudio () { outputname="$1" # First create the list file. printf "file '%s'n" [0-9][0-9].flac > podseglist.txt # Now concatenate them ffmpeg -f concat -safe 0 -i podseglist.txt "$outputname" rm podseglist.txt } # ====================================================================== # Basic filters. filter () { inputfile=$1 outputname=$2 # Using ffmpeg. # The high and low pass filters. hlpfil="highpass=f=80, lowpass=f=12000" # Band reject filters filter for 60Hz and another for 50Hz. linefil="bandreject=f=60:width_type=h:w=20, bandreject=f=50:width_type=h:w=20" # Using ffmpeg ffmpeg -i $inputfile -af "$hlpfil, $linefil" $outputname } # ====================================================================== # De-Essing. deessing () { inputfile=$1 outputname=$2 option=$3 # De-essing filter. ffmpeg -i $inputfile -filter_complex "deesser=i=0.5:m=0.5:f=0.5:s=$option" -b:a 336k -sample_fmt s16 $outputname } # ====================================================================== # Normalizing the audio to EBU R128 standard for review using ffmpeg. normffmpeg () { inputfile=$1 outputname=$2 # Normalize to EBU R128 standard. ffmpeg -i $inputfile -af loudnorm=I=-17:TP=-2.0:LRA=4.0 -ar 44.1k $outputname } # ====================================================================== # Output an MP3 version to help with reviewing. mp3convert () { inputfile=$1 # Get the name of the file and then create the output file name. j=$( basename $inputfile ".flac" ) outputname="$j"".mp3" # Convert to MP3. ffmpeg -i $inputfile $outputname } # ====================================================================== # Concatenate the separate audio files. concataudio fullpod-unfiltered.flac # Basic filtering. filter fullpod-unfiltered.flac filtered.flac # De-essing. This is the version to send for publishing. # The third argument should be "o" for de-essing, or "i" for pass through without de-essing. deessing filtered.flac fullpod.flac o # Normalized for review. normffmpeg fullpod.flac fullpod-norm.flac # Output an MP3 copy for review. mp3convert fullpod-norm.flac -------------------- -------------------- Provide feedback on this episode.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our membership campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from Rickie Lee Jones in an excerpt of a 2016 conversation.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our membership campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from Kenny G in an excerpt of a 2017 conversation.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our fundraising campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from Yes legend Jon Anderson from one of his appearances over the years. This interview is from 2020 during the pandemic.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our fundraising campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from one of TV host and comedian Bill Maher's appearances over the years. This interview is from 2019.

HPR All Things Considered Host Dave Lawrence offers a big mahalo to everyone supporting HPR now during our fundraising campaign with interview flashbacks from his 17 years on the air at HPR. Today we hear highlights from one of guitar legend John McLaughlin's appearances over the years. This interview is from 2018.

The overview show is back, and this time it's all about the big picture. Which nation is actually in the strongest position heading towards Aachen 2026? We talk about it all the time, but this is putting numbers behind it. Strength, depth, and what the data is really saying at the top of the sport.  While there's a lot of movement across the board, one thing is clear. Great Britain isn't going anywhere. The depth is still there, the results are still coming, and they remain the toughest team to beat. New Zealand bouncing back, Japan showing what's possible, and a number of nations who will feel like there's an opportunity if they can get three good performances on the board when it counts. Highlights Breaking down HPR and what it actually tells us about squad depth Why Great Britain still dominates, and just how far ahead they are Which nations are trending up, and which ones have work to do Why championship eventing feels more open than ever The bigger picture, participation, five-star numbers, and what comes next Guests Sam Watson - Irish five-star rider and EquiRatings co-founder bringing a data-led view of performance at the top of the sport Flair Strips support healthy breathing, reduce airway resistance and help horses perform and recover more comfortably. Learn more or explore the full range at flairstrips.com. UK listeners can shop Flair Strips via Equine Products UK using the code FLAIRUK10 for a discount.

HPR All Things Considered Host Dave Lawrence offers up a big mahalo to everyone donating to HPR by sharing cool interview flashbacks! Today it's The Police, and guitarist Andy Summers, from a 2021 conversation.

This show has been flagged as Explicit by the host. New hosts There were no new hosts this month. Last Month's Shows Id Day Date Title Host 4586 Mon 2026-03-02 HPR Community News for February 2026 HPR Volunteers 4587 Tue 2026-03-03 UNIX Curio #1 - Shell Archives Vance 4588 Wed 2026-03-04 HPR Beer Garden 11 - Belgian Scotch Ale Kevie 4589 Thu 2026-03-05 YouTube Subscriptions 2025 #15 Ahuka 4590 Fri 2026-03-06 Playing Civilization V, Part 9 Ahuka 4591 Mon 2026-03-09 A Bit of Git Lee 4592 Tue 2026-03-10 Happy by shower # 2 Antoine 4593 Wed 2026-03-11 Nuclear Reactor Technology - Ep 8 Generation Four Reactors Whiskeyjack 4594 Thu 2026-03-12 Hackerpublic Radio New Years Eve Show 2026 Episode 2 Honkeymagoo 4595 Fri 2026-03-13 WATER WATER EVERYWHERE! operat0r 4596 Mon 2026-03-16 Adding voice-over audio track created using text to speech on the movie subtitles Ken Fallon 4597 Tue 2026-03-17 UNIX Curio #2 - fgrep Vance 4598 Wed 2026-03-18 Recording good audio using open source tools Shane - StrandedOutput 4599 Thu 2026-03-19 Women in digital and games event Dave Hingley 4600 Fri 2026-03-20 The First Doctor, Part 5 Ahuka 4601 Mon 2026-03-23 How to be a better writer enistello 4602 Tue 2026-03-24 Hackerpublic Radio New Years Eve Show 2026 Episode 3 Honkeymagoo 4603 Wed 2026-03-25 On the Erosion of Freedom in Open Source Software HopperMCS 4604 Thu 2026-03-26 Quick Tips for January 20 26 operat0r 4605 Fri 2026-03-27 Lee locks down his wifey poo Elsbeth 4606 Mon 2026-03-30 My Nerdy Childhood: From Floppy Disks to Dial-Up Dreams Trollercoaster 4607 Tue 2026-03-31 UNIX Curio #3 - basename and dirname Vance Comments this month Past shows hpr3711 (2022-10-24) "Cars" by Zen_Floater2. m0dese7en said: "Additional details on cars" (2026-03-13 16:44:12) hpr4333 (2025-03-12) "A Radically Transparent Computer Without Complex VLSI" by Marc W. Abel. Marc said: "New online home for Dauug|36 and Dauug|18" (2026-03-25 15:18:15) hpr4424 (2025-07-17) "How I use Newsboat for Podcasts and Reddit" by Archer72. أحمد المحمودي said: "Not fixed" (2026-03-31 00:54:19) hpr4509 (2025-11-13) "HPR Beer Garden 5 - Heferweisen" by Kevie. Gan Ainm said: "Hefeweizen" (2026-03-04 06:47:39) Kevie said: "Thanks Gan" (2026-03-13 15:28:45) hpr4553 (2026-01-14) "Nuclear Reactor Technology - Ep 4 Less Common Reactor Types" by Whiskeyjack. Antoine said: "Were/are the designs patented?" (2026-03-18 12:41:35) Whiskeyjack said: "Reply to Antoine" (2026-03-19 03:31:50) Antoine said: "I will" (2026-03-21 02:30:29) hpr4565 (2026-01-30) "HPR Beer Garden 9 - Barley Wine" by Kevie. Aleman said: "Beer Garden" (2026-03-06 19:25:26) hpr4571 (2026-02-09) "Data processing retrospective" by Lee. Archer72 said: "previous generation" (2026-03-03 15:44:12) hpr4573 (2026-02-11) "Nuclear Reactor Technology - Ep 6 Thorium Reactors" by Whiskeyjack. Archer72 said: "Interesting series" (2026-02-28 16:59:15) Whiskeyjack said: "Reply to Archer72" (2026-02-28 23:06:46) Clinton said: "Modern situation." (2026-03-07 11:30:14) Whiskeyjack said: "Reply to Clinton" (2026-03-07 18:42:23) hpr4574 (2026-02-12) "UNIX Curio #0 - Introduction" by Vance. murph said: "Great show, looking forward to more." (2026-03-01 19:21:46) hpr4575 (2026-02-13) "Making First Contact" by Ken Fallon. Archer72 said: "Good to hear 73's" (2026-02-28 15:51:52) hpr4576 (2026-02-16) "Responce to Lee/Elsbeth eps" by operat0r. candycanearter07 said: "relatable episode" (2026-03-10 01:39:18) hpr4577 (2026-02-17) "HPR Beer Garden 10 - Scotch Ale/Wee Heavy" by Kevie. Kevie said: "Upcoming beers" (2026-02-26 18:14:16) hpr4583 (2026-02-25) "Nuclear Reactor Technology - Ep 7 Small Modular Reactors" by Whiskeyjack. brian-in-ohio said: "good shows" (2026-03-02 21:10:12) Whiskeyjack said: "Response to brian-in-ohio for HPR4583 Small Modular Reactors" (2026-03-03 23:38:55) hpr4584 (2026-02-26) "Recording a show, and crappy audio" by Archer72. Dave Lee (thelovebug) said: "Audio quality" (2026-02-27 08:33:24) Kevin O'Brien said: "The Zoom was perfect" (2026-02-27 17:29:43) Archer72 said: "Bad mic" (2026-03-03 15:08:13) jezra said: "false advertising! " (2026-04-03 17:28:05) hpr4585 (2026-02-27) "mpv util scripts" by candycanearter. Windigo said: "mpv fanclub" (2026-02-28 01:55:28) Windigo said: "Re: mpv fanclub" (2026-03-01 05:07:24) Archer72 said: "Second in mpv fanclub" (2026-03-01 08:52:41) candycanearter07 said: "updated script" (2026-03-01 22:35:38) This month's shows hpr4586 (2026-03-02) "HPR Community News for February 2026" by HPR Volunteers. candycanearter07 said: "41:40" (2026-03-01 23:39:18) Whiskeyjack said: "HPR Commnity News discussion on audio" (2026-03-03 23:11:25) hpr4587 (2026-03-03) "UNIX Curio #1 - Shell Archives" by Vance. Archer72 said: "Continuing series" (2026-03-03 15:15:19) xmanmonk said: "uuencode/uudecode on Solaris" (2026-03-05 01:47:53) Vance said: "Thanks, and Solaris" (2026-03-07 20:10:08) Jim DeVore said: "Thanks for the trip down memory lane!" (2026-03-17 01:19:46) hpr4591 (2026-03-09) "A Bit of Git" by Lee. candycanearter07 said: "anecdotal teaching is the best kind" (2026-03-09 04:58:24) hpr4592 (2026-03-10) "Happy by shower # 2" by Antoine. candycanearter07 said: "interesting!" (2026-03-10 04:20:16) Antoine said: "Sharing (response to candycanearter07)" (2026-03-21 02:27:17) hpr4593 (2026-03-11) "Nuclear Reactor Technology - Ep 8 Generation Four Reactors" by Whiskeyjack. Jim DeVore said: "Great series!" (2026-03-17 01:13:51) Whiskeyjack said: "Response to Jim DeVore" (2026-03-17 13:46:31) hpr4596 (2026-03-16) "Adding voice-over audio track created using text to speech on the movie subtitles" by Ken Fallon. folky said: "Interesting solution, but annoying " (2026-02-05 11:54:36) Carsten said: "Amazing project" (2026-02-25 00:29:08) candycanearter07 said: "interesting!!" (2026-03-16 13:38:03) hpr4597 (2026-03-17) "UNIX Curio #2 - fgrep" by Vance. Ken Fallon said: "Time to active use" (2026-03-05 05:58:31) L'andrew said: "Nice job explaining *grep features." (2026-03-18 03:34:11) candycanearter07 said: "informative" (2026-03-18 03:52:52) Vance said: "Expressions" (2026-03-20 18:16:09) hpr4598 (2026-03-18) "Recording good audio using open source tools" by Shane - StrandedOutput. Archer72 said: "Great tips!" (2026-03-19 10:39:24) Ole Aamot said: "GarageJam 6.0.1" (2026-03-24 01:50:51) hpr4600 (2026-03-20) "The First Doctor, Part 5" by Ahuka. Kevie said: "Great series" (2026-03-21 15:22:59) Kevin O'Brien said: "I think I will" (2026-03-21 21:23:38) Archer72 said: "Great series and 2nd continuation " (2026-03-21 22:35:05) hpr4605 (2026-03-27) "Lee locks down his wifey poo" by Elsbeth. Ken Fallon said: "Congratulations" (2026-03-18 11:09:45) Elsbeth said: "Thank you!" (2026-03-27 11:10:10) Trollercoaster said: "Congrats - and now we want all the fun puns!" (2026-03-27 12:58:38) Antoine said: "=)" (2026-03-29 22:39:06) ClaudioM said: "Congratulations to You Both!" (2026-03-30 13:22:43) Paulj said: "Congratulations" (2026-04-04 19:52:01) hpr4606 (2026-03-30) "My Nerdy Childhood: From Floppy Disks to Dial-Up Dreams" by Trollercoaster. Trey said: "Trip down memory lane..." (2026-03-30 14:24:54) xmanmonk said: "Great Episode!" (2026-03-30 16:23:43) Trollercoaster said: "Back to you..." (2026-03-31 08:24:58) Trollercoaster said: "Not to janitors" (2026-03-31 08:26:06) ClaudioM said: "Nerdy Nostalgia!" (2026-03-31 17:20:34) hpr4607 (2026-03-31) "UNIX Curio #3 - basename and dirname" by Vance. xmanmonk said: "Great episode!" (2026-03-31 14:19:12) Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2026-March/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Provide feedback on this episode.

HPR's Ashley Mizuo reports on what a proposed conveyance tax hike could fund; Sister Mary Nelle Gage recalls her work assisting with the adoption of thousands of Vietnamese children as part of Operation Babylift

HPR's Maddie Bender shares the story of a Hawaiʻi Island couple caught up in the immigration crackdown; Kalani High senior Anson Li, ʻIolani senior Jackson Brewer and University of Hawaiʻi freshman Mahealani Jackson talk about how AI is affecting their education

HPR speaks with participants in the latest "No Kings" rally in Honolulu, one of the more than 3,000 protests held across the country last Saturday; HPR's Cassie Ordonio reports on the steps the state is taking to acquire the 120-year-old Wahiawā Dam

This show has been flagged as Clean by the host. Two geeky people, both HPR hosts, decide to sign on the dotted line and do the darn thing and get married. Provide feedback on this episode.

Welcome to Episode 288 of the LinuxLUGcast We are an open podcast/LUG that meets at 9 PM EST every first and third friday of the month using mumble. We encourage anyone listening to join us and participate on the podcast. Check out https://www.linuxlugcast.com/ for the server details. If you have any questions, comments, or topic you would like us to discus and are unable to join us during the live show you can send us email at feedback@linuxlugcast.com Join in the conversation at https://matrix.to/#/#lugcast:minnix.dev Movie List https://etherpad.integrations.element.io/p/e24fde39-0b56-4941-9870-526055295062 Youtube Channel https://www.youtube.com/@thelinuxlugcast Peertube Channel https://nightshift.minnix.dev/c/linux_lugcast/videos Previous Movie:  Obex 2025 https://www.imdb.com/title/tt29544916 Next Movie: Untraceable 2008 https://www.imdb.com/title/tt0880578 https://therokuchannel.roku.com/watch/fd97789694bd514f80be6e092931e4e1 Elle and mordancy:e office with a large Ikea shelve to display our art, collectables, cultural, and religeous items and 2 new computer/office desks from home depo. We were going to buy the 71 inch desks but they would have been difficult to setup in the same room. We bought and  set up the “63 in. Rectangular Brown Wood Computer Desk Study Writing Table for Home Office” https://www.homedepot.com/p/63-in-Rectangular-Brown-Wood-Computer-Desk-Study-Writing-Table-for-Home-Office-BB-U0170CD-XL/329352239 and https://www.homedepot.com/p/63-in-Rectangular-Brown-and-Black-Engineered-Wood-Simple-Computer-Desk-Office-Executive-Desk-for-Home-Office-BB-U0149CD-XL/330445830 GrapheneOS and Motorola news that Gage Hopper posted in the HPR matrix group https://www.youtube.com/watch?v=Y5GrbhB2HHQ Logitech C-U0007 Unifying USB Receiver https://www.amazon.com/Logitech-Unifying-Receiver-Keyboard-Connects/dp/B0058OU8VY Jason Criddle https://jasoncriddle.com/ DstoPar Wireless Mechanical Keyboard https://www.amazon.com/dp/B0G6LL77Z6 New Intel S4520 3.84TB https://www.ebay.com/itm/156180491085?mkcid=2&mkevt=1&mkrid=711-175623-139228-7&mkscid=102&adsetid=9e759d84-03f7-4f9f-b253-735e8ca03382&keyword=nonbrand&norover=1&displaytype=simple Talking about the Apple Neo https://www.apple.com/macbook-neo/ Graphene and Motorola https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/ Keep Android Open https://keepandroidopen.org/ Stockholm syndrome (Minnix) https://en.wikipedia.org/wiki/Stockholm_syndrome DistroWatch https://distrowatch.com/ Framwork Desktop https://frame.work/desktop Framework Laptop 13 Cooler Master Mainboard Case https://frame.work/products/cooler-master-mainboard-case-and-mainboard-12th-gen-intel-core-kit?v=FRANHDCM01 Lobsters is a computing-focused community centered around link aggregation  and discussion, launched on July 3rd, 2012. https://lobste.rs/ CADQuery https://cadquery.readthedocs.io/en/latest/ 1 USD to MXN – Convert US Dollars to Mexican Pesos https://www.xe.com/en/currencyconverter/convert/?Amount=1&From=USD&To=MXN Real ID (in Virginia) https://www.dmv.virginia.gov/licenses-ids/real-id Barrier https://github.com/debauchee/barrier https://www.goodreads.com/series/85195-post-human https://www.bookseriesinorder.com/old-mans-war/ https://fickledragon.com/junkyard-pirate-series/ https://www.bookseriesinorder.com/the-last-reaper/ https://www.marissameyer.com/the-lunar-chronicles-books/ https://www.goodreads.com/series/41588-deathstalker “`bash #myip is a function myip { local ip=”/usr/bin/ip”; local curl=”/usr/bin/curl”; ${ip} -color -brief -family inet address; builtin echo -e “nnPublic IP Address: $(${curl} –ipv4 ifconfig.co)”; unset ip curl; return } “` Our next recording date will be April 3rd, 2026 Our music is “Downright” provided by Klaatu and Broam and we would like to thank Minnix for the mumble server

This show has been flagged as Clean by the host. We'll explain why we're doing it, what it is, and cover some useful tools along the way. I've been watching movies recommended to me by my colleagues. As I work for a global company, the recommendations are often “Foreign Language”, which by definition is every movie to someone. It's often difficult to read the subtitles, or they are distracting from the acting. So I thought of converting the subtitles to speech for inclusion as an audio track, to produce a Voice Over or Lectoring audio track. Lectoring aka Voice Over Translations First used is soviet countries to read the news and propaganda from a lectors - the first podcasts ? In Polish, lektor is also used to mean “off-screen reader” or “voice-over artist”. A lektor is a (usually male) reader who provides the Polish voice-over on foreign-language programmes and films where the voice-over translation technique is used. This is the standard localization technique on Polish television and (as an option) on many DVDs; full dubbing is generally reserved for children's material. https://en.wikipedia.org/wiki/Lector#Television Example: Night of the Living Dead To give you an idea of what this sounds like I'm going to play you an example of the out of copyright movie, Night of the Living Dead . In the United States, Night of the Living Dead was mistakenly released into the public domain because the original distributor failed to replace the copyright notice when changing the film's name Original First the original sound track, then the same clip with the voice over track. Voice Over Proof of Concept As a native English speaker I find it difficult to follow those Voice Over tracks as I am trying to focus on the underlying audio. In discussions with Polish friends, it seems that this is not a problem when Polish is your native language. To put that to the test I wanted to try it out on a movie to see if that were indeed the case. I asked on Mastodon for a non English movie that was Creative Commons but did have English Subtitles, and HPR host Windigo had the answer. 2009 Nasty Old People is a 2009 Swedish film directed by Hanna Sköld, Tangram Film. It premiered on 10 October 2009 at Kontrapunkt in Malmö, and on file sharing site The Pirate Bay. The film is available as an authorized and legal download under the Creative Commons license CC BY-NC-SA. So my idea was to take each bit of subtitle text, convert it to audio, then have the generated audio play at the same time the subtitle appears on the screen. We use piper to process shows here on HPR, and we also generate srt, or SubRip subtitle files for each show. SRT or SubRip files are the easiest subtitle file to work with. From https://en.wikipedia.org/wiki/SubRip The SubRip file format is described on the Matroska multimedia container format website as “perhaps the most basic of all subtitle formats.” SubRip (SubRip Text) files are named with the extension .srt , and contain formatted lines of plain text in groups separated by a blank line. Subtitles are numbered sequentially, starting at 1. The timecode format used is hours:minutes:seconds,milliseconds with time units fixed to two zero-padded digits and fractions fixed to three zero-padded digits (00:00:00,000). The comma (,) is used for fractional separator . A numeric counter identifying each sequential subtitle The time that the subtitle should appear on the screen, followed by –> and the time it should disappear Subtitle text itself on one or more lines A blank line containing no text, indicating the end of this subtitle I downloaded the movie from the Internet Archive , and then used Piper voice to convert a minutes worth of subtitles. piper_voice: A fast and local neural text-to-speech engine that embeds espeak-ng for phonemization. GPL-3.0 license Once I had the audio prepared for a sample of the subtitles, it was over to audacity to create a new subtitle audio track. Audacity is the world's most popular audio editing and recording app GPL v2 or later, Timing the segments would be a problem, if it were not for the fact that Audacity supports srt files as Labels. File > Import > Lables. Then select the srt file The subtitle track with the text of the audio will be displayed. I could then Import each Audio segment and line them up with the subtitle track for to get the correct timing. Each subtitles segment created a new separate audio file which I then exported. I then used Kdenlive to open the video and import the audio and subtitle tracks. Kdenlive: is the acronym for KDE Non-Linear Video Editor. It works on Linux, Windows, macOS, and BSD. GPL-3.0-or-later There is a good article on adding by Jean-Marc on How to Add Subtitles Easily in Kdenlive Project > Subtitles > Add Subtitle Track Select the Subtitle file Align the subtitle and audio track. After rendering the segment out I was satisfied that this was something worth doing. The script The script can be found on the episode page for this show on the HPR site, and I put it together as a proof of concept. It creates a new audio track for the subtitles, and merges this with the original sound track to create a new selectable sound track. It begins by creating a length of silent audio that is as long as up to the first subtitle time segment begin timestamp. The first subtitle segment is converted from text to speech using Piper voice That segment of audio is added to the initial silence track. We check the total length so far, and then see if there is supposed to be silence between the last and next subtitle segment begin timestamp. If there is, then a filler piece of silence is added until the next subtitle should appear. If not then the audio for both subtitles play immediately after one another. I was worried that the subtitle audio would then lag behind the on screen dialogue but it works surprisingly well. Even long series of dialogue sort themselves out after a bit. We do this over and over again for each subtitle, right up to the very end of the movie. This new subtitle to speech audio track is then merged back into the media file as a new audio track. 96 00:15:06,240 --> 00:15:10,640 It will be two years before it's this big 97 00:15:12,840 --> 00:15:17,840 But don't you bother. By then I'll be long gone 98 00:15:19,840 --> 00:15:22,400 It was just a question 99 00:15:22,880 --> 00:15:25,480 Porridge? Original First the original sound track, then the same clip with the voice over track. Voice Over Lessons learned Now that I have done this for a lot of movies, there a few tips for getting the best output. The creation of the audio track usually goes well, but you can run into issues with the merging of the new track back into the movie. Preparation The first thing you need is a subtitle file which will be the basis of the voice you will be listening to. It should be good quality so that it matches when the actors speak. It's important to clean up this before you use it, fixing spelling mistakes and removing html that will get rendered. Listening to three hours of “I L Zero ve y Zero u”, or “less than forward slash I, greater than”, or “L am from Lndia” can get a bit tedious. You should also try and get versions that translate the songs as well. Getting a SRT file from the media. As many Subtitles are taken from a DVDs they can often be poor Optical character recognition versions of the bitmap-based streams. So a picture of string “Hello World” rather than the letters. ffmpeg By far the easiest and best way to get the subtitles is to extract it from the movie itself, provided it's a separate track. ffmpeg is a complete, cross-platform solution to record, convert and stream audio and video. LGPL-2.1-or-later, GPL-2.0-or-later https://ffmpeg.org/ ffmpeg -y -hide_banner -loglevel error -txt_format text -i "${this_movie_file}" "${this_srt_file}" Getting a SRT file from the web. If that fails you can try to get the subtitle files from the Internet. https://www.opensubtitles.org Select your language with the highest subtitle rating. You can check the media using the mpv media player. mpv is a media player based on MPlayer and mplayer2. It supports a wide variety of video file formats, audio and video codecs, and subtitle types. GPLv2+, parts under LGPLv2.1+, some optional parts under GPLv3 https://mpv.io/manual/master/ Name the srt file with the same prefix as the movie and mpv will play it. You can also use the --sub-files= option as well. mpv "${this_movie_file}" --sub-files="${this_srt_file}" Scrub through the file to see if the timing is correct. The subtitles can be toggled using the j key. Fixing Timing issues It's very important to get the subtitles to align, otherwise the voices will be out of sync. When the subtitles don't match up, it's usually that they need to have the start offset corrected. ffsubsync will automatically try and adjust the offset of the first subtitle to the first use of speech in a movie. ffsubsync: Language-agnostic automatic synchronization of subtitles with video, so that subtitles are aligned to the correct starting point within the video. MIT license https://github.com/smacke/ffsubsync pip install ffsubsync ffs video.mp4 -i unsynchronized.srt -o synchronized.srt LosslessCut will allow you to quickly remove additional trailers, or ads, at the beginning, so that ffsubsync will have a better chance of working if they are trimmed away. LosslessCut: aims to be the ultimate cross platform FFmpeg GUI for extremely fast and lossless operations on video, audio, subtitle and other related media files. GPL-2.0 license https://github.com/mifi/lossless-cut If that fails to match up the subtitles, you can use mpv keyboard shortcuts , move to the first speech segment an then press the Ctrl+Shift+Left and Ctrl+Shift+Right to adjust subtitle delay so that the next or previous subtitle is displayed. It will also show a number giving the miliseconds the delay is, eg -148416 miliseconds or -148.416 seconds. You can use many tools to adjust the subtitles, and I tried out SRT Offset . srt-offset: A simple command-line tool to offset SRT subtitle files. This tool allows you to adjust the timing of subtitles in SRT files, which can be useful when subtitles are out of sync with the video. MIT license srt-offset -i input.srt -offset -148.416 -o output.srt Manually adding the new subtitle to speech audio track If that presents an issue then you can use avidemux to just add the new audio track. Avidemux: is a free video editor designed for simple cutting, filtering and encoding tasks. GPL V2 Open Avidemux, and select “File > Open”, to select the movie. Then go to “Audio > Select Track” Select the next unselected track and tick “Enabled”, “Add Audio Track” Then pick the new mixed track, in this example .~NastyOldPeople_mixed.mp3 Conclusion I now find it much easier to watch a movie with the voice over track. It gets to a point where I don't even notice it is there and just hear the actors speak in their own language, and I just know what they are saying. Links 2009 Nasty Old People A Spanish voice-over translation avidemux by Jean-Marc on How to Add Subtitles Easily in Kdenlive container format Decimal separator extension ffmpeg ffmpeg on wikipedia ffsubsync GPL-3.0 license GPL v2 or later Kdenlive LGPL-2.1 LosslessCut Matroska MIT license Movie on Archive.org mpv mpv keyboard shortcuts mpv wikipedia Nasty Old People from the Internet Archive Night of the Living Dead Noc żywych trupów | Film grozy | Polski lektor OpenSubtitles opensubtitles.org Optical character recognition Piper voice SRT Offset srt, or SubRip subtitle files SubRip Timecode Voice-over translation Whisper Provide feedback on this episode.

Hawaiʻi economist Carl Bonham discusses how the rise in global oil prices after U.S. military strikes on Iran may affect Hawaiʻi energy costs; HPR's Cassie Ordonio reports on what's causing a shortage of ADHD medication

This show has been flagged as Explicit by the host. New hosts Welcome to our new hosts: Vance, not_toby. Last Month's Shows Id Day Date Title Host 4566 Mon 2026-02-02 HPR Community News for January 2026 HPR Volunteers 4567 Tue 2026-02-03 Movie Recommendations for Hackers Deltaray 4568 Wed 2026-02-04 Book reading The Cuckoo's Egg by Cliff Stoll Henrik Hemrin 4569 Thu 2026-02-05 Kiosk with guest mode on Linux Klaatu 4570 Fri 2026-02-06 Playing Civilization V, Part 8 Ahuka 4571 Mon 2026-02-09 Data processing retrospective Lee 4572 Tue 2026-02-10 Uncommon Commands, Episode 3 - strace Deltaray 4573 Wed 2026-02-11 Nuclear Reactor Technology - Ep 6 Thorium Reactors Whiskeyjack 4574 Thu 2026-02-12 UNIX Curio #0 - Introduction Vance 4575 Fri 2026-02-13 Making First Contact Ken Fallon 4576 Mon 2026-02-16 Responce to Lee/Elsbeth eps operat0r 4577 Tue 2026-02-17 HPR Beer Garden 10 - Scotch Ale/Wee Heavy Kevie 4578 Wed 2026-02-18 Alex's journey into Amateur Radio thelovebug 4579 Thu 2026-02-19 Happy by shower Antoine 4580 Fri 2026-02-20 The First Doctor, Part 4 Ahuka 4581 Mon 2026-02-23 Sharp Intake of Breath City (A.K.A.) How I learnt to stop worrying about the fork bomb not_toby 4582 Tue 2026-02-24 Hackerpublic Radio New Years Eve Show 2026 Episode 1 Honkeymagoo 4583 Wed 2026-02-25 Nuclear Reactor Technology - Ep 7 Small Modular Reactors Whiskeyjack 4584 Thu 2026-02-26 Recording a show, and crappy audio Archer72 4585 Fri 2026-02-27 mpv util scripts candycanearter Comments this month These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 37 comments in total. Past shows There are 2 comments on 2 previous shows: hpr4562 (2026-01-27) "Software development doesn't end until it's packaged" by Klaatu. Comment 1: Steve Barnes on 2026-02-03: "(Yeah!)" hpr4564 (2026-01-29) "MakeMKV error" by Archer72. Comment 1: candycanearter07 on 2026-02-05: "regression testing?" This month's shows There are 35 comments on 11 of this month's shows: hpr4566 (2026-02-02) "HPR Community News for January 2026" by HPR Volunteers. Comment 1: Whiskeyjack on 2026-02-03: "Community News for January - Scheduling of Episodes"Comment 2: Ken Fallon on 2026-02-04: "response to Whiskeyjack"Comment 3: Whiskeyjack on 2026-02-04: "response to Ken Fallon - Episode Scheduling Guidelines"Comment 4: Ken Fallon on 2026-02-04: "You're right"Comment 5: candycanearter07 on 2026-02-06: "my two cents"Comment 6: Whiskeyjack on 2026-02-06: "Response to candycanearter07 on episode scheduling"Comment 7: Ken Fallon on 2026-02-07: "re "reschedule shows which don't need to be on a specific date forwards or backwards"" hpr4567 (2026-02-03) "Movie Recommendations for Hackers" by Deltaray. Comment 1: Kinghezy on 2026-02-03: "Office space lumbergh"Comment 2: Antoine on 2026-02-04: "An attractive invitation to watch"Comment 3: Henrik Hemrin on 2026-02-04: "Inspiring recommendations"Comment 4: ClaudioM on 2026-02-05: "Awesome Episode!"Comment 5: Jim DeVore on 2026-02-06: "Great Show!"Comment 6: hobs on 2026-02-23: "Loved the show!" hpr4569 (2026-02-05) "Kiosk with guest mode on Linux" by Klaatu. Comment 1: operat0r on 2026-01-18: "weee"Comment 2: candycanearter07 on 2026-02-05: "very informative!"Comment 3: Jim DeVore on 2026-02-06: "I learned some things that I will try out"Comment 4: candycanearter07 on 2026-02-06: "RE: I learned some things that I will try out" hpr4571 (2026-02-09) "Data processing retrospective" by Lee. Comment 1: Henrik Hemrin on 2026-02-10: "Conversation"Comment 2: Beeza on 2026-02-18: "A Special Episode" hpr4572 (2026-02-10) "Uncommon Commands, Episode 3 - strace" by Deltaray. Comment 1: Ken Fallon on 2026-01-13: "My future self thanks you"Comment 2: candycanearter07 on 2026-02-10: "fantastic learning and debugging tool!"Comment 3: Some Guy on the Internet on 2026-02-11: "It's MAGIC!"Comment 4: Paulj on 2026-02-18: "Great Information" hpr4574 (2026-02-12) "UNIX Curio #0 - Introduction" by Vance. Comment 1: brian-in-ohio on 2026-02-12: "This will be a good series"Comment 2: Vance on 2026-02-14: "Thanks, brian-in-ohio!"Comment 3: Paulj on 2026-02-18: "Thanks for your first show, and upcoming series!" hpr4576 (2026-02-16) "Responce to Lee/Elsbeth eps" by operat0r. Comment 1: Elsbeth on 2026-01-16: "Thank you" hpr4577 (2026-02-17) "HPR Beer Garden 10 - Scotch Ale/Wee Heavy" by Kevie. Comment 1: Gan Ainm on 2026-02-18: ""Scotch" Ale from the Baltic Sea" hpr4578 (2026-02-18) "Alex's journey into Amateur Radio" by thelovebug. Comment 1: Archer72 on 2026-02-17: "Congrats!"Comment 2: Trey on 2026-02-18: "Congratulations! " hpr4579 (2026-02-19) "Happy by shower" by Antoine. Comment 1: candycanearter07 on 2026-02-20: "timing"Comment 2: Antoine on 2026-02-26: "Re # 1 -" hpr4581 (2026-02-23) "Sharp Intake of Breath City (A.K.A.) How I learnt to stop worrying about the fork bomb" by not_toby. Comment 1: Archer72 on 2026-02-17: "First episode"Comment 2: Trey on 2026-02-23: "Welcome!"Comment 3: Steve Barnes on 2026-02-24: "Potted Plant Emoji" Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2026-February/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page.Provide feedback on this episode.

HPR's Catherine Cluett Pactol reports on the challenges facing business owners in Lahaina; Kapena Baptista talks about his win at the Ka Makou Kōnane Invitational Tournament, held earlier this month

Photo: A wide shot of the west side of the WélmeltiɁ Preserve in north Lake Tahoe, Calif. (Courtesy Elizabeth Carmel) The Washoe Tribe announced its acquisition of more than 10,000 acres of land north of Lake Tahoe. This new WélmeltiɁ Preserve marks the largest tribal land return in the Sierra Nevada and third largest in California. KUNR's Mariel Day has more. The Washoe Tribe recently finalized the purchase of the land in partnership with organizations like the Wildlife Conservation Board. The land spans across from the northeast of Lake Tahoe and to about 20 miles north of Reno. Washoe Tribal Chairman Serrell Smokey says this is an opportunity for the tribe to revitalize their traditional practices, stewardship and language preservation. “The Washoe People, being removed from our lands, fought hard to get every little bit back, and now we actually have something to call ours.” Although the preserve is the first under the Waší·šiw Land Trust, they hope to acquire more of the Washoe homelands. In the meantime, Smokey hopes to start restoring the land and focus on conserving the wildlife and its natural resources – while ensuring it's a safe place for everyone. Super Bowl Halftime headliner Bad Bunny recently won three Grammys, including Album of the Year. He's from Puerto Rico and one song explores colonization in his home and Hawaiʻi. HPR's Cassie Ordonio spoke with Puerto Ricans and Hawaiians last year about the similarities between the islands. Bad Bunny's song, “Lo Que Le Paso A Hawaii”, translates to what happened to Hawaiʻi. Many locals say it highlights stark similarities and is a reminder of the islands' colonial past. Daniel Kauwila Mahi is a Native Hawaiian artist. He interpreted the song as Bad Bunny protecting his homeland by taking a political stance against statehood. Puerto Rico became a U.S. territory in 1898, six years after the overthrow of the Hawaiian Kingdom. Mahi underscored that Native Hawaiian musicians have been raising issues of over tourism and sovereignty rights. These artists include, but are not limited to, Sudden Rush, Braddah Iz, and “Israel Kamakawiwoʻole's Hawai‘i ‘78”. “For this broader conversation is how Kanaka Maoli and Latino culture have been. through music since Paniolo came to Hawaii and our have have influenced each other for a lot longer than people think.” Angel Santiago-Cruz is a 69-year-old Puerto Rican who has lived in Hawai‘i for about 40 years. He joined the U.S Army with a guarantee to be stationed in Hawaiʻi. He wanted to see what statehood looks like. “What are you going to lose?” One lyric that stood to him was to never forget the lelolai. Santiago-Cruz says it's an expression from the jibaro, which is a person who is connected to the land. “When the Hawaiians say, ea, that’s an expression for your Hawaiianness, that’s an expression to the connection to the island. Lelolai is the same.” Get National Native News delivered to your inbox daily. Sign up for our daily newsletter today. Download our NV1 Android or iOs App for breaking news alerts. Check out today’s Native America Calling episode Friday, February 20, 2026 – Remembering Osage leader Jim Gray

In this episode of FWRD, hosts Corey Smith and Erick Jauregui break down what dealerships must do to professionalize the service advisor role in 2026 and beyond. From KPI literacy and daily coaching to AI adoption and video multipoint inspections, this conversation outlines a blueprint for transforming service departments into frontline revenue engines.You'll learn:Why one-time training fails and how to build a true practice cultureThe KPIs every service advisor must understand (ELR, approval rate, HPR, declined services)How AI tools like video MPIs and automated scheduling will reshape advisor workflowsWhy service must shift from “after sale” to lifetime ownership experienceHow integrating F&I knowledge into service drives retention and extended warranty revenueThe importance of visible scoreboards, daily huddles, and positive reinforcement coachingIf you want to increase approval rates, raise effective labor rate, improve CSI, and build long-term customer loyalty, this episode delivers the strategy.Service is no longer a back-end department. It is the dealership's competitive advantage.

Office of Hawaiian Education Director Kauʻi Sang talks about the Kaiapuni placement request process; HPR's Maui Nui reporter Catherine Cluett Pactol reports on a Hawaiian language immersion classroom on Molokaʻi

HPR's Ashley Mizuo talked with Lt. Gov. Sylvia Luke on details of a January 2022 meeting where she received two checks amid a current investigation on an "influential lawmaker" accused of accepting $35,000; New York Times journalist Jodi Kantor on her career and what she learned along the way

Professor Rudy Guevarra Jr., author of "Aloha Compadre: Latinx in Hawaiʻi," discusses the response to a hit new song by singer Bad Bunny about Hawaiʻi's history of colonization; HPR's Catherine Cluett Pactol reports on how Kalaupapa on Moloka'i's north shore is facing a big change

This show has been flagged as Explicit by the host. New hosts Welcome to our new hosts: Jim DeVore, Carmen-Lisandrette. Last Month's Shows Id Day Date Title Host 4544 Thu 2026-01-01 Uncommon Commands, Episode 2 Deltaray 4545 Fri 2026-01-02 YouTube Subscriptions 2025 #12 Ahuka 4546 Mon 2026-01-05 HPR Community News for December 2025 HPR Volunteers 4547 Tue 2026-01-06 Cheap Yellow Display Project Part 6: The speed and timing of Morse Trey 4548 Wed 2026-01-07 YouTube Subscriptions 2025 #13 Ahuka 4549 Thu 2026-01-08 [deprecated] Pomodoro Task Tool (pomotask.sh) candycanearter 4550 Fri 2026-01-09 Playing Civilization V, Part 7 Ahuka 4551 Mon 2026-01-12 “Elsbeth in IT: Since '97” (Part 2) Elsbeth 4552 Tue 2026-01-13 Printer Conspiracy MrX 4553 Wed 2026-01-14 Nuclear Reactor Technology - Ep 4 Less Common Reactor Types Whiskeyjack 4554 Thu 2026-01-15 How I do todo Jim DeVore 4555 Fri 2026-01-16 HPR Beer Garden 8 - Belgian Christmas Ales Kevie 4556 Mon 2026-01-19 Nitro man! RC Cars operat0r 4557 Tue 2026-01-20 Why I prefer tar to zip Klaatu 4558 Wed 2026-01-21 YouTube Subscriptions 2025 #14 Ahuka 4559 Thu 2026-01-22 Enkele off line vertaaltools Ken Fallon 4560 Fri 2026-01-23 Arthur C. Clarke: Other Works, Part 2 Ahuka 4561 Mon 2026-01-26 A bit about Mission:Libre, a new project for 11-14 year olds in free software Carmen-Lisandrette 4562 Tue 2026-01-27 Software development doesn't end until it's packaged Klaatu 4563 Wed 2026-01-28 Nuclear Reactor Technology - Ep 5 Fast Reactors Whiskeyjack 4564 Thu 2026-01-29 MakeMKV error Archer72 4565 Fri 2026-01-30 HPR Beer Garden 9 - Barley Wine Kevie Comments this month These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 20 comments in total. Past shows There are 6 comments on 5 previous shows: hpr4313 (2025-02-12) "Why I made a 1-episode podcast about a war story" by Antoine. Comment 3: Ken Fallon on 2026-01-23: "Spammer" hpr4424 (2025-07-17) "How I use Newsboat for Podcasts and Reddit" by Archer72. Comment 7: Ken Fallon on 2026-01-03: "Some podcast aggregators show ccdn.php as file name #321" Comment 8: Archer72 on 2026-01-05: "Re: download-filename-format for HPR podcasts" hpr4532 (2025-12-16) "Cheap Yellow Display Project Part 5: Graphical User Interface " by Trey. Comment 2: Ken Fallon on 2026-01-10: "Possible Graphics Library" hpr4536 (2025-12-22) "Welcome to the Linux Community" by Deltaray. Comment 6: Archer72 on 2026-01-05: "Re: Good talk CliMagic" hpr4543 (2025-12-31) "Nuclear Reactor Technology - Ep 3 Reactor Basics" by Whiskeyjack. Comment 2: Kevin O'Brien on 2026-01-01: "Really enjoying this series" This month's shows There are 14 comments on 9 of this month's shows: hpr4546 (2026-01-05) "HPR Community News for December 2025" by HPR Volunteers. Comment 1: Archer72 on 2026-01-06: "Nuclear Reactor series"Comment 2: Henrik Hemrin on 2026-01-07: "Linux" hpr4551 (2026-01-12) "“Elsbeth in IT: Since '97” (Part 2)" by Elsbeth. Comment 1: operat0r on 2026-01-15: "White Male" hpr4552 (2026-01-13) "Printer Conspiracy" by MrX. Comment 1: candycanearter07 on 2026-01-24: "printer issues" hpr4554 (2026-01-15) "How I do todo" by Jim DeVore. Comment 1: brian-in-ohio on 2026-01-17: "Welcome"Comment 2: candycanearter07 on 2026-01-24: "good first show!" hpr4555 (2026-01-16) "HPR Beer Garden 8 - Belgian Christmas Ales" by Kevie. Comment 1: KarldaTech on 2026-01-16: "Christmas Ale" hpr4557 (2026-01-20) "Why I prefer tar to zip" by Klaatu. Comment 1: candycanearter07 on 2026-01-20: "interesting experiment" hpr4559 (2026-01-22) "Enkele off line vertaaltools " by Ken Fallon. Comment 1: ClaudioM on 2026-01-23: "Just What I Needed!"Comment 2: mnw on 2026-01-26: "Great Recommendations!" hpr4561 (2026-01-26) "A bit about Mission:Libre, a new project for 11-14 year olds in free software" by Carmen-Lisandrette. Comment 1: Henrik Hemrin on 2026-01-27: "Happy to learn about the project"Comment 2: candycanearter07 on 2026-01-28: "cool project" hpr4563 (2026-01-28) "Nuclear Reactor Technology - Ep 5 Fast Reactors" by Whiskeyjack. Comment 1: mnw on 2026-01-29: "Great Series"Comment 2: Whiskeyjack on 2026-01-29: "hpr4563 :: Nuclear Reactor Technology - Ep 5 Fast Reactors" Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2026-January/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Provide feedback on this episode.

HPR's Ashley Mizuo says affordability ranks among lawmakers' top priorities heading into the new legislative session; Musician and kumu hula Robert Cazimero discusses the new exhibition "Ke Kilo Lani," which highlights his work as a steward of Hawaiian cultural heritage

HPR heads to the state Capitol for opening day of the 2026 legislative session; State lawmakers plan to put forward measures regulating AI use among kids

This show has been flagged as Clean by the host. Dave and Kevie bring the HPR listeners another festive edition of the Beer Garden, with the focus turning to Belgian Christmas ales. Kevie discovered a scan of the original advert in the Journal De Charleroi from 1896 Translation: Christmas beer has arrived at the Arabian horse and the globe, these two establishments so famous for Anglaise beers. Go and taste it, because Christmas is only sold for a short time. In this episode Dave samples Baby Jesus by Brouwerij 't Verzet and Kevie tries out La Binchoise Speciale Noel . Connect with the guys on Untappd: Dave Kevie The intro sounds for the show are used from: https://freesound.org/people/mixtus/sounds/329806/ https://freesound.org/people/j1987/sounds/123003/ https://freesound.org/people/greatsoundstube/sounds/628437/ Provide feedback on this episode.

This show has been flagged as Clean by the host. Hello, again. This is Trey. Welcome to part 6 in my Cheap Yellow Display (CYD) Project series. Thank you for hanging in there with me on this rambling series. If you wish to catch up on earlier episodes, you can find them on my HPR profile page https://www.hackerpublicradio.org/correspondents/0394.html To review, my project is to build a portable morse code "Keyer memory" which can be connected to any of my amateur HF transceiver radios by simply plugging it in to the code key input port. This is based around an ESP32 platform which comes prepackaged on a yellow PC board with a color touchscreen display, WIFI, and Bluetooth. We fondly call this contraption the Cheap Yellow Display. So far, I have defined the necessities, collected the required hardware, and failed miserably building the graphical user interface (GUI). While I sort out the technical challenges getting my GUI code to play nicely with the CYD's touchscreen, it is important that we spend some time discussing Morse code itself, and the timing standards we will need to follow. I am not going to dive too deeply into the history behind telegraphs and Morse code, but it is very interesting. If you want to learn more, Wikipedia has the origins and evolution written out quite nicely at https://en.wikipedia.org/wiki/Morse_code For our purposes, we will fast forward from the year 1820 (When telegraphy began) all the way to 1865 when the International Telecommunication Union (ITU) standardized, what it called "International Morse Code". When I say Morse Code for the remainder of this podcast, I am referring to this ITU International Morse Code. Morse code typically includes the following characters: The 26 letter basic Latin alphabet The Indo-Arabic numerals 0 to 9 There is also a single accented Latin letter (É), which is written as an E with an accent mark, and a handful of punctuation marks. These characters are encoded using a sequence of short and long signals. Each short signal is referred to as a dit . Each long signal is referred to as a dah . At a young age, I began to refer to them as dots and dashes, as this is how they are usually written. For example, the letter "A" consists of a single dit followed by a single dah. When written out this would look like a period followed by a hyphen (what some might call a minus sign) .- This encoding method allows messages to be sent by turning on and off an electrical signal. This could result in a light flashing or a tone sounding to the pattern of the signal. The timing of a dit and dah, along with the spacing between them is carefully defined. Morsecode.world does a great job explaining the timing, and you can find their explanation at https://morsecode.world/international/timing/ It all starts with the dit, or more accurately, the amount of time the dit signal is turned on. We will call this length of time 1 unit. We will get to the actual length of time for a unit later in this episode. For now, it is just one unit. So, if a dit is 1 unit long, a dah will be 3 units long, so there is an obvious and consistent difference between a dit and a dah. Also, empty space between elements of the same character is 1 unit long. The space between characters should be 3 units long. Let's demonstrate using the letters H, P, & R. An "H" would be 4 dits …. A "P" would be 1 dit followed by 2 dahs and ending with 1 dit .--. An "R" would be 1 dit followed by 1 dah and ending with 1 dit .-. Remember when we send these grouped together like a word, we need 3 units of spacing between each character. You can hear this now. This is Morse code for the letters "HPR" at 15 words per minute .... .--. .-. That is the perfect segue to the next section, words per minute. The speed of morse code is measured in "words per minute". But how do you calculate this when some characters are short (Like the letter "E" which is only a single dit long), and other characters are long (Like the letter "J" which starts with a single dit and is followed by 3 dahs)? And that's just letters. What about words? We have short words and long words. How can we standardize on words per minute with so much diversity of length? Well, thanks to the French, we have a quite elegant solution to this problem. Well, not the French in general. Just PARIS. PARIS is the standard word which has been agreed upon to be used for determining the speed of Morse code. The word PARIS is 50 units long. "P" = dit(1) + (1) + dah(3) + (1) + dah(3) + (1) + dit(1) = 11 units {Space between letters} = 3 units "A" = dit(1) + (1) + dah(3) = 5 units {Space between letters} = 3 units "R" = dit(1) + (1) + dah(3) + (1) + dit(1) = 7 units {Space between letters} = 3 units "I" = dit(1) + (1) + dit(1) = 3 units {Space between letters} = 3 units "S" = dit(1) + (1) + dit(1) + (1) + dit(1) = 5 units {Space between words} = 7 units 11+3+5+3+7+3+3+3+5+7 = 50 units Here is the word PARIS sent at 15 WPM .--. .- .-. .. ... Morsecode.world again does a great job explaining the maths for how many milliseconds long a dit should be for a specific WPM of code ( https://morsecode.world/international/timing/ ) But, no... We could not keep it that simple. Some guy named Donald R. "Russ" Farnsworth had to complicate things and increase the gaps between letters and words to make interpreting code much easier. There are even more maths for Farnsworth timing... Wait a minute. When did I start saying "Maths" instead of "Math" like a normal North American? What is the reasoning around pluralizing "Math" anyways? Which way is more original English, "Math" or "Maths"? This sounds like a show idea for someone other than me. If you know or are interested in researching it, I look forward to listening to your show in the future. ANYWAYS, there IS much more MATH about Farnsworth timing on another page on Morsecode.world. ( https://morsecode.world/international/timing/farnsworth.html ). But I don't want to get into all of it in detail here. Not when there is a shortcut we can use in our code. Simplified, we can take 1,200 and divide it by the WPM we desire, and it will give us a close enough approximation of the number of milliseconds long a dit should be. For the 15 WPM messages you have heard throughout this episode, a dit was 1200/15 = 80 ms in length. If I speed it up to 20 WPM (The speed at which I try to practice) a dit will be 1200/20 = 60 ms long. This will be an important calculation for us as we develop the code we will later be using to construct our messages using the CYD. And this is also a good stopping point so that I can get back to trying to build that infernal GUI. Provide feedback on this episode.

This show has been flagged as Explicit by the host. New hosts There were no new hosts this month. Last Month's Shows Id Day Date Title Host 4521 Mon 2025-12-01 HPR Community News for November 2025 HPR Volunteers 4522 Tue 2025-12-02 Lee interviews Elsbeth about SL Shop and Hop event Elsbeth 4523 Wed 2025-12-03 Nuclear Reactor Technology - Ep 1 - Nuclear Basics Whiskeyjack 4524 Thu 2025-12-04 Living the Tux Life Episode 3 - Automating the Install Al 4525 Fri 2025-12-05 Using mail merge in thunderbird Ken Fallon 4526 Mon 2025-12-08 Baofeng and SDR++ Lee 4527 Tue 2025-12-09 Overly Complicated Media Ripping setup Archer72 4528 Wed 2025-12-10 Photography software Henrik Hemrin 4529 Thu 2025-12-11 yoga370 review Brian-in-Ohio 4530 Fri 2025-12-12 Playing Civilization V, Part 6 Ahuka 4531 Mon 2025-12-15 HPR Beer Garden 6 - Imperial Stouts Kevie 4532 Tue 2025-12-16 Cheap Yellow Display Project Part 5: Graphical User Interface Trey 4533 Wed 2025-12-17 Nuclear Reactor Technology - Ep 2 Nuclear Fuel Whiskeyjack 4534 Thu 2025-12-18 Reviving My Kawai K4 Synthesizer Claudio Miranda 4535 Fri 2025-12-19 Living the Tux Life Episode 4 - Various software I have been using Al 4536 Mon 2025-12-22 Welcome to the Linux Community Deltaray 4537 Tue 2025-12-23 “Elsbeth in IT: Since '97” (Part 1) Elsbeth 4538 Wed 2025-12-24 HPR Branding Ken Fallon 4539 Thu 2025-12-25 YouTube Subscriptions 2025 #11 Ahuka 4540 Fri 2025-12-26 Arthur C. Clarke: Other Novels, Part 1 Ahuka 4541 Mon 2025-12-29 HPR Beer Garden 7 - UK Christmas Ales Kevie 4542 Tue 2025-12-30 Can Haiku Mumble? Claudio Miranda 4543 Wed 2025-12-31 Nuclear Reactor Technology - Ep 3 Reactor Basics Whiskeyjack Comments this month These are comments which have been made during the past month, either to shows released during the month or to past shows. There are 27 comments in total. Past shows There are 2 comments on 2 previous shows: hpr4424 (2025-07-17) "How I use Newsboat for Podcasts and Reddit" by Archer72. Comment 5: Ken Fallon on 2025-12-02: "Checking for أحمد المحمودي to see if there are issues." Comment 6: أحمد المحمودي on 2025-12-03: "download-filename-format for HPR podcasts" hpr4520 (2025-11-28) "Arthur C. Clarke: Rama and Sequels" by Ahuka. Comment 1: morhook on 2025-12-30: "programmer and content creator" Comment 2: Kevin O'Brien on 2025-12-30: "Glad you liked it" This month's shows There are 25 comments on 11 of this month's shows: hpr4521 (2025-12-01) "HPR Community News for November 2025" by HPR Volunteers. Comment 1: Archer72 on 2025-11-30: "Silent key"Comment 2: Trey on 2025-12-01: "Silent Key Archive"Comment 3: Trey on 2025-12-01: "TuxJam CYD Episode"Comment 4: candycanearter07 on 2025-12-12: "thoughts"Comment 5: Archer72 on 2025-12-19: "Re: thoughts"Comment 6: candycanearter07 on 2025-12-21: "Re: Re: Thoughts" hpr4522 (2025-12-02) "Lee interviews Elsbeth about SL Shop and Hop event" by Elsbeth. Comment 1: candycanearter07 on 2025-12-13: "peek into the community" hpr4523 (2025-12-03) "Nuclear Reactor Technology - Ep 1 - Nuclear Basics" by Whiskeyjack. Comment 1: bjb on 2025-12-04: "Love your show/series, thank you"Comment 2: Kevin O'Brien on 2025-12-04: "Looking forward to more"Comment 3: Trey on 2025-12-09: "Looking forward to this series" hpr4526 (2025-12-08) "Baofeng and SDR++" by Lee. Comment 1: Trey on 2025-12-09: "SDRs" hpr4529 (2025-12-11) "yoga370 review" by Brian-in-Ohio. Comment 1: Paulj on 2025-12-31: "Thanks - great show" hpr4532 (2025-12-16) "Cheap Yellow Display Project Part 5: Graphical User Interface " by Trey. Comment 1: norrrist on 2025-12-16: "starting small " hpr4533 (2025-12-17) "Nuclear Reactor Technology - Ep 2 Nuclear Fuel" by Whiskeyjack. Comment 1: bjb on 2025-12-18: "Thank the host for interesting series" hpr4535 (2025-12-19) "Living the Tux Life Episode 4 - Various software I have been using" by Al. Comment 1: candycanearter07 on 2025-12-19: "cool setup!"Comment 2: Archer72 on 2025-12-19: "Tmux" hpr4536 (2025-12-22) "Welcome to the Linux Community" by Deltaray. Comment 1: Archer72 on 2025-12-21: "Brilliant!! "Comment 2: Torin Doyle on 2025-12-22: "Deltaray did a fine job in covering GNU/Linux aka Linux, here."Comment 3: Ken Fallon on 2025-12-22: "Agree"Comment 4: Deltaray on 2025-12-26: "Thanks"Comment 5: Morhook on 2025-12-30: "Good talk CliMagic" hpr4538 (2025-12-24) "HPR Branding" by Ken Fallon. Comment 1: candycanearter07 on 2025-12-24: "interesting peak of behind the scenes!!"Comment 2: Steve Barnes on 2025-12-24: "Merci!"Comment 3: Archer72 on 2025-12-29: "Re: candycanearter07" hpr4543 (2025-12-31) "Nuclear Reactor Technology - Ep 3 Reactor Basics" by Whiskeyjack. Comment 1: L'andrew on 2025-12-31: "Praise for this series" Mailing List discussions Policy decisions surrounding HPR are taken by the community as a whole. This discussion takes place on the Mailing List which is open to all HPR listeners and contributors. The discussions are open and available on the HPR server under Mailman. The threaded discussions this month can be found here: https://lists.hackerpublicradio.com/pipermail/hpr/2025-December/thread.html Events Calendar With the kind permission of LWN.net we are linking to The LWN.net Community Calendar. Quoting the site: This is the LWN.net community event calendar, where we track events of interest to people using and developing Linux and free software. Clicking on individual events will take you to the appropriate web page. Any other business Thanks to all 57 HPR contributors in 2025! Ahuka, Al, Antoine, Archer72, beni, Brian-in-Ohio, candycanearter, Celeste, Claudio Miranda, Daniel Persson, Dave Hingley, Dave Morriss, Deltaray, dnt, Elsbeth, folky, FredBlack, gemlog, hairylarry, Henrik Hemrin, Honkeymagoo, HPR Volunteers, iota, Jerm, Jeroen Baten, Jezra, Ken Fallon, Kevie, Kirbotica, Klaatu, ko3moc, Lee, Lochyboy, Major_Ursa, Manon, Marc W. Abel, mightbemike, Moss Bliss, MrX, murph, norrist, operat0r, oxo, Paulj, Reto, Rho`n, Shane - StrandedOutput, SolusSpider, Some Guy On The Internet, Swift110, thelovebug, Thibaut, Trey, Trixter, Trollercoaster, Whiskeyjack, Wojciech Provide feedback on this episode.