Use dynamic compression to support listening in loud environments
If you are listening to podcasts in a loud environment (e.g. in traffic) you often need to turn up the volume to understand the quiet parts. But then the loud parts hurt your ears. And in podcasts it is especially important to be able to hear the quiet parts clearly. So a dynamic range compression would be IMHO very helpful.
The idea is here, that loud parts of the podcast are left as they are, but quiet parts of the podcast are amplified.
I appreciated that very much in http://www.rockbox.org/ until I started using my phone for podcasts. (The Rockbox compressor has way too many parameters with hardly any distinguishable effect, though.) Unfortunately, I haven't found any podcast manager or equalizer on android that supports this, so it would make PodcastAddict outstanding for me.
Peter Hubberstey commented
Lately I've noticed some podcasts' amplitude (BBC World Service looking at you) vary in and out by some significant degree.
I know this is a production issue but dynamic range compression and/or normalisation would fix this issue as well as lots of others mentioned by others.
Seems to have been an issue since covid19 maybe different clips being joined from different systems etc.
I listen to podcasts whilst going to sleep and it's most annoying..
John-Michael O'Brien (Jim the Cactus) commented
I know it's been a few years since this was last mentioned, but this is a feature that I could desperately use as well. The volume boost feature lets me make quietly mixed podcasts loud enough to hear, but if they've got a volume spike in them (which is usually why they mix themselves quietly) they clip which is Bad(tm). A dynamic compressor (ideally coupled with a normalizer) would make this a non-problem.
Matthew Alvarez commented
I believe boosting volume is the wrong approach, rather the loudest parts should be reduced. I think it would be easier to implement this way. Regardless of how, this is the feature I would most appreciate!
This is a feature I would love. Before PA, I listened via MP3's on CD--when I'd make the CD, I'd compress and normalize with the LInux app Sox, it made a big difference. If compression is battery draining, maybe it could be done while or right after downloading so users could choose to schedule this when their phone is charging.
Key feature. Thanks for this great suggestion
Brandon Deriso commented
Brandon Deriso commented
The current implementation of volume boost is actually quite dangerous from a sound design standpoint, it could dance people's speakers requiring repair, not to mention run audio quality when a loud podcast gets overdriven.
Is there a way to use compression with Android SDK?
This should be combined with normalisation as suggested in http://podcastaddict.uservoice.com/forums/211997-general/suggestions/4209961-add-an-option-to-normalize-the-audio-volume
So the normalisation at download would bring the whole podcast to maximum volume. The dynamic compression would make the quieter bits lounder. I think some people would need control of this per podcasts, but I'd be happy for it to be on/off all the time.
Olaf Marzocchi commented
I agree this feature is very needed for many podcasts. It is important to compress the dynamic range on a podcast basis: some podcasts do that already before releasing the episodes. It is also important to make sure that no clipping is introduced because it affects the listening experience heavily, while dynamic compression doesn't. Together with dynamic range compression you may want to introduce a separate voice fillet to equalise with a additional click specifically for voice content, without needing to go to the equaliser.
Suggestion if feasible: maybe if you apply the amplification to the FFT coefficients before the iFFT you may save processing power, instead of doing the iFFT to have the audio wave followed by amplification. There are less FFT coefficients than audio samples in the final audio stream...
FYI there will be an equalizer in the next version... but without this dynamic compression implementation :(
Hans-Peter Störr commented
This solves the problems described in most of the comments in
whereas the normalization described there does not actually solve them. So I decided to create a separate suggestion.