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.

 

Go Back   Doom9's Forum > General > Audio encoding

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 27th November 2008, 23:27   #7161  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by rica View Post
If your final container will be an mkv, i'd advise this way
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.
madshi is offline  
Old 27th November 2008, 23:27   #7162  |  Link
xkodi
Registered User
 
Join Date: Aug 2002
Posts: 221
Quote:
Originally Posted by madshi View Post
It seems so. I'm not sure how many different movies are out there with such tracks, but at least one movie is. Unfortunately I'm not in a position to fix this. It's technically too complicated. The only proper solution would be for people who have licensed ArcSoft and who own such a problematic 7.1 Blu-Ray disc to report the problem to ArcSoft and ask them for a DTS-HD decoder fix.
yes, you mentioned before that patching DTS-HA MA headers is too complicated, because of the variable frame size if i remember correctly.

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.
xkodi is offline  
Old 27th November 2008, 23:31   #7163  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by itsancho View Post
yep! and i'm waiting for TrueHD support, too...
theres some ironie, mkvmerge can mux DTS-HD MA, but theres no directshow decoder for it yet. but ffdshow supports thruehd support (soon), yet we cannot mux it yet
Thunderbolt8 is offline  
Old 27th November 2008, 23:34   #7164  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by xkodi View Post
i doubt that Arcsoft will fix it soon, if fix it at all
Not sure about that. Has anybody even brought this problem to ArcSoft's attention yet? Of course they won't fix it, if nobody reports it...
madshi is offline  
Old 27th November 2008, 23:35   #7165  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Thunderbolt8 View Post
theres some ironie, mkvmerge can mux DTS-HD MA, but theres no directshow decoder for it yet.
Doesn't the Sonic decoder work just fine? (Of course limited to 5.1, but still?)

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.
madshi is offline  
Old 27th November 2008, 23:40   #7166  |  Link
rica
Registered User
 
Join Date: Mar 2008
Posts: 2,021
Quote:
Originally Posted by madshi View Post
But if that's the case, it's caused by a bug in tsMuxeR and not by eac3to.
Sorry but did i tell something like this?

I just wanted to share my experience; that's all.

Code:
 which has suboptimal timestamps.
i disagree either.
rica is offline  
Old 28th November 2008, 00:09   #7167  |  Link
xkodi
Registered User
 
Join Date: Aug 2002
Posts: 221
Quote:
Originally Posted by madshi View Post
Not sure about that. Has anybody even brought this problem to ArcSoft's attention yet? Of course they won't fix it, if nobody reports it...
actually, i believe that ArcSoft can't fix anything about DTS-HD MA decoding, they just buy the DTS-HD decoding library from DTS Labs and use it.

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.
xkodi is offline  
Old 28th November 2008, 00:23   #7168  |  Link
Thunderbolt8
Registered User
 
Join Date: Sep 2006
Posts: 2,197
Quote:
Originally Posted by madshi View Post
Doesn't the Sonic decoder work just fine? (Of course limited to 5.1, but still?)
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.
Thunderbolt8 is offline  
Old 28th November 2008, 01:24   #7169  |  Link
gillie
Registered User
 
Join Date: Oct 2007
Posts: 13
Quote:
Originally Posted by madshi View Post
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.
Thanks Madshi. I have to agree that using eac3to to create .mkv video stream has always worked flawlessly for me. Likewise using it to create DTS audio stream from lossless audio on original Blu-ray source works great as well. My preference would always be this route and then use MKVmergeGUI to create single .mkv file, however the DViX M6500 is absolutley hopeless at streaming .mkv files with high bit rates, i.e. 20Mbps+ hence my reason for using .ts which the DViX plays without a problem even though the video and audio steams are identical to those in the .mkv container.

Have any changes been made to eac3to recently which change the header info in an .mkv video stream which may now be confusing tsMuxeR?
gillie is offline  
Old 28th November 2008, 01:38   #7170  |  Link
rica
Registered User
 
Join Date: Mar 2008
Posts: 2,021
Quote:
Think it may be the latest versions of eac3to which are producing odd .mkv files.
Who told this? Me?
rica is offline  
Old 28th November 2008, 03:17   #7171  |  Link
Nullity
Registered User
 
Join Date: Mar 2007
Posts: 46
Quote:
Originally Posted by madshi View Post
MKV doesn't support TrueHD (yet?).
Quote:
Originally Posted by itsancho View Post
yep! and i'm waiting for TrueHD support, too...
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:
Probably not. I don't have specs for Dolby TrueHD, nor do I have such files.

Regards,
Mosu
I have no idea if he has changed his stance, but madshi, you have much greater influence in this area, perhaps you could convince him or give him a hand?
Nullity is offline  
Old 28th November 2008, 09:14   #7172  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by xkodi View Post
actually, i believe that ArcSoft can't fix anything about DTS-HD MA decoding, they just buy the DTS-HD decoding library from DTS Labs and use it.
May be true. But I'm not fully sure. E.g. do they get source code from DTS or just a static lib to link with? Also I'm not sure if it's really the decoder which is lowering the volume or if it's ArcSoft's own post processing...

Quote:
Originally Posted by Thunderbolt8 View Post
it plays them completely without drc, dialnorm; this is only applied for (e)ac3?
Yes. BUT the decoder is slow and limited to 5.1. And I'm not sure if it accepts the Haali Media Splitter as input.

Quote:
Originally Posted by gillie View Post
Have any changes been made to eac3to recently which change the header info in an .mkv video stream which may now be confusing tsMuxeR?
No, not at all. But I've heard multiple times that tsMuxeR generally doesn't like VC-1 MKVs. Don't know if that's true. And I really don't care much.

Quote:
Originally Posted by Nullity View Post
I have no idea if he has changed his stance, but madshi, you have much greater influence in this area, perhaps you could convince him or give him a hand?
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.
madshi is offline  
Old 28th November 2008, 12:09   #7173  |  Link
Momber
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 can a track have a bit depth of 16 and 24 bits at the same time?
How should I treat the resulting lpcm track for further processing - as 16 or 24 bit?

Greets
S.
Momber is offline  
Old 28th November 2008, 12:18   #7174  |  Link
banker_rishad
Registered User
 
Join Date: Mar 2008
Posts: 12
Guides plz

Can anybody help with eac3to guides like to how to%. Step by step guide. madshi plz advise
banker_rishad is offline  
Old 28th November 2008, 12:40   #7175  |  Link
xkodi
Registered User
 
Join Date: Aug 2002
Posts: 221
Quote:
Originally Posted by madshi View Post
May be true. But I'm not fully sure. E.g. do they get source code from DTS or just a static lib to link with?
static lib for sure, DTS Labs will never give them source code. also, i think that when you buy license for the DTS decoding lib, seems you get license only for particular version and not for the future updated versions, because for example let's take Sonic - in all version of their decoder DLL (the latest version of CinemasterAudio.dll 4.3.0.230 is only 1-2 months old) they always link to the same version of the DTS decoding lib and it is very old version.

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".
xkodi is offline  
Old 28th November 2008, 13:39   #7176  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Momber View Post
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 can a track have a bit depth of 16 and 24 bits at the same time?
TrueHD always decodes to 24bit. A "16bit" TrueHD track also decodes to 24bit, but has the lower 8 bits zeroed out. So with this specific movie, obviously the surround channels have a true bitdepth of 24bit (all 24bits being made use of) while the other channels have the 8 lower bits zeroed out.

Quote:
Originally Posted by Momber View Post
How should I treat the resulting lpcm track for further processing - as 16 or 24 bit?
If you want to conserve the full quality you should treat it as 24bit track. E.g. FLAC compression will still work very well. The final FLAC filesize will be somewhere between a typical 16bit and a typical 24bit FLAC size.

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.
madshi is offline  
Old 28th November 2008, 14:36   #7177  |  Link
Momber
Registered User
 
Join Date: Mar 2007
Posts: 217
Thanks for your reply madshi!
I will treat it with pcm2tsmu as 24 bit... let's see how that works...
Momber is offline  
Old 28th November 2008, 15:31   #7178  |  Link
siella
Registered User
 
siella's Avatar
 
Join Date: Mar 2007
Location: Turkey
Posts: 66
I ask convert dts audio from here
siella is offline  
Old 28th November 2008, 19:30   #7179  |  Link
n0mag!c
use 'r'
 
n0mag!c's Avatar
 
Join Date: Feb 2008
Posts: 230
Quote:
Originally Posted by madshi View Post
TrueHD always decodes to 24bit. A "16bit" TrueHD track also decodes to 24bit, but has the lower 8 bits zeroed out.
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.
Maybe you can implement "smart" "-down16"-switch behaviour then? Which will truncate lower 8 bits instead of making "standard TPDF dithering" for these channels? Or there are hidden disadvantages?
n0mag!c is offline  
Old 28th November 2008, 19:51   #7180  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by n0mag!c View Post
Maybe you can implement "smart" "-down16"-switch behaviour then? Which will truncate lower 8 bits instead of making "standard TPDF dithering" for these channels? Or there are hidden disadvantages?
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...
madshi is offline  
Closed Thread

Tags
eac3to

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 05:35.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.