2020-02-28, 01:54 PM
(This post was last modified: 2020-02-28, 03:32 PM by Croweyes1121.)
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.
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.




