[madshi]

Originally Posted by KevinMcPool

Sorry madshi unfortunately 3.01 doesnt produce a log when i ask it to convert dtshd to lpcm from the seamless branching titles

My fault. Will be fixed in the next build.

Originally Posted by KevinMcPool

2.87-builds the lpcm file from the dtshd but then deletes it at the point of the required second pass leaving only a log file with the error message "The temp file could not be interpreted correctly"

Will be fixed in the next build.

Originally Posted by canTsTop

here is sample http://www.mediafire.com/file/kynimztnjwe/333_0_0.ts (~65mb), duration is 3mn 34s, but after i demux it with eac3to, its only few seconds
here is log http://www.paste.lt/paste/092a823690...e882c9b04966a3
it says The source file is encrypted. <WARNING>, but its not encrypted

here is another 2 samples with many errors http://www.mediafire.com/file/iqom3m...th_errors_2.ts (10mb) and http://www.mediafire.com/?zumjnyzywdy (24mb)
after i dumux them, audio is few seconds shorter then mediainfo reported on TS. is this normal?

can this tool repair video? thank you.

Thanks for the samples, but as mbcd already hinted, these files seem to be severely damaged, or maybe only partially decrypted. eac3to can not repair any such errors. It can only skip over errors. Which means that if the source is so much damaged, the output of eac3to can be much shorter than the source file claims to be. There's nothing I can do about that. eac3to's error tolerance just means that *minor* errors in a source file are properly ignored now (not repaired). If you have a really strongly damaged source file, just trash and rerecord.

Originally Posted by nautilus7

Do you mean w/o dts encoding? It is possible. Just do eac3to input.wav output.dts. If the wav is dtswav then the wav header will be stripped and you'll get raw dts file.

P.S maybe you need -768 if your dtswav is 768kbps, but i'm not sure.

The switch is not necessary. eac3to never reencodes, unless you ask it to.

Normally eac3to does detect dtswav automatically, but there are cases where the detection does not work. Maybe I can improve on that in a future version. For now you can use DtsParser to convert dtswav files to dts. And eac3to can then in any case decode them (if needed).

Originally Posted by jj666

Found a strange error with 3.01 whilst remuxing two VC1 HD-DVDs I had, Shaun Of The Dead and Motorhead Stage Fright.

Demuxing the video stream (and removing pulldown) with 3.01 produces an un-usable file reported as 8168:6118p in TSMUXER. No problem at all with 2.87 and the same file/settings - reported as 1920:1080p in TSMUXER.

Originally Posted by ragboy

I am having the same problem with Apollo 13, and another title

Originally Posted by Snowknight26

I can confirm it.

Originally Posted by sidekick2

I can confirm that vc1 pulled from Bourne Ultimatum hd-dvd also shows up as 8168x6188 res, and won't play in anything when muxed in tsmuxer.

Sorry guys, BAD bug. Will be fixed in next build.