Demuxed TrueHD doesn't decode correctly

[Superb]

Hello, I ran into a sample where a TrueHD from DGDemux doesn't decode correctly, but when it's demuxed with eac3to from the same disc, it works fine. How do I send the sample?

eac3to:

Code: Select all

eac3to v3.51
command line: eac3to.exe DISC_NAME 1) 3:v2-main.thd 3:v2-main.w64
------------------------------------------------------------------------------
Running in fast mode
Keeping dialnorm
M2TS, 1 video track, 2 audio tracks, 3 subtitle tracks, 1:31:42
1: Chapters, 13 chapters
2: h264/AVC, 1080p24/1.001 (16:9)
3: TrueHD/AC3, Chinese, 5.1 channels, 96kHz, dialnorm: -31dB
   (embedded: AC3 EX, 5.1 channels, 640kbps, 48kHz, dialnorm: -31dB)
4: AC3, Chinese, 2.0 channels, 384kbps, 48kHz, dialnorm: -31dB
5: Subtitle (PGS), Chinese
6: Subtitle (PGS), Chinese
7: Subtitle (PGS), English
[a03] Extracting audio track number 3...
[a03] Extracting audio track number 3...
[a03] Extracting TrueHD stream...
[a03] Extracting TrueHD stream...
[a03] Decoding with libav/ffmpeg...
[a03] Writing W64...
[a03] Creating file "v2-main.w64"...
[a03] Creating file "v2-main.thd"...
[a03] The original audio track has a constant bit depth of 18 bits.
Video track 2 contains 131925 frames.
eac3to processing took 3 minutes, 21 seconds.
Done.

eac3to v3.51
command line: eac3to.exe v2-main.thd v3-main.w64
------------------------------------------------------------------------------
Running in fast mode
Keeping dialnorm
TrueHD, 5.1 channels, 96kHz, dialnorm: -31dB
Decoding with libav/ffmpeg...
Writing W64...
Creating file "v3-main.w64"...
The original audio track has a constant bit depth of 18 bits.
eac3to processing took 3 minutes, 11 seconds.
Done.

DGDemux:

Code: Select all

eac3to v3.51
command line: eac3to.exe "14824 PID 1100 96000 6ch zho DELAY 0ms.thd" test.w64
------------------------------------------------------------------------------
Running in fast mode
Keeping dialnorm
TrueHD, 5.1 channels, 96kHz, dialnorm: -31dB
Decoding with libav/ffmpeg...
Writing W64...
Creating file "test.w64"...
The libav decoder reported error -1094995529 while decoding.  <ERROR>
Aborted at file position 2198210784.  <ERROR>

DGDemux log:

Code: Select all

DGDemux 1.0.0.74 by Donald A. Graft
Copyright (C) 2019-2023 Donald A. Graft, All Rights Reserved [Made in Frostbite Falls, Minnesota]
00003.m2ts
Created for demux: 14824 PID 1011.avc
Created for demux: 14824 PID 1100 embedded zho DELAY 0ms.ac3
Created for demux: 14824 PID 1101 2.0ch 48KHz 384Kbps zho DELAY 0ms.ac3
Created for demux: 14824 PID 1100 96000 6ch zho DELAY 0ms.thd
1 %
Created for demux: 14824 PID 1200 zho.sup
Created for demux: 14824 PID 1201 zho.sup
Created for demux: 14824 PID 1202 eng.sup
2 %
3 %
4 %
5 %
6 %
7 %
8 %
9 %
10 %
11 %
12 %
13 %
14 %
15 %
16 %
17 %
18 %
19 %
20 %
21 %
22 %
23 %
24 %
25 %
26 %
27 %
28 %
29 %
30 %
31 %
32 %
33 %
34 %
35 %
36 %
37 %
38 %
39 %
40 %
41 %
42 %
43 %
44 %
45 %
46 %
47 %
48 %
49 %
50 %
51 %
52 %
53 %
54 %
55 %
56 %
57 %
58 %
59 %
60 %
61 %
62 %
63 %
64 %
65 %
66 %
67 %
68 %
69 %
70 %
71 %
72 %
73 %
74 %
75 %
76 %
77 %
78 %
79 %
80 %
81 %
82 %
83 %
84 %
85 %
86 %
87 %
88 %
89 %
90 %
91 %
92 %
93 %
94 %
95 %
96 %
97 %
98 %
99 %
100 %
Created for demux: 14824 PID 1100 96000 6ch zho DELAY 0ms.thd+ac3
Generate thd+ac3
PGS 1200: 1138 total subs, 0 forced subs
PGS 1201: 1138 total subs, 0 forced subs
PGS 1202: 1091 total subs, 0 forced subs
Done!

[Rocky]

Your code block for DGDemux contains the eac3to stuff. Can you correct that? What do you mean by "doesn't decode correctly"? How did you test it? Did you use the thd or the thd+ac3 for testing? How big is the M2TS and would you be willing to upload it to our FTP?

Thank you.

[Superb]

Sorry, the first block is decoding the .thd demuxed by eac3to; second block is decoding the .thd demuxed by DGDemux. By doesn't decode correctly, I mean that eac3to fails, reporting a decoding error. The same thing happens on .thd and .thd+ac3.

m2ts is 21 GB, I can upload it.

[Rocky]

Thank you. PM sent with ftp details. Upload 00003.m2ts.

[Rocky]

OK, I started with DGIndexNV to demux the THD from 00003.m2ts. Then I decoded it with your command without issues.

Code: Select all

D:\tmp\00003\DGIndexNV>D:\Don\Programming\Delphi\EAC3TO\eac3to 00003.thd 00003.w64
Running in fast mode
Removing dialnorm
TrueHD, 5.1 channels, 96kHz, dialnorm: -31dB
Skipping TrueHD dialog normalization (already at -31 dB)...
Decoding with libav/ffmpeg...
Writing W64...
Creating file "00003.w64"...
process: 100%
The original audio track has a constant bit depth of 18 bits.
eac3to processing took 2 minutes, 23 seconds.
Done.

To test with DGDemux I need 00003.clpi and the mpls file. Please upload them. Thank you.

Note that I used 3.52 so you night give that a try too.

[Superb]

To test with DGDemux I need 00003.clpi and the mpls file. Please upload them. Thank you.

Uploaded.

Also, I updated to eac3to 3.52, and it has the same issue on my demuxed files.

[Rocky]

Thank you. Investigating...

[Rocky]

Something looks fishy. That MPLS has 00003.m2ts + 00012.m2ts. But your eac3to decode of the disk shows only 00003.m2ts. Also, the DGDemux log shows only 00003.m2ts.

Please clarify and provide the correct MPLS file. If it really is 00001.mpls as you sent then please upload 00012.m2ts and 00012.clpi.

BTW, if I go ahead and just let DGDemuxGUI error out on the missing 00012.m2ts it still creates the THD file and that is decoded fine as before for DGIndexNV. They use the same algorithm so it's not surprising.

It would be helpful to have your DGDemux command line used for demuxing.

Thank you.

[Superb]

It is the right mpls/m2ts. I skip the last m2ts in DGDemux since it has no TrueHD audio. Sorry, forgot to mention that. Still, uploaded those files.

Command:

Code: Select all

"D:\DGD\DGDemux" -l "D:\DGD\demux14200.txt" -i "C:\NZB\DISC_NAME\BDMV\PLAYLIST\00001.mpls" -sl

[Rocky]

Thank you. How did you skip the last M2TS when demuxing with eac3to?

Your DGDemux line is missing the -o option.

[Rocky]

OK, I duplicated it and found the key factor. If you demux including the video it fails, i.e., the THD file is truncated. If you demux excluding the video, e.g., with -demux 1100,1101,1200,1201,1202,Chapters, then the THD file is correct. Note that both no -demux given, or -demux 1011,... will demux the video.

My guess is that the audio is substantially longer than the video at the end of 00003.m2ts, and the end of video is terminating overall demuxing before all the audio is done. I thought I was handling that correctly but maybe it faiIs with a large amount of excess audio at the end. I will try to fix it tomorrow.

Thank you for your report and debugging assistance.

[Rocky]

Oh crap, I just accidentally deleted 00003.m2ts.

Could you pretty please upload it again? So sorry about that. I'll keep backups this time I promise.

You can also try with -ignorepl.

I tested with several of my THD disks and the result was the same with and without video, so it's something special with your disk.

[Superb]

Thank you. How did you skip the last M2TS when demuxing with eac3to?

Your DGDemux line is missing the -o option.

I didn't skip it with eac3to, I forgot I had it in dgdemux entirely. I don't know why -o is missing, probably because I loaded the disc again and then I copied it from the GUI, but it shouldn't matter.

Reuploaded.

[Rocky]

Thank you.

[Rocky]

OK, it works with -ignorepl. That suggests bad authoring with audio content at the end of 00003.m2ts that is outside of the OUT_time. Or it could be a bug. Or I misinterpreted the spec. Investigating...

[Rocky]

Reading the spec closely...

The IN_time and OUT_time refer only to the video, so if the audio goes past OUT_time it will be lost unless -ignorepl is given. This may not be a problem for subsequent decoding of other audio types, but THD is picky, as you have discovered.

The sequence info must be used to find the actual end of the overall audio-video clip. The relevant variable will be presentation_end_time[last_atc_id][last_stc_id]. The spec:

presentation_end_time[atc_id][stc_id]: this 32-bit field indicates a presentation end time of the AV stream data for the STC-sequence pointed to by the stc_id on the ATC-sequence pointed to by the atc_id.

It will take some time to revise the design (for the case of -ignorepl not given) as described above. In the meantime please give the -ignorepl parameter when encountering this issue. I may try a heuristic first instead, where I simply ignore the OUT_time for audio for the last play item (M2TS). But I'm not sure that's going to be correct at gaps between M2TSs. Is excess audio pushed into the next M2TS? Gonna do some experimenting...

BTW, if you do not demux video it operates as if the -ignorepl option was given. That's why it works when video is not demuxed.

[Rocky]

OK, I think I have a fix. We won't need the sequence info. The problem is, as mentioned before, I was using the video in or outside the window to control the audio as well. But that ignores that the audio can run ahead or behind the video in the stream. That is, the PTSs are not necessarily aligned. In your sample, the audio runs 0.76 seconds behind the video at the end. So I coded it to make them independently check their PTSs against the in/out window. It works fine for your sample.

I also want to change the -ignorepl option back to its reverse -strictpl.

Gonna do some regression testing and then make a release.

[Rocky]

OK, boys and girls, here is a test version with the fix. Please give it some tasting and advise if any issues are encountered. I will release it if no issues are found. Thank you.

https://rationalqm.us/dgdemux/binaries/ ... 5_test.zip

[Rocky]

Released as 1.0.0.75. Marking resolved.

[Superb]

Thank you, will test soon.