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. :confused:

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]

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]

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]

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/uuqn6f8spuk1ums/00005.track_4352_sample%201.mka
Sample 2 (~66 sec): https://dl.dropboxusercontent.com/s/aqyhro312hkbwly/00005.track_4352_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]

...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.

...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.php?p=1746427#post1746427

[nevcairiel]

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

[Boon]

They are identical.
Both decoders produce bit-identical output.You were right. I compared the SHA1 checksums from Dcadec and Arcsoft wavs.


Still don't know what is "hall" referred to audio, sorry. Maybe some echo? any problem must be in the sources before encoding.
Echo would be a matching description.


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 softwareStandard DTS-HD MA header = on all BDs
Global DTS-HD MA header = non-authored DTS file right from all (official licensed) encoders


The DTS-MA headers can be restored perfectly.And how can I restore the headers to make DTS files work again in the Master Audio Suite?

[tebasuna51]

And how can I restore the headers to make DTS files work again in the Master Audio Suite?
To restore the global header (and indexes) you can do:

eac3to "00005.track_4352_sample 1.mka" 1: mono.wavs

and recode the mono.wavs with Master Audio Suite, is a lossless operation.

[Boon]

I already done this. It was just my missunderstanding of the DTS file format. So in conclusion a DTS file created in the Master Audio Suite contains the exact same audio streams as on BDs, plus additional header information, which is removed on BDs (for whatever reason). These audio streams from BD are identical, weather you decode them through eac3to to WAVs with standard header or decode them through DTS StreamPlayer with global header.

[tebasuna51]

So in conclusion a DTS file created in the Master Audio Suite contains the exact same audio streams as on BDs, plus additional header information, which is removed on BDs (for whatever reason). These audio streams from BD are identical, weather you decode them through eac3to to WAVs with standard header or decode them through DTS StreamPlayer with global header.

Exact.

The additional header information is used by authoring programs to create BD's, but the data is traslated to m2ts headers in other format.

With MkvMerge the additional header is not needed because analyze the DTS-MA itself and create the equivalent info in mkv header.

But the audio data stream (with the standard headers) is the same in m2ts or mkv.

[Boon]

and create the equivalent info in mkv header.This explains why I getting a time code error, after modifying the .dts header in hex editor so it can be loaded in the DTS StreamPlayer. The time codes are stored seperated in the mkv.

Would be great if eac3to had an option to write the time codes back in the .dts file.

[tebasuna51]

And what am I supposed to do about that? :)
Was only a commentary. Don't worry.

You should ask whoever builds those to update the library.
The ffmpeg team always reject my suggestions in the past.
Maybe other user with more influence.

[tebasuna51]

Would be great if eac3to had an option to write the time codes back in the .dts file.

Was suggested already, but I think that is useless for common users, and have a easy workaround.