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.
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.