No audio output (silent) with converted E-AC-3 7.1 track despite AVR/Soundbar detecting "Dolby Digital Plus"

[ALLSTAR1986]

Describe the bug
After processing a video file with DTS-HD 7.1 audio using the script, the generated E-AC-3 (Dolby Digital Plus) 7.1 audio track produces no sound (completely silent) during playback.

Interestingly, the AV receiver / Soundbar detects the incoming signal correctly via eARC and displays "Dolby Digital Plus" on its screen, but there is no actual audio output.

Steps to Reproduce

1. Run the script on an .mkv file containing a DTS-HD MA / HRA 7.1 audio track.
2. Select the option to convert the audio to E-AC-3 7.1.
3. Play the resulting MKV file using VLC Media Player with HDMI Passthrough enabled (or via TV/AVR setup).
4. The receiver displays "Dolby Digital Plus", but the audio remains completely silent.

Expected behavior
The converted E-AC-3 7.1 track should output proper 8-channel audio.

Environment / Setup Details:

• OS: Windows 11 (Latest Version)
• FFmpeg Version: 2026-07-30-git-2ae2413488 (Latest Git Master Branch Build)
• Player / Test Software: VLC Media Player (with Audio Passthrough enabled)
• Audio Output: Soundbar / AV Receiver connected via HDMI / eARC

Additional context
It appears that the native FFmpeg eac3 encoder builds an E-AC-3 7.1 bitstream header/substream layout that triggers the receiver's "Dolby Digital Plus" detection, but the audio payload channels cannot be decoded properly by the hardware, resulting in silence. Converting the exact same source to E-AC-3 5.1 (-ac 6) works flawlessly and outputs sound as expected.

[HG3112]

Thanks for the detailed report.

The automated scripts are not intended to work on .mkv files, but on a single 7.1 track, it is just a 5.1 core encoder, a 4.0 dependent encoder and a stream-muxer. I suggest to demux the audio e.g. with gmkvextractGUI and process it. If it still does not work, convert to 7.1 uncompressed (wav or w64) and process the uncompressed audio.

Another source of problems could be strange characters in file name or a too long name/path of the file.

Does the audio plays ok on PC? Is the produced tmp 5.1 core ok?

[ALLSTAR1986]

Hi @HG3112 ,

Thanks for your reply! I tested the script exactly as suggested to rule out any path length or decoding issues:

Input: An uncompressed 7.1 W64 (PCM 24-bit) file, located directly in a simple root folder without special characters (C:\Audio\Track71.w64).

Result: The batch script runs through successfully and outputs the final .eac3 file.

Issue: The media player / AV receiver correctly detects the track as Dolby Digital Plus 7.1, but there is complete silence / no audio output at all.

Additional Context:

Original E-AC-3 7.1 tracks play back completely fine on my setup, so hardware or receiver compatibility is definitely not the issue.

The issue seems to be tied specifically to the muxing step (md71) or the dependent substream creation (possibly a channel mapping issue or broken bitstream header interleaving).

Do you have any idea what might be causing this, or what logs/sample data I could provide to help debug this?

Best regards!

[ALLSTAR1986]

@HG3112
Addition / Log Analysis:

I had a closer look at the md71 console output during processing. The muxing itself completes perfectly (209,116 frame pairs processed, zero frame loss). However, analyzing the initial frame headers reveals a metadata mismatch between the two substreams:

Input A (5.1 Core): compre : 0

Input B (4.0 Dependent): compre : 1 (compr : 00000000)

The dependent substream has a compression/DRC flag set while the core does not. This header mismatch in the bitstream might be causing AV receivers/decoders to mute the audio output for safety reasons.

Relevant log snippet:
Parsing first frame in inputA: SIZE 1792 - EAC3
strmtype : 00 | acmod : 111 | lfeon : 1 | compre : 0

Parsing first frame in inputB: SIZE 1024 - EAC3
strmtype : 01 | acmod : 110 | lfeon : 0 | compre : 1

[HG3112]

It is ok that compre is set to true in the dependent stream.

Perhaps some hardware decoders do not fully comply the specs and are more strict, this happens also with ffmpeg TrueHD encoder. The tmp-core file and the full output are recognized in windows? They play ok in windows? Is the problem only with the receiver or also with software decoder?

Unfortunately I only have a 5.1 receiver so I cannot do tests (only the core is recognized). I noticed as a difference with "official" dolby encoders and mine that in the dependent stream acmod is set to 101 rather than 110. This should not make any difference since channels are replaced by the cannelmap, but HW decoders may need 101. You can try, in the bat file, to replace the second command with

ffmpeg_eac371 -bitexact -i %1 -af "pan=4.0|c0=c6|c1=c4|c2=c7|c3=c5" -c:a eac3 -b:a %bdepn% -bitexact "tmp_%~n1_depn_%core%.eac3"

This should set acmod to 101