THD+AC3 merge when delay is present

[Peter]

I think that I might have found an issue with the creation of the THD+AC3 file. This is with 3.46, but I did not see anything mentioned about this since then (by skimming the posts after 3.46 was released).

On the Silent Night UHD (Lionsgate Films, USA) disc, I receive an error of "Cannot open TrueHD file", during the last step of the demux to merge the THD and AC3 files (log below). I'm guessing that the issue is that the THD track/file has a delay specified (and the AC3 track/file does not), so the code is maybe not looking for the correct file name(s) and therefore cannot find? I actually did not need the merged track, so it did not prevent me from doing what I needed, but I figured it was worth reporting.

I'm also curious if there is supposed to be a delay for the embedded track. The other AC3 tracks have a delay. Is the delay implied for the embedded track, since it's shown for the THD track. I'm not sure I've seen this before, so I don't know if the delay would be shown (in parentheses) for the embedded AC3 track or not if a delay exists. The log does show, "a04 A remaining delay of +9ms could not be fixed.", so maybe a delay is there for the AC3 track and was addressed. I suppose that would also mean that in the merged track (if it had been merged), the AC3 track would not be in sync by 9ms (not sure if the merge accounts for any remaining delay)?

Files generated by eac3to:
00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz DELAY 1001ms.thd
00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz.ac3

Code: Select all

Log (copied from console, not log file):
C:\TEMP>eac3to Z:\SILENT_NIGHT_UHD\BDMV\PLAYLIST\00001.mpls -demux
Running in normal mode
Keeping dialnorm
analyze: 100%
M2TS, 2 video tracks, 3 audio tracks, 2 subtitle tracks, 1:44:03, 24p/1.001
1: Chapters, 13 chapters
2: h265/HEVC, 2160p24/1.001 (16:9), 10 bits
3: *h265/HEVC, 1080p24/1.001 (16:9), 10 bits
4: TrueHD/AC3 (Atmos), English, 7.1 channels, 48kHz, dialnorm: -20dB, 1001ms
   (embedded: AC3, 5.1 channels, 384kbps, 48kHz, dialnorm: -20dB)
5: AC3, English, 2.0 channels, 192kbps, 48kHz, dialnorm: -31dB, 1001ms
6: AC3, Spanish, 5.1 channels, 448kbps, 48kHz, dialnorm: -31dB, 1001ms
7: Subtitle (PGS), English
8: Subtitle (PGS), Spanish
Creating file "00000 - Chapters.txt"...
a04 Extracting audio track number 4...
s07 Extracting subtitle track number 7...
s08 Extracting subtitle track number 8...
a04 Extracting audio track number 4...
v02 Extracting video track number 2...
v03 Extracting video track number 3...
a05 Extracting audio track number 5...
a06 Extracting audio track number 6...
a04 Extracting TrueHD stream...
a04 Extracting AC3 stream...
a04 Applying (E-)AC3 delay...
a05 Applying (E-)AC3 delay...
a06 Applying (E-)AC3 delay...
a06 A remaining delay of +9ms could not be fixed.
a05 A remaining delay of +9ms could not be fixed.
a04 A remaining delay of +9ms could not be fixed.
v02 Creating file "00000 - 2 - h265, 2160p24.h265"...
v03 Creating file "00000 - 3 - h265, 1080p24.h265"...
a04 Creating file "00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz.thd"...
a06 Creating file "00000 - 6 - AC3, Spanish, 5.1 channels, 448kbps, 48kHz.ac3"...
a04 Creating file "00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz.ac3"...
a05 Creating file "00000 - 5 - AC3, English, 2.0 channels, 192kbps, 48kHz.ac3"...
s07 Creating file "00000 - 7 - Subtitle (PGS), English.sup"...
s08 Creating file "00000 - 8 - Subtitle (PGS), Spanish.sup"...
process: 100%
Video track 2 contains 149674 frames.
Video track 3 contains 149674 frames.
Subtitle track 7 contains 795 captions.
Subtitle track 8 contains 185 captions.
eac3to processing took 22 minutes, 58 seconds.
Merging THD and AC3 for "00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz".
Cannot open TrueHD file
Done.

[Curly]

Hmm, that's a great point. Thank you for the thorough report, Peter. Just in time for the 3.49 release.

But who coded that? Was that you, Sherman? Nah, I take full responsibility. I would make excuses but you wouldn't believe them anyway. In my defense, it works for 2: out.thd 3:out.ac3, just not for -demux.

Yes, the THD delay is implied for the embedded AC3. The remaining gap for the AC3 is because AC3 has a larger frame size than THD and so cannot be corrected as closely. Delay refers to the start of the audio while gap refers to gaps between source files.

I'm gonna get it fixed for you, Peter. Balti would say something profound about it but profoundness is not a strength of mine. Strong of mind and character.

[Curly]

OK, all I gotta do is check only the first part of the file name: 00000 - 4. So should be a Sunday picnic. In case yer wondering, Britney suggested that. And here I thought she was just a dumb blonde. I shudda known there was a reason why DG keeps her around. Not what yer thinking!

[Peter]

Thanks, Curly.

Interesting. Yes, I do understand about the delays/gaps and what the "remaining delay" means. Since eac3to does reduce the delay of the AC3 track (from 1001ms to 9ms) and does not for the THD track, wouldn't you basically need the original (non-delay reduced) AC3 track to merge with the THD for the THD+AC3 track (so they'd both have a delay of 1001ms, as they do on the disc)? If not, maybe I'm missing something.

Also, I just noticed that the "Cannot open TrueHD file" error only displayed on the console, but did not get added to the log file. Log file has these lines only (so it looks like the merge was successful):

Merging THD and AC3 for "00000 - 4 - TrueHD+AC3 (Atmos), English, 7.1 channels, 48kHz".
Done.

[Curly]

The small difference in delays is inconsequential. I'll look into logging an error.

[Peter]

Yes, I agree that the 9ms is inconsequential, which I think is what you were stating. I guess what I was concerned about was the following:
eac3to does not correct the THD delay. So, when muxing, a +1001ms delay needs to be specified for the THD track that eac3to created (just like on the original disc, since it wasn't corrected). The AC3 track's delay, however, is corrected by eac3to (to within 9ms). So, if muxing with that track, a +9ms delay needs to be specified (or ignored) for this track (992ms of the +1001ms delay has been removed; 992ms of silence has been added to the beginning of the AC-3 track). If these 2 are merged, as-is, the 2 tracks will be 992ms (not 9ms) out of sync. Right?

[Curly]

eac3to does not correct the THD delay.

I believe that is wrong.

So, when muxing, a +1001ms delay needs to be specified for the THD track that eac3to created (just like on the original disc, since it wasn't corrected).

Umm, no.

[Peter]

eac3to does not correct the THD delay.

Wrong.

Really? OK, then I'm confused. If that's the case, why is " DELAY 1001ms" added to the file name? Isn't that placed there to inform the muxer to add a +1001ms delay when muxing (because it was not corrected)? That's what it does in MKVToolNix (which is what I'm using). If that delay is not specified when muxing, it's not in sync. If the THD delay was corrected, specifying the +1001ms delay would not be needed when muxing.

[Curly]

OK, sorry, I got delay vs gaps confused again. Don't forget I'm a stooge.

Yes, streams are not delay corrected but are gaps corrected. Best would be if I wrote the same delay in the AC3 name but until that happens, you can do it manually as below.

If you have to load them separately in mkvtoolnix, which I believe is the case, you'd configure the same delay for the AC3 in mkvtoolnix.

If your app takes thd+ac3 there would not be an issue.

Are we good now?

[Curly]

Re-download 3.49_test and see if it pairs things up better.

I just dropped a thd+ac3 with DELAY on mkvtoolnix and it split them and gave them the same delay. So we're good, right?

[Curly]

Darn, it's not working good with -destpath. I'll fix that tomorrow.

I may just remove the automaticity and have the user do it by hand if needed. Let's see.

[Peter]

OK, sorry, I got delay vs gaps confused again. Yes, streams are not delay corrected but are gaps corrected. Best would be if I wrote the same delay in the AC3 name but until that happens, you can do it manually as below.

If you have to load them separately in mkvtoolnix, which I believe is the case, you'd configure the same delay for the AC3 in mkvtoolnix.

If your app takes thd+ac3 there would not be an issue.

Are we good now?

OK, yes, I am referring to delays, not gaps. There is no seamless-branching here, so no gaps in play at all. I'm glad we're talking about the same thing now. However, there are still some incorrect statements, I believe, in your
first 2 paragraphs. You could not write the same delay (+1001ms) in the AC3 file name, and the same delay (+1001ms) would not need to be specified for the AC3 track when muxing. Again, eac3to corrected the AC3 track (to within 9ms). So, the THD track and AC3 track created by eac3to are 992ms out-of-sync. So, if muxing with MKVToolNix, a +1001ms delay would need to be specified for the THD track, and +9ms delay would need to be specified for the AC-3 track (that's always been what's required for the "remaining delay" after eac3to demux). That was my original point, as to why you cannot merge those together (the THD and AC3 generated by the demux, since 1 was corrected and 1 was not).

Yes, I'm good. I actually don't need the THD+AC3 files at all, as I am muxing primarily to MKV (and I don't keep the AC3/compatibility track at all). However, for someone muxing to M2TS (which I think really are the only ones who would need the merged THD+AC3 file anyway), I think that the THD & AC3 files do need to be in sync, prior to merging, since only 1 delay can be specified for the merged track when muxing (and it's then implied for the other track). So, I think my original point stands (that the pre-corrected AC3 track would need to be merged with the THD track, and you don't have that "pre-corrected track" at the time of the merge). But, if that were done (with pre-corrected AC3), the original delay (+1001ms) would then need to be specified for the THD+AC3 when muxing. So, maybe it's good that this merge currently fails, since it would otherwise create an out-of-sync track?

Proof below, for anyone who's interested, that eac3to does not correct THD delays. eac3to only writes the delay to the file name for THD (the original and "delay-applied" files are identical, binary-equivalents).

Code: Select all

C:\TEMP>eac3to test.thd test-1.thd +50ms
Running in normal mode
Keeping dialnorm
TrueHD (Atmos), 7.1 channels, 48kHz, dialnorm: -20dB
Creating file "test-1.thd"...
process: 100%
eac3to processing took 34 seconds.
Done.

C:\TEMP>fc /b test.thd "test-1 DELAY 50ms.thd"
Comparing files test.thd and TEST-1 DELAY 50MS.THD
FC: no differences encountered


C:\TEMP>

[Curly]

You could not write the same delay (+1001ms) in the AC3 file name, and the same delay (+1001ms) would not need to be specified for the AC3 track when muxing. Again, eac3to corrected the AC3 track (to within 9ms). So, the THD track and AC3 track created by eac3to are 992ms out-of-sync.

So you are saying that eac3to delay-corrects AC3 but not THD. I'll test it, but if true I'm just gonna rip out the automatic thdmerge and let users do what they want. It's a pretty bad deficiency of eac3to if it corrects one but not the other.

[Curly]

Rocky says rip it out, so I'm gonna do that, and probably remove thdmerge from the distribution. It's sad, because it means generating bluray-compatible muxes with eac3to is more difficult.

He says it's fine in DGDemux because while we gaps-correct both, neither one is delay-corrected. It would still be nice to put the same delay in there for AC3.

You could still put separate delays in mkvtoolnix but I don't want to generate a misaligned thd+ac3.

Thank for your patience and for bringing this up.

[Peter]

So you are saying that eac3to delay-corrects AC3 but not THD? I'll test it, but if true I'm just gonna rip out the automatic thdmerge and let users do what they want. It's a pretty bad deficiency of eac3to if it corrects one but not the other.

Yes, I am indeed saying that. That's why the output states:
a04 Applying (E-)AC3 delay...
a04 A remaining delay of +9ms could not be fixed.

eac3to can correct AC3 (and DTS) delays, but not THD. So, for AC3, which I believe has a frame size of 31ms, eac3to can correct to the nearest frame, and the remaining delay will be (+) or (-), depending on the smallest absolute value of the number, so a smaller (-) delay is chosen over a larger (+) delay, which is actually kind of annoying, since some muxers/formats do not like (-) delays. In this case, 992/31 = 32 frames exactly, so there are 9ms left from the 1001ms. When muxing with this corrected AC3 track, a "+9ms" delay needs to be specified.

[Curly]

Yeah, I get it. I just didn't know that eac3to corrected one but not the other.

BTW, it's 32ms not 31ms.

[Peter]

Yeah, I get it. I just didn't know that eac3to corrected one but not the other.

BTW, it's 32ms not 31ms.

Thanks. Not sure where I got 31 from (though the math happened to work for both here).

[Curly]

Marking resolved as this will be addressed by removing automatic invocation of thdmerge.

EDIT: Revised 3.49_test is now available.