Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
27th November 2008, 23:27 | #7161 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
I disagree. What you suggest is complicated, time consuming and results in an MKV file which has suboptimal timestamps.
If the target container is MKV, there's no reason not to use eac3to for VC-1 muxing. Actually eac3to will give you optimal results. You can't get any better VC-1 MKV than those created by eac3to, as far as I'm aware. Muxing to TS is another topic. It might be true that letting eac3to demux to a raw video stream is preferable if you want to create a TS with tsMuxeR. But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to. Last edited by madshi; 27th November 2008 at 23:29. |
27th November 2008, 23:27 | #7162 | Link | |
Registered User
Join Date: Aug 2002
Posts: 221
|
Quote:
i doubt that Arcsoft will fix it soon, if fix it at all, e.g. Arcsoft do not decode correctly also all DTS-HD MA 7.1 16bit samples that i have in GraphEdit, but at least Arcsoft+eac3to decode them correctly. |
|
27th November 2008, 23:35 | #7165 | Link | |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
The problem with TrueHD -> MKV muxing is simply that it's a totally separated codec. DTS-HD streams are muxed just like DTS streams are, so that was easy. Muxing TrueHD requires a whole new definition of how to do it exactly in MKV. |
|
28th November 2008, 00:09 | #7167 | Link | |
Registered User
Join Date: Aug 2002
Posts: 221
|
Quote:
if you look with hex editor in dtsdecoderdll.dll (Arcsoft), CinemasterAudio.dll (Sonic) and dtshddec.dll (Corel WinDVD9) you can find the version of the DTS Labs DTS-HD decoding library with which the corresponding DLL is linked. Arcsoft uses the most recent version of all of these 3 DLLs, but it's still old compared to the version that DTS Labs DTS-HD MAS suite version 1.6 is using. so, i'm under the impression that when DTS Labs make newer version of the DTS-HD decoding library they don't supply it to their customers of the old versions of the library for free, otherwise i can't understand why Arcsoft, Sonic and Corel don't update the version they are using to the latest one, but instead they use old versions. Last edited by xkodi; 28th November 2008 at 00:22. |
|
28th November 2008, 00:23 | #7168 | Link |
Registered User
Join Date: Sep 2006
Posts: 2,197
|
frankly said never tried it. i thought it was only used for eac3 decoding, didnt know I can use it to play dts-hd ma tracks as well. it plays them completely without drc, dialnorm; this is only applied for (e)ac3?
Last edited by Thunderbolt8; 28th November 2008 at 01:36. |
28th November 2008, 01:24 | #7169 | Link | |
Registered User
Join Date: Oct 2007
Posts: 13
|
Quote:
Have any changes been made to eac3to recently which change the header info in an .mkv video stream which may now be confusing tsMuxeR? |
|
28th November 2008, 03:17 | #7171 | Link | |
Registered User
Join Date: Mar 2007
Posts: 46
|
I sent Mosu (the mkvtoolnix maintainer) an email about this a couple months ago, asking if he was planning on adding TrueHD support. His response was not quite what I was hoping for...
Quote:
|
|
28th November 2008, 09:14 | #7172 | Link | |||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
The bigger problem is that there's no specification as of yet on how TrueHD should be stored in MKV. And it's not up to Mosu to make up such a specification himself. |
|||
28th November 2008, 12:09 | #7173 | Link |
Registered User
Join Date: Mar 2007
Posts: 217
|
Hi!
I just finished converting a True-HD track from HD DVD (Patch Adams) to lpcm and got this strange result: Code:
[a04] Original audio track, L+R+C+LFE: constant bit depth of 16 bits. [a04] Original audio track, SL+SR: constant bit depth of 24 bits. How should I treat the resulting lpcm track for further processing - as 16 or 24 bit? Greets S. |
28th November 2008, 12:40 | #7175 | Link | |
Registered User
Join Date: Aug 2002
Posts: 221
|
Quote:
same applies to Corel and Arcsoft with only the difference that Corel uses more recent version of the DTS-HD decoding lib than Sonic and Arcsoft uses more recent version than Corel, but still Arcsoft version is far from the latest that DTS-HD MAS uses. i look at this few month ago i and don't remember the exact version of the DTS lib that each DLL is using, but it was DTS-HD MAS > Arcsoft > Corel > Sonic. maybe, i will look at this again and post a table here in format "dll -> dts lib version". |
|
28th November 2008, 13:39 | #7176 | Link | ||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Of course the surround channels are slightly less important than the left/center/right channels. So you could also say since the more important channels are only 16bit, anyway, you can use "-down16" to convert the whole track to 16bit. However, doing this will result in eac3to applying dither to the main channels, too, unfortunately. So I'd recommend to keep the track as 24bit. |
||
28th November 2008, 19:30 | #7179 | Link | |
use 'r'
Join Date: Feb 2008
Posts: 230
|
Quote:
|
|
28th November 2008, 19:51 | #7180 | Link |
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
That'd be hard to realize. If you do "-down16" eac3to doesn't know yet which channel has which true bitdepth. So eac3to would have to apply dithering. Only at the end of the whole processing eac3to would notice "ooops, some of those channels were only 16bit to begin with" and thus would have to redo the whole processing from the get go. That's quite complicated and honestly I don't really think it's worth the effort...
|
Tags |
eac3to |
|
|