InfinityLoop1308
[Feature request] Add an option for gain (volume goes above 100%)
Checklist (Your issue will be automatically closed if you delete this part)
- [x] I make sure that there are no existing issues - open or closed - which I could contribute my information to.
I don't know why, but PipePipe as well as NewPipe (I presume the former is a fork of the latter) both have lower volume when everything is at max, when compared to the default YT app and the mods as well (ReVanced, ReVanced Extended, etc.). I presume this has maybe something to do with not honoring metadata gain that a video might have embedded.
Regardless, an option like this will be beneficial for hearing impaired people as well. I know this might damage the built in speakers or may cause ear damage, but a one time warning could be triggered if the value is raised above 100%.
I would have raised the same issue on NewPipe's repo, but there was a warning that said they're in the middle of a major rewrite and only accept bugfixes. So, I'm addressing this here, since I have no idea if PipePipe will follow the path NewPipe will be taking.
In conclusion, even if the real issue behind the volume/gain difference is found (the volume difference is definitely 3dB or more, I would be inclined to say more like 6dB), I believe an option like this would be something that would benefit everyone.
Second this, especiallly when driving in the car without being connected to the car speakers.
Enhancing gain is a very important feature as many tutorial videos use bad microphones or incompetent people who do not know what dynamic compression or level setting at the recording mic is. At least setting the recording volume to a decent level without clipping is something people should do after undertaking a small sound check....
So what can we do? Very simple: take every sample and shift the data to the left and insert a zero bit at the least significant bit
In c this would be: uint16 buffer //output buffer after decoding to be sent to /dev/dsp uint16 volume set volume to 2, 3 etc.
buffer << volume
https://en.wikipedia.org/wiki/Bitwise_operations_in_C
audio resolution suffers, but this is the only thing we can do after recording.
Shifting the bits is cheap and sufficient!
GUI: There should / may be a clipping detection. Look for the highest bit of the buffer if it sometimes gets to 1 after an volume increase operation (shift left). Then warn the used that additional "super volume" would ruin the audio data. This can be done by changing the color of the volume slider to red with a small delay for recovery as has been done at cheap tape recorders of the 1980 to show if the user recorded with too much volume (LED stayed red, small blinking was ok). So such behavior is nice for the volume slider if it gets moved over 100% so the number of bit shifts will be displayed and the slider will eventually blink red or be completely red depending on the number of "most significant bit set" events (still some room in the lower bits, but further shifting ruins audio).
Advanced: Also dynamic compression algorithms could be useful, especially when in a noisy car to overcome the noise of the car while maintaining the ability to hear for some decades. E.g. 70dBA car noise, 90dBA maximum sound pressure level leaves you with only 20dB of usable dynamic.
audio resolution suffers, but this is the only thing we can do after recording.
That is basically the only downside, but that is true for any non-master recording.
Still, it's better than nothing (not being able to hear what the video is all about).
There should / may be a clipping detection. Look for the highest bit of the buffer if it sometimes gets to 1 after an volume increase operation (shift left). Then warn the used that additional "super volume" would ruin the audio data.
Good, but only as warning. Do not actually force dynamic compression of the output signal. In some cases, the recording is of such a poor quality that there is no other way to actually hear what is being said/discussed in the video.
And an option to turn this off as well. Some might not care if the signal is continually clipping.
I would also note that doing this after the decoder would be an optimal approach, but doing it manually, with bit shifting would be... too much of an endeavor for every possible encoder/decoder out there (mp3, mp4, opus, etc.). I believe a lib postprocessing approach would be a much better approach (and simpler) in this case. Something like ffmpeg, just take the part of it that does audio postprocessing (gain, compression, whatever) and use that on the decoded signal.
Hi, as I told already bit shifting comes to play where the audio goes to the audio driver. AFTER decompression and fancy filters and effects. Because here is where the music is, here is where the speaker comes ™ :-)
It is that easy. And also do not block the user from doing stupid things (we are not microsoft) when the audio clips badly, the user will notice. Maybe he/she/it likes clipped audio. Some folks also liked to play guitar with overdriven tube amps. Just implement the “super volume” feature, that just does bitwise leftshift by 1,2,3,n bits until there is only 1 significant bit left. Cheers
Am Montag, Dezember 16, 2024 09:23 CET, schrieb xeroxslayer @.***>:
audio resolution suffers, but this is the only thing we can do after recording. That is basically the only downside, but that is true for any non-master recording. Still, it's better than nothing (not being able to hear what the video is all about). There should / may be a clipping detection. Look for the highest bit of the buffer if it sometimes gets to 1 after an volume increase operation (shift left). Then warn the used that additional "super volume" would ruin the audio data. Good, but only as warning. Do not actually force dynamic compression of the output signal. In some cases, the recording is of such a poor quality that there is no other way to actually hear what is being said/discussed in the video. And an option to turn this off as well. Some might not care if the signal is continually clipping. I would also note that doing this after the decoder would be an optimal approach, but doing it manually, with bit shifting would be... too much of an endeavor for every possible encoder/decoder out there (mp3, mp4, opus, etc.). I believe a lib postprocessing approach would be a much better approach (and simpler) in this case. Something like ffmpeg, just take the part of it that does audio postprocessing (gain, compression, whatever) and use that on the decoded signal. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": "https://github.com/InfinityLoop1308/PipePipe/issues/382#issuecomment-2544896557", "url": "https://github.com/InfinityLoop1308/PipePipe/issues/382#issuecomment-2544896557", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
Well the problem is we are an Android app and can't directly interact with the speaker/audio driver. All the playing is done through Exoplayer, and due to its restrictions it is impossible* for us to achieve the feature (see https://github.com/google/ExoPlayer/issues/3349).
However, for YouTube it is still possible to achieve a higher volume with the recently introduced DRC audio track. So as far as #732 done, this issue should be solved as well.
We plan to do #732 in maybe next 2 major versions.
*The custom AudioProcessor method will set the audio output to a fixed level, breaking the volume control
Not an ideal solution, but hey, it's better than nothing.
Do you think there is any chance ExoPlayer will implement a feature like this now, 7 years later, or not? My question is, is it worth reopening an issues like this.
EDIT: There seems to have been an issue like this open: https://github.com/google/ExoPlayer/issues/3657. Suggests opening a PR... might take a stab at it.