I've just recently run into an issue I'd never seen before.  I had an old Dolby Digital 5.1 track from a DVD that I wanted to use for a project.  I did some very minor editing in Premiere, and then exported to six mono wav files.  I then encoded the files with DTS Encoder Suite.  The resulting audio seemed to contain some sort of volume limiting when I played it back on my receiver.  Sudden loud noises seemed to get quieter, and then louder again once they stopped - sort of like my receiver's "late night mode" was cranked up to 11 or something. I'm trying to sort out why this may have happened, so here's what I've attempted thus far:

1. DD5.1 > Premiere > six mono wavs > DTS Encoder Suite
BAD FILE

2. DD5.1 > Premiere > 5.1 LPCM (w64)
BAD FILE

3. DD5.1 > six mono wavs (eac3to) > DTS Encoder Suite
GOOD FILE

There seems to me to be two possibilities at this point: either Premiere needs to be removed from the workflow, or eac3to needs to be added to the workflow (seeing as both of my bad results involved Premiere, and my one good result involved eac3to).  DTS Encoder Suite was involved in both good and bad results, so I'm sure that isn't the issue. eac3to IS removing the dialnorm encoded into the original DD5.1 track.  I'm wondering if that might be the culprit.  So for those who understand this, I have a question...if a DD5.1 contains dialnorm, will it be read incorrectly by a receiver if a) dialnorm is not stripped and b) the file is then put in a different codec (LPCM or DTSHD-MA 5.1)?  My theory is that the dialnorm information is not being read/decoded correctly by my receiver, because it's not seeing a DD5.1 file once I throw the audio in a new container.  So I'm thinking that when I strip that out in eac3to, it's allowing me to use those alternate containers without screwing up the decoding at the receiver's end.

Any help on this? My next test will be to run the DD5.1 through eac3to and then import/export via Premiere to see if removing dialnorm is fixing this issue or if Premiere is introducing it.

(2020-02-28, 01:54 PM)Croweyes1121 Wrote: So for those who understand this, I have a question...if a DD5.1 contains dialnorm, will it be read incorrectly by a receiver if a) dialnorm is not stripped and b) the file is then put in a different container (LPCM or DTSHD-MA 5.1)? 

No.  It's acceptable to retain dialnorm when extracting an AC-3 track. Putting such a track into another container should not cause it to be read incorrectly by a receiver; however, and this is important, the examples that you give in brackets are not containers: they are codecs.  If you wish to re-encode the AC-3, then you must indeed remove the dialnorm; otherwise, the dialnorm will be baked into the audio track.  My guess is that Premiere is indeed baking in the dialnorm, which is why option 3 (above) worked.  Of course, option 3 is what you should be doing anyway: it is not best practice to edit a delivery format, such as AC-3  [EDIT:  in an NLE such as Premiere]. 

The td;dr is that you may retain dialnorm when extracting an audio track, but you must remove it when decoding one -- eac3to's -keepdialnorm switch envisages the former, not the latter.

The easiest way to avoid this is to avoid transcoding the AC-3 entirely, editing with delaycut or eac3to directly based on an edit list. There are tutorials on this topic within the forum. The plus side is a significantly smaller filesize compared to DTS-MA and naturally no losses from decoding/re-encoding but depending on how many edits it can be a PITA.

Basically dialnorm applies a negative gain (usually -4dB) to the whole soundtrack, stripping it has the effect of raising playback by 4dB at any given level. When you play back tracks at relatively high levels this is quite a significant increase in SPL (remember decibels are a logarithmic scale)

Sorry, saying "container" rather than "codec" was just a brain fart on my part.  But you've basically confirmed what I was thinking - I need to remove the dialnorm first, before editing in Premiere, exporting, and creating my DTSHD-MA file.  I can edit with eac3to, but the editing process is a total PITA compared to Premiere.  But this at least solves the issue.

If I happen to run into this in the future, I will do the following:
1. Extract DD5.1 to six mono wavs (eac3to)
2. Recombine the six mono wavs to 5.1 LPCM (audiomuxer)
3. Remux the 5.1 LPCM into the original file (tsmuxer)
4. Edit/export (Premiere)
5. Encode to DTSHD-MA.

In theory, I shouldn't have any issues going that route.

One thing you said that I don't understand, though. As far as I was aware, I wasn't transcoding the AC-3 at all. I just imported it into Premiere and exported to six mono wavs. Why would that transcode so long as I wound up in a lossless codec at the end of the process? I'd liken what I was doing to downloading an mp3, exporting it to wav, editing, then resaving as FLAC. The only way I'd lose quality is saving to a lossy format a second time.

AC3 is infamous for this, yeah.

If you're gonna be cutting it in Premiere and lossless cutting (like with delaycut or eac3to) is not an option, just convert to wav first:

The "drc_scale" part is important!

This will convert to wave64 format, because normal wave format is limited to 4 GB. Then you can split the w64 into smaller wav files to import. I know it's bothersome but it's the best way I know unless Premiere starts supporting w64.

^^ Yes, that should work. My preference would be to go to .w64 from eac3to and skip step 2.


But I'm not a Premiere user, so perhaps you are working around a problem of which I'm unaware.

AFAIK, I've never had a problem importing video with a 5.1 LPCM track into Premiere (i.e., I think it supports w64 already).  Now, it won't bring in a w64 file by itself (well, it WILL, but it will show it as six mono streams in the timeline rather than a single 5.1 stream), but if you couple it with video (with something like audiomuxer), it works fine and shows a single 5.1 stream.

(2020-02-28, 03:33 PM)Chewtobacca Wrote: ^^ Yes, that should work.  My preference would be to go to .w64 from eac3to and skip step 2.

Code:

eac3to input.ac3 output.w64

But I'm not a Premiere user, so perhaps you are working around a problem of which I'm unaware.

Ahh, yes, great idea (skipping step 2).

Thanks to everyone for their responses.  I've learned a ton from this. 

Great stuff, last time I tried Premiere didn't want to swallow w64, so I needed to feed him wav. Sometimes when the movie is short, or when you use 16 bit (wouldnt recommend it), the wav file can come out under 4 GB, but it's not great practice. You can change the 6 mono issue by changing the channel interpretation by the way. Rightclick->interpret->audio channels or something like that, don't remember exactly.

You could also consider doing your editing in Virtualdub2, that accepts w64 fine.