eac3to - audio conversion tool

[madshi]

Originally Posted by Stereodude

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

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?

Originally Posted by Bigmango

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.

Originally Posted by tebasuna51

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.

Originally Posted by tebasuna51

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]

Originally Posted by nevcairiel

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]

Originally Posted by tebasuna51

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]

Originally Posted by madshi

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]

Originally Posted by Stereodude

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]

Originally Posted by madshi

...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]

Originally Posted by Stereodude

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).

Originally Posted by tebasuna51

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.

Originally Posted by Nebudchanezzer

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]

Originally Posted by madshi

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]

Originally Posted by madshi

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)

[tebasuna51]

Originally Posted by Nebudchanezzer

EDIT: As this is an eac3to-thread, I would kindly ask if there is an easy possibilty to add support for opus-encoding...

You can use the STDOUT from eac3to to opus-encode.
There are many encoders than can be used this way (Lame, oggenc, ffdcaenc, qaac, ...) eac3to can't support all parameters needed for all encoders.

Use for instance:

eac3to input stdout.wav | opusenc --ignorelength --bitrate 96 - output.opus

(use full paths for eac3to, input, opusenc and output.opus if there aren't in the same folder. Or use a GUI like UsEac3to)

[Stereodude]

Originally Posted by madshi

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.

It seems that your guess is correct. Playback of tebasuna51's test clip does result in some of the side speaker audio being mixed into the corresponding side's rear speakers while the back center signal is duplicated into just both rear speakers.

Since I don't want to lose my Audyssey calibration by switching to a 6.1 setup, at this point I have no way of definitively determining if the blu-ray disc really has a empty rear center channel or not, but it seems most likely.

[Libeluratio]

I've done a little testing, not sure I understand the results:

1) Source: DTS-HD MA 7.1 (from Exodus BluRay):
- A) to 8 wavs with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs

- B) to 6 wavs (-down6) with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs excepts the surround channels LS and RS: 3 different MD5 for each (but byte identical on windows properties)

==> how is that possible ? in B), LS and RS are created from A) Lsr, Lss, Rsr, Rss, right ? since no matter the decoder used in A), the outputs are bit-identical, how can I get not-bit-identicals LS and RS in B) ??




2) When creating 3 DTS-HD MA files from the 3 A) outputs, I get 3 bit-identical DTS-HD MA files, though not bit-identical to the 1) Source from original Bluray.

When I convert each of them with the 3 decoders, I end with bit-identical files but these are not bit-identical to the A) outputs !

That files where used as inputs to make these DTS-HD MA files, so I think I should get them back as outputs, since DTS-HD MA is lossless and arcsoft dtsdecoder V1.1.0.0, V1.1.0.8, and dcadec are lossless decoders !

Something seems wrong here, maybe it's me not understanding everything ?

[Nebudchanezzer]

Originally Posted by Libeluratio

2) When creating 3 DTS-HD MA files from the 3 A) outputs, I get 3 bit-identical DTS-HD MA files, though not bit-identical to the 1) Source from original Bluray.

When I convert each of them with the 3 decoders, I end with bit-identical files but these are not bit-identical to the A) outputs !

That files where used as inputs to make these DTS-HD MA files, so I think I should get them back as outputs, since DTS-HD MA is lossless and arcsoft dtsdecoder V1.1.0.0, V1.1.0.8, and dcadec are lossless decoders !

Something seems wrong here, maybe it's me not understanding everything ?

Maybe I can shed some light on this.
MA-suite adds 1024 samples of audio at the beginning of the audio when encoding (2 frames), you can easily cut them away after encoding, just use eac3to and add a negative delay of 21ms to the encoded dtshd-file.


However I came across something else when testing:
With seamless branching discs eac3to 3.28 and 3.29 produce different results when encoding directly to flac.

If I extract the dtshd-track and then encode it to flac both versions produce bitidentical results but when encoding directly to flac when demuxing 3.28 and 3.29 produce different results, how come?
"The Hunger Games: Catching Fire" US release is what I have encountered this on.

[kasper93]

@madshi:

This sample is refused by eac3to, but it can be decoded just fine with dcadec. http://forum.doom9.org/showpost.php?...postcount=3090

[madshi]

Originally Posted by Libeluratio

- B) to 6 wavs (-down6) with Arcsoft V1.1.0.0, V1.1.0.8, and dcadec: bit-identical outputs excepts the surround channels LS and RS: 3 different MD5 for each (but byte identical on windows properties)

==> how is that possible ? in B), LS and RS are created from A) Lsr, Lss, Rsr, Rss, right ? since no matter the decoder used in A), the outputs are bit-identical, how can I get not-bit-identicals LS and RS in B) ??

Mixing requires dithering, which produces different results, because dithering means adding random noise.

Originally Posted by Nebudchanezzer

However I came across something else when testing:
With seamless branching discs eac3to 3.28 and 3.29 produce different results when encoding directly to flac.

If I extract the dtshd-track and then encode it to flac both versions produce bitidentical results but when encoding directly to flac when demuxing 3.28 and 3.29 produce different results, how come?
"The Hunger Games: Catching Fire" US release is what I have encountered this on.

I'd suggest that you decode to WAV and then compare what the difference is, with both a file comparison tool and an audio WAV tool. Are some bytes different? Or is there's some sort of audio delay in one track? Or what...

Originally Posted by kasper93

@madshi:

This sample is refused by eac3to, but it can be decoded just fine with dcadec. http://forum.doom9.org/showpost.php?...postcount=3090

There's a DTSHD encoder header in front of the real DTS audio data. If you remove that, eac3to will accept the file just fine. It's a weird file, though, DTS-MA without a core.

[hubblec4]

hi madshi

is a support for DTS Express planed?

[rapscallion]

Originally Posted by madshi

[code]* added libDcaDec decoder for DTS decoding, new default for 7.x tracks
* fixed: #263: decoding TrueHD Atmos with active dialnorm information failed

Thanks for the new version madshi!

I normally "extract" DTS HD 7.x tracks from the *.m2ts stream. Is that the same thing as "decoding"?

[sneaker_ger]

Originally Posted by hubblec4

is a support for DTS Express planed?

dcadec author said:

might be eventually supported, although I'm not very interested in implementing it.

Originally Posted by rapscallion

I normally "extract" DTS HD 7.x tracks from the *.m2ts stream. Is that the same thing as "decoding"?

If the data is copied but stays in dts-hd format it is not decoding, only extracting. In that case this change does not affect you.

[rapscallion]

Thank you, that's what I was hoping.