auto-generating empty ac3 substream for pure TrueHD?

[Randrianasulu]

As far as I understand ffmpeg still generates just truehd audio stream in ts container.

In this post {0} it was said to be possible to generate silent/fake ac3 substream internally, but I have no idea where this code lives {in private repo somewhere? not checked all 100 forks of tsmuxer...} .

{0} - https://forum.doom9.org/showpost.php?p=1962468&postcount=1191

[jcdr428]

Hi @Randrianasulu , this is still work to be done. Currently, the pure THD streams without AC3 seem to be accepted by most of the standalone Blu-ray players, so no urgency.

[imhh1]

@jcdr428 which standalone bluray player is that ? I know of 3 players that cannot play a pure TrueHD stream ( oppo, Sony x700 and x800m2)

@Randrianasulu I use thdmerge with a 4h 64kbps silent track and it works great.

[jcdr428]

@imhh1 maybe I misunderstood https://forum.doom9.org/showthread.php?p=1962290#post1962290 .

[imhh1]

I don't know but I have an X800m2 and an x700 and they both fail to play pure TrueHD sound (at least for the DV files).

[Randrianasulu]

@jcdr428 I compiled Donald Graft's thdmerge on termux. Asked author via email about licence - he said (for this work) 'public domain'. So I put it (Linux version) on github.

I think original archive also contain exe file for Windows users.. https://github.com/Randrianasulu/thdmerge/

Not sure how tsMuxer currently handles situation where I put ac3 and thd on same pid - will it autointerleave them? (not exactly requested behavior, but might simplify workflow a bit, also you it seems to me with such cide in place you can just 'invent' empty/silent ac3 stream out of /dev/zero easily.. )

[Randrianasulu]

also, is this patch correct? (I tried to add line about TrueHD to help text)

diff --git a/tsMuxer/main.cpp b/tsMuxer/main.cpp
index a264795..6904d04 100644
--- a/tsMuxer/main.cpp
+++ b/tsMuxer/main.cpp
@@ -388,6 +388,7 @@ Names of codecs in the meta file:
 - A_AC3             AC3/AC3+/TRUE-HD
 - A_AAC             AAC
 - A_DTS             DTS/DTS-Express/DTS-HD
+- A_MLP             TrueHD
 - A_MP3             MPEG audio layer 1/2/3
 - A_LPCM            raw pcm data or PCM WAV file
 - S_HDMV/PGS        Presentation graphic stream (BD subtitle format)

[ghost]

Is generating the "real" ac3 fallback stream using eac3to blah.thd blah.thd+ac3 (or eac3to blah.thd+blah.ac3 mixed.thd if you already have both) really such a nightmare that everyone is clamoring for a file that will have playback issues if the .ac3 fallback is actually required? :P

[Randrianasulu]

@GabeBlincoln I do not think eac3to actually open-source like current tsMuxer? I probably can run it on x86 linux via wine, but I dislike fundamentally windows-tied and/or closed-source software ...

[ghost]

Ok, so ffmpeg to encode the ac3 stream from THD and thdmerge for merging. The real point wasn't an OS argument, it was more a question of why everyone seems to want a blank stream. I've seen multiple requests for this in various places on the web and it's always a blank ac3 just to make it "pass" players that enforce compliance. It's not really any harder to make it really be compliant (aka it'll actually play the audio if the THD can't be decoded) so if we're requesting a feature that probably doesn't belong in a muxer anyway why not make it correct?

[jcdr428]

@GabeBlincoln agreed. Although there are already few functions in tsMuxer that don't belong to a muxer -such as add missing Access Unit Delimiters removed by MKVToolNix, continuously add sps/pps... Adding blank ac3 frames is simple, whereas transcoding to ac3 needs a third party coder such as ffmpeg. Anyway, yes this is a pis-aller and some people might be upset to find some fake bluray muxes with blank ac3.

[Randrianasulu]

@GabeBlincoln back when I opened this issue I was not aware about thdmerge.

@jcdr428 feel free to close this, just add remark about existence of thdmerge in documentation, please ....

[jcdr428]

@ValZapod I think (I'm not sure) that the ac3 must have as many channels as the thd.

[imhh1]

Maybe it would be better to just remove coreless THD support in tsmuxer. To me, the current implementation is a lot worse than having an empty core since the audio doesn't work in bluray players at all.

[dts24436]

@ValZapod I think (I'm not sure) that the ac3 must have as many channels as the thd.

@jcdr428 There's no such requirement to output any TrueHD stream with embedded AC3 core, as they're supposed to be downmixed if the TrueHD lossless stream has a channel layout beyond 5.1ch. This applies to any E-AC-3 stream with embedded AC3 core as well, which is also in the current need with a tool like thdmerge mentioned above (thdmerge only does TrueHD but not E-AC-3 I tried of course).

@jcdr428 I compiled Donald Graft's thdmerge on termux. Asked author via email about licence - he said (for this work) 'public domain'. So I put it (Linux version) on github.

I think original archive also contain exe file for Windows users.. https://github.com/Randrianasulu/thdmerge/

Not sure how tsMuxer currently handles situation where I put ac3 and thd on same pid - will it autointerleave them? (not exactly requested behavior, but might simplify workflow a bit, also you it seems to me with such cide in place you can just 'invent' empty/silent ac3 stream out of /dev/zero easily.. )

@Randrianasulu Also wondering if there's such tool to embedded any AC3 core into E-AC-3 coreless stream.

Maybe it would be better to just remove coreless THD support in tsmuxer. To me, the current implementation is a lot worse than having an empty core since the audio doesn't work in bluray players at all.

@imhh1 And it would be better to just make an AC3 core to get merged into coreless THD and EC3 (E-AC-3) and finally get both the THD+AC3 and EC3+AC3 recognized and properly muxed in tsmuxer.

Ok, so ffmpeg to encode the ac3 stream from THD and thdmerge for merging. The real point wasn't an OS argument, it was more a question of why everyone seems to want a blank stream. I've seen multiple requests for this in various places on the web and it's always a blank ac3 just to make it "pass" players that enforce compliance. It's not really any harder to make it really be compliant (aka it'll actually play the audio if the THD can't be decoded) so if we're requesting a feature that probably doesn't belong in a muxer anyway why not make it correct?

I'm also stucked for a long time in ffmpeg, as it always recognize the THD+AC3 single stream as two independent stream and splits it when you want different wrappers for it to work.

[dts24436]

applies to any E-AC-3 stream with embedded AC3 core as well,

It is the opposite, any AC3 stream with dependent E-AC-3 stream.

But yeah, AC3 does not support 7.1 or more. So sure.

thdmerge does not support EAC3+ AC3, because it is much more complex.

So it's hard to deal with EAC3 to get played in any blu-ray player, right? Sony's X700 and X800M2 especially for the issues mentioned above.

I'd like some certain tool for EAC3 use as I personally think the EAC3 has got to be also embedded with an AC3 core as the TrueHD does. I imported some into tsmuxer and it shows me 0kbps AC3 core. And the EAC3 does bitstream passthrough within HDMI instead of SPDIF as TrueHD does. And the EAC3 also does Dolby Atmos so altogether I come for this.

[dts24436]

I personally think the EAC3 has got to be also embedded with an AC3 core as the TrueHD does

Moreover those are different bytes. TrueHD's AC3 is not the same place as AC3 of EAC3+AC3.

Atmos EAC3 on Blu-ray is also EAC3+AC3.

@ValZapod Seems that within the EAC3 stream, the embedded AC3 stream is frame-to-frame interleaved, for they share the same audio sample amount per data frame. If there's a way to get this solved, will it be much easier to get AC3 embedded into EAC3?

[dts24436]

it be much easier to get AC3 embedded into EAC3?

It is EAC3 that is embedded into AC3, EAC3 cannot be decoded without AC3.

Confused... Now that the EAC3 stream can only be packed into HDMI-bitstream format (usually 6144kbps 8-channel PCM as I've tested) instead of AC3 to be packed just into SPDIF-bitstream (as 1536kbps 2-channel PCM), why is it that the AC3 packs the EAC3 into itself? (as AC3 cannot have such an enormous data amount of extra data to be transferred the way SPDIF does.)

If the EAC3 cannot be decoded without AC3 (for regular blu-ray players), things come back at the start that there's the need of a tool to embed an AC3 core interleaved along into EAC3.

[dts24436]

that the EAC3 stream can only be packed into HDMI-bitstream format (usually 6144kbps 8-channel PCM as

No. EAC3 is always packed as 192 kHz 2 channels. It has its own mode in HDMI edid.

I just checked myself through HDMI passthrough to the AVR, 6144kbps does stand for 192kHz 2ch, instead of 48kHz 8ch I've mistaken. So is to say, the HDMI passthrough is always of 192kHz 16bit samples.

And so things turn back at the point how the interleaving of both EC3 and AC3 within EC3+AC3 works, or how the blank insertion works within both.

[DreckSoft]

At least my Panasonic can't handle pure TrueHD. Just outputs silent audio even though it would play the TrueHD part if the AC3 core is present.

I wouldn't even need adding a silent AC3 but interleaving an existing AC3 to TrueHD during muxing would be enough.

In MKV the tracks are always separated and demuxing, using thdmerge and manually adding the resulting track to tsmuxer is a bit annoying. An option for TrueHD "Interleave with the following AC3 track" would be great. The next track in order then has to be a valid AC3 file. I would also do a language check, just to avoid some mistakes by the user.