www.makemkv.com

Has anyone had problems with including the DTS Lossless Audio track along with the DTS 3/2+1, (5.1) audio and then encoding the resulting file in handbrake?

When I only include the DTS 3/2+1, (5.1) audio track in the output MKV file, handbrake has no problems encoding the file. When I also include the DTS Lossless audio track along with the DTS 3/2+1, (5.1) audio track, (in the MKV output file) handbrake will not encode the file. The handbrakes encode log shows the following:

Stream with high frequencies VQ coding
[22:18:45] dca_syncinfo failed
[22:18:45] dca_syncinfo ok
[22:18:45] dca_syncinfo failed
[22:18:45] dca_syncinfo ok
[22:18:45] dca_syncinfo failed
[22:18:45] dca_syncinfo ok

Has anyone else seen this behavior handbrake? Is I realize MKV turns the Lossless DTS track off by default, is this why?

handbrake uses very very old ffmpeg. It does not know about lossless tracks. Maybe try a more recent version from the handbrake nightly builds.

skittle wrote:handbrake uses very very old ffmpeg. It does not know about lossless tracks. Maybe try a more recent version from the handbrake nightly builds.

Thanks skittle

After checking into more of the inner workings of handbrake, (by the way I do use the nightly builds of handbrake) you nailed it. The current handbrake doesn't understand DTS Lossless audio and therefor the errors. The solution is to leave the DTS Lossless audio unchecked and not part of the final MKV output file.

Once again, MKV is really showing how current and robust a program it truly is. Hopefully this post will be of help with anyone that has this question in the future.

Thanks again skittle!

Of course you can also mux in the lossless track your self with mkvmerge(gui) after handbrake has encoded it.
http://www.bunkus.org/videotools/mkvtoolnix/

Its one more step, but if your equipment supports it... then go for it! Also if you feel up to it I have written a small guide that details both compiling latest and encoding directly with x264.
http://www.makemkv.com/forum2/viewtopic.php?f=6&t=1313

just found this post. was looking on Handbrake with no luck. i am getting the same error. does this mean i have to rip my BluRay without the Lossless audio track to Handbrake the .mkv file? when i ripped the BluRays with MakeMKV i chose ALL the "English" Audio as well as all the "English" subtitles. here are my questions:

1) sometimes there is more than one DD 2.0 Audio track. i choose both. should i be doing this?
2) sometimes there is more than one English set of subtitle tracks. one forced and one unforced. i typically choose ALL English subtitle tracks. should i be doing this?
3) what is the difference between forced and unforced?

i appreciate any and all help provided.....

thx.

What's your point to do that?
If you use Handbrake is for "REENCODE" your source... OK.. but why?

The only point I see it's for reencode them in MP4 format for use on DLNA mediaserver/mediacenter.
If it's the case, you must only have 1 audiotrack.
Most media center doesn't support mkv or mp4 having more than one audiotrack.

Basicly, your mkv file have many audiotrack and your mp4 file have only one audiotrack.

Second thing, for the DTS Lossless just try.. reencode few file with different audio format in handbrake.
1 audiotrack and save them with different name.
Tries them on your media center after.
That way you can identify what work or doesn't work on your DLNA.

DLNA standard doesn't mean this will works everywhere but you could at least be sure this works in your home.

The Handbrake nightly build now has beta support for DTS-HD. I haven't tried it yet but you can download the handbrake nightly builds from https://build.handbrake.fr/view/Nightlies/

rcork wrote:The Handbrake nightly build now has beta support for DTS-HD. I haven't tried it yet but you can download the handbrake nightly builds from https://build.handbrake.fr/view/Nightlies/

FWIW, this just means that FFmpeg will decode the DTS core of DTS-HD tracks from MKV files. I don't think FFmpeg supports DTS-HD yet (AFAIK, it discards the HD extensions and decodes the core).

The original issue was due to the following:

1) FFmpeg not providing enough information to distinguish between regular DTS and DTS-HD (addressed in https://trac.handbrake.fr/changeset/3779)

2) HandBrake sending all DTS tracks (including DTS-HD) to its usual DTS decoder, libdca (addressed in https://trac.handbrake.fr/changeset/3785)

3) libdca's lack of DTS-HD support (i.e. its inability to discard the HD extensions and decode only the core)

This was not an issue with BD file/folder structures and MPEG Transport Streams as HandBrake uses its own TS demuxer which can identify DTS-HD and extract the DTS core before sending it to libdca.

skittle wrote:Of course you can also mux in the lossless track your self with mkvmerge(gui) after handbrake has encoded it.
http://www.bunkus.org/videotools/mkvtoolnix/

Its one more step, but if your equipment supports it... then go for it! Also if you feel up to it I have written a small guide that details both compiling latest and encoding directly with x264.
http://www.makemkv.com/forum2/viewtopic.php?f=6&t=1313

HandBrake often goes out of its way to make sure that it syncs the audio and video appropriately. Remuxing outside of this process will generate inconsistencies between the transcoded video and the original audio.

For those interested: the latest HandBrake nightly still has issues with DTS-HD in MKV. It seems a few FFmpeg bugs cause it (FFmpeg) to sometimes give bogus timestamps for DTS-HD in MKV, resulting in A/V sync and other miscellaneous issues when re-encoding with HB. They'll get fixed eventually, but in the meantime, if you re-encode audio, it's easier/safer to include the DTS core and select that in HandBrake.