eac3to - audio conversion tool

[Anakunda]

MBAM 2.1.4 Premium uninstalled and ArcSoft is working again

[madshi]

eac3to v3.29 released

http://madshi.net/eac3to.zip

* added libDcaDec decoder for DTS decoding, new default for 7.x tracks
* fixed: #086: left/right eye information was inverted in some 3D Blu-Rays
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed
* fixed: #264: using "-float32 -normalize" didn't work in all cases
There's good and bad news. Let's start with the bad news:

We already knew that "7.1 (strange setup)" DTS-HD Master Audio tracks were not decoded correctly by the ArcSoft decoder. Recently I learned that also some other DTS-HD Master Audio 7.1 tracks may not have been decoded correctly. Basically there are 3 possible speaker configurations for 7.1 MA, one of them is the "strange setup", the other two eac3to has not specifically marked. One of them was decoded perfectly by ArcSoft - but only with some dtsdecoder.dll versions, not with all (with some old 1.1.0.0 versions the surround and back channels were swapped, but otherwise lossless). And one speaker config seems to have been decoded by ArcSoft correctly, but then post-processed, with some mixing going on. Basically this means, to be safe I'd recommend to redo all DTS-HD Master Audio 7.1 tracks. I'm sorry about that, and not very happy myself.

The good news is that there's a new open source DTS decoder (dcadec (https://github.com/foo86/dcadec)) available, which in its current form has the following advantages and disadvantages compared to ArcSoft:

+ it's faster
+ it never post-processes, for any channel/speaker configs
+ it can decode all three 7.1 configurations perfectly
+ eac3to can run multiple decoding tasks in parallel
- it's not that well tested yet
- it doesn't support 192kHz decoding yet
- it doesn't support XSA / LBR low bitrate tracks yet

The latest eac3to build now automatically switches to dcadec for all DTS 7.x tracks. However, because the new decoder isn't that well tested yet, for all other channel configurations ArcSoft is currently still the default decoder option (if it's available, otherwise dcadec becomes default).

I'd like to ask all of you eac3to users to stress-test the new dcadec decoder as much as you can. Throw any and all DTS tracks at it and check whether they decode completely and whether the final results appear to be correct. The decoder is supposed to error out if there's any kind of problem during stream parsing or decoding. So normally we should expect the results to be perfect as long as decoding completes. But I would still like to ask you to double check, just to be safe. You can force eac3to to use dcadec by using the "-dcadec" switch. Or by renaming or deleting the ArcSoft decoder. Please make sure that you really test the dcadec decoder and not accidently ArcSoft. I say this because ArcSoft is still the default decoder, so if you don't take extra care, you'll test ArcSoft instead of dcadec.

If you find any problems, could you please report them directly to the dcadec (https://github.com/foo86/dcadec) developer? The "libdcadec.dll" used by eac3to is a direct compile of the official source code. No patches or other modifications. So as long as the interface stays compatible (and I think it will, even "forever"), you can replace the eac3to libdcadec.dll with your own compilation. So if dcadec improves in some way, you won't need a new eac3to version, just compile a new libdcadec.dll.

[sl1pkn07]

http://www.videolan.org/developers/libdca.html (?)

[madshi]

@sl1pkn07, what are you trying to say? No, that is not the decoder eac3to is using, if that's your question? Click on "dcadec" in my previous post.

[Anakunda]

Is dcadec library up to pair with ArcSoft for quality of decoding?

[madshi]

In theory it should be on par or better. Obviously you can't improve quality for lossless decoding, other than decoding correctly. And there dcadec should be better for 7.1 (because ArcSoft is buggy with that) and on par for all other channel configurations. For lossy decoding I don't know for sure if ArcSoft internally does integer or floating point decoding. If it's integer decoding, dcadec should be slightly superior. Otherwise it might be equal.

[sl1pkn07]

@madashi is not the same project? dcaenc is a fork?

EDIT: https://github.com/foo86/dcadec/issues/15

oks

[Anakunda]

Conversion to Opus went fine :cool: and channel mappings seem same as source however I don't have 7.1 "strange setup"

if out there a movie having strange setup I might give a try tomorrow.

[nevcairiel]

dcadec will silently make strange-setup go away, and decode it perfectly lossless as any other 7.1 sample. :)

[Nebudchanezzer]

Conversion to Opus went fine :cool: and channel mappings seem same as source however I don't have 7.1 "strange setup"

if out there a movie having strange setup I might give a try tomorrow.

eac3to does opus too now?

Tested with the "strange setup"-track from Black Hawk Down and eac3to didn't default to dcadec.

Gonna do some more testing with this track tomorrow.

[Snowknight26]

Does dcadec report decoding errors? If yes, I'll see if I can throw every DTS-HD MA track I have at it to see what fails.

[kasper93]

Yes, eac3to uses strict mode. Decoding will be aborted upon errors. Though best way to test is decode with both ArcSoft and dcadec and compare resulting files. If they are not bit exact, that means one of decoders did something wrong.

[Boulder]

Thanks madshi, will give the new decoder some work to do soon to compare with Arcsoft :)

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.

[Libeluratio]

Hi, thank you madshi for the update.

For my truehd Atmos problem, forget it, it seems that when I extract / convert it into wavs directly from original bluray, the only message I get is the classic "Skipping identical AC3 Frames", and no more the "Lossless check failed" messages.

About the eac3to update, you talked about 7.1 DTS-HD tracks but with 6.1 DTS-HD decoding, did you learn problems with the Arcsoft decoder v1.1.0.0 (that was listed here to be the one to use to bit-perfect decode 6.1 tracks) or any other version of it ?

And for 5.1 DTS-HD tracks, can we stay with any version of Arcsoft decoder ? Thanks !

[madshi]

eac3to does opus too now?

Tested with the "strange setup"-track from Black Hawk Down and eac3to didn't default to dcadec.
No, Opus is not supported directly by eac3to.

Stupid me. I've enabled dcadec by default for the "7.1" and "7.0" channel strings, but not for the "7.1 (strange setup)" channel string. Argh...

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.
Atm, I'm only fixing what is broken (like 7.1 ArcSoft DTS decoding).

About the eac3to update, you talked about 7.1 DTS-HD tracks but with 6.1 DTS-HD decoding, did you learn problems with the Arcsoft decoder v1.1.0.0 (that was listed here to be the one to use to bit-perfect decode 6.1 tracks) or any other version of it ?

And for 5.1 DTS-HD tracks, can we stay with any version of Arcsoft decoder ? Thanks !
AFAIK ArcSoft decodes 5.1 and 6.1 just fine. But please do test and compare.

[Yoshi]

And there dcadec should be better for 7.1 (because ArcSoft is buggy with that) and on par for all other channel configurations.

Maybe I missed something, but for me, the contradiction between your efforts and the one of the MakeMKV developers is still unsolved for me.

I mean, you seem to struggle to workaround one issue or the other, the Arcsoft DTS-decoder allegedly has depending on the version, while the MakeMKV-guys claim "throw in any version of the dtsdecoder.dll and it will be okay".

Furthermore, why does eac3to still require the asaudio.ax filter to be registered in the system (and checkactivate.dll in addition) whereas MakeMKV by a fact only requires the more or less "pure core" of this component?

[Sparktank]

while the MakeMKV-guys claim "throw in any version of the dtsdecoder.dll and it will be okay".

IIRC, MakeMKV works on API level of Arcsoft.
If you search this thread, you'll find several posts that detail the differences.

[Yoshi]

I don't see how this is supposed to answer any of my questions. I know that eac3to and MakeMKV - obviously - access the Arcsoft decoder differently, but that's not the point.

The point is, that eac3to achieves worse results than MakeMKV, at least when it comes to 7.1 strange setups. Apparently, there is a technically better way to access the decoders from Arcsoft and thus the question arises why - without any accusation whatsoever - Madshi isn't able to do it but the MakeMKV-guys somehow are.

I've searched this thread again as you suggested and the last statement from Madshi is this one:

It's quite possible that the Chinese API bit is true. But the only practical consequence is that when picking a good dtsdecoder.dll version, you'll still get 100% bit perfect files with eac3to for 99.9% of all DTS-HD Master Audio files, with the only exception being those rare "strange setup" files, which eac3to explicitly warns you about (so you know when you hit those 0.1%). And even those decode "ok" (just too low volume), as explained by tebasuna51.

[Stereodude]

AFAIK ArcSoft decodes 5.1 and 6.1 just fine. But please do test and compare.
I had a 6.1 DTS-HD MA sample that didn't decode correctly with Arcsoft (but worked fine with hardware decoders in a receiver). I posted about it in the thread back in Sep 2013. I haven't tried it with dcadec yet, but I will soon.

[sl1pkn07]

EDIT: by the way, you might want to replace libFLAC.dll with a more recent one as there's been a new version out for some time now.


Atm, I'm only fixing what is broken (like 7.1 ArcSoft DTS decoding).

and when have a vulnerability?

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8962

eac3to ship a libflac 1.2.1

and the CVE is fixed in 1.3.1 https://xiph.org/flac/changelog.html

[Bigmango]

eac3to v3.29 released


I'd like to ask all of you eac3to users to stress-test the new dcadec decoder as much as you can.

Is there somewhere a list of movies with 7.1 strange setup?

I'm asking because I remember some of my movies had this but I don't remember which ones...

[nevcairiel]

The point is, that eac3to achieves worse results than MakeMKV, at least when it comes to 7.1 strange setups. Apparently, there is a technically better way to access the decoders from Arcsoft and thus the question arises why - without any accusation whatsoever - Madshi isn't able to do it but the MakeMKV-guys somehow are.


It seems pointless to re-hash that discussion now, at the point where we have a free and open-source decoder, which should be superior in all ways once its properly tested.

[Nebudchanezzer]

OK, further tests with the "strange setup"-track from Black Hawk Down:

Decoded the track to wavs using the Sonic decoder and all comparable channels are bitperfect to the ones decoded using dcadec.
For obvious reasons I cannot compare the backchannels this way and I don't have the tools to decode the backchannels properly.

[Stereodude]

I had a 6.1 DTS-HD MA sample that didn't decode correctly with Arcsoft (but worked fine with hardware decoders in a receiver). I posted about it in the thread back in Sep 2013. I haven't tried it with dcadec yet, but I will soon.
So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

It really is DTS-HD MA 6.1 discrete with audio in each channel. Here's what my Denon says about it:

http://i.imgur.com/rdqQN5t.jpg

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

Edit: Here is a 50MB sample (https://www.sendspace.com/file/31nlcl).

[nevcairiel]

So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

And how do you know that both are not correct? :p
It seems unlikely that both would be wrong and then even agree on the wrong-ness.

[Stereodude]

And how do you know that both are not correct? :p
It seems unlikely that both would be wrong and then even agree on the wrong-ness.
Oh, I don't know... Probably because DTS-HD MA capable receivers decode the track correctly. :p

I've tried it on multiple receivers / pre-processors that support DTS-HD MA over HDMI and they all decode a discrete back center channel (with audio in it) as well as not screwing up the LFE.

[tebasuna51]

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite:
A 7.1-L,R,C,LFE,Lss,Rss, Lsr,Rsr
B 7.1-L,R,C,LFE,Ls ,Rs , Lh ,Rh strange
C 7.1-L,R,C,LFE,Ls ,Rs , Lhs,Rhs strange
D 7.1-L,R,C,LFE,Ls ,Rs , Lsr,Rsr strange
E 7.1-L,R,C,LFE,Ls ,Rs , Cs ,Ch strange
F 7.1-L,R,C,LFE,Ls ,Rs , Cs ,Oh strange
G 7.1-L,R,C,LFE,Ls ,Rs , Lw ,Rw (see 3)
H 7.0-L,R,C, ,Lss,Rss, Lsr,Rsr (bug 1)
I 6.1-L,R,C,LFE,Ls ,Rs , Cs discrete
J 6.1-L,R,C,LFE,Ls ,Rs ,(Cs) matrix
K 6.0-L,R,C, ,Ls ,Rs , Cs discrete
L 6.0-L,R,C, ,Ls ,Rs ,(Cs) matrix
M 5.1-L,R,C,LFE,Ls ,Rs
N 5.0-L,R,C, ,Ls ,Rs
O 4.1-L,R, ,LFE,Ls ,Rs
P 4.1-L,R,C,LFE, , , Cs (see 2)
Q 4.0-L,R, , ,Ls ,Rs ,
R 4.0-L,R,C, , , , Cs (see 2)
S 3.1-L,R,C,LFE
T 3.1-L,R, ,LFE, , , Cs (see 2)
U 3.0-L,R,C
V 3.0-L,R, , , , , Cs (see 2)
W 2.1-L,R, ,LFE
X 2.0-L,R
Y 2.0-Lt,Rt
Z 1.0- , ,C mono

See the attached image.
Decoded with ArcSoft (dtsdecoderdll.dll v1.1.0.0 25-04-2008, reject other date), and libdcadec.dll.

1) eac3to-ArcSoft Bug with Layout H (7.0)
eac3to H70.dtshd
-----------------------------------------------------------------
DTS Master Audio, 6.1 channels, 24 bits, 48kHz (Must be 7.0)
(core: DTS, 5.0 channels, 1509kbps, 48kHz) (5.0 ok)

ArcSoft decoded like 7.0 (FL FR FC BL BR SL SR) but with wrong channel mix:
FL = 0.6335 x L + 0.2327 x Lss
FR = 0.6335 x R + 0.2327 x Rss
FC = 0.6335 x C
BL = empty
BR = 0.3890 x Lsr + 0.5892 x Lss
SL = 0.3890 x Rsr + 0.5892 x Rss
SR = 0.5000 x Lsr + 0.5000 x Rsr

DcaDec decoded all ok.

2) Rest of Layouts I-Z (6.1 to 1.0)
Bit identical ouput between ArcSoft and DcaDec. All ok.
Only this 4 have a little difference:

P 4.1-L,R,C,LFE,Cs
R 4.0-L,R,C, ,Cs
T 3.1-L,R, ,LFE,Cs
V 3.0-L,R, , ,Cs

Checked with sources the ArcSoft decoded channel Cs have differences of -79dB
The DcaDec output is bit identical with the source.

3) Layouts A-G (7.1)
I only see in BD's layouts A, D (strange setup) and G (seems the other than madshi say like not specifically marked).
Before to see the problems we must know the Channel equivalence betwenn DTS channels and WAV channels:

DTS WAV Speaker Position
---- --- ---------------------
L = FL Front Left
R = FR Front Right
C = FC Front Center
LFE = LF (Low Frequency (Efects))
Lsr = BL Back Left
Rsr = BR Back Right
(Lw) = FLC Front Left of Center
(Rw) = FRC Front Right of Center
Cs = BC Back Center
Lss = SL Side Left
Rss = SR Side Right
Oh = TC TopCenter
Lh = TFL Top Front Left
Ch = TFC Top Front Center
Rh = TFR Top Front Right
Lhs = TBL Top Back Left
- = TBC Top Back Center
Rhs = TBR Top Back Right
Ls = don't exist (can be replaced by SL or BL)
Rs = don't exist (can be replaced by SR or BR)
Like the pair Ls,Lr don't exist in WAV, the output can be aproximated with the pair SL*SR or BL*BR, but remember than is not exact.

- DcaDec decode losslessly all channel layouts, if we accept the change Ls,Rs to SL*SR, but the ChannelMask must be changed in layouts B,C,E and F. In G we must accept the change Lw,Rw -> SL*SR and Ls,Rs -> BL*BR .
- ArcSoft decode losslessly only the standard A layout, make a mix coherent with ChanelMask 1599 in layouts B,C,D and G, I can't understand the mix in layouts E and F.

Detailed info:

3.A) Layout 7.1-L,R,C,LFE,Lss,Rss,Lsr,Rsr
This is the standard layout and work fine with ArcSoft and DcaDec (bit identical output).
The channel equivalence is correct and match the WAV output ChannelMask 1599 (FL FR FC LF BL BR SL SR)

3.B) Layout 7.1-L,R,C,LFE,Ls,Rs,Lh,Rh
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.5858 x L + 0.4142 x Lh
FR = 0.5858 x R + 0.4142 x Rh
FC = 0.5858 x C
LF = 0.5858 x LFE
BL = 0.2751 x Ls
BR = 0.2751 x Rs
SL = 0.5171 x Ls
SR = 0.5171 x Rs

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
22031 (FL FR FC LFE SL*SR TFL TFR)

3.C) Layout 7.1-L,R,C,LFE,Ls,Rs,Lhs,Rhs
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.6290 x L
FR = 0.6290 x R
FC = 0.6290 x C
LF = 0.6290 x LFE
BL = 0.2954 x Ls
BR = 0.2954 x Rs
SL = 0.5553 x Ls + 0.4447 x Lhs
SR = 0.5553 x Rs + 0.4447 x Rhs

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
165391 (FL FR FC LF SL*SR TBL TBR)

3.D) Layout 7.1-L,R,C,LFE,Ls,Rs,Lsr,Rsr
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.6804 x L
FR = 0.6804 x R
FC = 0.6804 x C
LF = 0.6804 x LFE
BL = 0.6804 x Lsr + 0.3196 x Ls
BR = 0.6804 x Rsr + 0.3196 x Rs
SL = 0.6007 x Ls
SR = 0.6007 x Rs

Whit DcaDec all channels are decoded without remix losslessly but remember than the pair SL*SR is not exactly the Ls,Rs.

3.E) Layout 7.1-L,R,C,LFE,Ls,Rs,Cs,Chs
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 3855
(FL FR FC LF BC SL SR TC)

Decoded by ArcSoft with this mix not coherent with the ChannelMask 3855 or 1559
FL = 0.5858 x L
FR = 0.5858 x R
FC = 0.5858 x C + 0.4142 x Chs
LF = 0.5858 x LFE
BC = 0.5171 x Ls (seems SL)
SL = 0.2717 x Ls + 0.4142 x Cs (seems BL)
SR = 0.2717 x Rs + 0.4142 x Cs (seems BR)
TC = 0.5171 x Rs (seems SR)

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
9999 (FL FR FC LF BC SL*SR TFC)

3.F) Layout 7.1-L,R,C,LFE,Ls,Rs,Cs,Oh
Detected by eac3to like "strange setup" and decoded to WAV with ChannelMask 9999 (FL FR FC LF BC SL SR TFC)

Decoded by ArcSoft with this mix not coherent with the ChannelMask 3855 or 1559
FL = 0.7232 x L
FR = 0.7232 x R
FC = 0.7232 x C
LF = 0.7232 x LFE
BC = 0.6384 x Ls + 0.3616 x Oh (seems SL)
SL = 0.3397 x Ls + 0.5114 x Cs (seems BL)
SR = 0.3397 x Rs + 0.5114 x Cs (seems BR)
TFC= 0.6384 x Rs + 0.3616 x Oh (seems SR)

Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
3855 (FL FR FC LF BC SL*SR TC)

3.G) Layout 7.1-L,R,C,LFE,Ls,Rs,Lw,Rw
Detected by eac3to like standard setup (like A) and decoded to WAV with ChannelMask 1599 (FL FR FC LF BL BR SL SR)

Decoded by ArcSoft with this mix coherent with the ChannelMask 1559
FL = 0.5858 x L + 0.4142 x Lw
FR = 0.5858 x R + 0.4142 x Rw
FC = 0.5858 x C
LF = 0.5858 x LFE
BL = 0.2751 x Ls
BR = 0.2751 x Rs
SL = 0.5171 x Ls + 0.4142 x Lw
SR = 0.5171 x Rs + 0.4142 x Rw

[Whit DcaDec all channels are decoded without remix losslessly but the channelmask must be changed to:
1743 (FL FR FC LF FLC FRC SL*SR)]
EDIT:
I accept madshi comment in http://forum.doom9.org/showthread.php?p=1714925#post1714925
Then:
Whit DcaDec all channels are decoded without remix losslessly and the channelmask 1599 (FL FR FC LF BL BR SL SR), not exact because we make the equivalences:
Lw,Rw -> SL*SR
Ls,Rs -> BL*BR

[tebasuna51]

Edit: If someone can enlighten me how to trim the DTS-HD MA track I can provide a sample.
Easy, if you want trim the first 56 MB
eac3to original.dthd trim.dts -56mb

[nautilus7]

Great work tebasuna!

[tebasuna51]

@madshi
Thanks for the new version, checked also my request:
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed

[Stereodude]

Easy, if you want trim the first 56 MB
eac3to original.dthd trim.dts -56mb
Okay, thanks. I've added a sample.

[nevcairiel]

3.G) Layout 7.1-L,R,C,LFE,Ls,Rs,Lw,Rw
Whit DcaDec all channels are decoded without remix lossely but the channelmask must be changed to:
1743 (FL FR FC LF FLC FRC SL*SR)

This is done intentionally on madshi's request.

The main argument is that FLC/FRC are not the correct channels, because FLC/FRC are the 15° speakers (FL/FR are 30°), which sit between the front center and the front left/right speakers.
That is the wrong spatial order for Lw/Rw, so using SL/SR BL/BR is the closest we can get with the correct spatial order!

I haven't tested any of the setups with height channels myself, but real-world sources probably don't exist for that anyway.

[nevcairiel]

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

I don't know about the back channel, but having high frequencies in the LFE channel is unfortunately not entirely uncommon in DTS-HD.
Your receiver probably just applies a low-pass filter to get rid of them again.

Receivers are a black box unfortunately, so using them as a "reference" is not easy to validate. Who knows if thats lossless to the source?

[Stereodude]

I don't know about the back channel, but having high frequencies in the LFE channel is unfortunately not entirely uncommon in DTS-HD.
Your receiver probably just applies a low-pass filter to get rid of them again.

Receivers are a black box unfortunately, so using them as a "reference" is not easy to validate. Who knows if thats lossless to the source?
I understand that high frequency energy can end up in the LFE channel in the lossless formats because they're not band limited. I tried to EQ out the content above 120Hz with a 120dB per octave filter at 120Hz from the LFE channel, but it's still hard to tell how similar the core's LFE and the filtered lossless DTS-HD MA LFE is.

Also of note is that dcadec, libav, and arcsoft don't decode the core correctly either. The back center is still empty. There is most definitely a back center channel full of content in the mix that various receivers decode and output that the various software decoders do not.

[nevcairiel]

Or your receivers just decide to mix something in there. Its impossible to know, unfortunately.
Another software decoder that produces the result you are expecting would at least be something that can be investigated more easily.

[Stereodude]

Or your receivers just decide to mix something in there. Its impossible to know, unfortunately.
Another software decoder that produces the result you are expecting would at least be something that can be investigated more easily.
Right, external HW from Denon, Pioneer, & Sherbourn that's conformance tested must have bugs (and the exact same one that creates a channel out of thin air) while open source software that's reversed engineered is perfect. That's clearly the most logical explanation. ;)

Look, as requested, I'm providing a sample that doesn't decode as expected. If no one wants to investigate that's not on me.

[Bigmango]

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite:


Thanks, now that we have open source I hope you've filed a bug report with dcadec for the few issues.

[Nebudchanezzer]

Look, as requested, I'm providing a sample that doesn't decode as expected.

Looked through the last pages here but I couldn't find a sample, or are you about to post it...?
Thought I could atleast try and decode it with Sonic and Makemkv and see what result they output.

EDIT: Looked a bit closer an found it!

EDIT2: Dude, whats up with posting executables, chrome blocked it directly.

EDIT3: Second try did not generate an executable....

EDIT4: Sonic, Arcsoft (1.1.0.0), and dcadec all produce bitperfect track.
Next, I'm gonna play it via my receiver and see what happens.

[Sparktank]

EDIT2: Dude, whats up with posting executables, chrome blocked it directly.

EDIT3: Second try did not generate an executable....

That's SendSpace at work.
With most free file hosts, you have to be absolutely sure what you click next is indeed what you intend to click.

Most free file hosts also have their own free downloader tool, which is often checked by default (if you don't have adblock and other security plugins enabled/installed).

Chrome also blocks a lot of things these days, even for anything legit on SourceForge.

[Sparktank]

So dcadec doesn't decode this particular 6.1 DTS-HD MA track correctly either. It is bit identical to the Arcsoft's output though. :(

However, both Arcsoft and dcadec output an empty back center channel and seems to mess up the LFE channel (there's a bunch of high frequency content in it and it has an overall low volume [very different from decoding the core]).

Edit: Here is a 50MB sample (https://www.sendspace.com/file/31nlcl).

You should also really use the bug tracker, too.
http://eac3to.bugs.madshi.net/

[madshi]

Oh, I don't know... Probably because DTS-HD MA capable receivers decode the track correctly. :p

I've tried it on multiple receivers / pre-processors that support DTS-HD MA over HDMI and they all decode a discrete back center channel (with audio in it) as well as not screwing up the LFE.
Is your speaker setup 6.1 or 7.1? Have you disabled any surround processing and Audyssey etc in your receiver?

Thanks, now that we have open source I hope you've filed a bug report with dcadec for the few issues.
In this case it might actually be eac3to's fault. eac3to is currently overwriting the WAV channel mask provided by dcadec.

Test with all of Channel Layouts obtained with DTSHD Master Audio Suite
Thanks very much! :)

You often wrote "lossely". What do you mean with that? I think you rather meant "losslessly"? Or did you mean "lossy" which would be the opposite of "losslessly"?

Would you mind providing the test files you were using for these tests? They would be useful for me, and probably also for the dcadec developer.

Before to see the problems we must know the Channel equivalence betwenn DTS channels and WAV channels
I don't agree with that table. DTS channels "Lw" and "Rw" are defined as 60° in the DTS spec, which is absolutely not how I understand "Front Left/Right of Center". Instead I would say that the DTS channels "Lc" and "Rc" are 15° which I would say is what WAV FLC and FRC mean.

So IMHO all those three typical 7.1 speaker channel configurations which we often see in Blu-Rays should map exactly the way they do now. And I also believe there should be no processing applied to them. I don't think the encoding houses are actually aiming for specific angles when they encode the tracks. I think they're rather rolling the dice and they always choose the layout they usually do, or by random. I think the three different 7.1 speaker channel configurations in real life make no difference.

All those weird channel configurations with height speakers etc are definitely incorrect in eac3to. That's most probably my fault, not the fault of dcadec. It would be great if you could create a bug entry for that, so I won't forget about it the next time I work on eac3to.

So your final conclusion would be that dcadec has losslessy decoded all tracks, and the only problem you found were channel masks you were not fully happy with? Ok, to be honest, I'm not sure how to handle those speaker configs with height channels. But I've never seen any such track in real life on any Blu-Ray yet, so it's probably not overly important.

[tebasuna51]

The main argument is that FLC/FRC are not the correct channels, because FLC/FRC are the 15° speakers (FL/FR are 30°), which sit between the front center and the front left/right speakers.
That is the wrong spatial order for Lw/Rw, so using SL/SR BL/BR is the closest we can get with the correct spatial order!

Then you sugest:

Lw,Rw (-+45º) -> SL,SR (-+90º-110º)
Ls,Rs (-+120º) -> BL,BR (-+150º)

Maybe is better
Lw,Rw (-+45º) -> FL,FR (-+30º)
L,R (-+30º) -> FLC,FRC (-+15º)
with a remap -4,5,2,3,0,1,6,7 and channelmask 1743

BTW, with this sources I recommend make a downmix to 5.1
FL = L + Lw
FR = R + Rw

[madshi]

Then you sugest:

Lw,Rw (-+45º) -> SL,SR (-+90º-110º)
Ls,Rs (-+120º) -> BL,BR (-+150º)

Maybe is better
Lw,Rw (-+45º) -> FL,FR (-+30º)
L,R (-+30º) -> FLC,FRC (-+15º)
with a remap -4,5,2,3,0,1,6,7 and channelmask 1743
The DTS channels we're talking about are C L R Ls Rs LFE Lw Rw, which are: 0°, 30°, 60°, 110°, as far as I understand. The WAV channels don't have a specific angle assigned to them, so we can only guess what they mean. I would say we should assign the recommended 7.1 speaker angles to them, as a reasonable approximation. So WAV channels FL FR FC LFE SL SR BL BR would map to 0°, 22-30°, 90-110°, 135-150°. We don't have a WAV channel which maps to 60°. So I believe the best match is to assign DTS 0°, 30°, 60°, 110° to WAV 0°, 30°, 90-110°, 135-150°. Yes, it's not an exact match, but I think it's a reasonable choice. The only other reasonable choice would be to remap L/R to FLC/FRC and to remap Lw/Lw to FL/FR. But if we do that we flatten the surround sound. The Lw/Rw channels are supposed to create some sort of "surround" feeling. If we assign them to FL/FR, 5 of the 7 channels are just creating a more detailed stereo field with no surround feeling at all. I don't think that makes a lot of sense.

Furthermore, as mentioned before: I don't think movie studios are doing separate mixes for separate encoding houses. I think movie studios are likely sending their 7.1 masters to the encoding houses, and they just pick "by random" either PCM, TrueHD or DTS-MA. And if they decide to use DTS-MA, they probably by random select one of the 3 different speaker configs. I don't think the encoding houses are remixing the audio master they got from the studio, based on which speaker config in the DTS-MA is selected. I don't have proof for this, but I think this is very likely. So choosing the same normal WAV channel mask for all these 3 DTS speaker assignments is IMHO the best solution in real life, although it does mean we're "ignoring" the exact speaker angles encoded in the DTS-MA stream. But as I said, I don't think they have any meaning in real life (= Blu-Ray), anyway.

[Stereodude]

Is your speaker setup 6.1 or 7.1? Have you disabled any surround processing and Audyssey etc in your receiver?
Speaker setup is 7.1. AFAIK, DTS-ES duplicates the back center to the back left and back right in such a setup. I've tested this sample on both my Pioneer Elite and Denon with all processing disabled (even bass management & time alignment) using Pure Direct. There are no silent speakers.

It should be easy to eliminate possibility of a receiver/processor bug for this clip. Someone with the DTS encoder can encode the lossless output from dcadec (or Arcsoft) back to a DTS-ES discrete core + DTS-HD MA stream and I can play it back through my receiver and see if the rear channels are silent or not.

[Nebudchanezzer]

Speaker setup is 7.1. AFAIK, DTS-ES duplicates the back center to the back left and back right in such a setup. I've tested this sample on both my Pioneer Elite and Denon with all processing disabled (even bass management & time alignment) using Pure Direct. There are no silent speakers.

It should be easy to eliminate possibility of a receiver/processor bug for this clip. Someone with the DTS encoder can encode the lossless output from dcadec (or Arcsoft) back to a DTS-ES discrete core + DTS-HD MA stream and I can play it back through my receiver and see if the rear channels are silent or not.

From my tests:
eac3to + arcsoft (1.1.0.0), Sonic and dcadec all decode it bitperfect to each other.

Looking at the individual decoded channels one can clearly see there is an empty channel where center-back is supposed to be. ( http://someimage.com/4TQkHVH)
On the other hand the LFE-channel is absolutely not only LFE, listening to it individually it sounds like any other channel (badly mastered, authored track maybe...)

I haven't actually listened to the sample provided yet through my receiver.

So thats left to do, using "True Direct" or whatever Marantz call it.

EDIT: As this is an eac3to-thread, I would kindly ask if there is an easy possibilty to add support for opus-encoding, from the tests I've seen on avs-forum opus outperforms mp3 and AAC.

[tebasuna51]

...So I believe the best match is to assign DTS 0°, 30°, 60°, 110° to WAV 0°, 30°, 90-110°, 135-150°...
Ok, but, like DcaDec decode lossely all the channels, each user can do the mix or changes at their preference.

For that the more important question is identify the channel layout. We can't mistake the A layout with the G layout or all the rest with "strange".

Can eac3to supply this info?

[madshi]

Speaker setup is 7.1. AFAIK, DTS-ES duplicates the back center to the back left and back right in such a setup. I've tested this sample on both my Pioneer Elite and Denon with all processing disabled (even bass management & time alignment) using Pure Direct. There are no silent speakers.

It should be easy to eliminate possibility of a receiver/processor bug for this clip. Someone with the DTS encoder can encode the lossless output from dcadec (or Arcsoft) back to a DTS-ES discrete core + DTS-HD MA stream and I can play it back through my receiver and see if the rear channels are silent or not.
The 6.1 back center channel in supposed to be exactly in the middle of the back wall. While the 7.1 back channels are supposed to be nearer to the corners of the back wall. Because of that I think it's likely that the receivers are trying to simulate a 6.1 speaker setup by mixing the surround channels and the back center channel for playback on the 7.1 back channels. So I think what you're hearing is probably the surround channels being mixed into the 7.1 back channels. But of course this is only a guess.

There are 2 ways how we could test this:

1) You could temporarily convert your setup to 6.1. Not sure if you'd be willing to do that, considering that you'd have to modify your receiver setup etc, and you might lose Audyssey calibration etc.

2) Does anybody have a 6.1 channel test DTS-MA file? Playing this back on your receiver should also be interesting. You would learn exactly which 6.1 DTS-MA channel is played back by your receiver on which speaker(s).

Ok, but, like DcaDec decode lossely all the channels, each user can do the mix or changes at their preference.

For that the more important question is identify the channel layout. We can't mistake the A layout with the G layout or all the rest with "strange".

Can eac3to supply this info?
So basically you'd like eac3to to print out the DTS speaker config? That should be very easy. You can already use "-logdts" to get the speaker config right now. I'd just have to copy the information (maybe is somewhat prettier form) to the default output.

EDIT: As this is an eac3to-thread, I would kindly ask if there is an easy possibilty to add support for opus-encoding, from the tests I've seen on avs-forum opus outperforms mp3 and AAC.
I don't have the time to add new features atm, unless they're absolutely crucial for basic Blu-Ray remuxing.

[SeeMoreDigital]

2) Does anybody have a 6.1 channel test DTS-MA file? Playing this back on your receiver should also be interesting. You would learn exactly which 6.1 DTS-MA channel is played back by your receiver on which speaker(s).

The Star Wars 3-disc-set of IV, V and VI are all encoded with DTS-HD MA 6.1 ;)

[madshi]

Yeah, but those are not channel test files. For testing it would be crucial to have a 6.1 DTS-MA file where every channel is played sequentially like "this is the left channel", "this is the right channel" etc.

[tebasuna51]

2) Does anybody have a 6.1 channel test DTS-MA file? Playing this back on your receiver should also be interesting. You would learn exactly which 6.1 DTS-MA channel is played back by your receiver on which speaker(s).
Channel test 6.1 discrete sample: https://www.sendspace.com/file/l724qo

So basically you'd like eac3to to print out the DTS speaker config? That should be very easy. You can already use "-logdts" to get the speaker config right now. I'd just have to copy the information (maybe is somewhat prettier form) to the default output.

I forget check the "-logdts". Show:
A71 - activeSpeakers C L R LFE Lsr Rsr Lss Rss ($84b)
B71 - activeSpeakers C L R Ls Rs LFE Lh Rh ($2f)
C71 - activeSpeakers C L R Ls Rs LFE Lhs Rhs ($200f)
D71 - activeSpeakers C L R Ls Rs LFE Lsr Rsr ($4f)
E71 - activeSpeakers C L R Ls Rs LFE Cs Ch ($9f)
F71 - activeSpeakers C L R Ls Rs LFE Cs Oh ($11f)
G71 - activeSpeakers C L R Ls Rs LFE Lw Rw ($40f)

For me is enough than you include:
(Layout $84b)
(Layout $2f)
(Layout $200f)
(Layout $4f)
(Layout $9f)
(Layout $11f)
(Layout $40f)

Or:
(C L R LFE Lsr Rsr Lss Rss)
(C L R LFE Ls Rs Lh Rh)
(C L R LFE Ls Rs Lhs Rhs)
(C L R LFE Ls Rs Lsr Rsr)
(C L R LFE Ls Rs Cs Ch)
(C L R LFE Ls Rs Cs Oh)
(C L R LFE Ls Rs Lw Rw)

instead (strange setup)