Podcasts about FLAC

Tha Bloc Report Episode 94 is here. Donnie Ozone spins 12 tunes from the blocSonic catalog plus a 16-track Timezone Lafontaine Workout. Download free in FLAC, MP3 or OGG.

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.

Neil Howson in conversation with David Eastaugh  https://preciousrecordingsoflondon.bandcamp.com/album/prelp-8-age-of-chance-bbc-sessions-85-87 A stunning mix of Northern Soul, machine-like beats, electroclash, slogans and agitpop, Age of Chance were unquestionably one of the most exciting groups to emerge during the C86 era. They certainly didn't sound like anybody else, that's for sure. An uncompromising live act, Age of Chance were frantic and frenetic – and they even dallied with the mainstream via their version of Prince's Kiss. Janglepop this is not. Now, not before time, their three sessions for BBC Radio 1 are collected by Precious Recordings of London as part of the label's ongoing series. And for good measure, we've included both sides of their first two incredible ground-breaking singles – Motorcity and Bible Of The Beats, both unavailable in any form for decades. Limited edition (500 copies worldwide) comes with unseen pics, sleeve essay by close associate John F Power. and download codes. Includes unlimited streaming of PRELP 8: Age of Chance BBC sessions 85-87 via the free Bandcamp app, plus high-quality download in MP3, FLAC and more.

Представляю вашему вниманию новый эпизод. Специально для вас самые яркие треки середины 2026 года — новинки, которые задают тон сезону. А для ценителей проверенного звучания — знакомые ритмы, заигравшие совершенно новыми красками в смелых, неожиданных интерпретациях. Как всегда, в высочайшем качестве FLAC. 1.Archangel (PT) — Solento 2.Bcee, Thomas Oliver — Black Sky 3.Bcee, Emba, Philippa Hanna — Galaxy 4.Impish — So Sick (VIP 2021) 5.KDE — V 6.Maduk, Etherwood — Coming Down 7.KDE — Miss You 8.Keeno, sam welch, Noppo — The Simple Life 9.Messiah — Night Call 10.Pola & Bryson, Brookfield — No One but You 11.Surreal — Inbetween 12.Telomic, Susan H — Underwater 13.Rafau Etamski — Last Time 14.Pola & Bryson, Cimone — Twilight Live Mix

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.

Jim Shepherd in conversation with David Eastaugh  https://preciousrecordingsoflondon.bandcamp.com/album/prelp-12-be-careful-what-you-wish-for https://www.facebook.com/thejasmineminks/?locale=en_GB Alongside his pals, Jasmine Minks front man Jim Shepherd has produced his masterpiece. Okay, I guess we might have to call them a 'Creation supergroup' because the Pillars of Creation features a band of mainly former label stalwarts who bring Shepherd's epic to life. Dave Morgan from the Loft (and many others!) is on drumming, mixing and production duties, for example, with Frank Sweeney and Arash Torabi from the June Brides also on the team. (OK, the June Brides never released a record on Creation but let's not quibble here … and Frank is indeed on any number of records by the likes of Primal Scream and Felt etc). Ruth Tidmarsh and Innes Mackintosh complete the crew. They've produced a brilliantly memorable album – not far off a concept album of sorts, albeit with the title track as the lead digital single (released on Friday). It's distinctive and unique and you won't want to miss it. Includes unlimited streaming of PRELP 12: Be Careful What You Wish For via the free Bandcamp app, plus high-quality download in MP3, FLAC and more.  

Alright, tech heads, here's what's buzzing this week: We're diving wrist-first into the sleek, premium vibes of the OnePlus Watch 4 Titanium, then switching gears to pure audiophile bliss with the Topping DX9 DAC to see if it really earns its bragging rights. We also explore a clever browser tool that might just expose whether you can actually hear the difference between FLAC and MP3 (brace yourself), before getting hands-on with the futuristic Turtle Beach MC7 wireless mouse, yes, it's got a touchscreen. Retro lovers, you're eating good too, as SNK teases a modern take on the NeoGeo AES, blending nostalgia with new-school convenience. And finally, we round things out with Roberts' latest portable radios, proving that classic listening still has a place in our always-online world. With Gareth Myles and Ted Salmon Join us on Mewe RSS Link: https://techaddicts.libsyn.com/rss Direct Download | iTunes | YouTube Music | Stitcher | Tunein | Spotify  Amazon | Pocket Casts | Castbox | PodHubUK News OnePlus Watch 4 titanium smartwatch launches with up to 16 days of battery life Topping's new DAC promises "remarkable" sound from both headphones and speakers alike 'Turns out I'm deaf': Someone built a browser tool to test the difference between Hi-Res Audio FLAC and lossy MP3 with your own music, so you've no excuse for getting it wrong Turtle Beach launches $160 wireless mouse with 2.25-inch touchscreen and 10-hour battery life SNK is releasing a modern NeoGeo AES console with 'unrivaled authenticity' and £70 game cartridges Roberts announces two stereo portable radios, one of which has Spotify Connect Banters: Knocking out a Quick Bant Feedback on Hiding my Film/TV files from Google Photos Ted recipe... Make a folder on the card, say "Video Parent". Put the .nomedia file in that folder. Make another folder off of "Video Parent" called, say "Ted's Videos". Put all the video files in there (in nested folder structure if you like), then get VLC (or other players) to reindex from that folder, not the first. So Google Photos (and the Android system) ignores "Ted's Videos" (because of the .nomedia file in that folder) and the thumbnails are not littered through the Google Photos App. And VLC (and any other Media Playing app) is happy once pointed to Ted's Videos (and sub-folders) and indexed again. The trick was nesting one folder in another and putting the .nomedia file in the first one, then flowing the nest of folders further down the tree. Now, the Xperia 5 Mk V's poxy little 128GB storage is near-empty and everything is on my super-fast 1TB microSD Card! Bargain Basement: Best UK deals and tech on sale we have spotted Samsung Galaxy Chromebook Plus i3 (not i5) 256GB/8GB, Neptune Blue £399 from £649 NiPoGi E3B Mini PC AMD Ryzen 7 7735HS £399.99 Was  £599.99 Bang & Olufsen Beosound Explore Bluetooth Speaker £164 from £219 Sennheiser MOMENTUM 4 £161.46 Was: £205.21 Zoom ZDM-1 Podcast Pack Podcast Dynamic Microphone, Headphones, Tripod, Windscreen, XLR Cable, £64.30 from £93 INIU Power Bank, Smaller & Lighter 10000mAh £18.99 was £26.99 Fosi Audio SK01 Headphone Amplifier £64 from £80 - Operating Guide! Fuse Vert AT Vertical Record Player with Audio-Technica Cartridge - £225.63 Main Show URL: http://www.techaddicts.uk | PodHubUK Contact:: gareth@techaddicts.uk | @techaddictsuk Gareth - @garethmyles | Mastodon | Blusky | garethmyles.com | Gareth's Ko-Fi Ted - tedsalmon.com | Ted's PayPal | Mastodon | Ted's Amazon YouTube: Tech Addicts  

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.

Download Tha Bloc Report Episode 91, hosted by Donnie Ozone. The March 2026 episode features new music and blocSonic archive picks, plus a 15-track 20-Minute Workout by Timezone Lafontaine. Free in FLAC, MP3 and OGG.

¿Es Python siempre la mejor opción para tus scripts de automatización? En este episodio, Lorenzo profundiza en una de las discusiones más recurrentes de la comunidad: la estabilidad de los scripts frente a la comodidad de los módulos de terceros. Acompaña a nuestro experto en Linux mientras desglosa los motivos que lo llevaron a abandonar soluciones basadas en Python para la gestión de metadatos de audio.Descubre ID3CLI, una herramienta potente y ligera escrita en Rust que soluciona los problemas de retrocompatibilidad y fallos en tiempo de ejecución. Aprenderás cómo automatizar el etiquetado de tus podcasts extrayendo datos directamente de archivos Markdown, eliminando la necesidad de introducir información manualmente en herramientas gráficas. Analizamos la importancia de tener binarios compilados que simplemente "funcionan", permitiéndote centrarte en crear contenido en lugar de arreglar herramientas rotas.Temas destacados del episodio: Bash vs Python: ¿Cuándo el "follón" de compilar merece la pena? Los peligros de depender de módulos de terceros que cambian sin previo aviso. De EasyTag a la automatización total en la terminal. Uso de Front Matter y RipGrep para un flujo de trabajo eficiente. Soporte de metadatos para Apple y carátulas en múltiples formatos. Capítulos,00:00:00 Introducción: El dilema de Bash vs Python00:00:48 El riesgo de las dependencias de terceros en Python00:01:35 La obsesión por la automatización de metadatos00:03:01 Flujo de trabajo: De EasyTag a la Terminal00:05:36 Extrayendo datos del Front Matter en Markdown00:07:24 Herramientas antiguas: ID3 y MiD3v2 (Mutagen)00:09:12 El colapso de los módulos y la necesidad de compilar00:10:13 Presentando ID3CLI: La solución definitiva en Rust00:11:53 Características técnicas y soporte de formatos (MP3, OGG, FLAC)00:13:48 Integración de ID3CLI en scripts de automatización00:15:23 Reflexión sobre la importancia de los metadatos00:16:42 Nuevo proyecto: El podcast "La Era de las Distros"00:17:47 Comunidad y cierre del episodioAdemás, Lorenzo nos habla sobre su nuevo podcast "La Era de las Distros", una mirada necesaria a las distribuciones Linux que marcaron un hito en la informática española como LinEx o Guadalex. ¡Disfruta del episodio y optimiza tu entorno Linux!Más información y enlaces en las notas del episodio

Éclipse partielle du Soleil : Flic-en-Flac se prépare pour l'événement astronomique de l'année by TOPFM MAURITIUS

Дорогие друзья. Сегодня Вас ждёт праздничный Drum & Bass микс. Вы услышите ремиксы и Blend'ы от: Tokage, Denis Juice, Dj Antonio, Индекс 861, Dj ALL AIR, DJ Flasher, Andry Makarov, Dj Den Krasin, FLAC, DIQÓ, R-Remixer, DJ SOROK1N, Dj Goman, Sneclipse, Bolshak, INvisiBLE, The Resonance Theory & CJ Plus, Pure Motion, Mega Vocant, EZZIATI & Dj Katya Guseva. С наступившим Новым 2026 годом! Поехали! TRACKLIST: 01. Вирус - Каренина (Tokage Remix) 02. Mary Gu - Косички (Denis Juice Remix) 03. Sasha Komovich - Расскажи, Снегурочка (Dj Antonio D'N'B Remix) 04. Катя Чехова - Снежные лебеди (Индекс 861 Mix) 05. Ленинград - Кислотный Ди Джей (Dj ALL AIR Remix) 06. Валерия - Маленькиий самолет (DJ Flasher DnB Blend) 07. The Mate, SERPO - Эмилия (Andry Makarov Remix) 08. ТРАВМА x Tantrum Desire - Закричу на весь мир (Dj Den Krasin D'n'B Blend) 09. X-ROMB - Зима апгрейд (Black mix DNB) 10. Краски - Оранжевое солнце (FLAC Remix) 11. Nyusha - Выбирать чудо (DIQÓ BLEND) 12. ЕЛЕНА МАКСИМОВА - ТЕТ-А-ТЕТ (R-Remixer REMIX) 13. White Queen - Альтушки (DJ SOROK1N 174 bpm Remix) 14. Anacondaz - Кроме любви (Dj Goman Remix) 15. GONOPOLSKY - Я остаюсь (Sneclipse Remix) 16. Макс Корж - Небо Поможет Нам (Bolshak DnB Remix) 17. BAGAUHOM - Новый год (INvisiBLE dnb remix) 18. Доминик Джокер - Плачут Небеса (DJ Flasher Blend) 19. Filatov & Karas feat. Masha - Лирика (DIQÓ BLEND) 20. Смысловые Галлюцинации & The Resonance Theory vs Аида Ведищева & CJ Plus - Песенка о вечно молодых медведях (PASHA DELUXE NYE BLEND) 21. MC Вспышкин и Никифоровна - Новогодняя (Pure Motion RMX '25) 22. Надежда Гайдукевич - Что-то на богатом, что-то на красивом (Mega Vocant Remix) 23. EZZIATI - С Новым Годом, Россия! (Dj Katya Guseva Remix/PASHA DELUXE Outro Edit) Подписывайтесь на мой подкаст (Subscribe to My Podcast): ● Apple Podcasts - podcasts.apple.com/ru/podcast/… ● Pocket Casts - pca.st/drpc1gfj Слушайте и наслаждайтесь! Listen & Enjoy! From Russia with Love!

Gothic Storm⚙️ FANTASTiC | 23 December 2025 | 373 MB …: SFX Trailer Percussion / 24-Bit/44.1 kHz :… INFO/DEMO/BUY: https://mage.si/gothic-storm Gothic Storm SFX Trailer Percussion FLAC-FANTASTiC ♪ Download ♪

S.I Sound Effects Collection Team DjYOPMiX | 23 December 2025 | 2.09 GB ..: 24-Bit/48 kHz :.. Includes: – Toys Sound Effects FLAC – Boxing Sound Effects FLAC – Game […]

  Leigh Goorney in conversation with David Eastaugh  https://gnuinc.bandcamp.com/album/moribundiing https://www.facebook.com/leigh.goorney The new album by The Long Decline finds Leigh Goorney (formerly Kenny Wisdom) and his ever-shifting collaborators pulling together strands of history, politics, and autobiography into a startlingly unified whole. Produced by Cos Chapman (Rude Mechanicals), the record is perhaps the band's most accomplished to date. Includes unlimited streaming of Moribundiing via the free Bandcamp app, plus high-quality download in MP3, FLAC and more.  

Bill and Larry both break things. Questions for the listener: In addition to MP3, should we have a second feed? If so, should it be OGG, FLAC, OPUS, or something else? Suggestions for Solitaire, website upgrades, community comments, episode topics, printers, running Linux Mint, and computers for running Linux. Episode Time Stamps 00:00 Going Linux #473 · Listener Feedback 01:30 Bill broke Manjaro 02:30 Larry breaks audio 03:18 Request to provide a FLAC feed 04:18 Questions for the listener: In addition to MP3, should we have a second feed? If so, should it be OGG, FLAC, OPUS, or something else? 09:18 Jblough: Ideas for an online Solitaire game 10:40 Frank: Free, open source Solitaire 12:50 Jack: Confusion over the feed 21:10 David: A link suggesting CachyOS is more popular than Ubuntu or Mint 23:57 Tolga: Unable to leave comments. Distro suggestions. 29:27 Kenneth: A suggestion for our website 32:60 Frank: Think Penguin 34:35 Paul: Asus laptop and Mint 35:53 Jim: Linux printers 42:30 Frank: Weird RSS stuff 45:14 Torontal7: About the picture in our ogg file 48:31 David: An interesting episode idea 54:46 Paul: Problems with Linux Mint 59:28 goinglinux.com, goinglinux@gmail.com, +1-904-468-7889, @goinglinux, feedback, listen, subscribe 60:32 End

The gang dives into the Battle Zone™ to talk about games like Pokémon Legends Z-A, Ninja Gaiden 4, Lisa: The Painful and way more! We also chat about the recent Britney Spears knife video, RFK Jr. having brainworms, and we give a big shout-out to Kansas (the state and the band). 

The Alan Cox Show

The Alan Cox ShowSee omnystudio.com/listener for privacy information.

In part one of a two part interview, SBRnet President Neil Schwartz joins the In Route to discuss the influence of data on sports. Plus, D and Z analyze the Joe Flacco trade, break down the MLB Division Series, discuss the Mark Sanchez saga, and more! —————————————————————Join D and Z, two veteran sports aficionados and lifelong friends, as they dissect the week's top stories with wit and a touch of New York flair. Subscribe today and never miss an episode!New episode drops:Fade Route - #Wednesday Order Up/The Option - #SaturdayRed Light, Green Light - #SundayWebsite: https://www.podpage.com/the-fade-route-with-d-and-z/?fbclid=PAZXh0bgNhZW0CMTEAAadJrroCzNzmCkojX5FjMa0r6-17sFD180OJuV7gJuCTQ48A3NS66t9fGDXw0A_aem_Z9cVJ0YHRQ2BOk7oI00ShgHit us up with questions, comments, picks, and segment suggestions. Email: faderoutemail@gmail.com#sports #podcast #faderoutedandz #football #basketball #baseball #hockey #soccer #mlb #nfl #nba #nhl #futbol #mls #ncaa #fyp #wnba

The Alan Cox ShowSee omnystudio.com/listener for privacy information.

The Alan Cox Show

This week we cover the latest Audacity update, an EU grant for Bottles, and the dustup with the DuckStation PS1 emulator on Linux. KDE Linux has a pre-alpha, Chrome is looking to play nicer with Wayland, and there's a really big AI Lawsuit on the horizon. For tips we have an intro to WirePlumber and wpctl, a howto for clearing the RAM cache and Swap, and our first time covering tr to translate characters in a string. You can find the show notes at https://bit.ly/4fDoPgM and enjoy! Host: Jonathan Bennett Co-Hosts: Jeff Massie and Ken McDonald Download or subscribe to Untitled Linux Show at https://twit.tv/shows/untitled-linux-show Want access to the ad-free video and exclusive features? Become a member of Club TWiT today! https://twit.tv/clubtwit Club TWiT members can discuss this episode and leave feedback in the Club TWiT Discord.

Cei născuți înainte de 1989 ne aducem aminte de portretul lui Nicolae Ceaușescu prezent în toate instituțiile, de Cântarea României și de omagiile aduse conducătorului iubit.  Toate făceau parte dintr-un amplu cult al personalității, element central al propagandei regimului. Un cult al personalității bicefal, care era un instrument-cheie în menținerea puterii absolute și în eliminarea oricărei forme de opoziție. Începe Historincul, cu Iuliana Panache și Cosmin Popa. 01:42 Cum apare cultul personalității 03:20 Anii 65-67, măsuri democratice 10:14 Cultul personalității e scris în ADN 13:59 Schimbare de putere 22:24 1968 - un nou salt în popularitatea lui Ceaușescu 29:03 Comunismul și mistificarea istoriei 33:50 Modelul nord-coreean 37:30 1973, apariția cenaclului Flacăra condus de Adrian Păunescu 42:12 ”Frigiderele erau goale, iar oamenii aveau inimile pline de mândrie națională” 56.20 Noiembrie, ultimul bal 1:02:01 Moștenitorul coroanei 1:09:25 Începuturile tracomaniei 1:15:12 În loc de concluzie

By listener request, we're talking about our personal file organization and storage layouts this week, with a focus on our desktop computers--including how we use our OS-level home folders, whether to interact with the root system drive or not, and how much data we even keep on those machines these days--and also how we attempt to organize media, archives, backups and more on our home servers. Plus, a check-in on the state of Windows backup tools. Is it actually possible to avoid the dreaded Nth-level nested "old desktop" folder? Maybe!Software mentioned in this episode:Ventoy, the multi-ISO bootable USB image: https://www.ventoy.net/en/index.htmlEverything, the universal search tool: https://www.voidtools.com/How to use Windows File History: https://support.microsoft.com/en-us/windows/backup-and-restore-with-file-history-7bf065bf-f1ea-0a78-c1cf-7dcf51cc8bfcMore info on Windows Libraries: https://learn.microsoft.com/en-us/windows/client-management/client-tools/windows-librariesEaseUS' free Windows backup utility: https://www.easeus.com/backup-software/tb-free.html Support the Pod! Contribute to the Tech Pod Patreon and get access to our booming Discord, a monthly bonus episode, your name in the credits, and other great benefits! You can support the show at: https://patreon.com/techpod

The Hemispheric Triad is back together again! With our powers combined, you get episode 136!

We're on holiday this week! Wait, I am being told, we are in fact not on holiday. The show must go on! (Although a bit shorter than normal. Sorry and you're welcome!) A little ranty in the beginning, but it picks up! We've got Andrew's mouse follow up, Turbo Media Corner, and Turbo Photography Corner. Martin won some trivia. Jason even got to say FLAC! We're on Holiday 00:00:00 We're on holiday!

Josh proves that he's the host with the most - and guides us through a brisk show that ends just before the really good stuff. Probably. Also, his cat tried to host.  We've got the "best" NVME, the most expensive 5090, melty parts, EVGA talk and there is no Subnautica 2 playtest - STOP CLICKING on things!Timestamps:00:00 Intro02:57 (no) Food with Josh03:54 Radeon RX 9070 XT listed early in Canada at 700 USD08:59 Here we go again - reports of melting RTX 5090 power connectors17:01 How far does overclocking the RTX 5080 get you?19:51 PassMark records first ever YoY drop in CPU performance23:43 Is the WD_Black SN7100 the new best SSD? (TPU says yes)28:22 FLAC encodes are now multi-threaded in version 1.529:53 RTX 5070 reportedly delayed until early March33:17 EVGA closes forums35:14 Podcast sponsor Stash36:39 (in)Security Corner43:20 Gaming Quick Hits53:28 MSI RTX 5090 SUPRIM LIQUID SOC reviewed57:05 Picks of the Week1:12:18 Outro ★ Support this podcast on Patreon ★

My guest on the podcast this week is Eric Skye, who joins me to celebrate the album 'Phillips, Grier & Flinner'.Released in 1999 on Compass Records, it marks the first collaboration between bassist Todd Phillips, guitarist David Grier, and mandolinist Matt Flinner and features three original tunes from each.We chat about how Eric first discovered the record and why it means so much to him, plus what's so special about these three musicians and this collection of tunes. We also chat about the album's sound and why listening is such an important part of making (and understanding) music.This was a fantastic conversation to get to have and it's always a pleasure talking to Eric.You can buy 'Phillips, Grier and Flinner' on CD or as a digital download in mp3,FLAC or WAV via the Compass Records websiteFor more info on Eric's music and production services, check out ericskye.comThe Chris Thile and David Grier bootleg we discuss in the episode is available via sugarmegs:Part 1Part 2  SetlistHappy picking,MattSend a message to Bluegrass Jam Along! (Don't forget to include your name so I know who you are!) Support the show===Thanks to Bryan Sutton for his wonderful theme tune to Bluegrass Jam Along (and to Justin Moses for playing the fiddle!)- Sign up to get updates on new episodes - Free fiddle tune chord sheets- Here's a list of all the Bluegrass Jam Along interviews- Follow Bluegrass Jam Along for regular updates: Instagram Facebook - Review us on Apple Podcasts

Is KFC chicken? Let's talk lossless! Have you ordered your stickers yet? That time Andrew learned shorthand. The foot has trapped you in a force feld. Does salad excite you?? KFC & What 3 Words 00:00:00 Kentucky Fried Chicken (https://en.wikipedia.org/wiki/KFC)

RADIO NUG (Ethnic language program) 10thJUN 2024.This item has files of the following types: Archive BitTorrent, Flac, Item Tile, Metadata, PNG, Spectrogram, VBR MP3, WAVE

Weekly Ethnic language program (Matupi Times).This item has files of the following types: Archive BitTorrent, Flac, Item Tile, Metadata, PNG, Spectrogram, VBR MP3, WAVE