New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio level/peak for correct gain #1676

Open
Xuchilbara opened this Issue Nov 13, 2018 · 6 comments

Comments

@Xuchilbara
Copy link

Xuchilbara commented Nov 13, 2018

Describe the change or feature you'd like to see added to HandBrake:

I really appreciate HandBrake can let you modify the dynamic range of some audio formats.

But I've always found lacking the gain feature, as you can possibly ever know how much gain can you apply without the audio being saturated (clipping).

So... It would be amazing to have some sort of metering tool, graph or just an automatic maximum peak calculator as in Adobe Premiere.

What version of HandBrake are you currently using? (e.g., 1.0.0)

All of them.

What operating system and version are you running? (e.g., Ubuntu 16.04 LTS, macOS 10.3 High Sierra, Windows 10 Creators Update)

Windows 7 Ultimate x64 SP1.

HandBrake Activity Log required (see https://handbrake.fr/docs/en/latest/help/activity-log.html)

Can't post a log about this...
@woodstockathbf

This comment has been minimized.

Copy link

woodstockathbf commented Nov 13, 2018

Handbrake has a gain control, but it is not displayed by default, and it is not available if you chose to "pass through" the audio from the source to the destination.

On the audio tab, on the right side of the track listing (next to the red X for delete), there is an arrow (at least on the Windows GUI), that will make available additional settings for that track. One of the options is "Gain".

And no, it does not do peak leveling, it's just a "volume control" for the track.

@bradleysepos

This comment has been minimized.

Copy link
Member

bradleysepos commented Nov 13, 2018

The problem with normalization is the need to calculate the relative gain across the entire source. It's not a great idea to read a 50 GB Blu-ray source just for this. And we're certainly shying away from editor-focused features on purpose.

An alternative that could be run in real time would be a soft and/or hard limiter to avoid clipping. While I've considered this, I haven't made the time.

@jstebbins I'm not sure how our existing code handles peak overshoot. If it simply clips, are you aware whether FFmpeg has a limiter we could use?

@Xuchilbara

This comment has been minimized.

Copy link

Xuchilbara commented Nov 14, 2018

The problem with normalization is the need to calculate the relative gain across the entire source. It's not a great idea to read a 50 GB Blu-ray source just for this. And we're certainly shying away from editor-focused features on purpose.

An alternative that could be run in real time would be a soft and/or hard limiter to avoid clipping. While I've considered this, I haven't made the time.

@jstebbins I'm not sure how our existing code handles peak overshoot. If it simply clips, are you aware whether FFmpeg has a limiter we could use?

Hello, bradleysepos.

Well, I understand that kind of thing requires a lot of time, but it would make HandBrake much better and much more useful since many AC3, DTS... formats always get very low volume when converted for some reason and the DR setting isn't enough (and sometimes it even does nothing?).

So it would be very convenient to be able to get a converted file with an adequate volume level from the start...

@woodstockathbf

This comment has been minimized.

Copy link

woodstockathbf commented Nov 14, 2018

Perhaps convenient, but at the cost of a mandatory "first pass" to obtain the level information.

If you're already doing a first pass for other reasons (subtitle scan, computing bit rates), that's one thing. If not, it is a significant increase in conversion time.

@jstebbins

This comment has been minimized.

Copy link
Contributor

jstebbins commented Nov 14, 2018

There are a number of reasons a first pass is desirable. See #746 and #1483

I think it's a good idea to have essentially a "Full Scan" mode that does all of these things. It doesn't have to be mandatory. It would either be invoked manually and supply the necessary extra information, or invoked implicitly whenever the user selects an option that requires it. It's just a matter of having time to address all of this. I've had very little of late.

@bradleysepos

This comment has been minimized.

Copy link
Member

bradleysepos commented Nov 14, 2018

Indeed, when I responded previously I had forgotten we already do this for foreign audio. If we can overcome the most obvious pitfalls, no problem.

An audio normalization filter would also not require scanning the entire source to produce a short preview, so an intelligent cache that supports ranges as opposed to all or nothing would be preferable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment