HD audio extraction (DTS-MA, TrueHD, ...)

[jeroenh]

Hi Mike,

if I'm correct, there was an issue with writing HD audio (DTS-MA, TrueHD, ...) into an MKV in version 1.4.10. This should have been corrected in version 1.4.11, right?

When I backup a blu-ray with DTS-MA or TrueHD in version 1.4.11 and I use TSmuxer to convert it to m2ts (PCH claims a A-110 cannot play TrueHD from inside MKV), it gives an error while loading the file into TSmuxer (complains about a track, I guess it's the HD audio track).

could it be there is still an issue with the HD audio extraction in 1.4.11?

Jeroen

[smoke420]

Hi Mike,

if I'm correct, there was an issue with writing HD audio (DTS-MA, TrueHD, ...) into an MKV in version 1.4.10. This should have been corrected in version 1.4.11, right?

When I backup a blu-ray with DTS-MA or TrueHD in version 1.4.11 and I use TSmuxer to convert it to m2ts (PCH claims a A-110 cannot play TrueHD from inside MKV), it gives an error while loading the file into TSmuxer (complains about a track, I guess it's the HD audio track).

could it be there is still an issue with the HD audio extraction in 1.4.11?

Jeroen

@Jeroen i have no issue with 1.4.11 yet at all in this regard, thanks

[ragboy]

I have seen many TrueHD tracks in MKVs with 1.4.11 that are not readable by eac3to in the mkv. I have to extract them out first with mkvextract to then convert them, and sometimes they are not convertible, eac3to reports many errors, like this:

[mlp @ 009F32E0]Lossless check failed - expected 0, calculated f9
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 1
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated fb
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 6
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 1
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 4
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated 1
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated f9
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated f8
[mlp @ 009F32E0]Lossless check failed - expected 0, calculated f9

If I take the same BR and use ANYDVD and then eac3to, no issue. I this mostly with TrueHD tracks, and PCM tracks, dtshd seem ok. A recent example of this I noticed was with Madagascar 2.

[mike admin]

You are describing a known problem in eac3to. Please try the following receipe from author of eac3to and keep an eye for a new version.

At the time when I wrote eac3to's MKV reader, there was no way to mux TrueHD streams to MKV yet. That's why eac3to doesn't know how to handle such a track. However, you can make eac3to handle it correctly by using the "proper" output extension. Basically eac3to can demux any raw MKV streams of unknown formats. You have to use the track's format identifier as the file extension, though.You can properly demux the TrueHD track by using this command line:

eac3to thdtest.mka 1: test.TRUEHD

The resulting TrueHD file is correct. Of course it's not nice that you have to use the format identifier instead of the more common "thd" file extension. Also the warnings are annoying. And you have to use "1:", without it demuxing doesn't work, either.

I'll add "proper" support for MKV TrueHD tracks to the next eac3to build.

[ragboy]

You are describing a known problem in eac3to. Please try the following receipe from author of eac3to and keep an eye for a new version.

At the time when I wrote eac3to's MKV reader, there was no way to mux TrueHD streams to MKV yet. That's why eac3to doesn't know how to handle such a track. However, you can make eac3to handle it correctly by using the "proper" output extension. Basically eac3to can demux any raw MKV streams of unknown formats. You have to use the track's format identifier as the file extension, though.You can properly demux the TrueHD track by using this command line:

eac3to thdtest.mka 1: test.TRUEHD

The resulting TrueHD file is correct. Of course it's not nice that you have to use the format identifier instead of the more common "thd" file extension. Also the warnings are annoying. And you have to use "1:", without it demuxing doesn't work, either.

I'll add "proper" support for MKV TrueHD tracks to the next eac3to build.

I will give that a shot.

[ragboy]

This is working, but I still have to check channel mappings, seems to work so far.

wine32 eac3to title00.mkv 3:stdout.TRUEHD | ffmpeg -f mlp -i - -acodec pcm_s24le -v 0 -f wav - | neroAacEnc -q .9 -lc -ignorelength -if - -of hdaudio.m4a

[nikeshoe]

thanks

[AjzRide]

Using the above information, I have successfully been able to extract the TrueHD audio out, and remux into a .m2ts file. The sound is crystal clear, but I am having audio sync issues (Using both VLC and playing on a PS3). I have tried the following two methods:

A) eac3to title00.mkv 1:title00.h264 2: title00.truehd
rename title00.truehd title00.thd (i have also tried thd+ac3 with no noticeable difference)

B) mkvextract tracks title00.mkv 1:title00.h264 2:title00.thd

Mux together with TSmuxer (I've tried 1.8 and 1.10.6, windows and mac)

A little further tinkering showed that extracting the DD 3/2+1 audio instead of the trueHD audio gives me the exact same problem.
One more thing of note, when watching on the PS3, if you call up the informaiton so you can see bit rates, the timer at the bottom jumps around. I.e. 1,2,3,4,3,4,5,6,7,8,7,8,9........

Any suggestions

Edit: If I drop the .mkv with just the .h264 and .ac3 streams directly into TSMUXER, I do not have these problems, it appears to be related to the demux/remux process. Obviously I cannot drop a .mkv containing a TrueHD track directly into TSMUXER

Thx

[ragboy]

I have found that even using the method used, with eac3to TRUEHD to get perfect demux, there are still errors at the begin and end of the track. Interesting, most BRs I have found are off by approx 1500ms. So here is an example of how you can fix it:

eac3to title00.mkv 2:hdaudio.TRUEHD <-- you must use this to correctly extract.

Then you need to use eac3to again to add a 1500ms delay. So lets say convert to flac, or aac.

eac3to hdaudio.TRUEHD hdaudio.flac +1500ms

-OR-

eac3to hdaudio.TRUEHD hdaudio.m4a -quality=0.9 +1500ms

That should work. If it doesn't, then you have to experiment with the 1500ms to get the amount of the delay right, which is a pain in the a$$. But I have found, most of these problem mkvs with truehd require just the 1500ms delay.

[AjzRide]

Then you need to use eac3to again to add a 1500ms delay. So lets say convert to flac, or aac.

Not too sure where you dug up 1500ms from, but the number is spot on, and it solved my problems.

Thanks alot.

[ragboy]

Trial and error, and most titles had the same exact fix. I have found a couple that didn't.