Posts: 471
Threads: 16
Joined: 2019 Oct
Thanks: 813
Given 227 thank(s) in 155 post(s)
Country:
2020-08-17, 09:14 PM
(This post was last modified: 2020-08-17, 09:24 PM by BDgeek.)
I know it's 2020, but I guess I still have some questions that I couldn't quite figure out about Dialog Nomarlization on AC-3, THD and DTS tracks.
I noticed that on the majority of AC-3 and THD encoded tracks on commertial discs, when attemped to decode to wav/w64 with EAC3TO, the program detects clipping and makes a second pass applying a negative gain to correct the issue. But it's usally less than the -4db Dialog Normalization standard.
- So my first question is, in case of such tracks, if Dialog Normalization flag is removed from an encoded track (EAC3TO default demuxing parameter), what would happen when played back and decoded by a regular consumer AVR product? I mean, will it occour in clipping?
My guess is that the receiver won't be able to perform such second pass correction on the fly. Is this assumption correct?
- The second question is, what's the practical implication of applying such negative gain, Does it affect the quality of the audio in any way?
- Third and final question, what about a positive gain (usually applied when setting the "normalize" option on EAC3To decoding process), does it have any negative impact on the audio quality?
In other words, is applying a positive gain is more "harmfull" than a negative one?
Thanks a lot for any valuable info!
I did a previous search on these issues, but couldn't find convincing answers. So what's better than couting on the knowledge of the great userbase here.
Posts: 1,554
Threads: 60
Joined: 2015 Jan
Thanks: 229
Given 627 thank(s) in 372 post(s)
Country:
2020-08-17, 09:54 PM
(This post was last modified: 2020-08-17, 09:55 PM by Chewtobacca.)
If you remove the dialnorm from a track, all that should happen is that it won't be applied upon playback; there shouldn't be any clipping. As I understand it, the clipping that eac3to detects is sometimes a consequence of handling the data generated by the decoding process. (I seem to remember mentioning something similar in response to your DTS-HD questions.) If the specifics are hazy, it's because madshi hasn't elaborated on this, and eac3to is closed source, so it's not always clear how it works internally.
The positive gain applied on normalizing shouldn't harm the audio, but if you are uneasy about it, don't normalize. Just turn up the volume on your amp, as you have to do with some LD PCM tracks anyway. Bear in mind that when downmixing eac3to customarily uses the second pass in place of normalizing the matrix; in other words, the matrix coefficients that it uses are not the normalized ones.
It doesn't make sense to me to say that positive gains are more harmful than negative ones. You might have to be more careful when applying the former, but in general it depends on the situation.
Posts: 471
Threads: 16
Joined: 2019 Oct
Thanks: 813
Given 227 thank(s) in 155 post(s)
Country:
2020-08-18, 12:40 AM
(This post was last modified: 2020-08-18, 12:42 AM by BDgeek.)
Thanks a lot Chewtobacca!
The answers for question 2 and 3 are fully understood!
As for the first question, you correctly pointed out we touched this issue on that other thread, but since it was going out of topic, I held of not to derail it.
But I don't think I quite understood the answer, maybe because as you put it madshi himself hasn't elaborated on this. Since EAC3TO when decoding points out it has to apply a negative gain to avoid this clipping, isn't it ocurring because the volume is too loud?
With the track originally having the dial norm flag, it wouldn't clip when decoding on consumer AVR exactly because of the -4db gain being applied. But if this flag is removed, than it might cause same trouble to the decoder, right? Or is this reasoning inaccurate?
Posts: 1,554
Threads: 60
Joined: 2015 Jan
Thanks: 229
Given 627 thank(s) in 372 post(s)
Country:
2020-08-18, 11:17 AM
(This post was last modified: 2020-08-18, 11:21 AM by Chewtobacca.)
(2020-08-18, 12:40 AM)BDgeek Wrote: With the track originally having the dial norm flag, it wouldn't clip when decoding on consumer AVR exactly because of the -4db gain being applied. But if this flag is removed, then it might cause same trouble to the decoder, right?
Not necessarily. The idea of dialnorm was that tracks with different volume levels could be played back at the same level to avoid shifts in volume when going from one to the other (like the annoying jump in volume that occurs when commercials are louder than whatever you are watching). It didn't really work, because it was rarely applied consistently, but that was the idea. Removing the dialnorm removes the adjustment to a notional norm, but that doesn't necessarily mean that the track clips without the adjustment, although it might. It's like telling someone in the house to turn the music down because it's too loud for your liking: being too loud for your liking doesn't mean it's clipping.
What you are touching on is precisely the gray area. How do receivers handle tracks that clip without applying the dialnorm? madshi says that he doesn't know, but he suspects that they will play the tracks back clipped. It probably depends on the behavior of the receiver.
(2020-08-18, 12:40 AM)BDgeek Wrote: Since EAC3TO when decoding points out it has to apply a negative gain to avoid this clipping, isn't it occurring because the volume is too loud?
The question is right in respect of the volume's being too loud but wrong in stating that eac3to is doing the decoding: it is Arcsoft or Sonic or libdcadec that is doing the decoding. The decoded data has to be transported to eac3to, and with libdcadec the data is 32-bit, allowing headroom: this is why the preferred decoder was switched from Arcsoft, which works differently: libdcadec does not apply the dialnorm, allowing eac3to to process its data, but Arcsoft does apply the dialnorm and leaves you with integer output -- at least that's my understanding of the situation. The volume reduction is applied only when necessary because it involves dithering, which is better than clipping.
Beyond this point, I can't help much, because it means going past my understanding of the principles at play. But I do think that you are thinking about all this too much. Unless you need to decode the track, leave it as it is. If you need to decode it, let eac3to do its job.
Posts: 471
Threads: 16
Joined: 2019 Oct
Thanks: 813
Given 227 thank(s) in 155 post(s)
Country:
2020-08-18, 08:28 PM
(This post was last modified: 2020-08-18, 08:34 PM by BDgeek.)
Perfect, thanks a lot Chewtobacca!
You don't need to go any further, now I got it!
And yes, for muxing purposes, I don't decode unless absolutely necessary. I do it mostly for experimenting and to compare the tracks on Audacity and Spek. My concern now is exactly because these experiments lead me to find out most tracks with dial norm indeed clip and I've always had my personal muxes with dial norm removed per EAC3TO default.
Now that I understand it better, I'm convinced it's not the best alternative
Thanks a lot for all the information and enlightment.
|