eac3to - audio conversion tool

[rickardk]

Will truehd decoded with nero and libav give bit identical result?

[nautilus7]

Yes, of course. Truehd is lossless, so a decoder has to output the same data.

[Chumbo]

Yeah, if there's an audio sync problem with this EVO, please upload it. BTW, is there no audio sync problem when playing this EVO directly with PowerDVD?
Here's (http://www.filefactory.com/file/9aa239/) the link to the file.

[rickardk]

Yes, of course. Truehd is lossless, so a decoder has to output the same data.

Exactly... But I remuxed Inside Man today (did the same title a couple of weeks ago) and compared filesize of the resulting flac. Not the same as the old one (done with nero).

[nautilus7]

I did inside man too. Bit identical result between nero and libav.

[Chumbo]

@madshi,
I had some time to do a quick test with that paralogo.evo:


Wrote the h264 video to an mkv file
Transcoded the audio to ac3 letting eac3to do its thing by not using any parameters which meant applying the delay correction automatically
Muxed the ac3 file into the mkv
Played the MKV file which played perfectly


From that test, the stuff worked like a charm, so I'm not sure why I had the sync issues over the weekend.

I also took the reencoded mpeg2 video and muxed in the transcoded track which had the auto delay applied and it played perfectly. So I'm more preplexed at what the heck happened over the weekend.

Any how, everything's working as it's supposed to and I'm sorry I wasted your time on this. I really should have double and triple checked things and saved us all the headache. Sigh.

[rickardk]

I did inside man too. Bit identical result between nero and libav.

Hmm...strange...

[Wackyphill]

Well I deffinately have the US version of 300and stillhave sync problems. I'm going to try Harry Potter and the Chamber of Secrets next and see if the results are the same.

Has anyone tried this disc or the 300 disc before?

[madshi]

Any how, everything's working as it's supposed to and I'm sorry I wasted your time on this. I really should have double and triple checked things and saved us all the headache. Sigh.
Not a problem, mate.

[madshi]

Hmm...strange...
If you can reproduce the problem I'd be happy to analyze it. Best thing would be to decode to RAW and check the beginning and end of both Nero/libAV decoded RAW files. Are they identical in the beginning or at the end or both or neither nor?

[madshi]

Well I deffinately have the US version of 300and stillhave sync problems.
If you are able to produce a little sample with which the problem is reproduceable, just let me know.

[Jaja1]

I've remuxed at least 15 VC-1 HD DVDs to MKV without a single problem. So I don't think that there is a general problem with VC-1 HD DVDs. Well, blu-ray in both VC1 and AVC and also HD DVD in AVC playback fine. It is just HD DVD VC1 that gives me problems, from hardly noticable stutters from time to time to a total garbled mess.

Moreover all VC1 encoded HD DVD titles playback fine in Powerdvd and most of them using a total sonic graph. So, it is hard for me to understand that all are ripped fine except for the HD DVD VC1 titles. But I will look into that.

I have done remuxed about 60 titles now. Very few problems...
Unforgiven remuxed without problems
That is interesting, where you able to playback Unforgiven as an EVO using Haali splitter? That must have been. I can only playback Unforgiven with PDVD and using Sonic HD Demuxer, Sonic audio and video decoders and VMR9. Haali splitter totally destroys the image. I will give Unforgiven another try.

To make things more complicated, I noticed that VMR9 and the Haali video renderer give different results for VC1 HD DVD's.

[nautilus7]

A friend of me (he just registered here and he can't post right away) has this problem:

I have some trouble with eac3to (2.14) right now. When I try to create a flac file with eac3to from a truehd track I end with a much bigger flac file as the original mpa file. This only happens if I use the nero decoder instead of libav.

I demuxed the evo with the newest version of evodemux and have a 500mb mpa file (truehd track, 24bit, 48khz, 6 channels). I'm not yet sure if it is a problem with the nero decoder or with eac3to or even with flac itself. First the really strange thing is the huge diff in the filesize.


D:\Encoding\eac3to>eac3to 33.mpa 33.flac -test
Nero Audio Decoder (Nero 7 or older) works fine
Sonic Audio Decoder (4.2.0.102) works fine
Haali Media Splitter (2007-12-29) is installed
Surcode DTS Encoder doesn't seem to be installed
MkvToolnix (v2.1.0) is installed
TrueHD, 5.1 channels, 48khz, dialnorm: -27dB
Removing dialog normalization...
Encoding FLAC...
This audio track contains more than 16 bit of information.
Creating/writing file "33.24bit.flac"...


33.mpa ~500mb

eac3to 33.mpa 33.flac -> ~430mb
eac3to 33.mpa 33.flac -nero -> ~1130mb
eac3to 33.mpa 33.flac -libav -> ~430mb

All the flac files play fine, but I noticed that I cannot reencode the flac files with flac.exe itself. If I try to do so then I get an error. Trying to reencode the flac files with eac3to works fine. Also if I downconvert the flac files to 16bit with eac3to the size of the resulting file seems to be ok. Its just that the 24bit (nero) flac file has an abnormal filesize.

Checking the header of the flac files with metaflac shows that the "nero" flac uses much higher framesize.

33.flac (default)

METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 32 bytes
maximum framesize: 38987 bytes
sample_rate: 48000 Hz
channels: 6
bits-per-sample: 24
total samples: 128859920
MD5 signature: 7deea38289c600254f5b33723f6be7ee
METADATA block #1
type: 4 (VORBIS_COMMENT)
is last: true
length: 40
vendor string: reference libFLAC 1.2.0 20070715
comments: 0


33.flac (nero)

METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 4219 bytes
maximum framesize: 63132 bytes
sample_rate: 48000 Hz
channels: 6
bits-per-sample: 24
total samples: 128859920
MD5 signature: a27fed6041351d0e940b7d1d289db383
METADATA block #1
type: 4 (VORBIS_COMMENT)
is last: true
length: 40
vendor string: reference libFLAC 1.2.0 20070715
comments: 0

[madshi]

It is just HD DVD VC1 that gives me problems, from hardly noticable stutters from time to time to a total garbled mess.

Moreover all VC1 encoded HD DVD titles playback fine in Powerdvd and most of them using a total sonic graph. So, it is hard for me to understand that all are ripped fine except for the HD DVD VC1 titles.
I can confirm trouble with some selected VC-1 HD DVD movies. E.g. Phantom of the Opera and the Polish Underworld Evolution are 2 such examples. But from my experience I'd say the number of problematic VC-1 HD DVD movies is lower than 5%. Of course I've not tested every movie, but only some.

Haali splitter totally destroys the image.
I'm not sure who is the guilty one. I've managed to remux the Polish Underworld Evolution HD DVD to MKV by only using Haali's Matroska Muxer but feeding it manually with my own code (instead of using the Haali Media Splitter). But the playback was garbled exactly the same way as when using the Haali Media Splitter for remuxing. Ok, for playing back the MKV file again I was using the Haali Media Splitter. But still I'm not convinced yet that the bug is caused by the splitter. It could also be the muxer. It could also be the logic used for storing VC-1 in MKV. Haali throws away all data packets except the encoded frames. But sequence headers and that kind of stuff are not muxed into the MKV file (except the very first sequence header which is stored separately from the frames). Maybe the problematic movies don't work this way? Maybe they need the full headers etc? But I don't know why that should be the case...

FWIW, the MS VC-1 decoder seemingly wants to have only the frames, it doesn't want the sequence headers in the stream. In contrast to that the Sonic VC-1 decoder does want to have the sequence headers inside of the stream. That's why you cannot connect the MS VC-1 decoder to the Sonic Demuxer and why you cannot connect the Sonic VC-1 decoder to the Haali splitter. The splitters behave differently. And the decoders want different data.

Edit: Is there any movie which is available in VC-1 on both HD DVD and Blu-Ray, *and* which shows these total garbling in HD DVD but not in Blu-Ray (after having remuxed both to MKV)? If so, maybe we could find out what the difference is exactly...

[madshi]

A friend of me (he just registered here and he can't post right away) has this problem
A sample would be great. I think the dialog normalization removal doesn't work for this specific track (don't know why). The libav decoder never applies dialog normalization, so it works fine nevertheless. But the Nero decoder does apply dialog normalization if it's in the TrueHD stream.

[nautilus7]

How big would the sample be?

[madshi]

How big would the sample be?
10MB should be plenty.

[Beastie Boy]

Has anyone tried this disc or the 300 disc before?

My copy of 300 has the same file names as yours, the TrueHD track does not have a delay. I had no synch problems when the files were remuxed.

Cheers, Beastie.

[nautilus7]

I have a problem, delay related.
I want to reverse pal speed and delay an ac3 i have, so i do:

eac3to input.ac3 output.ac3 -slowdown -384 +2910ms

but the delay applied to the track is different than the one i set (3048ms instead of 2910ms).

I've made a sample here (http://www.sendspace.com/file/n5ua7z). Details included.

[madshi]

I have a problem, delay related.
I want to reverse pal speed and delay an ac3 i have, so i do:

eac3to input.ac3 output.ac3 -slowdown -384 +2910ms

but the delay applied to the track is different than the one i set (3048ms instead of 2910ms).

I've made a sample here (http://www.sendspace.com/file/n5ua7z). Details included.
Well, it's a difficult situation: Do you want to have the delay applied to the source file or the destination file? That's open to interpretation... I think that's probably where the difference is coming from.

[nautilus7]

Well, first of all... Does the order i specify the options has anything to do? No, right? (i use eac3to long enough so... it can't be that :p )

I 've done it several times and never got that big difference, but i think this is the first time i have to apply such a huge delay. I guess that's why i notice this behavior now.

I want the delay to be applied to the slowdown track. In my mind i do the actions in this order: 1.slowdown 2.delay 3.encode.

[nautilus7]

A sample would be great. I think the dialog normalization removal doesn't work for this specific track (don't know why). The libav decoder never applies dialog normalization, so it works fine nevertheless. But the Nero decoder does apply dialog normalization if it's in the TrueHD stream.

Here's (http://www.sendspace.com/file/6xr03j) the sample you asked for.

[madshi]

Well, first of all... Does the order i specify the options has anything to do?
No.

I want the delay to be applied to the slowdown track. In my mind i do the actions in this order: 1.slowdown 2.delay 3.encode.
Yeah. But how can eac3to know? Maybe someone else thinks about: 1. delay 2. slowdown 3.encode? E.g. I'm thinking about the h264 HDTV broadcasts I'm recording here in Germany. If I want to convert them to 24p, I'd first add a PAL DVD track to the original 50i recording. For that to work I'd first need to find out the necessary delay. Afterwards I then need to slowdown the PAL DVD track and rewrite the video timestamps. Doing it this way I'd need to do 1. delay 2. slowdown 3. encode.

So as far as I can see when you do slowdown and delay at the same time eac3to simply doesn't know in which order to do things. Both order variations can be right or wrong depending on what the user wants. The only way to solve this properly would be to let eac3to make use of the order in which you specified the delay and slowdown options. But then there are further problems: If you demux an audio track from an EVO file and at the same time want to apply PAL speedup and delay it, there'd be the automatic delay correction which HAS to be made before speedup, then the speedup and finally the manual delay. That's all getting extremely confusing. So my recommendation is that in such situations you should probably better do the operations in 2 steps, so that there's no room for interpretation.

[madshi]

Here's (http://www.sendspace.com/file/6xr03j) the sample you asked for.
Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".

[nautilus7]

No.


Yeah. But how can eac3to know? Maybe someone else thinks about: 1. delay 2. slowdown 3.encode? E.g. I'm thinking about the h264 HDTV broadcasts I'm recording here in Germany. If I want to convert them to 24p, I'd first add a PAL DVD track to the original 50i recording. For that to work I'd first need to find out the necessary delay. Afterwards I then need to slowdown the PAL DVD track and rewrite the video timestamps. Doing it this way I'd need to do 1. delay 2. slowdown 3. encode.

So as far as I can see when you do slowdown and delay at the same time eac3to simply doesn't know in which order to do things. Both order variations can be right or wrong depending on what the user wants. The only way to solve this properly would be to let eac3to make use of the order in which you specified the delay and slowdown options. But then there are further problems: If you demux an audio track from an EVO file and at the same time want to apply PAL speedup and delay it, there'd be the automatic delay correction which HAS to be made before speedup, then the speedup and finally the manual delay. That's all getting extremely confusing. So my recommendation is that in such situations you should probably better do the operations in 2 steps, so that there's no room for interpretation.

Ok, i see.

Maybe you can modify eac3to to "care" about the order of these 2 switches (slowdown, delay) when they are applied together. But i really don't mind. If you can make without investing much time and you want to, do it. I am happy there isn't a bug in eac3to.

[nautilus7]

Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".

I'll tell him to check again. Thanks for your time.

[Wackyphill]

My copy of 300 has the same file names as yours, the TrueHD track does not have a delay. I had no synch problems when the files were remuxed.

Cheers, Beastie.


Thanks for the info! It seems to be a problem w/ my process. I tried w/ Harry Poter 2 also and got the same sync problem. I've been using AnyDVD to rip the disc before using eac3to on the evo files. Does anyone know if AnyDVD can cause this sync problem?

If not it seems maybe to be a decoder problem? The video is VC1, the audio encoded into flac from the dolby true HD. What are the reccomended codecs for playback of this type?

I've just been installing ffdshow. Thanks for any help.

[Beastie Boy]

Maybe you can modify eac3to to "care" about the order of these 2 switches (slowdown, delay) when they are applied together.

Perhaps I'm being a bit slow here, but I can't think of any occasion when you would want to apply the speed change before applying the delay :confused:
When the video and audio are extracted with the delay automatically applied, you now have an audio file and a video file that are the same duration and in synch. If the same speed change is now applied to both, they will remain in synch. Therefore, even if the audio is done as a 1 step process, the delay should always be applied first.
Or am I missing something?

Cheers, Beastie.

[Beastie Boy]

Thanks for the info! It seems to be a problem w/ my process.

Without knowing your process, it's hard to comment. Re-encoding vc1 video with the Sonic video filters in the Graphedit chain can cause synch to drift.
I do know that it is not a eac3to problem, so perhaps it would be better to discuss your problem in another thread.

Cheers, Beastie.

[madshi]

Thanks for the info! It seems to be a problem w/ my process. I tried w/ Harry Poter 2 also and got the same sync problem. I've been using AnyDVD to rip the disc before using eac3to on the evo files. Does anyone know if AnyDVD can cause this sync problem?

If not it seems maybe to be a decoder problem? The video is VC1, the audio encoded into flac from the dolby true HD. What are the reccomended codecs for playback of this type?

I've just been installing ffdshow. Thanks for any help.
You should really try to find out which filters are being used on your PC. I take it you have remuxed the video to MKV, right? Have you muxed the FLAC track into the MKV, too? Or are you playing the FLAC track externally? Personally, I'm using madFlac for FLAC decoding.

[nautilus7]

Does anyone know if AnyDVD can cause this sync problem?AnyDVD doesn't cause any problems, unless you use the explorer to rip the disc. Then you may end up with corrupted files.

[madshi]

Without knowing your process, it's hard to comment. Re-encoding vc1 video with the Sonic video filters in the Graphedit chain can cause synch to drift.
I do know that it is not a eac3to problem, so perhaps it would be better to discuss your problem in another thread.
Agreed. If the problem is not related to eac3to at all, it would make sense to discuss elsewhere. This thread is long enough as it is already... :)

[nautilus7]

Perhaps I'm being a bit slow here, but I can't think of any occasion when you would want to apply the speed change before applying the delay :confused:
When the video and audio are extracted with the delay automatically applied, you now have an audio file and a video file that are the same duration and in synch. If the same speed change is now applied to both, they will remain in synch. Therefore, even if the audio is done as a 1 step process, the delay should always be applied first.
Or am I missing something?

Cheers, Beastie.Yes you are right.

First, i apply -slowdown and decode the pal track to wav.
Then, i decode to wav the original ntsc track of the movie.
After, i figure out the delay by checking multiple points of the decoded wavs (using an audio editor). I only make dub tracks for animation which is difficult to find the exact delay.
Finally, i encode the final ac3 audio by applying slowdown and delay at one step.

Confused?

[Beastie Boy]

Confused?

Yes :)

[madshi]

First, i apply -slowdown and decode the pal track to wav.
Then, i decode to wav the original ntsc track of the movie.
After, i figure out the delay by checking multiple points of the decoded wavs (using an audio editor). I only make dub tracks for animation which is difficult to find the exact delay.
Finally, i encode the final ac3 audio by applying slowdown and delay at one step.
Slowing down is what consumes the most time. So why don't you reuse the slowed down WAV file from your first step to encode the final AC3 file? You'd only have to slowdown once that way and would save time.

[nautilus7]

The wav file is actually mono wavs (-mono switch, remember?).
But a 2 hour movie won't fit in 6 channel wave because of the 4 GB limit.

I 'll have to re-consider my method, anyway...

[nautilus7]

Yes :)

I know... even i would be!

Assume you have a 23,976 fps track and a pal (25 fps) dub track of an animation movie. And because you have a brain damage (that's me :eek: ) you want to have perfect sync even if you never hear a difference. How would you do it?

I take the original (23,976) track and decode it to wav(s) (center channel is enough) and open it in a wav editor. Then i do the same for the 25 fps dub with slowdown applied.
This way i can compare=find the delay. Actually i check multiple point of the tracks to be sure (the brain damage we were talking :p ) so i need them to be in the same fps (slowdown must be done already).

Hope you understand. Sorry for spoiling the topic.

[nautilus7]

Thanks. Just tested it. The sample size is 11.1MB. Transcoding to FLAC with libav results in 9.68MB. Transcoding to FLAC with Nero also results in 9.68MB for me. Compared the two FLAC files and they are bit identical.

Can your buddy please retest whether he can reproduce the problem with the 10MB sample? Also please let him check whether he's using the latest eac3to version. And let him run "eac3to -test".
He can reproduce the problem with the sample (he gets ~30MB). Uses latest eac3to, -test switch shows nero working ok. He has Vista 64bit.

I also tried the sample. Size ok here. I told him to re-install nero (he has v7.10.1.0 installed)

[nesNYC]

Okay madshi, first I'd like to thank and congratulate you on such a nice tool. So far I've re-encoded about 4 DD+ movies without any issues. DD+ seems to work fine.

Now my only issue is on THE_CHRONICLES_OF_RIDDICK, the track I want to use is DTSHD. When I play the audio track back, it's 2:11:42 in lenght, this coming right off of a EVODemux, demux. The movie, however, is 2:14:04 in length.

I've tried to apply 57ms delay (with eac3to) and try to get the DTS track to be 2:14:04 in length as well but it seems no matter what number I use in delay, when I play the track back it's still it's default time. Does adding delay in eac3to simply put markers for sync or does it actually try and time stretch the files to fit? I've read a lot of pages on this thread but cannot figure this one out. Should be simple right?

What's annoying is that the DTSHD file sounds so much better than the DD+ file and upto 1/3 into the movie, things are pretty much in sync. But by the end there is an amost 2 to 3 second delay, aaarrrhhh, LOL!

Any suggestions?

BTW, I also used the TrueHD -> DTS conversion suing SurCode and it also worked like a charm. I am having no delay issues on anything other than DTS(HD).

[hristoff2]

Try demuxing DTS core (blabla.dtshd blabla.dts -core) and mux the DTS stream with your video. Some DTS tracks have odd runtimes but muxed in matroska they're alright.

[nesNYC]

Yeah, this is the first method I tried (the -core), it was a little slower but I got the same results. Here's the tracks in DD+ and DTSHD as reported by eac3to:


F:\HDAPPS~1\EAC3TO>eac3to "F:\HD Apps\Sandbox\FEATURE_1_MERGED.DTSHD.stream.01.dtshd"

DTS, 5.1 channels, 2:14:31, 24 bits, 1536kbit/s, 48khz

F:\HDAPPS~1\EAC3TO>eac3to "F:\HD Apps\Sandbox\FEATURE_1_MERGED.DD+.stream.00.ddp"

E-AC3, 5.1 channels, 2:14:04, 1536kbit/s, 48khz, dialnorm: -27dB

See the kooky time on the DTS? And if I play that on MPC using AC3 filter or Sonic, they report '2:11:42' as runtime. I'm scratchin' my head so hard I have a bald spot :D

Try demuxing DTS core (blabla.dtshd blabla.dts -core) and mux the DTS stream with your video. Some DTS tracks have odd runtimes but muxed in matroska they're alright.

[madshi]

He can reproduce the problem with the sample (he gets ~30MB). Uses latest eac3to, -test switch shows nero working ok. He has Vista 64bit.

I also tried the sample. Size ok here. I told him to re-install nero (he has v7.10.1.0 installed)
Can't explain it right now. Maybe it's Vista64? Don't know why it should be a problem, though. It would be great if he could find the cause of the problem. But if we fail, he can still use the libav decoder, of course. It's the default decoder, anyway. That said, I do like to find out why Nero decoding fails to work properly...

[madshi]

Yeah, this is the first method I tried (the -core), it was a little slower but I got the same results. Here's the tracks in DD+ and DTSHD as reported by eac3to:


F:\HDAPPS~1\EAC3TO>eac3to "F:\HD Apps\Sandbox\FEATURE_1_MERGED.DTSHD.stream.01.dtshd"

DTS, 5.1 channels, 2:14:31, 24 bits, 1536kbit/s, 48khz

F:\HDAPPS~1\EAC3TO>eac3to "F:\HD Apps\Sandbox\FEATURE_1_MERGED.DD+.stream.00.ddp"

E-AC3, 5.1 channels, 2:14:04, 1536kbit/s, 48khz, dialnorm: -27dB

See the kooky time on the DTS? And if I play that on MPC using AC3 filter or Sonic, they report '2:11:42' as runtime. I'm scratchin' my head so hard I have a bald spot :D
First of all please demux with eac3to and not with EvoDemux. Not sure whether it makes a difference, but there are some movies where EvoDemux corrupts demuxed tracks. Next: How are you playing that DTS track? Are you playing the DTS track as an external file? If so, which DTS source filter are you using? If the DTS track is DTS-HD Master Audio I'd recommend to transcode that to FLAC. I'd recommend to transcode it to AC3 or FLAC for testing purposes, anyway. If the transcoded AC3 or FLAC doesn't have any audio sync issues then you know that the DTS file itself is alright and just the source filter makes trouble. If the transcoded AC3/FLAC file shows the same sync problems then the DTS-HD track is faulty.

[ACrowley]

Try demuxing DTS core (blabla.dtshd blabla.dts -core) and mux the DTS stream with your video. Some DTS tracks have odd runtimes but muxed in matroska they're alright.

It was a problem with old DTS_AC3_DDP Source Filter.
The Runtime from dts core Tracks was ~4 sec wrong and its async.

Madshi SourceFilter (eac3to Folder) can handle extracted dts core Audio Tracks perferctly, with correct Runtime and fully in sync.

[nautilus7]

Can't explain it right now. Maybe it's Vista64? Don't know why it should be a problem, though. It would be great if he could find the cause of the problem. But if we fail, he can still use the libav decoder, of course. It's the default decoder, anyway. That said, I do like to find out why Nero decoding fails to work properly...Nero re installation didn't solve the problem.

I'll stop posting about this now. When my friennd is able to post, he'll continue...

[nesNYC]

Thanks madshi! I'll try some of these steps later when I'm home.

I'm using the file to play right off of the demux track with Sonic and AC3 filters and both report times that are VERY different from what the movie is in lenght and what eac3to reports. BTW, how does eac3to determine the time length? Does it use DTS source filter to determine?

I'll report back in a few hours and see if I can solve this.

:thanks:

First of all please demux with eac3to and not with EvoDemux. Not sure whether it makes a difference, but there are some movies where EvoDemux corrupts demuxed tracks. Next: How are you playing that DTS track? Are you playing the DTS track as an external file? If so, which DTS source filter are you using? If the DTS track is DTS-HD Master Audio I'd recommend to transcode that to FLAC. I'd recommend to transcode it to AC3 or FLAC for testing purposes, anyway. If the transcoded AC3 or FLAC doesn't have any audio sync issues then you know that the DTS file itself is alright and just the source filter makes trouble. If the transcoded AC3/FLAC file shows the same sync problems then the DTS-HD track is faulty.

[nesNYC]

Would that be simple command:

c:\>eac3to <source>.dtshd <destination>.dts

Or is there another command to use (-core?)

It was a problem with old DTS_AC3_DDP Source Filter.
The Runtime from dts core Tracks was ~4 sec wrong and its async.

Madshi SourceFilter (eac3to Folder) can handle extracted dts core Audio Tracks perferctly, with correct Runtime and fully in sync.

[Jaja1]

I want to hexedit a piece out of an EVO. How do I recognize a packet header?

[nautilus7]

Why don't you ask in the appropriate sub forum?

[Chumbo]

@madshi,
If I may request a wish list item as you continue to update this please. Would you consider adding the number of frames on the video codec line please, along with the codec, fps, etc.? Many thanks.