[RESOLVED] Issue with EAC3 demuxing

[Guest 2]

I have demuxed Solo - A Star Wars story, I think some sort of european version.

It has 3 different mpls as there are english, italian and spanish rolling screen at the beginning of the movie (usual Star Wars style) and each mpls contains multiple chained m2ts.

In my case (italian), I select 801.mpls = 00814.m2ts+00811.m2ts+00815.m2ts+00813.m2ts

The issue appears with the extracted EAC3.

When playing it, it's of the correct length but when converting with ffmpeg, it creates a shorter AC3 and out of sync.

You will tell: blame ffmpeg!

The strange fact is that if I create a mkv with MakeMKV, extract EAC3 from the resulting MKV and convert to AC3 with ffmpeg, voilà, it's correct size and in sync.

The EAC3 from MakeMKV is different in size from the one demuxed with DGIndexNV.

Ideas?

[Rocky]

Investigating...

[Rocky]

Can you please upload the EAC3 from MakeMKV and also give your ffmpeg command line? Thank you.

Does this happen with EAC3TO demuxing? I am comparing bit for bit identical except that EAC3TO deletes one extra frame for gaps processing.

[Rocky]

OK, I ripped it to MKV using MakeMKV. Then I demuxed the EAC3 using DGIndexNV. The files are bit-for-bit identical except that I deleted one more frame for gaps processing.

You are going to need to give me more on this, i.e., the ffmpeg command line, the two EAC3 files, and tell the errors you claim to get from the DGIndexNV one. Putting on back burner until I get those things.

EDIT: I did notice that the DG tools are detecting the stream as 7.1 but putting 5.1 in the file name. I will fix that.

[Guest 2]

You are going to need to give me more on this

Of course, everything it will be necessary.

First of all you can use MakeMKV in 2 ways: stripping or retaining core audio from DTSHD, EAC3 and so on.

I usually strip it because I will anyway work with the highest bitrate stream to encode the AC3.

Moreover, nothing will change on the output EAC3 from the MKV as MakeMKV automatically splits the main audio stream in master and core, creating 2 different audio tracks, in our case a italian Dolby Digital Plus track and a Dolby Digital one.

From now, every software is x64 flavor.

To extract streams from MKV, I don't use EAC3TO as it is not the "official" tool and it has not been updated since years. I use gMKVExtractGUI 2.5.2.0 with MKVToolnix updated to last continuous build (48.0.0-016-g4d51d03ab), obtaining:

[ita] MakeMKV.eac3 with a size of 905'716'224 bytes and a lenght of 2:14:46.75 according to FFProbe

[ita] DGIndexNV.eac3 with a size of 905'714'176 bytes and a lenght of 2:14:46.73 according to FFProbe

To encode EAC3 to AC3 I use latest FFMPEG from Zeranoe nightly (ffmpeg-20200628-4cfcfb3-win64-static).

The generic command line is

ffmpeg.exe -i [ita].eac3 -acodec ac3 -ab 640k -af dynaudnorm=f=2000:g=23:m=15 [ita].ac3

The results are:

[ita] MakeMKV.ac3 with a size of 646'940'160 bytes and a lenght of 2:14:46.75 according to FFProbe

[ita] DGIndexNV.ac3 with a size of 643'253'760 bytes and a lenght of 2:14:00.67 according to FFProbe (confirmed by MPV.NET and VLC) but of 2:12:01 when playing with MPC-BE (with or without LAV Filters).

The audio files are up.

P.S: What about adding a font editing capability to forum? Courier is almost necessary sometimes.

[Rocky]

Thank you for all that.

So ffmpeg does not like me to delete frames for gaps processing. I know that because if I demux with gaps processing disabled, everything is fine as with your MakeMKV stuff. I wonder if MakeMKV even does gaps processing for EAC3. Anyway, I'm off to study the spec now to see why ffmpeg is getting upset. Maybe a similar issue like we had with THD, where you have to be careful about what and when you delete frames?

I'll need to look for a phpbb extension to allow font changes. Not high on my list for a while. There is the code tag for monospacing stuff. Not ideal obviously because of the clutter.

Code: Select all

this is monospaced

[Guest 2]

Thank you for all that.

You are always the most welcome.

I wonder if MakeMKV even does gaps processing for EAC3.

Looking at the logs it seems to process frames in some way.

Anyway, I'm off to study the spec now

I was reading that EAC3 is capable of ATMOS positioning and you need to be careful not to strip it too.

What a PITA.

Not ideal obviously because of the clutter.

Yeah, the same thing I thought at the first editing of my report. I used CODE tags and looked awful.

[Rocky]

I was reading that EAC3 is capable of ATMOS positioning and you need to be careful not to strip it too.

Do you have a link for that? Thank you.

[Guest 2]

Oh man, I need a drink.

No beer smilies found, sorry.

Do you have a link for that? Thank you.

https://professional.dolby.com/product/ ... der-client shows it exists.

ATMOS is plain dynamic metadata that can be added to any 7.1 channel audio, so you can "attach" it to THD or EAC3.

EDIT: someone says "Atmos is not just metadata. It's a layered bitstream that has a 5.1 or 7.1 E-AC3 channel based bed, and the object audio data (and associated metadata) on top of that."

I did some Google research and I've found that it's more common in streaming or broadcast than in BDs (for now).

Here https://thedigitaltheater.com/dolby-trailers/ you can find some examples of Dolby Digital Plus (EAC3) with ATMOS.

It's spelled "Rejoice".

Thanks pal.

[Rocky]

I really appreciate the great feedback but I'd really prefer to stay focused on one issue at a time. We are working on EAC3 demuxing right now. If you overload me I will fly into a wall and die. Please wait for each issue to be resolved before posting about subsequent issues. Thank you for your cooperation in this regard.

OK, pretty sure I know what is going on with the EAC3. When the stream is 7.1 then there is an independent and a dependent stream. The independent gives the 5.1 AC3 content and the dependent extends it to 7.1. Now, when I remove a frame for gaps processing I am only removing the independent frame and not its following dependent frame. I need to remove both. Off to experiment with that...

[Rocky]

Hoo-yah! That was it. I made a quick change and the demuxed eac3 matches EAC3TO, shows the right duration, and gives a correct AC3 from ffmpeg. Let me check everything and then I'll give you a test build. Then we can move on to the other issues.

[Rocky]

Please test the following build of DGIndexNV. Only the EAC3 demuxing has been addressed. The file name was corrected to show 7.1 also.

http://rationalqm.us/misc/DGIndexNV_eac3.exe

[Guest 2]

Only the EAC3 demuxing has been addressed.

Yep, great job Rocky!

I can confirm both from listening and muxing that the generated AC3 are now ok, both for Solo – A Star Wars story and Onward.

I would have bet that they would have been the same size of TSMuxer AC3 and instead they are of the same size of MakeMKV AC3.

Now let's battle against damned SUPs!

[Rocky]

Yep, great job Rocky!

Great to hear. Thanks for your testing.

Now let's battle against damned SUPs!

I'd like to get all the audios running properly first. Lemme check out the DTS audio, for which you had mentioned possible anomalies. Maybe nothing but lemme check that first. Then we will kick some subtitle ass.

[Guest 2]

Lemme check out the DTS audio

Any help you need, just ask.

[Rocky]

I have not found any problems with the DTS tracks. Differences can be due to removing different frames for gaps processing, removal of dialog normalization, etc. The transcoded AC3s are the correct length and play fine.

Moving on to subs unless you want to claim something is wrong with DTS.

[Guest 2]

Moving on to subs unless you want to claim something is wrong with DTS.

With TSMuxer misarably failing (in this case), the other 3 ways I know to demux to AC3 give me overlapping results.

Go on and kick some .ASS!

Onward DGIndexNV HDMA.dts 3.607.706.420 ⇨ .ac3 491.312.640 1:42:21.41
Onward eac3to HDMA.dts 3.607.698.020 ⇨ .ac3 491.312.640 1:42:21.41
Onward MakeMKV HDMA.dts 3.607.702.696 ⇨ .ac3 491.312.640 1:42:21.41
Onward TSMuxer HDMA.dts 3.607.714.696 ⇨ .ac3 487.585.280 1:41:34.82

Onward DGIndexNV HDHR.dts 1.570.662.368 ⇨ .ac3 491.312.640 1:42:21.41
Onward eac3to HDHR.dts 1.570.659.640 ⇨ .ac3 491.312.640 1:42:21.41
Onward MakeMKV HDHR.dts 1.570.662.368 ⇨ .ac3 491.312.640 1:42:21.41
Onward TSMuxer HDHR.dts 1.570.667.824 ⇨ .ac3 491.315.200 1:42:21.44

[Rocky]

The EAC3 fix was released as slipstream 31 for DGDemux. Corresponding changes for DGIndexNV are pending. Subtitles stuff was moved to a new thread.

[Rocky]

Fixed in slipstream 212. Marking RESOLVED.

[Guest 2]

Fixed in slipstream 212. Marking RESOLVED.

Great job.

[Rocky]

Couldn't do it without y'all!