AntennaPod
AntennaPod copied to clipboard
AntennaPod
Loudness normalization (compressor/limiter)
Some podcasts have wildly varying audio levels. It can be quite unpleasant to listen to them via headphones -- either you don't understand what's being said, or your ears start to hurt. This is also a health risk.
In technical terms, this is an issue of missing normalization during postproduction of the podcasts, or postproduction for a different target: Attentive listeners with a Hifi rack and speakers can appreciate voices talking softly and shouting alternately, while people with headphones, sitting on a train, jogging, or listening on car audio while driving can not.
A basic audio effect can go a long way to fix this: We need a compressor, to push up the soft parts, and a limiter, to keep the loud parts within bounds.
There are some quite sophisticated solutions for this, e.g. auphonic. A good introduction in their blog: https://auphonic.com/blog/2011/07/25/loudness-normalization-and-compression-podcasts-and-speech-audio/
For Android, this opensource app seems to offer a normalization feature: http://vipersaudio.com/blog/
I have also found this free compressor which focuses on PD apps: http://cdm.link/2013/12/free-open-source-compressor-built-pd-perfect-mobile/
and this one, which is only "free as in beer" for use in apps: http://superpowered.com/compressor-limiter-clipper#compressor
Am Sa 19 Nov 2016 11:59:14 CET schrieb Martin Fietz [email protected]:
Related to #612
Yes, and more or less identical to issue #1085. I did look through the "enhancement" tagged issues and missed the "feature request" tag, sorry for that.
Meanwhile I found your Pull request #1208 -- looks good! Back then, the project lead didn't want to mix GPL/LGPL into the MIT-licensed code. Here's an implementation of ReplayGain licensed as 2-clause BSD, that should be compatible: https://github.com/albertz/music-player-core/blob/master/musicplayer_replaygain.cpp
Cheers Michael
As a stop gap while this is evaluated, is it possible to add a volume boost option per podcast/subscription? For example, Podcast A set for 110%, Podcast B set for 90%... etc?
This issue seems kind of dead, but I'd also very much like this feature. Several of the podcasts I listen to are essentially impossible to use with a GPS, since there's no option to change the volume in OsmAnd~.
Any news/update on this?
I echo gappleto97's comment. I find it hard to listen to podcasts whilst driving and impossible with OsmAnd~. Some form of dynamic range compression would be good. Other apps have this setting it is called "volume boost" (Pocket Casts) and "voice boost" in (Overcast).
If I knew enough Java to feel comfortable submitting it I would. But it's been a long time since I wrote anything in Java that could be considered remotely production ready.
Hi, IMHO you are planning to reinvent auphonic.com. That's fine, they are already quite good, and I hope that competition will drive both of you to improve even further, and lower prices. But I don't see how that meets this feature request.
It is conceivable to include an option in antennapod to upload podcasts for processing to auphonic or your pcleaner, but that does not fulfill the need for a compressor/limiter working in the background, "always on". I listened to more than 2 GB of podcasts last month, tripling that (download/upload/download) is a heavy hit on your data transfer limits.
Cheers, good luck! Michael
Am 1. Juni 2018 00:49:31 MESZ schrieb "Brandon L. Deriso" [email protected]:
I'm currently working on a service to work-around this request here: https://www.patreon.com/pcleaner I hope you don't mind me linking it! Eventually I'll probably package it up and then we can consider submitting a pull request, but for now it will have to suffice as a standalone service.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/AntennaPod/AntennaPod/issues/2187#issuecomment-393707011
would love to see this, a compression slider on the "Audio controls" widget would be great.
There is still interest for this feature. I was in the process of creating a feature request for this when I saw this post. Just want to add my vote for it.
I am also interested in this feature. Maybe someone can implement a way to add a global setting that enables dynamic compression? Is it an option to use android's core audiofx DynamicsProcessing (see https://developer.android.com/reference/android/media/audiofx/DynamicsProcessing)
also see https://www.youtube.com/watch?v=_hPlNoF1Tyc
Just use player with audio normalization.
- Voice loudness enhancing feature
- Reducing loudness of speceffects Night Player
Just use player with audio normalization.
- Voice loudness enhancing feature
- Reducing loudness of speceffects {shameless advertising link removed}
@NuyshaKott , so your solution is to use a different media player altogether? That makes no sense in a discussion thread for feature suggestions for the AntennaPod media player product.
Antennapod does support different mediaplayers, it's in the settings. But AFAIK that one is not supported.
Cheers Michael
Am 30. Januar 2019 15:26:50 MEZ schrieb Patrick Heney [email protected]:
@NuyshaKott , so your solution is to use a different media player altogether? That makes no sense in a discussion thread for feature suggestions for the AntennaPod media player product.
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/AntennaPod/AntennaPod/issues/2187#issuecomment-458962664
Rather than trying to do this with the player, why not make it a function of download processing and normalize the files instead. I know this really won't fix the issue for those who stream episodes unless you normalize the buffer before handing it to b the player
@bytehamster normalization is a very specific digital process and is not the same a setting custom volume level as requested by #1085
https://en.wikipedia.org/wiki/Audio_normalization
Close the issue if you wish of course, but calling it a duplicate in unfair to the requesters.
This issue has been mentioned on AntennaPod Forum. There might be relevant details there:
https://forum.antennapod.org/t/normalization/337/3
If this is implemented it needs to be with an option to turn it on and off. I produce podcasts and put great effort into getting it loud enough and still have dynamics. I wouldn't want a player to by default try to normalize that as it is in many cases done in a not so good way.
Meanwhile I found your Pull request #1208 -- looks good! Back then, the project lead didn't want to mix GPL/LGPL into the MIT-licensed code. Here's an implementation of ReplayGain licensed as 2-clause BSD, that should be compatible: https://github.com/albertz/music-player-core/blob/master/musicplayer_replaygain.cpp
@ByteHamster Since AntennaPod looks like it's now on a GPL license, is there any reason the same changes proposed in #1208 wouldn't work today?
If I read it correctly, it was written for Sonic or ffmpeg. We no longer support Sonic (because it causes countless issues on various devices), so there needs to be a re-implementation for ExoPlayer. Maybe the person who does the implementation can take inspiration from the code linked above but I won't be the person who implements it :)
Hi! I'd really love to see (hear) this feature as well. Kind of a showstopper not to have dynamic compression. To make it even better than other implementations it should feature some basic controls (threshold, gain reduction ratio).
Rather than trying to do this with the player, why not make it a function of download processing and normalize the files instead. I know this really won't fix the issue for those who stream episodes unless you normalize the buffer before handing it to b the player
Just in case people were thinking of doing it this way, I don't think it's a great idea to modify the files themselves — a major problem with this sort of thing is that it might lead to clipping that sounds bad if it goes wrong, and clipping is a lossy process. This should really be post-processing done in the player itself on the fly.
If it's a huge computational burden, I think you can get something like 95% of the way there by taking a random sample of the podcast audio and calculating its norm, then adjusting the volume for the whole file up or down accordingly, see this: https://github.com/pganssle/python-norm-estimate
+1 to having this feature. I recently started listening to a new podcast that was too quiet, and I had no way to boost the volume/loudness, so while outside in noisy environments I had to pause the podcast when the ambient noise got too loud =(
Rather than 'normalisation' it seems we should go for LUFS-correction. Details about LUFS here: https://podnews.net/article/lufs-lkfs-for-podcasters (quite an interesting read).
