DTS-HD missing headers

[Ramscoop]

I'm encoding my BD audio tracks to 2559Kbps DTS-HD (I use DTS HD Encoder Suite). I've continually ran into the same problem:

When I mux the tracks together (using MKVMerge GUI 3.2.0, I always receive the error/warning:

Warning: 'C:\_TMP\_RipBot264_Jobs\Wall-E[1080p].dtshd' track 0: Skipping 140 bytes (no valid DTS header found). This might cause audio/video desynchronisation.

The audio and video are always synched just fine but, it's still irritating to see that error/warning everytime I mux. I've never had this problem with the DTS audio encoded by Surcode.

BTW, this error is consistent with any profile of DTS encoded by the HD suite (Master Audio, Hi-Resolution, ES, 92/24, etc .. all produce the "missing header" alert in MKVMerge)

[rik1138]

The Master Audio Suite adds additional header information to the files that is normally stripped off in authoring (i.e., by Scenarist or whatever). If you take a Blu-ray and demux the DTSHD-MA, and compare it to the original file created by the DTS software, they won't match (they do match if you offset the demuxed file a little). 140 bytes sounds about right, been a while since I looked into this... So, if you are using files directly from the encoder, this is normal. MKVMerge could probably be programmed to recognize what this extra info is and just remove it without the warning.

I had the same problem a year ago or so when eac3to would fail to recognize any DTS stream encoded directly from the Audio Suite (that info is buried in the eac3to thread somewhere). I believe that software is updated to handle it now.

As long as your final muxes are working, then MKVMerge is doing what it should and I wouldn't worry about it.

[Midzuki]

Originally Posted by rik1138

I had the same problem a year ago or so when eac3to would fail to recognize any DTS stream encoded directly from the Audio Suite (that info is buried in the eac3to thread somewhere). I believe that software is updated to handle it now.

eac3to 3.18 still is unable to identify "raw" .DTSHD files. If you wrap these in a transport stream with TSMuxer, then eac3to will work as expected.

[rik1138]

Well, I supplied all the info to make it accept them... Maybe it's just one item on a long list of 'things that need to be done'. Probably not a high priority since not too many people are actually working with files straight out of the DTS encoder... And at least there's a work around.

[ACrowley]

Originally Posted by Midzuki

eac3to 3.18 still is unable to identify "raw" .DTSHD files. If you wrap these in a transport stream with TSMuxer, then eac3to will work as expected.

yes, ofcourse. But the DTS HD MAS Suite Tools wont accept the Streams anymore.
When you take a look into with a Hexeditor you can see there a only a few bytes difference. Hopefully somebody write a small Tool/Workaround to change the Header.

[rik1138]

Well, you can just throw into any hex editor and delete the extra stuff (I think it's abuot 140 bytes or something). You'd have to save that bit and re-attach it if you want to go back into Stream Tools or something. (DTS probably has a way to redo it too, never looked). Worse case you can just re-encode it...

[ACrowley]

Originally Posted by rik1138

Well, you can just throw into any hex editor and delete the extra stuff (I think it's abuot 140 bytes or something). You'd have to save that bit and re-attach it if you want to go back into Stream Tools or something. (DTS probably has a way to redo it too, never looked). Worse case you can just re-encode it...

what i mean is reversed.

The DTS HD streams from the Suite (MA and HRA) have some extra Data.
These Extrabytes are stripped off when you run them through TSmuxer or mkvmerge so other Tools/Player can read it
But you need the extra bytes in the Header to use them again with the Suite Tools.
So we need a simple small tool (or eac3to function) which is able to add/strip this Bytes.

[rik1138]

That's why I mentioned you would probably have to save the removed data yourself (with a hex editor or something if you have the original file). If you don't have (or never had) the original file, I'm not sure if it can be 'rebuilt'...

I think this metadata contains parameters and such used by the stream tool (like the setting used in encoding, etc.) It may not be possible to determine all of the information from the existing stream... Not sure about that. I think you'd have to actually save it first if you want to re-use the file in Stream Tools.

But, worse case, if you have the DTS-HD MA file, and the DTS encoder, just convert it back to WAVs and reencode it if you need to put it in Stream Tools or something. Not the optimum solution, but do-able...

[rik1138]

So, it seems the lack of these headers has been left in place as a sort of anti-piracy measure... If the headers were intact, then anyone could take the lossless DTS stream off the Blu-ray and have a perfect copy of the master audio to work with for whatever reason. With these headers removed, you can't load the stream into DTS's Stream Tools program to make any modifications to it, including converting back to the original WAV files. The studios like this limitation, so there's no way to rebuild the missing DTS-HD MA header information (officially)...

(Yeah, we all know there's other ways to convert the files, but I guess in the beginning of Blu-ray the statement made sense...)

[Boon]

Is this still the actual state that those .dtshd headers cannot be restored? I've got a "DTS-HD MA" audio stream with a terrible tinny hall and since eac3to failed to decode to wavs my plan was using the DTS StreamPlayer. But without rewriting the original .dtshd header this won't work either.

[tebasuna51]

@Boon
This is a old thread, and the headers explained here aren't needed to decode a DTS-MA.

Are you using the last eac3to v3.31?
What is exactly "a terrible tinny hall"? Can you provide a sample?

[Boon]

Hi tebasuna51,

I used eac3to v3.11 and that's the error ocurred:

DTS Master Audio, 5.1 channels, 16 bits, 48kHz
(core: DTS, 5.1 channels, 1509kbps, 48kHz)
Decoding with libDcaDec DTS Decoder...
libDcaDec reported the warning "XLL output not lossless".  <WARNING>
Writing WAVs...

He're 2 .mka samples. Maybe it's hard to hear if you're not a native speaker.
Track 1=German with tinny hall during speech
Track 2=English with supposed-to-be vocal tone

Sample 1 (~49 sec): https://dl.dropboxusercontent.com/s/...sample%201.mka
Sample 2 (~66 sec): https://dl.dropboxusercontent.com/s/...sample%202.mka

[nevcairiel]

Such warnings are "normal", they can happen on all sorts of perfectly valid DTS-HD samples, especially if the stream is cut or stitched together.

[Boon]

That makes no sense to me. I decoded the .dtshd to WAVs and got a 768 kbps/16 Bit mono .wav for each channel. Seems a way to low bitrate for DTS-HD Master Audio. So I tested what I get when decoding only the DTS core to WAVs. And I got the same 768 kbps/16 Bit mono .wavs, except a few bytes smaller. Where did the lossless stream go?

[nevcairiel]

768kbps is expected for mono, 48000 Hz, 16-bit. The formula to calculate PCM bitrate is simple, number_of_channels * sample_rate * bitdepth --> 1 * 48000 * 16 -> 768000.
Note that the PCM size does not change for lossless or lossy streams.

[Boon]

Ok, when both formats have the same size then the only question to me is what's the better DTS decoder? Dcadec or ArcSoft's TMT? Which is getting closer to the original studio master, as the header can't be restored?

[nevcairiel]

They are identical. The header is not required.

[tebasuna51]

Originally Posted by Boon

...Maybe it's hard to hear if you're not a native speaker.
Track 1=German with tinny hall during speech

I don't listen anything wrong. Still don't know what is "hall" referred to audio, sorry. Maybe some echo?

Checked the wave forms I don't see clips, glitches or other problems.
For me the decoded dts-ma is perfect and any problem must be in the sources before encoding.

Originally Posted by Boon

...what's the better DTS decoder? Dcadec or ArcSoft's TMT? Which is getting closer to the original studio master,

Both decoders produce bit-identical output.
And don't exist reasons to suspect than aren't bit-identical to original studio master.

as the header can't be restored?

The DTS-MA headers can be restored perfectly.

Like I say before don't mistake the standard DTS-MA headers with the global header (and indexes) than Master Audio Suite add to the stream, to help authoring software, but not needed at all to decode the DTS-MA.

[tebasuna51]

@nevcairiel
Off topic, sorry.

Seems the last ffmpeg.exe zeranoe buid, and last LSMASHSource.dll (from MeGUI update) still don't have the last libdcadec version.
Both produce the glitches like was detected by Yoshi here: http://forum.doom9.org/showthread.ph...27#post1746427

[nevcairiel]

And what am I supposed to do about that?
You should ask whoever builds those to update the library.