Creating a 7.1 Channel MKV with E-AC3/DD+

[JimmyK814]

I recently upgraded to a 7.1 channel receiver and have been trying to figure out a way to create a dolby digital plus E-AC3 encode for the audio track of my .mkv files so that I can maintain the 8 channels of audio from the source for those sources that have 7.1 channels. My receiver will decode these files over HDMI using a WDTV Live, show Dolby Digital Plus on the display and give me audio from all speakers. I don’t like using the True HD/DTS Master Audio because of the large file sizes even though I know there quality would be better for a true audiophile.

I’ve been using the expensive Dolby Media Coder SE on a MAC which is Dolby’s own program to create/convert to these sources. I end up with a seemingly valid E-AC3 file that I can put into an .MKV and it works perfectly except for one problem and the reason for my post.

When I attempt to add the E-AC3 file with MKVToolnix it will identify the source as: “EAC3 (ID 0, type: audio) from <filename>”

Just as a double check... eac3to will identify the source as:
E-AC3, 7.1 channels, 2:05:09, 1280kbps, 48kHz
(core: E-AC3, 5.1 channels, 2:05:09, 717kbps, 48kHz)
--
To the problem… whenever I click “Start muxing” I start receiving these errors:

'C:\temp\infile.eac3': Using the AC3 demultiplexer.
'C:\temp\infile.eac3' track 0: Using the EAC3 output module.
The file 'C:\temp\TestOut.mkv' has been opened for writing.
Progress: 0%
Progress: 3%
Progress: 7%
Progress: 10%
Progress: 12%
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 355 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 409 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.
Progress: 16%
Progress: 19%
Progress: 22%
Progress: 24%
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 15 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 605 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 15 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.
Warning: 'C:\temp\TestOut.eac3' track 0: This AC3 track contains 605 bytes of non-AC3 data which were skipped. The audio/video synchronization may have been lost.

I end up with a playable MKV file that is horribly out of sync with the video and once it reaches the point where the non-AC3 data was removed, the receiver starts emitting a strange noise and stops displaying DD+ like corruption occurs at that point. What I am wondering is what is this “non-AC3 data” that is being skipped. Is it something perhaps that the Dolby Digital Plus encoder is adding to the file that it shouldn’t be? Since the program is made by Dolby, you would think the file would be created correctly. What I am wondering is if mkvmerge is possibly seeing E-AC3 data that is not normally present in AC3 files as invalid or as non-ac3 data. I think that I am treading in mostly uncharted waters since DD+/E-AC3 mostly died off with HD-DVD.
--
I am only posting after many days and hours of frustration. The other muxers I have tried don’t recognize E-AC3 at all. I feel that once I get past this error, my problem may be solved.
This is more of an issue with mkvmerge than the MKVToolnix GUI because I get the same results when trying to form my own command line.

Since 7.1 channel is becoming less expensive, and MKV is on the rise as one of the best formats, I imagine that there will be others trying to do this eventually. It’s too bad that Aften(or someone) didn’t have a DD+ version of an encoder that would bring DD+/E-AC3 back into the mainstream for those of us who don't want to have 5-6GB worth of audio in order to have 7.1 channel in a container that is playable with a standard receiver.


If anyone has been down this road before or has any ideas, please let me know.

[Baldrick]

Please do not cross post in several forums. Just bump/reply to your thread instead.

Nope, I have no solution. But check/Search in forum.doom9.org also.

[JimmyK814]

Sorry, I was looking for a way to move my post into the audio subsection instead of posting it again, but there didn't seem to be an option. I thought it would receive more attention there.

[rob2081]

Sorry, for the resurrection of an old post. I came across it while looking for how to tag an EAC3 bitstream in an MKV file.

I don't know if this is exactly the solution, but I would suspect its the demuxer not properly handling dependent EAC3 frames. These are the 'extra' frames for the 7.1 data, the idea being that a 5.1 decoder can safely ignore them. Try muxing a 5.1 stream. If that works, I suggest you contact whoever wrote the muxer and get them to double check that its correctly handling dependent frame types when reading the BSI.

[JimmyK814]

Thanks for the reply. I am no farther along finding a solution to this than before. I spoke to the author of mkvmerge and received this response:

There are at least two strange things happening:

1. At the places where mkvmerge complains about skipping garbage there
are no valid AC3 headers. Normally the 4 channel add-on stream contains
the same AC3 headers as the 5.1 downmix.

2. Normally each 5.1 packet is stored along with its 4-channel add-on
stream packet in the same Matroska block with the same
timecode. However, there are a few places where ffmpeg splits up such a
combination into two separate packets while mkvmerge doesn't. This
results in higher timecodes from that place on in the ffmpeg generated
file. I haven't figured out why ffmpeg does this at all...

Also:

There's simply no way to determine the amount of time that garbage data
should occupy. Therefore there's no way for mkvtoolnix to mux it properly.

It's unfortunate that DD+ isn't more prevalent and that more tools don't exist to work with it properly.