LAV Filters - DirectShow Media Splitter and Decoders

[nevcairiel]

If you don't downmix the LFE, then clipping is relatively rare even in a stereo downmix, at least from a 5.1, from 7.1 its of course more severe as its even more channel.

[flossy_cake]

Originally Posted by nevcairiel

If you don't downmix the LFE, then clipping is relatively rare even in a stereo downmix, at least from a 5.1, from 7.1 its of course more severe as its even more channel.

I have always used your default downmixing settings which is center 1.00, surround 0.71, LFE 0.

If it's as rare as you say, then maybe I'll just let it clip? To be honest I never actually noticed any audible clipping while watching anything on my 5" JBL monitors so maybe it's a minor issue.

But on that gunshot scene, I tested just now and MPC-HC Normalize 100% + Regain volume sucessfully lowered the gunshot without affecting dialogue on other scenes, so maybe that could be good too.



And be sure to untick "Apply DRC for formats AC3/EAC3" on Audio Settings tab because I heard some sources that used that metadata really poorly with audible pumping like Stargate SG1 and Beverly Hills Cop 2 DVD in the intro sequence when Axel revs the engine it goes unusually quiet.

[Sunspark]

@flossy_cake Try dropping the surrounds to 0.50. See what happens on your graph.. I've been using 0.50 lately instead of 0.71 for the surrounds. Helps with spoken dialogue for me. The rest of the Mixing pane settings in the screenshot are the same.

I don't use the normalize in the player because the one in the realtek sound driver worked better for me.. you need to be in shared mode for it though, otherwise it has to be what HC has if you're in exclusive mode.

There's another mixer you can try too with HC (also shared mode), the Windows mixer. Go to your control panel (old control panel) and open sound, go through the wizard and make sure full-range is selected.. then go to properties for the audio device you're using and ensure it's a good setting like 24/48000 so it won't be resampling your video. Now in LAV uncheck mixing and in HC make sure "ignore system mixer" is not checked.. so what's going to happen now is that LAV will decode the source and it will be Windows doing the downmixing using their own coefficients which are not the same as LAV's. Try your graph again with the Windows mixer.

Lastly, if you want a full array of knobs and dials, you can do a fancy mixing job using https://equalizerapo.com/ It's overkill for me so I don't use it, but if you really need to dial something in, this is basically the only thing you can get that is free on Windows.

[flossy_cake]

Originally Posted by Sunspark

@flossy_cake Try dropping the surrounds to 0.50. See what happens on your graph.. I've been using 0.50 lately instead of 0.71 for the surrounds. Helps with spoken dialogue for me. The rest of the Mixing pane settings in the screenshot are the same.

Pretty much the same




It must be the the summing of the 3 fronts circled in red that is causing it. The 4th bar is LFE, 5th and 6th are surrounds.

[flossy_cake]

Originally Posted by Sunspark

I don't use the normalize in the player because the one in the realtek sound driver worked better for me..

The way I've got it set in the screenshot won't do much for boosting quiet dialogue or any sort of DRC type thing that you're probably after. All it will do is the same as clipping protection in LAV but with the added benefit of restoring it back to the original volume level after the clipping stops so that subsequent quiet dialogue won't be too quiet.

What I don't understand is why MPC-HC's normalizer makes the gunshot sound perceptually quieter. I was expecting it to sound the same volume but just without clipping, since both the clipped and unclipped versions are going to end up at 0dB at the optical cable going to my speakers anyway (apparently optical PCM uses integer values which can't exceed 0dB). I need to get some third party tools to debug the output levels of MPC-HC's normalizer.

[Sunspark]

I remember now, when I was playing around with HC's Normalize+Regain, I felt that 100% was not a good setting, and that's what you have set in the screenshot. Try 200% instead. 400% is too loud.

Everyone has their own different implementation of how it should work. VLC's is decent, MPV's is very customizable but you really need to know what you're doing. BE's gain control is terrible and should not be used, but their AC-3 DRC works well if the source has good metadata.

[flossy_cake]

Originally Posted by Sunspark

I remember now, when I was playing around with HC's Normalize+Regain, I felt that 100% was not a good setting, and that's what you have set in the screenshot. Try 200% instead. 400% is too loud.

I deliberately set it to 100% to avoid pumping. At 100% it doesn't raise the volume at all, it normalises to 100% which means "don't boost the volume, just leave it at 100%" which would mean something like "mutliply by 1.0" which just equals itself. So it's like passthrough.

But because the feature is still active, it's still monitoring for clipping above 0db (such as what comes out of LAV's downmixer) and reacts to that by reducing the level to avoid clipping when detected.

Then, the "regain volume" feature ensures it is raised it back to 100% after the clipping ends, which helps because then you aren't stuck with quiet dialogue after a loud explosion went into clipping for the first time.

In other words, it's the same as LAV's "clipping protection" but with the added benefit of raising it back to 100% afterwards, which is exactly what I was begging nevcairiel for earlier.

This is good for me, but not necessarily good for everyone eg. if the source was mastered with huge dynamic range where the dialogue is SUPPOSED to be quiet in relation to explosions, and you want to listen to the audio quietly at night on a modest speaker setup. In that case you'd need a DRC solution and can achieve that by raising the value above 100% to something like 200% which I would agree is a better setting than the default 400%. But then you will probably get some pumping due to the decay curves which I don't know how the MPC author has set up.

I am only familiar with the Dolby DRC curves - "music light fast" and "music standard fast" are my go-to's. From memory, "music standard fast" was causing some pumping on the intro song to Family Guy and I had to switch to the light preset. There probably isn't a one-size-fits-all solution that works perfectly for all content types. I often wondered how TV networks do it and I suspect they have metadata for each program being aired that would act as a hint for automated systems to choose which DRC curve would suit that content type. For news and sitcoms for intsance, they might choose the Dolby "speech" DRC curve. I suspect these Dolby DRC curves are what's used to create the AC3/EAC3 metadata for that other DRC feature.

[starsat]

Hello,

Could somebody take a look on this test Transport Stream file?
https://filebin.net/3amgivcfkmiohow1
It is playing correctly on mine RTX 4060 only if I'll select NVIDIA CUVID.
Playout through both DXVA (native/copy-back) and D3D11 gives macroblocks, like the TS file would be damaged, but it is not.

[Aleksoid1978]

Stream is incompatible with DXVA decoders.

[starsat]

There's no doubt about that
But what exactly makes this stream unplayable? Looks quite normal for me, AVC High@L4.1, 4:2:0, 8-bit, BT.709, 1920x1080.
This can be improved?

[huhn]

you try to get this to amd nvidia intel and hope they improve that for the next generation but beyond that reencode?

on the other hand this is Separate Field Coding which is very unusual to me. usually mbaff is used. that's maybe the one thing the hardware decoder can not handle or is missing to do a proper decode
or get's and it actual is mbaff honours SFC and falls flat?

something like that.

[starsat]

Thanks, so in fact this can be fixed only on HW level?

As a curiosity - additional stream with issues on DXVA, but here I have 2 samples taken from different time.
This service seems to dynamically changing something and one sample is unplayable, but other, taken just few hours later - is playable.
https://filebin.net/owg6sml9thygult1

[flossy_cake]

Hmm, new member, 3 posts, wants us to play a weird glitched file. Nope! Could be some kind of buffer overflow attack to make the decoder do something it isn't supposed to.

[starsat]

Everybody was a new member at some point
I'm just a satellite TV viewer, I'm using AltDVB app as my viewer and observed such behaviour for a long time, but I was never able to understand why (very rarely) this is happening.
I finally found some time to register and prepare samples and that's the whole story

Last sample is from Equ TV from Hot Bird: https://www.lyngsat.com/tvchannels/it/Equ-TV.html
I saw this also on NHK World Japan from Hot Bird: https://www.lyngsat.com/tvchannels/j...rld-Japan.html
And the first sample is from some feed. All files are just a clean TS satellite recordings.

But of course no pressure on anybody, I was just curious if this is a bug and can be fixed or it's not a bug and nothing can be done about this.