eac3to - audio conversion tool

[madshi]

-Is there a quality difference between between Nero and libav?
See nautilus7's reply.

-When running it says "Removing dialog normalization..." which is good, but it does not mention the status of DRC, if it's being removed also or not.
Both Nero's TrueHD decoder and the libav TrueHD decoder don't apply DRC, anyway, so there's nothing eac3to needs to do. It's different for E-AC3.

[madshi]

"The Sonic Audio Decoder doesn't decode TrueHD properly"

Anyone know why I'm getting this error?
You're getting this error because the Sonic Audio Decoder doesn't decode TrueHD properly... :p

No, seriously. The Sonic Audio Decoder adds noise/distortion if you decode TrueHD to full 5.1. Strange enough everything's fine if you decode to 2.0 only. Anyway, because of this problem I've decided that eac3to will not allow using the Sonic Decoder for TrueHD. Please use libav instead which should give you perfect results.

[moshmothma]

Madshi, I used eac3to 2.09 to combine my 300 evos to one file and encode the truehd audio to flac and then mux to mkv. Everything worked fine accept the flac never got muxed. The operation ended without errors and gracefully. I manually muxed the file using mkvtoolnix and everything was cool.

This is the syntax I used:

C:\downloads\eac3to>eac3to M:\HDDVD\300_HDDVD\HVDVD_TS\feature_300NDOM6LF1VC1_HD
1.EVO+M:\HDDVD\300_HDDVD\HVDVD_TS\feature_300NDOM6LF1VC1_HD1_Divide.EVO 2: 300.mkv 5: truehd.flac -nero

I used -nero cause libav chocked on the 1st go around. Please let me know if there is anything I am missing.

Also, can I mux wav with mkv instead of flac? Thanks

[rack04]

You're getting this error because the Sonic Audio Decoder doesn't decode TrueHD properly... :p

No, seriously. The Sonic Audio Decoder adds noise/distortion if you decode TrueHD to full 5.1. Strange enough everything's fine if you decode to 2.0 only. Anyway, because of this problem I've decided that eac3to will not allow using the Sonic Decoder for TrueHD. Please use libav instead which should give you perfect results.

Thanks. Do using libav I would just leave the force filter to default?

[madshi]

Everything worked fine accept the flac never got muxed.
It's not intended to. Theoretically I could add options to mux audio files to the MKV file, but the usage of eac3to is already complicated enough for my taste. Adding further options for muxing would make things extremely complicated, I fear. Because of that eac3to just muxes the video to MKV and leaves audio muxing to you. This way you can at least choose exactly which audio tracks you want to have muxed. Maybe you also want to mux additional audio tracks from DVD? Or subtitle tracks? eac3to cannot handle all that.

I used -nero cause libav chocked on the 1st go around.
Generally, if you find any situation where the libav decoder chokes, *please* try to make a little sample. Because the libav TrueHD developer can only fix bugs he gets a sample for. If you have a sample, just let me know. I'm in contact with the libav TrueHD developer and can forward any samples to him. Let's make the libav TrueHD decoder stable! All we have to do is to provide the developer with samples whenever a problem occurs with his decoder...

Also, can I mux wav with mkv instead of flac? Thanks
Never tried that yet, but I think you can. Of course file size will grow noticably.

[madshi]

Thanks. Do using libav I would just leave the force filter to default?
Yep, that's right.

[shambles]

Example 5:
The following command line muxes the primary video track to MKV and rewrites the timestamps to 23.976. Furthermore all AC3, E-AC3, DTS and DTS-HD Hi-Res tracks are demuxed. And all PCM, TrueHD and DTS-HD Master Audio tracks are automatically converted to FLAC:
eac3to FEATURE_1.EVO+FEATURE_2.EVO movie.mkv

the created flac tracks are not muxed into the mkv with this example though, right? would be nice if you could create the flac + remux the video/flac track into a matroska container with just a single command line.

edit: hmh, answered while i was typing, nevermind. although, the less times you need to (re)mux something, the less discspace needed/less wear on the harddrives/less annoyance..

other than that, it's all awesome :D m2ts support would also be amazing if it would mean you wouldn't have to concatenate before remuxing (especially amazing for the seamless branching movies)

[madshi]

although, the less times you need to (re)mux something, the less discspace needed/less wear on the harddrives/less annoyance..
Let's first check if the automatic delay calculation of eac3to works correctly before even thinking about auto muxing of audio tracks into MKV. Auto muxing wouldn't make much sense if the delay calculation doesn't work reliably... ;)

m2ts support would also be amazing if it would mean you wouldn't have to concatenate before remuxing (especially amazing for the seamless branching movies)
eac3to can handle multiple EVO source files without you having to concatenate them before. I expect the same behaviour for m2ts files.

[nautilus7]

Because of that eac3to just muxes the video to MKV and leaves audio muxing to you. This way you can at least choose exactly which audio tracks you want to have muxed. Maybe you also want to mux additional audio tracks from DVD? Or subtitle tracks? eac3to cannot handle all that.

In addition, maybe someone want to specify languages for each audio/subtitle track he muxes. So it's good that eac3to doesn't mux the files.

[moshmothma]

In addition, maybe someone want to specify languages for each audio/subtitle track he muxes. So it's good that eac3to doesn't mux the files.

Just make it an option then and not requirement. Madshi, please consider auto muxing. Thanks again

[moshmothma]

Generally, if you find any situation where the libav decoder chokes, *please* try to make a little sample. Because the libav TrueHD developer can only fix bugs he gets a sample for. If you have a sample, just let me know. I'm in contact with the libav TrueHD developer and can forward any samples to him. Let's make the libav TrueHD decoder stable! All we have to do is to provide the developer with samples whenever a problem occurs with his decoder...


Doh!! Ok, will do in the future. How do I make a sample? Just demux and use and split program? Thanks again

[nautilus7]

Demux the track and open it with a hex editor like HxD.
Cut a piece which contains the part that gives you the problem and then upload.

[nautilus7]

@ madshi

If you have time, please add the processing time display feature we discussed some days before.

Thanks.

[madshi]

Just make it an option then and not requirement. Madshi, please consider auto muxing. Thanks again
Maybe later. But first I need to know whether delay calculation is correct or not. So guys, please test remuxing to MKV with eac3to with some movies and let me know if audio seems to be in sync or not. Thanks.

[madshi]

If you have time, please add the processing time display feature we discussed some days before.
Forgot about that. I'll try to remember...

[nautilus7]

OK, thanks!

I just tested 24 bit trueHD decoding with Inside man HD DVD. I got bit identical flac files with both libav and nero decoder.

I understand that you need us to test the delay... Any particular movie? :p
I 'll just have to find one that needs a delay though, right?

[Thunderbolt8]

The decoder always calculates 24bit for DTS-HD Hi-Res tracks. Sonic normally dithers down to 16bit internally. If you want to have it that way you can use the undocumented switch "-dontPatchDts". That will disable to 16bit->24bit patching. Alternatively you could also ask eac3to to dither down to 16bit. I don't know whether Sonic's or my down dithering has a better quality.

Which is your target format? FLAC? How about dithering down to 18bit then?
hm dithering down was related to lower overall quality, right? then I better stick to the 24-bit version just to be sure.

nice additions btw in the new version! did you also plan to make eac3to .m2ts compatible in the future ? :P

[madshi]

I understand that you need us to test the delay... Any particular movie? :p
I 'll just have to find one that needs a delay though, right?
Yeah, any movies where eac3to shows some bigger delay values in the track listing. But also those with small delay values might be interesting to test.

Please remember that eac3to can not (yet) apply delay on bitstream audio (E-AC3, DTS). You'll need to use delaycut for those. But eac3to should write the needed delay into the filename of the demuxed audio track.

[madshi]

hm dithering down was related to lower overall quality, right? then I better stick to the 24-bit version just to be sure.
Yes, dithering down reduces audio quality. However, most experts seem to agree that more than 20bit doesn't have any benefit. So dithering down to 20bit should (at least in theory) not harm.

nice additions btw in the new version! did you also plan to make eac3to .m2ts compatible in the future ? :P
You're about the twenty-seventh person asking for that. Please see my earlier replies about this.

[Thunderbolt8]

ok, just read it now .m2ts later then, first making this one stable:
some questions though:

-so the offsetpts function is included as well now, for example when remuxing studio canal HD DVD we dont need to do that with the main .evo files manually any more?

-what about the fps rate, will it remain at 23.976 or change it to 24000/1001 ? might be useful to have another -option command for the other one. I guess you might merge eac3to with h264tsto sooner or later anyway, so in case of TV broadcasts 23.976 should be useful and for HD DVDs 24000/1001


btw. that -83ms for the audio track of the band of brothers remuxed proved to be right at the end. in some scenes this very fine difference could be spotted.

[madshi]

-so the offsetpts function is included as well now, for example when remuxing studio canal HD DVD we dont need to do that with the main .evo files manually any more?
Correct.

-what about the fps rate, will it remain at 23.976 or change it to 24000/1001 ? might be useful to have another -option command for the other one. I guess you might merge eac3to with h264tsto sooner or later anyway, so in case of TV broadcasts 23.976 should be useful and for HD DVDs 24000/1001
I'll change it to 24000/1001. Should work for both HD DVDs/Blu-Rays and for TV broadcasts.

btw. that -83ms for the audio track of the band of brothers remuxed proved to be right at the end. in some scenes this very fine difference could be spotted.
That's good!

[Thunderbolt8]

hm better please leave it at 23.976 for broadcasts, because sometimes the audio tracks get replaced with those coming from DVDs and those are afaik exact 23.976 values (at least I once tested it with a star wars broadcast and found some scenes were 23.976 looked better over 23.9760239 (rest scenes were more like neutral)). or at least please add a switch for that case

[shambles]

ntsc = 30000/1001, with the video 24000/1001 when ivtc'd. i don't think any source should ever be 23.976 instead of 24000/1001..

[Thunderbolt8]

are you 100% sure about that, also in cases of DVDs? is there actually a possibility to have proof for this, some technical sheets or such?

[shambles]

http://en.wikipedia.org/wiki/NTSC :)

[nautilus7]

How do i check whether a truehd track is 16, 20 or 24 bits?

I am not sure if the truehd track from inside man hd dvd is 24 bit. The flac i got from it claims to be 24, but size is only 1,88 GB for 2 a hour movie, whether the prestige's flac track (which is definately 24 bits) is 2,79 GB.

[Thunderbolt8]

cant see them talking there explicitly NTSC being 24000/1001 fps. they use 23.976 fps too often there, even though in case this might only be used as abbreviation to 24000/1001. still not enough to convince its really 24000/1001 all the time

[Snowknight26]

Madshi, here is a sample from The Phantom of the Opera:
http://www.stfcc.org/misc/PEVOB_1.EVO

[MuteyM]

Generally, if you find any situation where the libav decoder chokes, *please* try to make a little sample. Because the libav TrueHD developer can only fix bugs he gets a sample for. If you have a sample, just let me know. I'm in contact with the libav TrueHD developer and can forward any samples to him. Let's make the libav TrueHD decoder stable! All we have to do is to provide the developer with samples whenever a problem occurs with his decoder...

Hi Madshi, love your app, and I've got what I think is a libav problem for you to puzzle over... On the NIN HD DVD, every single demuxed TrueHD track gives the same error message, right at the very end of decoding:
eac3to.exe EVOB010.thd blah.wav -libav
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Writing WAV...
Removing dialog normalization...
Creating/writing file "D:\blah.24bit.wav"...
This audio track contains more than 16 bit of information.
-------------------------------------------------------------------------------[
mlp @ 68A442E0]End of stream indicated
[mlp @ 68A442E0]Substream 1 parity check failed
[mlp @ 68A442E0]Substream 1 checksum failed
[mlp @ 68A442E0]Substream 1 length mismatch.
Done.

Up to version 2.08, this error was ignored by eac3to and the resulting output file could be used without problems. But starting with version 2.09, the output file gets erased upon error! If it's not a big deal, I'd like to request you revert back to the old behaviour, for cases where libav chokes or just for general debugging of errors.

I'm 99% sure it's not a decrypting or demuxing problem, because I get the same results with demux.exe, EvobDemux, and eac3to 2.10's demux-to-wav functionality, and it happens with all EVOs on the disc. But the resulting output file always sounds perfect.

So I'm thinking it's a bug in libav (or maybe a defect on my disc?) Anyway, you can download a sample .thd file from here:
http://www.sendspace.com/file/udpvza

Once again, thanks for such an amazing app!

[nautilus7]

I had the same error, but with matrix truehd. It's not really a big problem, just few millisecs that are missing at the end of the track.

I had made a sample and madshi said that he was going to forward it to the libav developer.

Someone forgot to do it... :devil: (just kidding)

[moshmothma]

I had the same error, but with matrix truehd. It's not really a big problem, just few millisecs that are missing at the end of the track.

I had made a sample and madshi said that he was going to forward it to the libav developer.

Someone forgot to do it... :devil: (just kidding)

Madshi, that's the error I had with truehd from 300. Just FYI

[bmnot]

Is it possible to make 24-bit legacy DTS tracks from 24-bit DD+/TrueHD tracks?

[scarbrtj]

I recently tried my first DTS-HD --> DTS conversion. Went well insofaras got a perfect DTS stream, playable by itself. I muxed this DTS with the video AVC elementary stream using mkvmerge GUI.

If I mux just the AVC stream to .mkv, or just play it back by itself, plays perfectly and smoothly. I am using WMP 11 for playback.

BUT... if I mux the DTS and AVC together, I get "problems." I am sending the bitstream out by SPDIF. First I tried ffdshow. The file overall plays, but every few seconds there's just a slight "jump" or hiccup. It is mild, but noticeable enough to be bothersome. Perhaps this is the audio and video trying to stay in sync? Then I tried AC3 filter for my SPDIF output of the DTS. This allows the file to play smoothly, but about 10 minutes in, the audio and video begin to noticeable desync. By 1 hour in, they're really out of sync (a few seconds).

If I convert the DTS-HD into AC3 and mux that with my 1920x1080 AVC file, I get very smooth playback and no out-of-sync whatsoever.

I'd love of course to start using DTS's higher bitrates, but I can't seem to conquer this. I have tried multiple iterations.

Thoughts?

[Chumbo]

I recently tried my first DTS-HD --> DTS conversion. Went well insofaras got a perfect DTS stream, playable by itself. I muxed this DTS with the video AVC elementary stream using mkvmerge GUI.

If I mux just the AVC stream to .mkv, or just play it back by itself, plays perfectly and smoothly. I am using WMP 11 for playback.

BUT... if I mux the DTS and AVC together, I get "problems." I am sending the bitstream out by SPDIF. First I tried ffdshow. The file overall plays, but every few seconds there's just a slight "jump" or hiccup. It is mild, but noticeable enough to be bothersome. Perhaps this is the audio and video trying to stay in sync? Then I tried AC3 filter for my SPDIF output of the DTS. This allows the file to play smoothly, but about 10 minutes in, the audio and video begin to noticeable desync. By 1 hour in, they're really out of sync (a few seconds).

If I convert the DTS-HD into AC3 and mux that with my 1920x1080 AVC file, I get very smooth playback and no out-of-sync whatsoever.

I'd love of course to start using DTS's higher bitrates, but I can't seem to conquer this. I have tried multiple iterations.

Thoughts?
You must use a timecodes file on the video stream in mkvmerge with the correct fps. Read the mkvmerge help as it has a detailed explanation of this feature.

[Chumbo]

@madshi,
I just wanted to say thanks for the new version. Man you packed a lot of stuff into it. Very nice. I want to contribute any findings, so here goes.

I have a short test pcm file that converts just fine to both ac3 and dts, see output below. However, when you run it to just get the info on the file, the program crashes, i.e., "eac3to audio.pcm" crashes.

Output of eac3tov2 audio.pcm audio.ac3 -384 -16 -littleThis might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
---The RAW/PCM file seems to be little endian.
---The suggested endian (little) should be correct.
---The RAW/PCM file seems to have a bitdepth of 16 bits.
---The suggested depth of 16 bits should be correct.
---The RAW/PCM file seems to have 6 channels.
---RAW/PCM, 5.1 channels, 0:04:19, 16 bits, 48khz
---Reading RAW/PCM...
Encoding AC3...
Creating/writing file "audio.ac3"...
-------------------------------------------------------------------------------
Done.

Output of eac3tov2 audio.pcm audio.dts -16 -littleThis might be a RAW/PCM file. Trying to figure out the details.
This will probably take a while. Please be patient...
---The RAW/PCM file seems to be little endian.
---The suggested endian (little) should be correct.
---The RAW/PCM file seems to have a bitdepth of 16 bits.
---The suggested depth of 16 bits should be correct.
---The RAW/PCM file seems to have 6 channels.
---RAW/PCM, 5.1 channels, 0:04:19, 16 bits, 48khz
---Reading RAW/PCM...
Writing WAVs...
Creating/writing file "audio.L.wav"...
Creating/writing file "audio.R.wav"...
Creating/writing file "audio.C.wav"...
Creating/writing file "audio.LFE.wav"...
Creating/writing file "audio.SL.wav"...
Creating/writing file "audio.SR.wav"...
-------------------------------------------------------------------------------
Found Surcode DTS Encoder version 1.0.23.0.
Surcode encoding successfully started. Please wait...
Closing Surcode...
Done.
I'll send the debug info separately. Thank you.

[scarbrtj]

You must use a timecodes file on the video stream in mkvmerge with the correct fps. Read the mkvmerge help as it has a detailed explanation of this feature.

I did, I think; I thought of this (see below). As I said, the AVC file if muxed into .mkv by itself plays back flawlessly. Also, playback is flawless if I mux AVC with AC3 (generated from DTS-HD). But... the .mkv of an AVC and DTS (actually it is DTS-ES 6.1 stream) plays back jumpy (ffdshow audio decode to SPDIF) or out-of-sync (AC3filter to SPDIF).

The timecodes file I used was:

# timecode format v1
Assume 23.976

Should this have produced a good DTS/AVC mkv merge? I did not use this to merge AVC and AC3 and the mkv plays back great (but did have to specify a 23.976 framerate in mkvmerge GUI).

[Chumbo]

I did, I think; I thought of this (see below). As I said, the AVC file if muxed into .mkv by itself plays back flawlessly. Also, playback is flawless if I mux AVC with AC3 (generated from DTS-HD). But... the .mkv of an AVC and DTS (actually it is DTS-ES 6.1 stream) plays back jumpy (ffdshow audio decode to SPDIF) or out-of-sync (AC3filter to SPDIF).

The timecodes file I used was:

# timecode format v1
Assume 23.976

Should this have produced a good DTS/AVC mkv merge? I did not use this to merge AVC and AC3 and the mkv plays back great (but did have to specify a 23.976 framerate in mkvmerge GUI).
I'm sorry, you did mention that muxing ac3 works fine and I read right past it. My bad. Your timecode stuff is correct, so I'm not sure why it's not syncing unless it's an issue with whatever splitter you're using.

I, personally, avoid WMP at all costs. ;) Try using MPC and use its built-in source filters: DTS/AC3, Matroska and MPEG PS/TS/PVA. I normally use the Haali splitter, but at times, with DTS, I have to switch to MPC's internal filters to get smooth play back. Good luck. :)

[Snowknight26]

I have a short test pcm file that converts just fine to both ac3 and dts, see output below. However, when you run it to just get the info on the file, the program crashes, i.e., "eac3to audio.pcm" crashes.
I can confirm this. Happens on several pcm streams I have.

[itsancho]

Hi Madshi, love your app, and I've got what I think is a libav problem for you to puzzle over... On the NIN HD DVD, every single demuxed TrueHD track gives the same error message, right at the very end of decoding:
eac3to.exe EVOB010.thd blah.wav -libav
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Writing WAV...
Removing dialog normalization...
Creating/writing file "D:\blah.24bit.wav"...
This audio track contains more than 16 bit of information.
-------------------------------------------------------------------------------[
mlp @ 68A442E0]End of stream indicated
[mlp @ 68A442E0]Substream 1 parity check failed
[mlp @ 68A442E0]Substream 1 checksum failed
[mlp @ 68A442E0]Substream 1 length mismatch.
Done.

Up to version 2.08, this error was ignored by eac3to and the resulting output file could be used without problems. But starting with version 2.09, the output file gets erased upon error! If it's not a big deal, I'd like to request you revert back to the old behaviour, for cases where libav chokes or just for general debugging of errors.

I'm 99% sure it's not a decrypting or demuxing problem, because I get the same results with demux.exe, EvobDemux, and eac3to 2.10's demux-to-wav functionality, and it happens with all EVOs on the disc. But the resulting output file always sounds perfect.

So I'm thinking it's a bug in libav (or maybe a defect on my disc?) Anyway, you can download a sample .thd file from here:
http://www.sendspace.com/file/udpvza

Once again, thanks for such an amazing app!

absolutely the same problem with "TMNT" and when i forced to use nero - everything its OK...

[shambles]

How do i check whether a truehd track is 16, 20 or 24 bits?

I am not sure if the truehd track from inside man hd dvd is 24 bit. The flac i got from it claims to be 24, but size is only 1,88 GB for 2 a hour movie, whether the prestige's flac track (which is definately 24 bits) is 2,79 GB.

the bitrate is a good indicator.. 16bit is usually less than 1500kbps, 20bit > 2000kbps, 24bit > 3000kbps

[madshi]

hm better please leave it at 23.976 for broadcasts, because sometimes the audio tracks get replaced with those coming from DVDs and those are afaik exact 23.976 values (at least I once tested it with a star wars broadcast and found some scenes were 23.976 looked better over 23.9760239 (rest scenes were more like neutral)). or at least please add a switch for that case
I don't believe you can see a difference of 7ms - and that's all there is between 23.976 and 23.9760239 at the end of a two hour movie. FWIW, I believe 24/1.001 is "more correct" than 23.976.

[madshi]

How do i check whether a truehd track is 16, 20 or 24 bits?

I am not sure if the truehd track from inside man hd dvd is 24 bit. The flac i got from it claims to be 24, but size is only 1,88 GB for 2 a hour movie, whether the prestige's flac track (which is definately 24 bits) is 2,79 GB.
We had a similar effect with Pirates of the Caribbean 1. I checked that movie and there were some very short sequences of the PCM track which were 24bit while the majority of the track was 16bit. I think the same thing is very likely to be true with the inside man track.

[madshi]

Madshi, here is a sample from The Phantom of the Opera:
http://www.stfcc.org/misc/PEVOB_1.EVO
Thanks! Will have a look.

[madshi]

On the NIN HD DVD, every single demuxed TrueHD track gives the same error message, right at the very end of decoding:
eac3to.exe EVOB010.thd blah.wav -libav
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Writing WAV...
Removing dialog normalization...
Creating/writing file "D:\blah.24bit.wav"...
This audio track contains more than 16 bit of information.
-------------------------------------------------------------------------------[
mlp @ 68A442E0]End of stream indicated
[mlp @ 68A442E0]Substream 1 parity check failed
[mlp @ 68A442E0]Substream 1 checksum failed
[mlp @ 68A442E0]Substream 1 length mismatch.
Done.

Up to version 2.08, this error was ignored by eac3to and the resulting output file could be used without problems. But starting with version 2.09, the output file gets erased upon error! If it's not a big deal, I'd like to request you revert back to the old behaviour, for cases where libav chokes or just for general debugging of errors.

I'm 99% sure it's not a decrypting or demuxing problem, because I get the same results with demux.exe, EvobDemux, and eac3to 2.10's demux-to-wav functionality, and it happens with all EVOs on the disc. But the resulting output file always sounds perfect.

So I'm thinking it's a bug in libav (or maybe a defect on my disc?) Anyway, you can download a sample .thd file from here:
http://www.sendspace.com/file/udpvza
Yeah, it seems to be a bug in the libav decoder. My guess is that the decoder believes that the truehd stream is done and finished and then surprisingly there's more truehd data coming in. And the decoder doesn't seem to like that. Should be easy to fix, though. Give the decoder developer a few days. His replies sometimes take a few days, but he always comes back with a fix. You can use the Nero decoder in the meanwhile ("-nero" switch).

Someone forgot to do it... :devil: (just kidding)
No, I didn't... ;)

[madshi]

Is it possible to make 24-bit legacy DTS tracks from 24-bit DD+/TrueHD tracks?
Sure. Just do "eac3to source.thd dest.dts" or "eac3to source.eac3 dest.dts". Or directly from the EVO source: "eac3to feature_1.evo+feature_2.evo 2: dest.dts".

However, you need to have the commercial (and quite expensive) Surcode DTS encoder installed!

[madshi]

I recently tried my first DTS-HD --> DTS conversion. Went well insofaras got a perfect DTS stream, playable by itself. I muxed this DTS with the video AVC elementary stream using mkvmerge GUI.

If I mux just the AVC stream to .mkv, or just play it back by itself, plays perfectly and smoothly. I am using WMP 11 for playback.

BUT... if I mux the DTS and AVC together, I get "problems." I am sending the bitstream out by SPDIF. First I tried ffdshow. The file overall plays, but every few seconds there's just a slight "jump" or hiccup. It is mild, but noticeable enough to be bothersome. Perhaps this is the audio and video trying to stay in sync? Then I tried AC3 filter for my SPDIF output of the DTS. This allows the file to play smoothly, but about 10 minutes in, the audio and video begin to noticeable desync. By 1 hour in, they're really out of sync (a few seconds).

If I convert the DTS-HD into AC3 and mux that with my 1920x1080 AVC file, I get very smooth playback and no out-of-sync whatsoever.

I'd love of course to start using DTS's higher bitrates, but I can't seem to conquer this. I have tried multiple iterations.

Thoughts?
My first guess would be that the muxer doesn't like the DTS-HD core. There's a small difference to "normal" DTS files. Normal DTS files usually have 2013 bytes per DTS frame while the DTS core from a DTS-HD track only has 2012 bytes per DTS frame. I don't know it behaves this way. And it gets even stranger: If you want to keep audio sync, the DTS parser needs to behave as if the frames were 2013 bytes long!! Extremely strange and kind of annoying. Personally, I'm not muxing the DTS files into the MKV file. Instead I'm keeping them external. The MPC HC can play them as external files. Earlier in this thread you'll find a modified source filter which plays these DTS core tracks with correct audio sync.

[nautilus7]

We had a similar effect with Pirates of the Caribbean 1. I checked that movie and there were some very short sequences of the PCM track which were 24bit while the majority of the track was 16bit. I think the same thing is very likely to be true with the inside man track.
That's possible...
I tried the -check16bit switch, but it told me thats the track contains more than 16 bit of information. But how many exactly?

How did the studio manage to make a track with variable bit depth?

[nautilus7]

We had a similar effect with Pirates of the Caribbean 1. I checked that movie and there were some very short sequences of the PCM track which were 24bit while the majority of the track was 16bit. I think the same thing is very likely to be true with the inside man track.
That's possible...
I tried the -check16bit switch, but it told me that the track contains more than 16 bit of information. But how many exactly, none knows...

How did the studio manage to make a track with variable bit depth?

[shambles]

i think it's just constant 20bit.. the track the nero decoder had problems with before was inside man, and madshi suspected it could be 18 or 20bit.. i dithered some other 24bit tracks down to 20bit and they compressed to very similar bitrates

[nautilus7]

Can flac have bit depths of 20 bits? If yes why eac3to said "writing 24 bit flac"...