Podcasts about khz

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.

Amigos y amigas, sean bienvenidos al informe mensual de la Asociación Española de Radioescucha. Antes de las noticias, indicamos que las frecuencias se dan en kilohercios mientras que las horas son UTC, es decir, están referidas al Tiempo Universal Coordinado. Además, deletrearemos algunas direcciones usando el alfabeto internacional de deletreo. Comenzamos en la Isla de Madagascar, pues la emisora religiosa WORLD CHRISTIAN BROADCASTING, que en español se identifica como LA VOZ ALEGRE, cuenta con dos programas diarios en español dirigidos hacia América del sur: de 02.00 a 03.00 y de 03.00 a 04.00, siempre por la frecuencia de 9.755. Los informes de recepción se pueden enviar a la siguiente correo: info@worldchristian.org La siguiente noticia nos llega desde el Reino Unido, la emisora de onda larga BBC Radio 4 que emite por la frecuencia de 198 Khz, anuncia que cesará sus emisiones el próximo 26 de junio. Desde la Base Esperanza en la Antártida Argentina, LRA36 RADIO NACIONAL ARCANGEL SAN GABRIEL permanecerá fuera del aire debido a un fallo grave en su transmisor. Mientras se realizan las reparaciones no se espera su regreso a su frecuencia habitual de 15.476 hasta el mes de octubre del presente año. Por su parte, LA VOZ DE VIETNAM tiene dos emisiones diarias en español de aproximadamente media hora de duración, la primera de ellas a las 18.00 y la segunda a las 21.00. En ambas emisiones, dirigidas hacia Europa, se utilizan las frecuencias de 9.730 y 11.885. Se solicitan y agradecen los informes de recepción en el correo: vovworld@vov.vn Y, terminamos con RADIO EL CAIRO, que continua emitiendo diariamente en español, hacia Europa y América, de 00.45 a 02.00 en 9.900, con muy mala modulación. Los informes de recepción se pueden enviar al correo: radioelcairoespa@yahoo.com Antes de despedirnos, recuerden que pueden oír y leer este informe en radio.aer.org.es; además, tienen disponibles todos sus programas diexistas favoritos en programasdx.com. Y, como no, pueden contactar con nosotros a través de info@aerclub.es, desde nuestra sitio web aer.org.es así como desde nuestro perfil en Facebook. ¡Hasta la próxima, muchos 73s y buenos DX!

Many thanks to SRAA contributor, Dan Greenall, who shares the following recording and notes:Broadcaster: Israel Broadcasting Authority, Jerusalem 1971Date of recording: Circa 1971Starting time: 2130 UTCFrequency: 9.625 MHzReception location: Ancaster, Ontario, CanadaReceiver and antenna: Hallicrafters S-52 using a longwire antennaMode: AMNotes: The Israel Broadcasting Authority used to broadcast in various languages on shortwave in the early 1970's. Their English language transmission to Europe could often be heard well here in southern Ontario, Canada between 2045 and 2130 hours UTC on 9625 kHz. Here is a recording made circa 1971 as they concluded their program in English and switched to French at 2130 hours UTC. Israel Broadcasting Authority, Jerusalem: Circa 1971 Dan Greenall Download The second recording is also circa 1971. It begins with their interval signal, then sign on announcement in English. Israel Broadcasting Authority, Jerusalem (Interval Signal): Circa 1971 Dan Greenall Download

This show has been flagged as Clean by the host. 01 This is the fourth episode in a four part series on simple podcasting. 02 Introduction In this episode we will discuss alternatives to Audacity when it comes to analyzing audio spectrums to find the sources of unwanted noise. I previously promised some gratuitous hackery, and we will get into that in this episode. 03 Recall that with Audacity you first import the audio file, then select the part of the audio you wish to analyze (or ctrl-A for all), and then select analyze > plot spectrum. This is in fact the only feature of Audacity that I know how to use. I am definitely not an audio expert. I do however have some background in processing and analyzing other signals, so some of the basics are familiar to me. 04 We can accomplish the same thing that Audacity does in this instance provided we can do the following. First, we need to get the data out of the audio file and into a form which we can import into other software. Second, we need to perform certain mathematical operations on this data. Finally, we need to be able to plot the results of these calculations on a chart. -------------------- 05 Fourier Transforms First though, we need a bit of mathematical background. What Audacity is doing when it shows a plot of frequency versus amplitude is that it is showing the results of a Fourier Transform. A Fourier Transforms is a mathematical operation that converts the time domain into the frequency domain. Any complex signal, audio or otherwise, can be broken down into a collection of sine waves of various frequencies. For example, a simple square wave signal of say 100 hertz can be represented as a sine wave of frequency 100 hertz plus a collection of higher frequency sine waves which add together to give the sharp corners. 06 A Fourier Transform finds these sine waves and sorts them out into separate bins, with each bin representing an individual frequency or a collection of closely related frequencies, depending on how fine grained the sorting is. 07 This is exactly what we want when we are trying to figure out how to filter out noise. Recall that earlier in this series we had to solve a problem with a high pitched background noise which was originating in my cheap microphone. Analyzing this audio by frequency showed that it was a series of individual tones at 1 kHz intervals. We were then able to use filters targeted at those frequencies to get rid of that noise. 08 There are several optimized versions of the Fourier Transform algorithm. A very common one is the Fast Fourier Transform, common abbreviated to just "FFT". This is so common that the term "FFT" is often used to simply mean any Fourier Transform even though this is not technically correct. 09 Typical FFT algorithms require that the number of data samples is exactly a power of two. So the number of samples we need may be something like 4096, 8192, or 65536, to give a few random examples. When we transform from the time domain to the frequency domain, each sample becomes a single frequency "bin". So the more samples we have, the finer the resolution we get in terms of frequency. 10 If we assume we are dealing with flac files recorded at a 44.1 kHz sample rate, that is, 44100 samples per second, then if we have 32768 samples, each "bin" represents slightly more than 1 hertz. If we have 65536 samples, then each "bin" represents a fraction of a hertz. For our purposes we will pick 65536 samples. That means we need 1.48 seconds of data. For simplicity's sake we will record at least 2 seconds of data and then just discard the samples that we don't need. 11 There is a further complication here. Fourier Transforms normally work with complex numbers. Recall from your school days that as well as integers and real numbers there are complex numbers. Each complex number consists of two parts, a real component and an imaginary component. I won't go into the details of this, just accept that each sample needs to have two components. Fortunately, if we don't have complex number data we can just set the imaginary component to zero and use that. This is enough talking about the theory, let's get into the practical details. -------------------- 12 Extracting Data from Audio Files First we will look at how to extract the data from the audio files. Fortunately, one of the programs which we have already been using can do this. To do this we will use Sox. I am not aware of an equivalent feature in ffmpeg. 13 Sox calls itself "SoX - Sound eXchange, the Swiss Army knife of audio manipulation" Sox is free software and is licensed under the GPLV2 or later. In this case we want to use a feature which allows us to convert a binary audio signal file to a text data file. To convert the file to text data we just give the output file a ".dat" file extension and Sox will do this for us. 14 Here is a command example. sox inputfile.flac tdata.dat 15 This gives us a file in the following format, assuming this is a mono audio recording. ; Sample Rate 44100 ; Channels 1 0 0.045471191406 2.2675737e-05 0.055023193359 4.5351474e-05 0.048217773438 6.8027211e-05 0.053192138672 etc. The first line states the sample frequency The second line states that the data is for channel 1. The data starts on the third line. Column 1 is the time in seconds. Column 2 is the waveform data point. 16 To analyze the data we want a subset of these samples. When we convert from the time domain to the frequency domain, our resolution will be determined by the number of samples. We would like therefore to have at least as many samples as the sampling rate. We also want the samples size to be an even multiple of two. The number of points we want to have is equal to the next even multiple of two above our chosen sampling rate, 44,100 Hz. This number would be 65536. 17 To extract this data from the file we can do the following. tail tdata.dat -n+3 | head -n65536 | awk '{printf "%sn", $2}' > tdata.csv 18 We use tail to skip over the first three lines. We use head to take the next 65536 lines and discard the rest. We use awk to extract the second column which we will use as the real component. We now have this data as a csv file in one column. -------------------- 19 Analyzing the Data To analyze the data we need software which can calculate FFTs. I will now show two examples of this, a very simple case using Libre Office Calc, and a more complex but more complete one using GNU Octave. 20 Using Libre Office We can do fourier analysis and plot charts using Libre Office. Take the csv file of data that we previously created. For this example I used data from a recording of silence so that I could see what internal noise was being generated by the headset. Open the csv file and import it into Libre Office Calc. 21 Now select all 65536 rows of column A. The Fourier function will automatically fill the imaginary component with zeros if we don't provide an column of imaginary numbers, so we don't need to provide a column of zeros. Then select Data > Statistics > Fourier Analysis. 22 A window will open allowing you to select various parameters. For Results to:, enter "D1". Grouped by Columns. Select OK. 23 New data should now appear starting in cell D1. The first line will say " Fourier Transform" The second line will state the input range. The third line will state "Real" in column D, and "Imaginary" in column E. The data will start in row 4. 24 For our simple example we will ignore the imaginary data and just use the real data, which will form our Y component when we plot it on a chart. We now need to create the X axis data. 25 Each cell is a "bin" of frequencies. Each cell therefore represents (sample frequency) / (Number of samples) Hz. 26 To create the X axis data showing frequency, enter the following formula in to column C to the left of each D column number. =((44100/65536) * (ROW() - 4) 27 We can now create an XY chart showing the frequency analysis. You may need to exclude the first couple of dozen rows as very low frequency components which cannot be heard may otherwise overwhelm the data we are interested in. Also, you only need the first half of the chart. The FFT mirrors the data from the first half of the array into the second half. 28 Because characterizing a sine wave requires a minimum of 2 points, although we have a sample frequency of 44.1 kHz, we really only have sound waves up to a maximum of half that, or 22.05 kHz. Create the chart with lines only. If you followed the above instructions, you should see something resembling what we saw in Audacity, except with each bin more sharply defined. 29 In the data that I had from a recording of unfiltered headset noise, I could see a distinct noise spike every 1000 hertz. 30 However, we have taken several shortcuts. First, the imaginary component of the data was ignored. Second, the magnitude (that is, Y axis) has both positive and negative peaks. Third, the data is not scaled to dB sound units, so we just have a relative measure. However, that by itself is enough to tell us where the frequencies are that we need to construct filters to deal with. 31 We could refine this spreadsheet a bit more to deal with the above issues, but I think we have demonstrated the basic principle, and working with a spreadsheet can be a bit awkward. However, if working with a spreadsheet is what you want to do, then you can add more columns and more formulae to improve on it. -------------------- 32 Other Analysis Software I will go on to GNU Octave in a moment, but I want to get a few other alternatives out of the way first. I won't go into any detail on them other than to point them out to people who want to have a go at trying these themselves. 33 Grace There is math and plotting software called Grace. This is free software, released under the GPL V2. According to the documentation, it seems to have the features we need, including an FFT function. However, I could not get it to work properly on Ubuntu 24.04. I could not get it to load a data file and plot data. 34 The error messages were vague and unhelpful. The file navigation system didn't work. There was no obvious path to success, and if it isn't easy to use then there is no point to it. This is fairly old software, designed for X Window and Motif. I gave up on it as not suitable for this series as I am looking for some fairly low effort things for people to try themselves. If someone else can get it to work on their PC, perhaps they could do an HPR episode on this themselves. 35 Command Line FFT Packages There are several command line FFT packages. They will read data from std in or from a file and output the FFT. However, these are not packaged for Ubuntu and appear to be distributed as C source code which you would download and compile. You can experiment with those if you wish, but I felt they were a bit out of scope for discussion here as I am looking at common tools that are ready to use. 36 Here are two examples. One is Command-line Fast Fourier Transform utility https://github.com/gregfjohnson/fft Another is cli-fft https://github.com/jonolafur/cli-fft 37 I have not tried these and cannot say whether they are any good or not. Similarly, there are a number of FFT packages that are libraries for languages such as Python. If you want to take the time to write a short program to go with them, you can create a dedicated FFT command line program. However, I felt that this too was out of scope for what I was trying to do here. 38 Doing it the Hard Way Hypothetically, it may be possible to write an FFT function in bash bc, which is the arbitrary precision calculator language which is part of the standard shell package. I say hypothetically, because I have not tried it. I think it would be an interesting challenge, but I don't have the time at the moment to try it. If anyone feels motivated to give it a try, they're welcome to give it a go and then do a podcast episode on it. -------------------- 39 GNU Octave We have seen that as well as using features built into Audacity to analyze the audio spectrum to see the frequencies of undesired noises, we were able to do the same using a Libre Office spreadsheet. 40 Now we'll look at another bit of software, GNU Octave. GNU Octave is free software, licensed under the GPL V3 or later. It is a mathematical scripting language, very similar to Matlab. People use it for mathematical, engineering, and scientific work. It can be found in most Linux distros and is available for some other operating systems as well. 41 Octave has two features built in that we need for our purposes. It does FFTs, and it has a plotting system built in to produce graphs. -------------------- 42 We will take the same audio test file that we used with Audacity and Libre Office and use it here as well. The bash script to convert the flac file to text data is essentially the same, with the exception that file extension on the output file as is ".txt" instead of ".csv". This latter change was an arbitrary decision on my part. 43 As a quick review, this bash script uses sox to convert a flac file to a text ".dat" file. Then it uses tail, head, and awk to extract the first 65536 rows of data, skipping over the header information and ignoring the first column of time data. This script will be in the show notes. -------------------- #!/bin/bash # This version is for use with the GNU Octave script. sox hsnoisemono.flac hsnoisemono.dat tail hsnoisemono.dat -n+3 | head -n65536 | awk '{printf "%sn", $2}' > hsnoisemono.txt -------------------- 44 We now have a 1.1 MB file containing 65536 samples of data in text format. Now the next thing we need to do is to create a short Octave script file. I will just give a brief overview of the script here, the full script will be in the show notes. 45 I put the script in a file called "octavespectrum.m". I have never used Octave before now, but the convention seems to be to give the script a ".m" ending. The "she-bang" line is "#!/usr/bin/env octave". If you make the file executable you can run it like any other script, or you can type "octave" and then the name of the script to run. 46 I won't read out the script in detail, as that would be too hard to following along in a podcast. However, I pass several arguments to the script including the name of the data file, and then two integers that I use to limit the display area in the Y and X axes so I can have the chart focus on the areas of interest that I want to see. I also pass a string containing the name of the graphic file that I want the chart exported to. This was an arbitrary decision on my part and you can just hard code these values in if that is what you want to do. 47 The arguments are accessed by calling the "args()" function, which returns an array of strings. Next, it reads in the specified file using the "dlmread()" function. This reads all of the data into an array. 48 Next, it performs a hamming windowing function on the data. I'll explain that briefly. It is standard practice when doing FFT signal processing to "window" the signal. Since the signal sample is of finite length, it will stop at each end of the array. 49 Unless you were lucky enough for this to happen exactly at a zero crossing, this would produced an abrupt transition in the data which looks like "noise" to the FFT. The solution is to taper the signal off gradually towards the ends so that when it gets cut off the signal is fairly small at that point anyway. There are a variety of different windowing functions, but "hamming" seems to be the most commonly used. 50 Next, it does an FFT using the "fft()" function. 51 This gives us real and imaginary outputs. These are combined by summing the squares of each corresponding real and imaginary element and then taking the square root of each and storing that in a new array. This gives a single array of the same length as the originals, but combining the two output components. If anyone wants to tell me that this isn't how things are done in the audio world, they're welcome to make an HPR episode telling us all the right way to do things. 52 Then it does some scaling and selection of subsets of data so we get the X axis in hertz and just the number of samples that we wish to look at. If you are looking at the script, the thing to keep in mind is that Octave will work on entire arrays of data in a single operation. You don't need to write explicit loops for this. The looping is handled implicitly as part of the syntax. 53 It also does various other things that make the chart easier to read. The comments in the script describe these in more detail. Since this is a script it's easier to add these sorts of refinements than is the case for a spreadsheet so I have made the effort to add them. Finally it calls the "plot()" function. If an output graphics file name was provided, it also creates a PNG file containing the same image using the "saveas" function. 54 We now see the chart, and it looks more or less as expected. However, this chart is interactive. You can zoom and pan the data, something that you can't do with either Audacity or Libre Office. The chart window doesn't have a function for exporting the resulting chart to a "png" file, it will only save to an ".ofig" file. The ofig file is not a standard graphics file, it is a serialization of the chart data that can only be looked at using the Octave chart viewer. 55 Alternatively, you can just take a screenshot of the chart after you have interactively zoomed and panned to a point of interest. At the bottom left of the chart window is a pair of x-y coordinates which tell you the current position of the mouse pointer in chart units. This is very handy as it can be used to get the exact (or close to exact) frequency of each noise spike. 56 The Y axis is not scaled in any particular units such as dB, as I'm not sure how to do that according to audio industry conventions. On the other hand, I'm not sure that it's really necessary, as I don't know what dB means in tangible terms anyway. It does show relative sizes, so it helps to determine whether you have one noise frequency or multiple frequencies to worry about. 57 If anyone is familiar with how to scale the raw data from a flac file as exported by Sox into dB units according to audio industry convention, then they are welcome to create an HPR episode telling us how to do it. -------------------- 58 Comments on GNU Octave I had never used GNU Octave before this, although I had heard of it and it is quite a significant piece of software for a specific segment of users. 59 The syntax is a bit odd especially in how it deals with array operations, but I was able to google various examples and answers to eventually get this working. A few other peculiarities are that it uses the percent "%" character to denote a comment, and leaving out the semi-colon at the end of the line causes it to print the answer to the console after executing the statement. 60 The GNU Octave solution was harder to get working than the Libre Office method. However, once it was working it is easier to use repeatedly. If I were to want to automatically generate audio files with different filtering or other options and wanted to script the creation of a large number of images showing the results, this would be the way to do it. 61 When your run the Octave script you may get a warning which says something like "QSocketNotifier: Can only be used with threads started with QThread". This is apparently a routine warning message from the Qt graphics system which has no real significance in this context and can be ignored for our purposes. -------------------- 62 We now have a bash script which will use sox to extract the data from a flac file, and a GNU Octave script which can be used to display the resulting frequency spectrum. This does more or less the same thing as "Plot Spectrum" does in Audacity, but allows for zooming and panning to get a more detailed look at the data. 63 However it doesn't give you an absolute reading of the sound levels in dB, something that Audacity does provide. What I wanted it for though was to find the frequencies of the audible noise in the signal, something that it does quite well. -------------------- #!/usr/bin/env octave % Perform an FFT on the data in a file and plot the results. % ====================================================================== % The sampling frequency. This must be changed to accommodate the % actual sampling frequency if it was something else. samplefreq = 44100; % Thickness of line on plot. linewidth = 2; % ====================================================================== % The name of the data file is passed as a argument. args = argv(); if length(args) < 3 quit endif % File name. fname = args{1}; % Clip the peak values. peakclip = str2double(args{2}); % How much data to show, in kHz. rbound = str2double(args{3}) * 1000; % The optional file name to save a chart image to. if length(args) > 3 chartfile = args{4}; else chartfile = ""; endif % ====================================================================== % Read the data in from the file. sampledata = dlmread(fname); % Number of samples. samplecount = length(sampledata); % ====================================================================== % Window the data. This helps deal with the discontinuity of data at % each end of the array and the effects this has on introducing apparent % noise into the signal. windoweddata = (hamming(samplecount) .* sampledata); % ====================================================================== % Do the actual FFT. fftresults = fft(windoweddata); % Get real component. r = real(fftresults); % Get the imaginary component. i = imag(fftresults); % Combine the real and imaginary. In order to square each element of each % array, we must use the ".^" operator, not just "^". rfft = sqrt(r.^2 + i.^2); realfft = rfft(1:samplecount); % ====================================================================== % Scale factor for frequency. fscale = samplefreq / samplecount; % X axis scale, scaled to frequency. f = (0:samplefreq/2) * fscale; % Take a subset of the data if specified. rbound has to be re-scaled % from kHz to array increments. freq = f(1:min(rbound / fscale,length(f))); % y axis. We take the absolute value and then limit (clip) the peaks % so that a few large peaks don't obscure the smaller ones. mag = min(abs(realfft(1: length(freq))), peakclip); % Plot the results. figure; whandle = plot(freq, mag, 'LineWidth', linewidth); title(["Audio Spectrum of ", fname]); xlabel("Frequency (Hz)"); ylabel("Unscaled Magnitude"); grid on; % If the appropriate optional argument was specified, save the chart % to a file of that name. if length(chartfile) > 4 saveas(gcf, chartfile, "png"); endif % Need this so the plot window stays open. waitfor(whandle); % ====================================================================== -------------------- This is the shell script used with the above Octave script. The arguments are 1 - the file name for the input data file. 2 - The value to clip the peaks at. 3 - The upper frequency bound in kHz. 4 - The output graphics file name. #!/bin/bash octave octavespectrum.m hsnoisemono.txt 10 12 hsnoisemono.png -------------------- 64 Episode Conclusion In this episode we covered the following topics. What Fourier transforms are. Extracting data from audio files using Sox. Analyzing the data using Libre Office. Analyzing the data using GNU Octave. And, several alternative analysis methods. 65 Series Conclusion This is the end of a four part series on simple podcasting. In the first episode, we covered a simple podcast recording method. This first episode is all you really need to make a podcast. 66 In the second episode we covered basic filtering and a few other simple topics. The methods discussed in that episode provide basic improvements to your audio if you feel the need for it. 67 In the third episode we covered how to analyze audio noise problems using Audacity and additional filtering techniques to deal with specific problems that we may find. We also covered command line recording, playback, and getting information about an audio recording. 68 In the fourth episode we engaged in a bit of gratuitous hackery for the fun of it and showed how to use alternative software methods to analyze audio signals. 69 I hope that this series has been both useful and entertaining and that you will use the knowledge gained here to create and submit your own HPR podcast episodes. -------------------- -------------------- Provide feedback on this episode.

Today's video is sponsored by Ham Radio Prep - use code JASON20 to save a 20% discount off of all of their courses - https://geni.us/830iXi5Is the Cold War era of spycraft back? We dive into the latest updates on V32, the mysterious Persian-language numbers station that appeared following the 2026 conflict in Iran. In this video, we break down the latest logs and technical analysis from Priyom.org regarding the V32 numbers station. First appearing on February 28, 2026, V32 broadcasts strings of numbers in Farsi (Persian) across shortwave frequencies, specifically 7910 kHz.Become a supporter of this podcast: https://www.spreaker.com/podcast/ham-radio-2-0--2042782/support.

Tonight on The Fact Hunter, I'm sharing a special edition of Foundations In Faith Radio centered around my new book, Exposing Dispensationalism: Prophecy, Zionism, and the Corruption of Modern Evangelicalism. In this broadcast, we examine the origins of modern dispensational theology, the rise of the pre-tribulation rapture doctrine, the influence of the Scofield Reference Bible, and how prophecy sensationalism has reshaped much of modern evangelical Christianity. This is not an attack on sincere believers, nor is it another fear-driven prophecy discussion. It is a biblical and historical examination of teachings that many Christians have simply inherited without question. With Scripture, church history, and careful analysis, we ask whether modern prophecy culture has distracted believers from discipleship, endurance, repentance, and the true mission of the church.Purchase the book here: https://a.co/d/0dWpWCEq**Foundations In Faith airs every Thursday night on WRMI 5950 KHz and FoundationsInFaith.netEmail: thefacthunter@mail.comSupport us! Zelle: 719-651-0642

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

Crônica da morte anunciada de uma rádioSegundo o Dicionário Online de Português, Eldorado é um lugar imaginário, fictício, cheio de riquezas e de pedras preciosas que, supostamente, existia na América do Sul, nomeadamente na Amazônia.Durante quase 70 anos, esse eldorado foi encontrado em um local chamado Rádio. O que parece ficção é o que temos acompanhado desde o dia 23 de abril.Não é o fim da era do rádio, mas de uma emissora que há muito tem sido relegada a segundo plano pelo grupo que deveria dar valor a ela.É dessa forma que podemos tratar o anúncio do encerramento das atividades de uma das emissoras mais tradicionais do dial brasileiro. A Eldorado, fundada há pouco mais de 68 anos, teve seu fim decretado pelo Grupo Estado para o dia 15 de maio de 2026.Talvez - e muito provavelmente - o início do fim se dá há 15 anos. Em 20 de março de 2011, a emissora passa a ocupar os 107,3 MHz da Frequência Modulada, em São Paulo, onde “invade” o espaço da Rádio Brasil 2000. Na então nova configuração, os 92,9 – em transmissão simultânea com o AM - mudam de Eldorado para Rádio Estadão ESPN. No fim de 2012, a ESPN tira o time de campo.O desmonte da marca Eldorado tem outros capítulos que são difíceis de entender. Em maio de 2015, um acordo com o bispo R.R. Soares faz com que os tradicionais 700 KHz do AM paulistano deixe de transmitir a Eldorado para passar a retransmitir a programação da Nossa Rádio. (FICA A PERGUNTA: SE O RÁDIO E A TV NO BRASIL SÃO CONCESSÕES PÚBLICAS, COMO PODE UMA FREQUÊNCIA SER VENDIDA DE UM GRUPO A OUTRO?)À época, o Grupo Estado já falava que as mudanças refletiam um contexto de prioridade para as plataformas digitais. Ao que me consta o Grupo Estado não tem assim tanta relevância até hoje nas tais plataformas. Melhor seria descer do salto e aceitar que esse passo foi um tropeço.Mas quem disse que pior do que está não dá pra ficar. O ano de 2017 tem início com um plano de demissão voluntária nas Rádios Estadão e Eldorado. Era o terreno sendo preparado para mais um baque. Fevereiro de 2017 traz a fusão das programações da Estadão com a Eldorado.Menos de uma década depois de acabar com a Rádio Estadão é a vez do Grupo Estado decretar a morte da rádio que fala com melhores ouvintes, a Eldorado. Capítulo esse que começa no fim de 2025, quando a Rádio Bandeirantes começa a se movimentar para ocupar os 107,3. Ainda havia uma possibilidade de a Eldorado migrar para os 86,3, mas o Grupo Estado e a Fundação Brasil 2000 parecem não ter levado essa alternativa em consideração.Muito mais do que os argumentos apresentados, sobretudo do crescimento do streaming - até porque os conteúdos de uma rádio podem gerar excelentes podcasts, cortes em vídeos e afins, se houver planejamento - a morte da Eldorado tem a ver, como se vê, com a incompetência de um grupo de gerir uma rádio que fez história e agora entra para a história.Essa é a opinião do blog e podcast Peças Raras.

Consider supporting my show with a donation via PayPal to vorwinfo@gmail.com it needs your help to survive! New Broadcast to East Asia - Thursdays at 0900 UTC on 9705 kHz (300 kW from Taiwan) Main Broadcasts: 4840 kHz at 2 AM Eastern every Saturday Morning (New Show) 4840 kHz at 12 AM Eastern every Monday Morning (New Show) Repeat Airings: 5950 kHz at 7 PM Eastern every Saturday Evening (Rebroadcast) 5950 kHz at 8 PM Eastern every Sunday Evening (Rebroadcast) 5850 kHz at 4 AM Eastern every Tuesday Morning (Rebroadcast) 15770 kHz at 4 PM Eastern every Tuesday Afternoon (Rebroadcast) 9455 kHz at 7 PM Eastern every Wednesday Evening (Rebroadcast) 9395 kHz at 10 PM Eastern every Wednesday Evening (Rebroadcast) 15770 kHz at 12 PM Eastern every Thursday Afternoon (Rebroadcast) 9955 kHz at 6 PM Eastern every Thursday Evening (Rebroadcast)

Many thanks to SRAA contributor Dan Greenall, who shares the following recording and notes:On March 16, I listened to V32 using the SV1BTL SDR in Athens, Greece. The voice came on at exactly 1800 UTC, but right up to 1759, the bubble jammer was being heard on that frequency. There did not appear to be any jamming during the actual "broadcast". The signal was very strong, averaging 20 dB over 9. At 1823 UTC, there were 12 users listening on this particular SDR, and 8 of them were tuned to 8742 kHz! V32 Persian/Farsi Numbers Station: March 16, 2026 Dan Greenall Download

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.

This episode explores the integration of AI into enterprise, project management in the AI era, and future skills needed to thrive alongside AI. Guests share insights on AI readiness, skill development, and upcoming training opportunities. Takeaways AI readiness programs provide valuable insights into enterprise AI adoption Project managers need to adapt to AI-driven workflows or risk obsolescence Developing visual thinking skills enhances communication and collaboration in AI contexts Chapters 00:00 Skills in the Age of AI 02:16 The Role of Project Management in AI 03:41 Future Trends and Skills Investment 05:04 Systems of Imperfection Podcast Introduction 06:29 Visual Thinking and Communication Links AI Ready Certification by C4G Enterprises - https://maven.com/c4g-academy/ai-ready Systems of Imperfection Podcast - https://systemsofimperfection.riverside.com/ The Responsive Chord by Tony Schwartz https://tinyurl.com/4sb4kcvj Find Stuart  linktr.ee/stuartliveart

Find Dave  linktr.ee/mrsungo To get a discount on upcoming classes just email dave@drunkenpmradio.com No One Is Coming to Save You: The Power-Ups you need to surf the chaos
Amazon: tinyurl.com/yv7chp54
Leanpub: leanpub.com/surfthechaos ******************************************************
The soundbed at the start and end of the podcast was built using samples from freesound.org/
Waves on Rocks with CP water and surf.wav by sparxx001 -- freesound.org/s/684383/ -- License: Creative Commons 0
SFXShuffling Dominos_Ennerdale_Xena_Owsfx.wav by Xena123457 -- freesound.org/s/709628/ -- License: Creative Commons 0
RussianMeteorite_SFX.flac by jongrubbs -- freesound.org/s/178182/ -- License: Creative Commons 0
Weather station on 5450 kHz in USB RAF Volmet 220113.wav by klankbeeld -- freesound.org/s/614719/ -- License: Attribution 4.0
Sounded created using the following samples:
Floyd Filtertron Riding G.wav by aceinet -- freesound.org/s/424240/ -- License: Attribution 4.0

Foundations of Amateur Radio The thing I love most about this amazing hobby of amateur radio is the sheer size of the community and the depth of knowledge that comes with it. Case in point, the other day I mentioned the spark gap transmitter at Grimeton in Sweden. A few hours after releasing my comments into the void I received a message from Paul SA7CND who lives, wait for it, 153 km from the transmitter. He's been on-site while it was running, transmitting on 17.2 kHz. Paul pointed out that the Grimeton transmitter is not a spark gap transmitter at all. It's actually an Alexanderson alternator, an entirely different beast, and all the more interesting for it. Invented by Swedish electrical engineer and inventor, Ernst Frederick Werner Alexanderson, he received a patent for it in 1911 whilst working for General Electric. He died in 1975, aged 97 with 345 patents to his name. Before I dig in, because you know I will, the transmitter at Grimeton was officially opened on the 1st of December in 1924. Built to increase Swedish independence after World War I revealed its vulnerability to foreign controlled transatlantic telegraph cables. Serving as a telegraphy station capable of transmitting traffic across the Atlantic ocean the station was in regular service until 1996. Unlike its scrapped brethren, the Grimeton transmitter is currently operated several times a year as a functioning transmitter using the callsign SAQ. Announcements are made on the station mailing list and the website at grimeton.org, but generally on Alexanderson Day in July and Christmas Eve in December. You'll need to tune to 17.2 kHz, something you can do with a sound-card, or with an SDR. Sound-card you say? Yes. Not for audio, but for RF. Connect an antenna to the microphone centre-pin input and have at it. Note that this will likely be highly susceptible to noise, so filtering and experimentation are to be expected. There's several tools around to play with this, GNU Radio, Quisk, SuperSID and SAQrx. Also, there's plenty of other VLF, or Very Low Frequency stations to listen to. I should probably add this as a 51st thing to do with SDR, but I digress. Back to Grimeton. As the last remaining functional Alexanderson alternator transmitter, it was added to the UNESCO World Heritage List in 2004. You can visit and see first hand what radio history looks like. As I said, if you pick your day, you can even watch it working. Failing that, there's plenty of YouTube videos showing the entire process, it's an absolute monster. There's even an amateur radio shack on-site with the callsign SK6SAQ. The website says that it's open sporadically, so I'd recommend you contact them before heading to Grimeton. I'll note that at the time that this station was being commissioned in 1924, it was already being superseded by valve oscillators, which brings me to how it works. Depending on where you live, you're likely familiar with the 50 or 60 Hz alternating current associated with household electricity. In 1891, Irish experimental physicist Frederick Thomas Trouton pointed out that if you could run an alternator at high enough speed it would create an alternating current at radio frequencies, said differently, creating a continuous wave at radio frequencies. Much experimentation followed and many giant shoulders supported this effort. It goes a little like this. Use an electric motor designed to spin at 900 revolutions per minute. Connect it to a gearbox. Connect that to a rotor with multiple poles. Then run the motor with a clutch to vary the speed. If that's not enough, to produce high power, the clearances between rotor and stator have to be kept to a millimetre. Then there is cooling and lubrication to consider, not to mention dealing with thermal expansion and contraction of a fast spinning and closely toleranced disk. At Grimeton, the whole transmitter weighs in at 50 tonnes, pretty much the opposite of portable operation. The rotor at Grimeton is a 1.6 meter diameter disc with a 7.5 cm thick edge with 488 slots milled into it, each filled with brass. The motor at Grimeton runs at just over 711.3 revolutions per minute, the gearbox has a ratio of 2.973 and the whole contraption generates 17,200 Hz. If you get the sense that you're balancing an elephant on top of a needle, you're almost there, but if you consider that keying the transmitter changes the load and currents, it's more like an elephant being shoved by a train, balancing on top of a needle. At Grimeton, the motor is loaded by one of three liquid resistors, which each consist of a two metre high container filled with water and baking soda. The liquid level is controlled by separate pumps, varying the resistance. Whilst transmitting, a second liquid resistor is added, reducing the resistance to regulate the speed of the motor to maintain the overall speed and the associated frequency. The resistors generate heat which is fed through a heat exchange to the station's water cooling system. The third resistor is available as a spare. The remarkable thing? It works. So much so, that there were several stations built and operated across the planet. There's more. This system is also capable of Amplitude Modulation, and with it, the ability to send the human voice across the airwaves. As an aside, there is a rotating spark-gap transmitter by Canadian electrical engineer and inventor Reginald Fessenden who is said to have given voice to radio in 1900 across a 1.6 km distance, but that's a tale for another day. The frequency that Grimeton transmits on, 17.2 kHz, means a wavelength of nearly 17.5 km. The antenna at Grimeton is "only" about 2 km long, in other words it's a compromise antenna. I'm making a joke here, but also a point, every antenna is a compromise. Any antenna is better than no antenna. Meanwhile, the antenna at Grimeton looks like a string of high voltage pylons with eight wires strung between them. Each of the six towers is 127 meters tall, with a cross arm that's 46 metres wide. Every tower holds a vertical radiator, connected to the ßground via a coil to tune the phase and capacitance of each radiator. So, spark gap this is not, well at least not intentionally. This remarkable piece of engineering makes me wonder if you can use the same system to spin a modern motor, say the spindle of a CNC, and use it to get on air and make noise. Now all I need is someone to talk to. I'm Onno VK6FLAB

Foundations of Amateur Radio The other day I was playing around with RDS, or Radio Data System, it's a digital signal that's often embedded in a commercial broadcast FM transmission. Among other things it contains information about the station, its content, frequencies and potentially other useful information, such as traffic alerts. If you recall I've been working on 50 things to do with a Software Defined Radio and decoding RDS is one of those things. The decoding effort aside, I imagined a screen where you could see the RDS information, in real-time, as it was being transmitted by all the local FM broadcast stations. You'd see what music each station was playing, what their local clock thought the time was, how much they transmit other data and what they might do for emergencies, like say a Tropical Cyclone heading this way. It occurred to me that this would be an example of a fundamental difference between a traditional radio and a Software Defined Radio or SDR. Specifically, we're taught that you tune a radio to a frequency, it demodulates or decodes what's there and plays the sound, or digital information, or whatever is being transmitted, on that frequency. If you want to hear something else, you need to change frequency and the radio decodes that new frequency. If you have multiple channels to choose from, there are ways to automatically switch frequency, one after the other. One of my friends recently discovered an old scanner in a box and according to the specifications, it can scan 20 stations per second. If all 1,000 stations are programmed, it takes 50 seconds to scan them all. A lot can happen in that time. The traditional solution is having more radios. Ideally you'd have one for every frequency you care about. Cost aside, logistically this is not fun. Imagine having to power a thousand radios, or find the one where the volume isn't right, or even find space for them, or antennas. In the SDR world that's not quite how it works. Instead of tuning to one frequency, you essentially tune to a range of frequencies and then, using software, decode one or more of those frequencies, at the same time. Listening to multiple broadcast FM stations like that might not make a whole lot of sense, but what about decoding RDS, or listening to aviation frequencies, or local amateur radio repeaters, or multiple digital modes? While that might sound far fetched, a $50 RTL-SDR dongle can manage 2.5 MHz of bandwidth over USB, by comparison, my $1,000 Yaesu FT-857d can receive all of 200 kHz in Wideband FM mode, and only whilst tuned to the broadcast band frequencies. In normal AM or FM mode it's 10 kHz, so you'd need 250 of them to listen to the same frequency range. Again, just so we're clear, in analogue radio you need to change frequency to decode a different signal. In SDR you can simultaneously decode as many signals as resources permit. For example, I can make a simple GNU Radio flowgraph, a little program, that accepts a command line setting, in GNU Radio it's called a parameter block, and run it with a frequency I'm interested in. Then I can run another copy of the same program with a different frequency. Rinse and repeat and I have as many receivers as I need. While we're at it, you don't need to run the same program multiple times, you can run an FM decoder, a RTTY decoder, an AM decoder, all at the same time, as long as the frequencies you're looking at fit inside the bandwidth of the receiver you're playing with. Just so we're clear, this is one receiver, one antenna, one power supply, with as many decoders as resources allow. In other words, these two methods, analogue and SDR, are not the same. Am I glossing over things? Sure. With such a wide bandwidth comes susceptibility to interference and signal overload, also the RTL-SDR dongle doesn't transmit, although, in 2014 Ismo OH2FTG managed to change the centre frequency of his dongle 300 times per second, causing the on board oscillator to leak in a controlled manner, making a Frequency Shift Keyed or FSK transmission. Yes, I know, that's not quite up to the standard of a transmission coming from an 857d. You'll also need a computer, which you don't need to run an analogue radio, though truth be told, an analogue radio from the last couple of decades is pretty much a computer anyway. You can likely get away with a Raspberry Pi to process the data coming from an RTL-SDR dongle, so another $5, and yes, you'll need a monitor, keyboard, and a power supply. The point I'm making is that these two methods are not the same and in the evolving world of amateur radio, there's space for both. It also means that once you have this infrastructure, you can start experimenting with new radio technologies and approaches. Will it make my 857d and its siblings obsolete? Perhaps, but I doubt it. There's still plenty of valve radios going around, not to mention the spark gap transmitter at Grimeton in Sweden. In other words, this is growing the hobby, which ultimately is why I'm here. I will mention that it's not all hot cocoa and cookies. I've spent the past two days attempting to figure out why my very simple AM decoder isn't actually playing back the local ATIS or Automatic Terminal Information Service and why MacOS SDR applications don't include SoapySDR support, because of course they don't. Oh, yeah, I'm still trying to get my Proxmox server guest audio to work. I'm sharing this to make sure that you understand, that just like creating your own circuit board design and building it, there's plenty of experimentation to be done, problems to solve and challenges to meet, ultimately we're playing at the bleeding edge, at least it's not with sharp or hot implements. I'm Onno VK6FLAB

Agile or waterfall? Wrong question. In our latest Surf the Chaos episode, we revisit a topic that keeps coming up — organizations aren't choosing between methodologies anymore. They're dissolving the barrier entirely and just grabbing whatever tool works. Multifaceted skills are winning over rigid roles. And in our Throwing Bones segment, we get into something that'll resonate with anyone job hunting right now: the ATS screening system is starting to crack. Resumes are being gamed, fake candidates are appearing in interviews, and the whole process is slowly having a break down — but there's a glimmer of hope with groups working to bring humans back into hiring. Episode 4 is out now. Listen wherever you get your podcasts. #SurfTheChaos #Agile #FutureOfWork #Hiring #Podcast #neuland Neuland https://www.neuland.com/ Find Stuart linktr.ee/stuartliveart
 Find Dave linktr.ee/mrsungo
 No One Is Coming to Save You: The Power-Ups you need to surf the chaos
Amazon: tinyurl.com/yv7chp54
 Leanpub: leanpub.com/surfthechaos ******************************************************
The soundbed at the start and end of the podcast was built using samples from freesound.org/
Waves on Rocks with CP water and surf.wav by sparxx001 -- freesound.org/s/684383/ -- License: Creative Commons 0
SFXShuffling Dominos_Ennerdale_Xena_Owsfx.wav by Xena123457 -- freesound.org/s/709628/ -- License: Creative Commons 0
RussianMeteorite_SFX.flac by jongrubbs -- freesound.org/s/178182/ -- License: Creative Commons 0
Weather station on 5450 kHz in USB RAF Volmet 220113.wav by klankbeeld -- freesound.org/s/614719/ -- License: Attribution 4.0
Sounded created using the following samples:
Floyd Filtertron Riding G.wav by aceinet -- freesound.org/s/424240/ -- License: Attribution 4.0

L'atelier des médias reçoit le journaliste Guillaume Origoni, qui publie Le mystère des stations de nombres. Ce livre, fruit d'une enquête s'étalant sur plus de douze ans, retrace l'histoire de ces fréquences clandestines dont il est admis qu'elles ont été utilisées par les services de renseignement pour communiquer avec des agents infiltrés. Et pourraient encore l'être aujourd'hui... Le 28 février 2026 au soir, quelques heures seulement après le début des bombardements israélo-américains sur l'Iran, une fréquence s'est animée sur les ondes courte. Sur 7910 kHz, une transmission radio a débuté : une voix d'homme égrène des suites de chiffres en persan. C'est ce que l'on appelle une station de nombres. Quelques jours plus tard, elle est pasée sur 7842 kHz à la suite d'un brouillage de la fréquence initiale mais celle que l'on a baptisée V32 continue de diffuser deux fois par jour durant plusieurs dizaines de minutes et jusqu'à 1h30. Qui diffuse ces messages ? À qui sont-ils destinés ? Que contiennent-ils ? Et plus globalement : que sont les stations de nombres ? Des ondes décamétriques au service du secret Le journaliste indépendant Guillaume Origoni vient justement de publier un livre intitulé Le mystère des stations de nombres (Buchet Chastel, février 2026). Il rappelle que « tout le monde peut les entendre mais en fin de compte personne ne peut savoir quelle est la nature des communications et des messages qui sont échangés et à qui ils s'adressent ». Ce retour des voix chiffrées n'est, selon lui, pas une coïncidence : des stations de nombres avaient déjà recommencé à émettre à la suite de l'invasion à grande échelle de l'Ukraine par la Russie de Vladimir Poutine, en 2022. À lire aussi sur France 24Derrière le mystère des émissions radio en persan, le retour d'une vieille technique d'espionnage Les stations de nombres utilisent les ondes courtes (entre 3 et 30 MHz), capables de parcourir des milliers de kilomètres en rebondissant entre la croûte terrestre et l'ionosphère. Durant la guerre froide, elles étaient le « théâtre de l'esprit », selon l'expression du pionnier Havana Moon. Parmi les plus connues : Swedish Rhapsody (G02) avec sa berceuse, ou du Lincolnshire Poacher (E03). L'analogique survit au XXIe siècle Guillaume Origoni souligne la dimension esthétique et inquiétante de ces émissions : « une froideur qui confine à la rigor mortis. Ces messages n'ont pas d'âme ». Pourtant, derrière ces voix synthétiques se cache un chiffrement efficace qui repose sur un one-time pad (masque jetable), un code mathématiquement inviolable si la clé n'est utilisée qu'une seule fois. Comme l'explique l'auteur : « Personne ne peut craquer le message, personne ne peut le décrypter. Les rares fois où cela est arrivé, c'est parce qu'il y a eu une négligence humaine. » À l'heure du numérique, la survie de ces spy radios a de quoi fasciner. La résilience des ondes courtes réside dans leur robustesse, leur efficacité et la simplicité du matériel de réception. Posséder un poste de radio n'est pas suspect, contrairement à l'usage de logiciels de cryptage sophistiqués. Par ailleurs, en cas de shutdown numérique, comme en Iran, les ondes courtes restent un moyen fiable de recevoir des informations.

Many thanks to SRAA contributor, Dan Greenall, who shares the following recording and notes:Broadcaster: V32 Persian/Farsi numbers station Date of recording: March 13, 2026 Starting time: 0226 UTCFrequency: 7.842 MHz Receiver location: Israel Receiver and antenna: Kiwi SDR with MLA-30+ Active antenna Mode: Single Side Band Notes: Background material obtained via Radio Free Europe / Radio Liberty.This radio signal first started broadcasting on February 28, about 12 hours after the United States and Israel began bombing Iran.A man's voice can be heard speaking Persian, counting out a series of apparently random numbers. The numbers are read out for varying stretches of time, followed by a pause in which the word tavajjoh -- which translates as "attention" -- is spoken three times. (around the 48 second mark in the attached recording)Beginning on March 4, the signal started to be jammed, with a cacophonous screech of electronic noise that made it all but impossible to hear the numbers. The original transmission paused for a period of time, then moved to another shortwave frequency.The transmission, that has been dubbed V32 by at least one group, is called a numbers station, a Cold War-era tool that employs radio transmissions and old-school cryptology to transmit secret messages, usually to spies around the world. It's location is suspected to be somewhere in central Europe.The attached recording of V32 was made on March 13, 2026 around 0230 hours UTC on 7842 kHz upper sideband USB using a Kiwi SDR located in Israel. I began the recording on 7841.9 kHz, but switched after a few minutes to 7842 kHz. This will account for the change in voice pitch. Also attached is a brief recording of the jamming signal, or “bubble jammer”, made on March 6, 2026 on 7910 kHz (V32's original frequency) at 0218 UTC.

Busy brain? Moving feet? This one's for you. In this episode, Dave and Stu cover the tools, trends, and mindset shifts worth your attention right now. Stu makes the case for a surprisingly powerful low-tech feedback tool (index cards and envelopes — trust the process), then calls out the "waiting trap" that's keeping too many people stuck while the world moves on without them. Dave shares a heads-up on the upcoming Enterprise Agility Manifesto, dropping March 3rd from PMI and the Agile Alliance — and tempers expectations with just the right amount of agile-community realism. Plus: upcoming training classes, a CSPO in Edinburgh, a talk in Finland, and a book your mother-in-law might just love. Short. Sharp. Worth your time. Find Stuart https://linktr.ee/stuartliveart Find Dave https://linktr.ee/mrsungo No One Is Coming to Save You: The Power-Ups you need to surf the chaos Amazon: https://tinyurl.com/yv7chp54 Leanpub: https://leanpub.com/surfthechaos ****************************************************** The soundbed at the start and end of the podcast was built using samples from https://freesound.org/ Waves on Rocks with CP water and surf.wav by sparxx001 -- https://freesound.org/s/684383/ -- License: Creative Commons 0 SFXShuffling Dominos_Ennerdale_Xena_Owsfx.wav by Xena123457 -- https://freesound.org/s/709628/ -- License: Creative Commons 0 RussianMeteorite_SFX.flac by jongrubbs -- https://freesound.org/s/178182/ -- License: Creative Commons 0 Weather station on 5450 kHz in USB RAF Volmet 220113.wav by klankbeeld -- https://freesound.org/s/614719/ -- License: Attribution 4.0 Sounded created using the following samples: Floyd Filtertron Riding G.wav by aceinet -- https://freesound.org/s/424240/ -- License: Attribution 4.0

Many thanks to SRAA contributor Paul Walker, who shares the following field recording of Radio Ndarason Internationale on 12,050 kHz made on October 26, 2025 at 1836 UTC in McGrath, Alaska.

In this eye-opening episode, Dave and Stu explore how organizations lose their edge by mistaking agility for abandoning solid project management. They reveal the perilous consequences of sacrificing skills for surface-level agility and offer practical steps to regain control before chaos takes over. Discover why planning skills are collapsing, how to identify and fix skill gaps, and the critical role human skills play as return-to-office trends revive collaboration. Perfect for project managers and leaders, this episode is your blueprint for thriving amid chaos and complexity. The Plaud Note Pro https://www.plaud.ai/products/plaud-note-pro Find Stuart https://linktr.ee/stuartliveart Find Dave https://linktr.ee/mrsungo No One Is Coming to Save You: The Power-Ups you need to surf the chaos Amazon: https://tinyurl.com/yv7chp54 Leanpub: https://leanpub.com/surfthechaos ****************************************************** The soundbed at the start and end of the podcast was built using samples from https://freesound.org/ Waves on Rocks with CP water and surf.wav by sparxx001 -- https://freesound.org/s/684383/ -- License: Creative Commons 0 SFXShuffling Dominos_Ennerdale_Xena_Owsfx.wav by Xena123457 -- https://freesound.org/s/709628/ -- License: Creative Commons 0 RussianMeteorite_SFX.flac by jongrubbs -- https://freesound.org/s/178182/ -- License: Creative Commons 0 Weather station on 5450 kHz in USB RAF Volmet 220113.wav by klankbeeld -- https://freesound.org/s/614719/ -- License: Attribution 4.0 Sounded created using the following samples: Floyd Filtertron Riding G.wav by aceinet -- https://freesound.org/s/424240/ -- License: Attribution 4.0

Staring at your fish finder and seeing nothing but squiggly lines? Or worse—a completely blank screen while you're trolling for salmon in Puget Sound?In this episode, Jamie breaks down the four essential fish finder skills that'll help you stop guessing and start catching more salmon in Puget Sound and Washington waters. You'll learn how to dial in your settings, interpret what you're actually seeing, and make real-time decisions that put your gear right in front of the fish.Episode Overview: Why leaving your sonar on "auto" is sabotaging your catch rate How to choose the right frequency for your depth What those arches and bait balls actually mean—and what they don't Simple adjustments that will help you catch more fish consistently Timestamps: 00:00 – Why your fish finder feels overwhelming 01:00 – The 4 essential fish finder skills 02:00 – Using the right frequency for your depth 03:00 – Understanding what your sonar is showing you 04:00 – Don't be afraid to tweak your settings 05:00 – Fish finder decision making: React to what you see 06:00 – Making it a habit and final takeawaysKey Takeaways: Low frequency (50-83 kHz) = zoomed out, wide view with less detail. High frequency (200 kHz) = zoomed in, sharp detail on smaller area. Big arches don't always mean big fish—interpret shape, density, and what's around it. Your downrigger ball sits higher than the depth you set it at due to momentum and angle. When you see bait or marks, adjust your gear depth immediately—don't just observe. If you're not watching your fish finder consistently, you're missing fish.Resources & Links: Washington Department of Fish & Wildlife fishing regulations: https://wdfw.wa.gov/fishing/regulationsWant the full structured learning experience? Join the waitlist for Anglers Unlimited Gold membership at https://anglersunlimited.co/goldAbout the Podcast Fishing for a Reason is the Pacific Northwest saltwater fishing education podcast for new anglers and families who want to catch more salmon, halibut, lingcod, shrimp and crab in Washington waters. Hosted by Jamie & Scott Propst from Anglers Unlimited, each episode delivers practical techniques, local knowledge, and expert insights to help you get off the couch and into the fish. Perfect for relocated professionals, military families, and boaters who are just getting into fishing.

COPYRIGHT NDR Live, off-air, two-hour recording of the special annual Gruss an Bord program from German broadcaster NDR, Norddeutscher Rundfunk, on 24 December 2025. Gruss an Bord features music and greetings to and from mariners around the world. The Christmas greetings were recorded at an event in Hamburg.Relatives and friends had the opportunity to wish their loved ones at sea a happy holiday and a happy new year. The Hamburg event was recorded on the third Sunday of Advent, 14 December, in the Duckdalben International Seamen's Club and was hosted by Susanne Stichler. The program included a number of special guests including Bishop Kirsten Fehrs; Hamburg's Senator for Economic Affairs, Melanie Leonhard; the Federal Government's Maritime Coordinator, Christoph Ploß; and Vice Admiral Axel Deertz. Music was provided by the folk music duo of Frank Grischek and Ralf Lübke. The broadcast was primarily in German, however there were several minutes in English when Filipino seamen were interviewed and some of the songs had English lyrics.In addition to being carried on the NDR Info and NDR Info Spezial networks, the broadcast was transmitted around the world on shortwave using transmitters at Nauen, Germany; Issoudun, France; Tashkent, Uzbekistan; and Okeechobee, Florida, U.S.A.; and was organized by Media Broadcast.The scheduled frequencies (kHz) were: 6030 (via Issoudun) for the Northeast Atlantic, 6080 (via Tashkent) for Europe, 9635 (via Nauen) for the Indian Ocean, 11650 (via Issoudun) for the Atlantic and Indian Oceans, 13830 (via Nauen) for the Southern Atlantic, and 15770 (via Okeechobee) for the Northwest AtlanticMonitors reported that the program did not air on 9635 or 11650 kHz.This recording was made in Hanwell (just outside Fredericton), New Brunswick, Canada. It is of the transmission on the frequency of 15770 kHz for the full two hours.The recording was made primarily using a Belka-DX receiver in pseudo-synchronous (AM2) mode with a bandwidth of 50 Hz - 2.7 kHz outdoors with a Tecsun AN-03L 7-metre wire antenna Reception was quite good for the most part with a bit of fading at times. But that receiver was initially tuned to 13830 kHz with a weaker signal. However, 15770 kHz was being recorded simultaneously with a KiwiSDR 2 software-defined radio receiver in narrow AM (AMN) mode with noise cancelling and with a W6LVP indoor magnetic loop antenna. So, the recording here has about a 4-1/2-minute splice from the KiwiSDR receiver at the beginning with the remainder of the recording from the Belka-DX receiver. A few seconds of the end of the program are missing as WRMI cut over to other programming before the complete end of the program.

Many thanks to SRAA contributor Dan Greenall, who shares the following recording and notes:Broadcaster: Radio Barquisimeto, Venezuela 1970Frequency: 4.990 MHzReception location: Ancaster, Ontario, CanadaReceiver and antenna: Hallicrafters S-52 using a longwire antennaNotes: On 4990 kHz shortwave, Radio Barquisimeto in Venezuela was one of the "regulars" on the 60 metre band here in southern Ontario Canada during the evening hours in the 1970's. On nearby 4980 kHz, you could find Ecos del Torbes from San Cristobal.

Consider supporting my show with a donation via PayPal to vorwinfo@gmail.com it needs your help to survive! New Broadcast to East Asia - Thursdays at 0900 UTC on 9705 kHz (300 kW from Taiwan) Main Broadcasts: 4840 kHz at 2 AM Eastern every Saturday Morning (New Show) 4840 kHz at 12 AM Eastern every Monday Morning (New Show) Repeat Airings: 5950 kHz at 7 PM Eastern every Saturday Evening (Rebroadcast) 5950 kHz at 8 PM Eastern every Sunday Evening (Rebroadcast) 7730 kHz at 8 PM Eastern every Sunday Evening (Rebroadcast) 5850 kHz at 3 AM Eastern every Tuesday Morning (Rebroadcast) 15770 kHz at 3 PM Eastern every Tuesday Afternoon (Rebroadcast) 9455 kHz at 6 PM Eastern every Wednesday Evening (Rebroadcast) 7570 kHz at 10 PM Eastern every Wednesday Evening (Rebroadcast) 9395 kHz at 10 PM Eastern every Wednesday Evening (Rebroadcast) 15770 kHz at 11 AM Eastern every Thursday Morning (Rebroadcast) 9955 kHz at 6 PM Eastern every Thursday Evening (Rebroadcast)

Foundations of Amateur Radio On your amateur radio journey, you'll likely discover that many transceivers run on 13.8 volt DC, give or take. For example my FT-857d requires 13.8 volt plus or minus 15 percent, with a negative ground, and a current draw of 22 ampere, more on that later. In other words, the power supply needs to be between about 11.7 and 15.9 volts, the same voltage that runs most vehicles with some wiggle room for fluctuating alternator charging cycles. While some radios will absolutely fit in your car, there's plenty where that just isn't the case, even though they're set-up for a 13.8 volt power supply. You might think of it as an anachronism, a few steps removed from spark gap transmitters, but there's more to the story. Most residential power grids run on AC power, at varying voltages and frequencies between 50 and 60 Hz. Across the world there's eight different AC voltages in use between 100 and 240 volts. Some countries use more than one combination and I haven't even looked at three phase power. Perhaps 13.8 volt DC isn't looking quite as odd. With this revelation comes the need to actually have 13.8 volt available in your shack. Converting your grid power to something you can plug your gear into requires some form of transformation, typically achieved with a power supply. Efficient, cheap and plentiful, the switch mode power supply is the most common. Built to a price, they're also often noisy, not just the fan, but noisy from a radio emissions perspective. Amateur radio has very sensitive receivers and as a result you can often hear, or see if you have a waterfall display, RF birdies, a sound reminiscent of a budgie whistling, every 100 kHz or so across the whole radio spectrum. Not something most other equipment cares about, so you're often left to fend for yourself in figuring out how to deal with this phenomenon. There's plenty of filtering techniques and circuits to be found and some of them even work, but for my money, I'd spend it on a power supply that doesn't make noise in the first place. A regulated power supply maintains a constant output voltage or current, regardless of variations in load or input voltage. An unregulated power supply can wander all over the place. Adjustable power supplies allow you to set the voltage, amperage, or both, sometimes with knobs, sometimes using external controls. At this point you might decide that this is all too hard and you want to do away with all this complexity and use a Sealed Lead Acid, or SLA battery, after all, that's what the 13.8 volt is based on, but then you'll need to charge it. Similarly, picking any battery technology requires some form of charging. Another word for charger is: power supply, often a switch mode one, and likely not filtered in any way that matters to you, since batteries, and for that matter solar power inverters, are unlikely to care about RF birdies. I will make mention of linear power supplies. When I started on this journey, this was the strong recommendation from my peers as the most desirable option. Although they're significantly less efficient than switch mode power supplies, only 30 percent versus better than 80 percent, from an RF perspective, they're extremely quiet. Of course, the lack of efficiency reveals itself in the form of heat, which necessitates the application of cooling, from a fan, often a very noisy fan. One potential source of power supply is a computer power supply unit or PSU. Before you go down that route, consider that they're intended for installation inside a case, often generate various voltages at very specific current draws and are not typically known for being RF quiet. After weighing up all the variables, I chose a laboratory grade switch mode current limiting adjustable power supply. It's set to 13.8 volt and it sits on my desk doing its thing. Rated at 1 to 15 volts at 40 ampere, it's now as old as I am in amateur radio terms, well and truly a teenager, it's also overkill, by quite a margin. Remember when I mentioned that my FT-857d is rated at drawing 22 ampere? As a QRP or low power station I typically use my transmitter set to 5 watt, but even when others use it at full power, I have never ever seen it draw more than 12 ampere. That's not to say that it can't draw 22, I've just never seen it. As a benefit of having such a massive overkill in the specifications of my power supply, I can power more than one radio and not notice. Not that they're all transmitting at the same time, or using more than 5 watt, it just doesn't matter. I previously discussed setting a standard for coax connectors in the shack, the same is true for deciding what to pick for power supply connectors. In my case I chose Anderson Powerpole connectors. Pins come in 15, 30 and 45 ampere ratings, are genderless and housings are available in many different colours. When I say genderless, it means that you can join two identical connectors. Within my shack, I use the RACES or ARES Powerpole wiring standard and every single 13.8 volt connection uses it. If I get new gear that uses some other connector, I'll cut the power supply wire in half and terminate both the power supply and the cut off cable using Powerpole connectors. That way my gear will connect to my own power supply and I'll have a universal adaptor cable when I need it. Over the years I've collected an impressive array of adaptors using this method and it's helped immensely when sharing gear with other amateurs. Word of warning, make sure you get positive and negative the right way around when you join your Powerpole connectors, and make sure that you have the red and black housings the right way around too, you can thank me later. If you do this more than a few times, I'd recommend that you spend the money on a proper crimping tool. It makes the experience So. Much. Better. To avoid many of the pitfalls of interference whilst connecting power and coax to the same radio, try hard to avoid running both in parallel, or worse, joined to each other. Instead, attempt to run them in different directions and only cross at right angles if you have to. One thing to consider is the ability to switch everything off immediately. To that end I have a power switch on my desk that isolates all power to the equipment. You'll notice that I have not said anything about grounding or earthing, that's on purpose. Your laws and mine are not the same. Similarly, information you'll find online rarely, if ever, describes the jurisdiction it applies to, so, look at your own rules and implement accordingly. I'm Onno VK6FLAB

Many thanks to SRAA contributor Paul Walker, who shares the following field recording of the BBC World Service on 9410 kHz made on September 28, 2025 at 0603 UTC in McGrath, Alaska. Paul notes that this was an exceptionally strong signal to have been received in McGrath, Alaska.

We're on Patreon! Find us at https://www.patreon.com/AudioUnleashed Although Brent and Dennis will probably never again work up the gumption to attend CES, they can muster the courage to read through others' CES reports and weigh in with their own opinions. That's this week's first segment. Then they check out an article from Darko about age-related hearing loss and its relationship with audio copium, and think real hard about whether buying a $10,000 DAC is worth it if you can't hear above 12 kHz. They then take a TAS hostage video hostage and use it as a jumping-off point for a deep dive into Class G and H amp topologies.    And for Patrons: What the heck is Snyderman's Maxim? And would you want a million-dollar audio system if you could only use it to listen to “Hotel California”?  

Many thanks to SRAA contributor David Goren, who shares the following recording of Emisoras Jesús del Gran Poder Quito, which he recorded on cassette tape, most likely in the summer of 1989. This broadcast was received on 5050 kHz.

Many thanks to SRAA contributor Paul Walker, who shares the following field recording of the BBC World Service (French Language Service) on 13790 kHz made on Sept 20, 2025 at 1815 UTC in McGrath, Alaska.

Many thanks to SRAA contributor Paul Walker, who shares the following field recordings of the BBC World Service on 9410 kHz made on September 19, 20, and 25, 2025 at 0458 UTC in McGrath, Alaska. Paul notes:The English feed via Ascension to West Africa operates from 05:00 to 07:00 UTC on several days in late September, featuring something rare: the carrier is switched on, followed by a brief silence and then an interval signal. This sequence occurs every time I hear this transmission sign on, but I have noticed it almost nowhere else on BBC World Service shortwave, which usually just “crash starts” and ends abruptly.

Ever wondered how a “high-efficiency” motor can start wasting energy and damaging bearings before it's even been switched on?We did too. So we tested it.Using offline motor circuit analysis alongside online motor current signature analysis, we inspected brand-new IE4 motors still sitting in their crates. What we found changed the conversation completely. Critical impedance imbalance straight out of the box. One motor already showing early winding defects before it ever saw load.That's the moment labels stop mattering and evidence takes over.This episode walks through why pairing de-energised and energised testing matters.Offline MCA tells us what's happening in the windings – contamination, resistive imbalance, insulation condition. Online MCSA, sampled at 44 kHz with serious resolution, shows us what vibration often can't: rotor bar issues, air-gap problems, electrical harmonics, inverter-driven bearing currents.In difficult environments – noisy plants, submersible pumps, generators, limited access assets – current signature analysis often gives cleaner, more repeatable insight than vibration alone. We're seeing faults that used to hide in the noise.And this isn't theory. Across 750+ motors tested in the field, we see a clear link between impedance imbalance and winding health:• 15% – criticalThat gives teams something powerful: defensible alarm limits and a simple acceptance test that stops bad assets entering the plant.There's a practical win too. On one motor we reduced resistive imbalance from over 30% down to around 3.8% just by cleaning and correctly torquing the terminations. Test. Fix. Retest. Immediate improvement.The real gains come when sites take this seriously: Acceptance testing written into purchase orders. Evidence required from the factory. Faults confirmed using at least two technologies.That's how you reduce energy loss, prevent shaft currents from destroying bearings, and turn condition monitoring into real reliability improvements – not reports that sit on a shelf.If uptime matters. If energy efficiency matters. If you want better decisions with less noise and less drama.This episode shows the path: measure what matters, set your own standards, verify the fix, and keep learning.Enjoy the episode. If it helps you rethink your motor strategy, subscribe, share it with a teammate, and drop a quick review with your biggest testing win or surprise.Support the show

De TP-7 van het Zweedse Teenage Engineering is een draagbare audio-recorder die zich lastig laat vangen in één categorie. Het apparaat is bedoeld voor spraakopnames, interviews, memo’s en field recording, maar flirt tegelijk nadrukkelijk met de wereld van muziek en performance. Dat past bij het bedrijf erachter. Teenage Engineering werd in 2005 opgericht door Jesper Houthoofd en David Mollerstedt en bouwde een reputatie op met iconische, minimalistisch vormgegeven muziekgadgets zoals de OP-1. Design en eenvoud staan daarbij altijd centraal, maar wel tegen een stevige prijs. Die filosofie zie je direct terug in de TP-7. Het apparaat is gemaakt van aluminium, heeft een opvallend groot draaiwiel en een klein, sober scherm. De bediening is extreem minimalistisch: geen knoppenrijen of uitgebreide menu’s, maar vrijwel alles loopt via dat ene wiel. Dat oogt rustig en doordacht, maar suggereert ook een eenvoud die in de praktijk niet altijd klopt. Qua opnamekwaliteit stelt de TP-7 niet teleur. Hij beschikt over een goede interne microfoon en een ingebouwde audiocompressor. Opnames klinken duidelijk beter dan wat je gemiddeld met een smartphone vastlegt, al blijft het verschil beperkt. Voor serieuzer werk is het aansluiten van externe microfoons eigenlijk onmisbaar. Opnemen kan tot 96 kHz, met 128 GB interne opslag en een batterijduur van ongeveer zeven uur. Via drie jack-aansluitingen kun je externe apparaten koppelen. Teenage Engineering richt zich met de TP-7 onder meer op journalisten en makers. In de praktijk zijn er slimme details, zoals het tijdelijk pauzeren van een opname door het draaiwiel vast te houden tijdens een interview. Tegelijk voelt het apparaat soms te abstract. Juist door de extreme eenvoud is er een leercurve, en denk je regelmatig: dit gaat sneller op een ander apparaat. Om dat te testen is ook een muzikant gevraagd om ermee te werken: Fump.ie. Die liet zien hoe creatief je met de TP-7 kunt zijn, maar was kritisch: het luxe ontwerp maakt je voorzichtig, waardoor je ’m minder snel meeneemt. En dat is juist waar hij voor bedoeld is. Het maakt je dus minder creatief dan je wil zijn. Met een prijs van 1500 euro, zonder accessoires zoals een hoesje, positioneert de TP-7 zich duidelijk als luxe gadget. Voor liefhebbers van design en experiment is het een intrigerend apparaat. Voor praktisch dagelijks gebruik blijft de vraag of die elegantie ook echt iets toevoegt. Luister de hele review in de podcastSee omnystudio.com/listener for privacy information.

What if the fastest way to a better mix is caring more about the human, the song, and the signal path than the plugin chain? We pulled seven moments from our 2025 conversations that changed how we write, record, mix, and master, and stitched them into one practical, heart-first guide you can use on your next session.We start where great records begin: with the singer. Rich Bozic, a professional vocal coach, shares why physical comfort is essential for sound design, encompassing layers, a calm seat, a dialled-in headphone mix, and planned breathers to manage fatigue. Then we zoom out with Dan Giffin, who reminds us that composition beats the perfect kick. His three-touch rule snaps you out of tweak loops and keeps momentum high, while a top-down approach to mixing preserves the vibe you loved in production.Next we clean up the myths around digital audio with Ian Stewart's crystal-clear take on sample rate and the Nyquist theorem. You will understand why 48 kHz often hits the sweet spot for modern workflows, how aliasing and imaging appear, and when oversampling actually matters. We carry that clarity into big, emotive mixes with Drum X Wave and Brian Skeel: translate vision to buses first, let guitars and synths complement rather than collide, and make size breathe with arrangement, not brute force.We also unpack the creative blind spots Michael Oakley calls out, how you can become “noseblind” to your own work and why feedback before the third rewrite can save songs. And we wrap with Eric Mitchell on mastering restraint: distortion as salt, not a main course. A little saturation wakes the record; too much smears it. Forget the viral “crank it” tips and listen for blur as much as for bite.Links mentioned in this episode:Listen to E194Listen to E181Listen to E203Listen to E215Listen to E207Listen to E188Listen to E182Send me a messageSupport the showWays to connect with Marc: Listener Feedback Survey - tell me what YOU want in 2026 Radio-ready mixes start here - get the FREE weekly tips Book your FREE Music Breakthrough Strategy Call Follow Marc's Socials: Instagram | YouTube | Synth Music Mastering Thanks for listening!! Try Riverside for FREE

HMCS margaret Brooke off rothera station during the canadian antarctic science research expedition on March 15, 2025 (Courtesy of Dr. kevin wilcox) A live, off-air, half-hour recording of the BBC World Service special Antarctic Midwinter Broadcast on 21 June 2025 beginning at 21:30 UTC.The broadcast, hosted by Cerys Matthews and which celebrated the 70th anniversary of the first BBC broadcast to Antarctica, featured messages and music for the members of the staff of the British Antarctic Survey (BAS) overwintering in Antarctica at the Rothera (Antarctic Peninsula) and King Edward Point and Bird Island (South Georgia) research stations. In addition to personal messages from family and friends, there was a message from Professor Dame Jane Francis, Director of BAS, who highlighted the construction of the Discovery Building at Rothera, and a very special message from King Charles III, a first for a monarch, highlighting climate change. He said "Each observation, measurement and calculation you undertake adds to the world's understanding of the Earth's fragile systems."The recording is of the transmission on 12065 kHz from the BBC's Woofferton, England, transmitting station. The broadcast was received by the Web-interface wideband software-defined radio at the University of Twente in Enschede, The Netherlands, with a "Mini-Whip" antenna in AM synchronous mode with 5.08 kHz RF filtering. Reception was quite good with little noise or fading and good signal strength. The additional parallel frequencies of 5960 kHz from Al'Dhabbaya, United Arab Emirates, and 9575 kHz from Ascension were heard but not as well as 12065 kHz.

Many thanks to SRAA contributor Carlos Latuff, who shares the following field recording of All India Radio on 9620 kHz made on August 20, 2025 at 19:34 UTC in Porto Alegre, Brazil.

Many thanks to SRAA contributor Paul Walker, who shares the following field recording of the Voice of Korea on 11,910 kHz made on August 29, 2025 at 18:51 UTC in McGrath, Alaska. Paul notes that the recording begins in French then moves to their English language service.

Many thanks to SRAA contributor David Goren, who shares the following recording of Radio Gjirokaster recorded in January 1988, likely on 7200 kHz (but subscribers can comment with corrections). David was using his Panasonic RF-2900 as a receiver. He has also kindly shared the following photos of his logs and the cassette tape notes. David notes:Found this little scrap on an old cassette…it's the middle of a recording of the Road Gang, the trucking show I was obsessed with at the time…and of course I would tune around during it sometimes and I marked the cassette…I have Gjirokaster and Yerevan in the same segment

The Thompson Show – October 24, 2025 (WWCR 4840 kHz) Todd closes the curtain on The Thompson Show's shortwave era with a defiant, reflective, and emotionally charged finale. After months on WWCR's legendary 4840 kHz frequency, he signs off with a sweeping critique of modern politics, a warning about human nature, and a reminder of what made the show—and shortwave itself—worth keeping alive.

Many thanks to SRAA contributor Carlos Latuff, who shares the following recording and illustrated listening report for this Voice of Vietnam broadcast celebrating their 80th anniversary. This recording was made on September 7, 2025 at 20:39 UTC on 11,885 kHz from Rio de Janeiro, Brazil:

**Unveiling Bigfoot Mysteries with James Lady | Untold Radio Network**Join us on this thrilling episode of the *Untold Radio Network* as hosts Doug Hajicek and Jeff Perrella dive deep into the enigmatic world of Bigfoot with special guest James Lady, head of the Michigan Aboriginal Project!

¡Vótame en los Premios iVoox 2025! VIII ANTES DE NADA QUIERO RECORDARTE QUE LOS PREMIOS IVOOX HAN COMENZADO. Pulsa en el enlace. https://go.ivoox.com/wv/premios25 El episodio se sumerge en los archivos más perturbadores de la radio mexicana paranormal, revisando algunos de los testimonios más recordados y debatidos en la historia de La Mano Peluda y su antecesor, La Mano Pachona. Abre con una declaración de intenciones: la eterna lucha entre la necesidad de creer y la inevitable duda del escéptico. A través de cuatro casos emblemáticos, el programa reconstruye momentos que marcaron a toda una generación de oyentes entre los años 1995 y 2014, cuando México vivía una auténtica fiebre por la radio nocturna de misterio. El Caso Josué El joven Josué Velázquez, residente en California, afirmó haber realizado un pacto satánico. Su conversación con Juan Ramón Sáenz en 2002 es una de las más célebres de la radio esotérica. Años después, en 2011, durante una reunión televisiva con el mismo conductor, ocurrieron hechos extraños: el cámara sufrió una hernia repentina, el investigador Mario Estrada tuvo un grave accidente y Sáenz murió el 29 de mayo de 2011 de peritonitis aguda. Hoy, Josué ejerce como pastor en Puerto Rico. El caso abrió un debate aún vivo: ¿coincidencia o consecuencia? 2. El Niño Reencarnado de Sierra Fría (2014) Alejandro Javier Álvarez, de Guanajuato, llamó al programa conducido por Rubén García Castillo para contar la historia de su hijo Álex, quien aseguraba recordar una vida anterior en Sierra Fría, Aguascalientes, donde habría vivido entre 1898 y 1926. El menor describía lugares y costumbres imposibles para su edad. Psicólogos no hallaron explicación. El niño finalmente se negó a seguir hablando del tema, dejando tras de sí un testimonio que desafía a la ciencia. 3. La Radio Rusa – UVB-76 (1980s–actualidad) Se analiza la misteriosa frecuencia de 4625 kHz, conocida como “The Buzzer” o UVB-76, activa desde hace más de 35 años en Rusia. Transmite un zumbido constante interrumpido por voces que recitan palabras sin sentido aparente. Aunque se cree que es una frecuencia militar, jamás ha sido reconocida oficialmente. El relato describe su inquietante ambiente y su posible relación con protocolos de guerra nuclear. Un misterio real, documentado y todavía vigente. 4. El Caso Clarita (1995) Transmitido en La Mano Pachona, el antecedente directo de La Mano Peluda, conducido por Víctor Manuel Barrios Mata, esta llamada estremeció a todo México. Una mujer llamada Clarita narró cómo su hijo de 15 años, tras usar una ouija, comenzó a mostrar poderes paranormales, levitaciones y cambios físicos inexplicables. La desesperación real en su voz marcó un antes y un después. Tras esa noche, se reportaron fenómenos en el estudio: mesas que se movían, luces que parpadeaban y empleados que renunciaron. Nunca se volvió a saber de Clarita ni de su hijo. Queremos creer… pero cuando lo vimos de primera mano, dudamos. Cada caso se apoya en registros reales, transmisiones, fechas y nombres verificables, pero sus consecuencias y fenómenos escapan a la verificación empírica. Por eso, el programa mantiene una tensión constante entre razón y fe. El Caso Josué es probablemente el más documentado y, a la vez, el más controvertido. La muerte de Juan Ramón Sáenz ocurrió realmente en las fechas y condiciones mencionadas, aunque no existe evidencia médica que vincule su fallecimiento con causas sobrenaturales. El Caso Clarita, por su parte, es un clásico de la radio mexicana, y aunque no se conserva grabación completa ni registro verificable de la mujer, miles de oyentes atestiguan haberlo escuchado. El Niño de Sierra Fría mezcla tradición mexicana de reencarnación y espiritualismo con testimonios actuales, pero sin documentación externa que lo respalde. Y la radio rusa UVB-76, a diferencia de los anteriores, sí es totalmente real; su señal se puede escuchar en tiempo real y ha sido analizada por radioaficionados y universidades. HAZTE MECENAS: No dejes que La Biblioteca cierre nunca sus puertas. Suscríbete en iVoox o en tu Plataforma preferida y comparte. Gracias a nuestros MECENAS, sin ustedes esto no sería posible. Canal Telegram: https://t.me/LaLamadaDeLaLuna YouTube: https://www.youtube.com/channel/UCEOtdbbriLqUfBtjs_wtEHw Escucha el episodio completo en la app de iVoox, o descubre todo el catálogo de iVoox Originals

Many thanks to SRAA contributor, Dan Greenall, who shares the following recording and notes:Broadcaster: Radiodiffusion du Dahomey, Circa 1971Frequency: 4.870 MHzReception location: Ancaster, Ontario, CanadaReceiver and antenna: Hallicrafters S-52 using a longwire antennaNotes: Prior to 1975, the country of Benin in West Africa was called Dahomey. This recording, made in 1971, is Radiodiffusion du Dahomey in Cotonou signing off for the day. While the signal level on 4870 kHz is only fair at best, the announcement in French can be heard giving frequency information followed by "Ici Cotonou, Radiodiffusion du Dahomey" just before the end of the recording. Reception location was Ancaster, Ontario, Canada and equipment used was a Hallicrafters S-52 and a long wire antenna. Also attached is a short recording from the 1990's of Radiodiffusion Nationale du Benin in French with a voice announcement and ID just prior to sign off. Also on 4870 kHz, but using a Panasonic RF-3100 receiver and a long wire antenna in Thamesford, Ontario, Canada.

Sappalot schon 21 Uhr und keine Sau hat den Ankündigungstext geschrieben. Bleibt also AUCH DAS an mir hängen. Danke Merkel. Danke Schmitti. Danke Klaas. Danke Jakob. Also die Folge „Ist der Prominente flutschig?“ weist einen sauberen Headroom von etwa -3 dBFS auf, keine Clippings. Der Dynamikumfang liegt bei rund 14 LUFs, was diese Folge sehr natürlich wirken lässt. Das untere Mittenband um 250 Hz ist leicht überbetont, wodurch die Mischung etwas mulmig wirkt. Die Höhen oberhalb 10 kHz sind klar, aber minimal harsch bei Sibilanten. Das Stereobild ist gut definiert, mit stabiler Phantommitte. Der Raumanteil ist angenehm dezent, könnte aber etwas mehr Tiefe vertragen. Ansonsten ist Schmitti wohl wie ein Allwetterreifen. Klaas besucht bald einen Clownerie Workshop und Jakob erklärt warum manche Promis erst flutschig gemacht werden, obwohl sie sich aber ca. 8 min später wieder zu verpissen haben. Also hört diese Folge „Baywatch Berlin“. Ich kann nur sagen auch wenn die Hauptmikrofonierung etwas zu nah wirkt, bleibt das Rauschniveau aber unauffällig. Euer Tonmann Pfeife. Du möchtest mehr über unsere Werbepartner erfahren? Hier findest du alle Infos & Rabatte: https://linktr.ee/BaywatchBerlin

What does a true wall of sound feel like when the vocal still breathes? We sit down with vocalist‑producer Jay Cali (DRUMxWAVE) and mixer‑producer Brian Skeel to unpack the craft behind Severed, big drums, widescreen synths, supportive guitars, and why clarity starts with a shared vision before a single plug‑in loads.We trace the journey from demo to master, beginning with an hour of alignment on emotion, references, and the “mountaintop” vocal image that sets every downstream choice. Brian breaks down how he builds commanding vocals without harshness: Revoice for doubles and harmonies that behave like real performances, meticulous cleanup, Slate's processing for character and control, FabFilter DS for precision, and a touch of L1 to pin dynamics so automation can shape arcs. Width becomes a dynamic fader, verses intimate and centred, choruses opening with MicroShift for that lift you feel more than hear. Jay and Brian also reveal the “demon” breakdown: a vocoder moment sculpted with Baby Audio's Humanoid, tamed by Soothe 2 and widened just enough to shock, then glide.If you've ever struggled to pair synths and guitars, you'll get a clear playbook. Guitars serve aggression rather than steal focus, panned L/R and low‑passed to make way for hi‑hats and vocal air. Synth choices lean on Serum 2 and ANA 2, with patches picked for fit, not flash. The top end gets the same discipline as the low: cut clutter above 10 kHz so the mix doesn't fizz, a lesson that came into focus after upgrading monitors and hearing what the old room hid. And for loudness without lifelessness - around −7.8 LUFS - Brian details a reference‑driven, top‑down chain using Metric AB, soft clipping and bus moves to reduce limiter strain, and focused multiband to keep choruses powerful without pumping.Along the way, you'll pick up collaboration habits that save weeks: arrive with a concise brief and references, label stems to spec, and send specific revision notes. Ready to test it? Grab one current track with guitars, synths, and vocals. Try widening only the chorus vocal and low‑passing rhythm guitars until the breath returns. Hear the space? That's what loud and open can sound like. If this resonates, follow, share with a friend who mixes dense productions, and leave a quick review so more producers can find these deep dives.Links mentioned in this episode:Follow DRUMxWAVEFollow Brian SkeelListen to Chroma CloudSend me a message Support the showWays to connect with Marc: Download your FREE Producer Growth Scorecard Radio-ready mixes start here - get the FREE weekly tips Book your FREE Music Breakthrough Strategy Call Follow Marc's Socials: Instagram | YouTube | Synth Music Mastering Thanks for listening!! Try Riverside for FREE

Many thanks to SRAA contributor Dan Greenall, who shares the following recording and notes:Broadcaster: Republic of Yemen Radio via Jeddah, Saudi Arabia transmitterFrequency: 11.935 MHzReception location: Addis Ababa, Ethiopia and Riyadh, Saudi ArabiaReceiver and antenna: remote Kiwi SDRNotes: Two recordings of Republic of Yemen Radio broadcasting in Arabic on 11935 kHz shortwave from a transmitter located in Jeddah, Saudi Arabia. Reported transmitter power is 50 kw.February 15, 2025 at 1959 UTC, good signal, no hum, received using SDR located in Addis Ababa, EthiopiaApril 9, 2025 at 1658 UTC, bad hum or buzz on their signal, received using SDR located in Riyadh, Saudi, ArabiaThis station has not been heard more recently.

Many thanks to SRAA contributor Dan Greenall, who shares the following recording and notes:Broadcaster: WYFR Scituate MA transmitterDate of recording: May 02, 1974Frequency: 17.785 MHzReception location: Ancaster, Ontario, CanadaReceiver and antenna: Realistic DX-150A with long wire antennaNotes: Your Family Radio, WYFR is heard here via their Scituate, Massachusetts transmitter on May 2, 1974 at 2200 hours UTC on 17785 kHz shortwave.The station has a very colorful history:W2XAL (1927–1929)W1XAL (1929–1939)transmitter moved from Boston to Scituate, MA in 1936WRUL (1939–1966)WNYW (1966–1973)WYFR (1973-2013)transmitter moved to Okeechobee, FL in 1977transmitter purchased by WRMI in December 2013

COURTESY BAS A live, off-air, half-hour recording of the BBC World Service special Antarctic Midwinter Broadcast on 21 June 2024 beginning at 21:30 UTC. The broadcast, hosted by Cerys Matthews, featured messages and music for the 47 members of the staff of the British Antarctic Survey (BAS) overwintering in Antarctica at the Rothera (Antarctic Peninsula) and King Edward Point and Bird Island (South Georgia) research stations. In addition to personal messages from family and friends, there were interviews with Professor Dame Jane Francis, Director of BAS; Olivier Hubert, a former chef at Rothera and the Halley VI research station; and Nadine Frontier, a marine biologist at King Edward Point; and Allie Clement, an ocean scientist at Rothera. The transmitter came on the air with a test tone (1108 Hz plus harmonics) about a minute before the program started. As sometimes happens, the first few words of the introduction were missed.The recording is of the transmission on 11685 kHz from the BBC's Woofferton, England, transmitting station. The sender had a registered power of 300 kW with antenna beam 182 degrees. The transmission was received on a Belka-DX receiver with a Tecsun AN-03L 7-metre wire antenna outdoors in Hanwell (just outside Fredericton), New Brunswick, Canada, in pseudo-synchronous (AM2) mode with 50 Hz - 2.7 kHz bandwidth. Reception was quite good with little noise or fading and very good signal strength. The additional parallel frequencies of 9585 kHz from Woofferton and 9870 kHz from Ascension were heard but not as well as 11685 kHz. There was a break in transmission at about the 21-minute mark in the recording for approximately one minute. A studio quality, slightly longer, podcast version is available on the BBC World Service website.

copyright NDR Live, off-air, three-hour recording of the special annual Gruss an Bord program from German broadcaster NDR, Norddeutscher Rundfunk, on 24 December 2024 with an introductory "warm-up" segment beginning shortly after 18:00 UTC with Gruss an Bord itself starting at 19:00 UTC. The "warm-up segment" featured reports on seafaring, its economic relevance, and everyday life at sea. Gruss an Bord features music and greetings to and from mariners around the world. The Christmas greetings were recorded at an event in Hamburg. Unlike for the past several years, there was no event in Leer.Relatives and friends had the opportunity to wish their loved ones at sea a happy holiday and a happy new year. The Hamburg event was recorded on 8 December in the Duckdalben International Seamen's Club and was hosted by Birgit Langhammer and Ocke Bandixen. Music was provided by the Swedish-South African duo "Fjarill." The broadcast was primarily in German with some greetings in other languages.In addition to being carried on the NDR Info and NDR Info Spezial networks, the broadcast was transmitted around the world on shortwave using transmitters at Nauen, Germany; Moosbrunn, Austria; Issoudun, France; Tashkent, Uzbekistan; and Okeechobee, Florida, U.S.A.; and was organized by Media Broadcast.The frequencies (kHz) were: 6030 (via Issoudun) for the Northeast Atlantic, 6080 (via Tashkent) for Europe, 9635 (via Moosbrunn) for the Indian Ocean,11650 (via Issoudun) for the Atlantic and Indian Oceans, 13830 (via Nauen) for the Southern Atlantic, and15770 (via Okeechobee) for the Northwest AtlanticThe "warm-up" segment was not carried on the NDR Info Spezial network, which broadcast the children's program Mikado instead. And as the Moosbrunn transmitter took the feed from the NDR Info Spezial network, the "warm-up" segment didn't go out on this shortwave transmitter.The recording is of the transmission on the frequency of 11650 kHz for the full three hours.The program was received outdoors on a Belka-DX receiver in pseudo-synchronous (AM2) mode with a bandwidth of 50 Hz - 2.7 kHz with a Tecsun AN-03L 7-metre wire antenna in Hanwell (just outside Fredericton), New Brunswick, Canada. Reception was fairly good for the most part with a bit of noise at times.

Consider supporting my show with a donation via PayPal to vorwinfo@gmail.com it needs your help to survive! Main Broadcasts: 4840 kHz at 2 AM Eastern every Saturday Morning (New Show) 4840 kHz at 12 AM Eastern every Monday Morning (New Show) Repeat Airings: 5950 kHz at 7 PM Eastern every Saturday Evening (Rebroadcast) 5950 kHz at 8 PM Eastern every Sunday Evening (Rebroadcast) 5850 kHz at 4 AM Eastern every Tuesday Morning (Rebroadcast) 15770 kHz at 4 PM Eastern every Tuesday Afternoon (Rebroadcast) 9455 kHz at 7 PM Eastern every Wednesday Evening (Rebroadcast) 9395 kHz at 10 PM Eastern every Wednesday Evening (Rebroadcast) 15770 kHz at 12 PM Eastern every Thursday Afternoon (Rebroadcast) 9955 kHz at 6 PM Eastern every Thursday Evening (Rebroadcast)

Consider supporting my show with a donation via PayPal to vorwinfo@gmail.com it needs your help to survive! Main Broadcasts: 4840 kHz at 2 AM Eastern every Saturday Morning (New Show) 4840 kHz at 12 AM Eastern every Monday Morning (New Show) Repeat Airings: 5950 kHz at 7 PM Eastern every Saturday Evening (Rebroadcast) 5950 kHz at 8 PM Eastern every Sunday Evening (Rebroadcast) 17810 kHz at 11:30 AM Eastern every Monday Morning (South Asia Program) 5850 kHz at 4 AM Eastern every Tuesday Morning (Rebroadcast) 15770 kHz at 4 PM Eastern every Tuesday Afternoon (Rebroadcast) 9455 kHz at 7 PM Eastern every Wednesday Evening (Rebroadcast) 9395 kHz at 10 PM Eastern every Wednesday Evening (Rebroadcast) 15770 kHz at 12 PM Eastern every Thursday Afternoon (Rebroadcast) 9955 kHz at 6 PM Eastern every Thursday Evening (Rebroadcast)