eac3to - audio conversion tool [Archive] - Page 264

tebasuna51

28th March 2015, 12:55

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

28th March 2015, 15:12

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

28th March 2015, 15:13

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

28th March 2015, 16:32

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

28th March 2015, 19:05

@madshi:

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

madshi

28th March 2015, 19:41

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

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

@madshi:

This sample is refused by eac3to, but it can be decoded just fine with dcadec. http://forum.doom9.org/showpost.php?p=1715032&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

28th March 2015, 20:41

hi madshi

is a support for DTS Express planed?

rapscallion

28th March 2015, 20:57

[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

28th March 2015, 20:59

is a support for DTS Express planed?
dcadec author said:
might be eventually supported, although I'm not very interested in implementing it.

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

28th March 2015, 21:01

Thank you, that's what I was hoping.

Nebudchanezzer

28th March 2015, 22:23

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

To start with I did a bitcomparison using foobars tool for just that:

Differences found in compared tracks.
Zero offset detected.

Comparing:
"L:\The.Hunger.Games.Catching.Fire.FLAC.for.comparison.eac3to.3.28.flac"
"L:\The.Hunger.Games.Catching.Fire.FLAC.for.comparison.eac3to.3.29.flac"
Compared 424063871 samples.
Differences found: 1193 values, starting at 6:56.707458, peak: 0.0000610 at 6:56.707583, 8ch
Detected offset as 0 samples.

As you can see both tracks contain the exact same amount of samples but the diffrences begin at 6:56 wich also happens to the be the same time as the first audio-overlap reported by eac3to.
Same thing applies on other seamless branching discs, tried with Divergent as well and it too had diffrencies in the decoded audiotrack between 3.28 and 3.29.

Audio-overlaps reported by eac3to:
[a02] Audio overlaps for 3ms at playtime 0:06:57. <WARNING>
[a02] Audio overlaps for 7ms at playtime 1:33:51. <WARNING>
[a02] Audio overlaps for 10ms at playtime 1:38:54. <WARNING>
[a02] Audio overlaps for 8ms at playtime 1:40:26. <WARNING>
[a02] Audio overlaps for 10ms at playtime 1:40:49. <WARNING>
[a02] Audio overlaps for 6ms at playtime 1:55:50. <WARNING>
[a02] Audio overlaps for 13ms at playtime 1:57:32. <WARNING>

I also decoded the track to wavs and used foobar to compare each channel individually and the conclusion is that the diffrences is found in all channels.

I was sort of going through my old flac files (7.1) to hash out wich ones were decoded improperly by Arcsoft when I stumbled across this, making it hard to compare old tracks vs new.

windiff first diffrences of centerchannel:
http://someimage.com/aJR2FEb

Libeluratio

29th March 2015, 16:07

Thank you madshi and Nebudchanezzer for your explainations.

One test I did:

on the TRON Legacy DTS-HD MA 7.1 track:

BL, BR, C, LFE, SL, SR channels between arcsoft v1.1.0.0, v1.1.0.8, and dcadec are bit-identical, BUT L and R channel are not !

(they are bit-identical between arcsoft v1.1.0.0 and v1.1.0.8 but not with dcadec).

I know this DTS-HD MA track was known to have issues, that is why I tested it.

Here is a sample if you want: https://www.sendspace.com/file/0gha9a

and as Nebudchanezzer did, a picture showing some differences between the two L channels from arcsoft v1.1.0.8 and dcadec for example: http://someimage.com/NUzaDn3

Basically, in the L and R files extracted with dcadec, the differences with L and R extracted from Arcsoft are some values replaces by 00

Can we know if one of the decoders extracted the L and R channels right, and which one ?

tebasuna51

29th March 2015, 16:36

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.

- Of course "losslessly", a typo and copy/paste repeat.

- Here is the full test files DTS-MA: https://www.sendspace.com/file/pd2o0f

tebasuna51

29th March 2015, 17:01

BL, BR, C, LFE, SL, SR channels between arcsoft v1.1.0.0, v1.1.0.8, and dcadec are bit-identical, BUT L and R channel are not !

(they are bit-identical between arcsoft v1.1.0.0 and v1.1.0.8 but not with dcadec).

Here is a sample if you want: https://www.sendspace.com/file/0gha9a

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

EDIT: Sorry, you are right, I forget use eac3to 3.28
I confirm the differences.

Libeluratio

29th March 2015, 17:13

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

I don't understand why.

Here is what I get with that sample:

From Arcosft v1.1.0.0:
channel L MD5: d063bd2fa3fc061c53e355e95d0d13ba
channel R MD5: e5ddeb27e0d35932a9298f3802d50f44

From DcaDec
channel L MD5: fe53588e9dbe05b3b58bcdc820daa5ff
channel R MD5: e078126224c5c465b9ee2dff349935a3

And if I compare them with tools like VBinDiff as on the picture attached to my previous post, I see differences a well. What tool are you using to determine the bit-identicalness ?

(Also, I use eac3to v3.28 to extract with arcsoft and eac3to v3.29 to extract with DcaDec as I didn't find a switch like "-arcsoft" to force the use of arcsoft on V3.29 on 7.1 tracks)

Nebudchanezzer

29th March 2015, 17:21

I can't reproduce the problem with your sample.
Output from ArcSoft v1.1.0.0 and DcaDec are bit-identical.

I could, using eac3to 3.28 and arcsoft 1.1.0.0 vs 3.29 and dcadec

However there was no differences found when using 3.29 for both dcadec and Arcsoft.

Could be interesting to try with the sonic decoder as well.

EDIT: Yes the "-arcsoft" switch does not work on 3.29.

EDIT2: Tried with sonic aswell and then compared the left channel and none of the 3 decoders produced the same result....

Libeluratio

29th March 2015, 17:33

EDIT: Yes the "-arcsoft" switch does not work on 3.29.

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ? I can't try sonic decoder unfortunately

Sparktank

29th March 2015, 17:55

EDIT2: Tried with sonic aswell and then compared the left channel and none of the 3 decoders produced the same result....

Doesn't Sonic just decode 5.1 while dropping the remaining channels?

Nebudchanezzer

29th March 2015, 18:13

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ? I can't try sonic decoder unfortunately

Yes on both questions.

Doesn't Sonic just decode 5.1 while dropping the remaining channels?

It does, but since Libeluratio already had tested with Arcsoft and dcadec and found that the difference that where found was only in left and right channels, so Sonic should in this case be sufficient to se if I could come up with a result that either matched the Arcsoft or dcadec (only tested Left channel) but it produced a third result.........

So it would be interesting if someone could test with MakeMKV and see what they come up with there.

tebasuna51

29th March 2015, 19:05

So basically, you tested two times with DcaDec, thinking one time was with arcsoft, right ?

But then, using 3.28 you where able to use arcsoft and to find same results as me ?

Yep, before I use 3.29, with 3.28 I have the same results.

EDIT:
MakeMkv: bit-identical to ArcSoft (same dstdecoderdll.dll)

BTW, the differences between ArcSoft and DcaDec aren't audibles (-108 dB)

stax76

29th March 2015, 20:35

@madshi

It's great the external dependency for DTS-HD decoding is gone, if you also want to remove the Haali muxer dependency at one time maybe this project could be helpful:

http://sourceforge.net/projects/yamka

sl1pkn07

29th March 2015, 20:51

that poject sounds great. i hope works ok with wine (linux) through eac3to (if it can be implement)

NikosD

29th March 2015, 21:04

Kurtnoise

30th March 2015, 09:16

why this one specifically ? The matroska muxer from FFmpeg should be fine...

stax76

30th March 2015, 09:55

I don't know either but remember neuron2 was very disappointed from ffmpeg libs and switched to NVIDIA because of it.

the_weirdo

30th March 2015, 11:26

I don't know either but remember neuron2 was very disappointed from ffmpeg libs and switched to NVIDIA because of it.

I didn't expect a long-time developer like you to make assumption like this.

stax76

30th March 2015, 12:25

he said this:

Stopping DGAVCDec has more to do with the serious deficiencies of libavcodec, such as its dropping of good frames (a showstopper for accurate random access), its poor performance, its lack of a native Windows build, and its lack of support

problems were not only technical, I don't have anything more to say here other then that I have very good experience with both ffmpeg and DGDecNV, because of StaxRip I have to focus on free and portable tools though.

Kurtnoise

30th March 2015, 12:30

those comments are depreciated...this is not true nowadays.

nevcairiel

30th March 2015, 12:52

That comment was from 2010, it certainly doesn't apply anymore today.

Atak_Snajpera

30th March 2015, 18:46

Another reason why we should dump ArcSoft Decoder ;)
a05 The Arcsoft DTS Decoder only allows one operation at a time.

Bigmango

31st March 2015, 18:11

Another reason why we should dump ArcSoft Decoder ;)
a05 The Arcsoft DTS Decoder only allows one operation at a time.

This is a problem of eac3to.

Makemkv uses arcsoft and does as many parallel conversions on the fly as you want, with the same arcsoft dll.

... and it does all of this in 1 shot demuxing - correcting audio gaps - converting and remuxing on the fly.

With makemkv I have converted movies with 4 DTS-HDMA tracks to flac in 1 shot without any issues at all.

lolo258

31st March 2015, 23:52

eac3to v3.28 released

Please note that some of these changes have been implemented without a lot of testing. So it would be great if you guys could double check things, especially the changes, to make sure they really work as intended. Also please make sure TrueHD decoding still works losslessly, as usual (even for non-Atmos tracks). I've hacked Atmos "support" into the old ffmpeg version I've been using for years, so I wouldn't have to update to the latest ffmpeg version. Don't have much time atm, so I tried to do the most important stuff with the least amount of work.

Hi, I've done some test on TrueHD and TrueHD with Atmos stream, eac3to can decode pure TrueHD very well, but I've tested 4 Atoms streams, it both shows some differences on bit depth, I don't know if it means lossy or not.

TrueHD track：
http://uploadingit.com/file/uoexuaibbrpd577b/truehd1.jpg

Atmos track-1：
http://uploadingit.com/file/cyebtezhwgkebdfc/atmos1.jpg

Atmos track-2：
http://uploadingit.com/file/mrwk7sehdnhpsfvu/atmos2.jpg

Atmos track-3：
http://uploadingit.com/file/c30qnbiffkbsqthh/atmos3.jpg

Atmos track-4：
http://uploadingit.com/file/stdp0nyozicd2ciz/atmos4.jpg

If you need Atmos streams for testing, please download:

https://mega.co.nz/#!RdYBDLwC!K2tmsD9MatFwEi7YCuVZit0VoAQTAOcfDn4mDGHRO4U

https://mega.co.nz/#!dFQm2agR!JfMupNxapp1PBE_KXFtRnbWzNC7BvFOWzTEsIHr7e2w

https://mega.co.nz/#!pRYXjBza!0hOdOa3oXwlEy40C3U_c4WzICRukxqN_8I4EUmQOvoI

https://mega.co.nz/#!JBZFzZ4J!P2mQcaJi5T6UBMsya_Rvuh-fDHOOOsjjUuMXraD0xrg

madshi

31st March 2015, 23:58

That looks alright to me. It's quite common to see things like that with TrueHD tracks.

lolo258

1st April 2015, 00:35

That looks alright to me. It's quite common to see things like that with TrueHD tracks.

Thanks, because some people in my country who just purchased new Atmos receiver, they don't (want to) believe that PC can use the almighty eac3to to decode Atmos stream, so I need to prove to them.:D

Another question, Do you think Lav Filter 0.64 can decode Atmos stream like eac3to?

:thanks:

Sparktank

1st April 2015, 00:39

decode Atmos

If you mean ignore the Atmos extension and deliver just TrueHD, then it should.

To get actual Atmos audio as it is advertised, you need to play the disc through the BD player to the Atmos-enabled receiver.
And probably check settings in the player so that it reads Atmos audio and not discarding it to deliver regular TrueHD extension.

lolo258

1st April 2015, 05:00

If you mean ignore the Atmos extension and deliver just TrueHD, then it should.

To get actual Atmos audio as it is advertised, you need to play the disc through the BD player to the Atmos-enabled receiver.
And probably check settings in the player so that it reads Atmos audio and not discarding it to deliver regular TrueHD extension.

So your meant eac3to can't actual decode Atmos, but only decode the TrueHD, Thanks.

Sparktank

1st April 2015, 05:28

So your meant eac3to can't actual decode Atmos, but only decode the TrueHD, Thanks.

Taken from the LAV filters thread, regarding any Atmos decoding...
so I guess the only thing now missing is a free Dolby Atmos decoder?That will quite certainly stay missing. Atmos relies on measuring the equipment to achieve optimal utilization.

Since it works in a 3D atmosphere.
Actual 3D with height, width, and depth (not DSP on receivers that create a 'center' speaker using front left+right speakers).
Height is a new aspect for receivers. A seemingly discreet new aspect.

You still get 7.1 (2D; width+depth), though. Which ain't all that bad.

Music Fan

1st April 2015, 16:58

There are also Dolby Atmos trailers there ;
http://www.demo-world.eu/2d-demo-trailers-hd/

I extracted the sound in thd+ac3 and I see with eac3to that it still contains the Atmos extension ; does it mean eac3to can't remove the Atmos extension if one need only True HD ?

Sparktank

1st April 2015, 17:37

does it mean eac3to can't remove the Atmos extension if one need only True HD ?

If you're just extracting (demuxing), it shouldn't be a big deal since anything that can't read Atmos will read just the TrueHD.
Most software is updated to use ffmpeg patch to ignore Atmos and most hardware is already designed to not read the Atmos extension if it's not supported.

nevcairiel

1st April 2015, 19:31

Personally, I wouldn't even know how to reliably remove the Atmos extension, and I wrote the patch for the ffmpeg truehd decoder to ignore it during decoding, so i'm somewhat versed in the topic. It would probably need quite complex bitstream manipulation.

Libeluratio

3rd April 2015, 15:21

Yep, before I use 3.29, with 3.28 I have the same results.

EDIT:
MakeMkv: bit-identical to ArcSoft (same dstdecoderdll.dll)

BTW, the differences between ArcSoft and DcaDec aren't audibles (-108 dB)

Differences may not be audible, but this means that at least one of the two decoders (arcsoft and/or dcadec) is'nt bit-exact decoding the source...

I have an other problem decoding a 5.1 DTS-HD MA file from french Bluray movie "La French". every 6 channels decoded from dcadec is different from the 6 decoded by arcsoft (v1.1.0.8)...!!

Here is a screen I made after opening the Center channels in audacity: top is decoded with dcadec, bottom decoded with arcsoft. It is the same for every other 5 channels (channel decoded with dcadec seems to be at a higher volume).

http://91.68.209.8/bmi/img11.hostingpics.net/pics/398304Capture.jpg

In this case again, at least one of the two decoders is doing wrong

tebasuna51

3rd April 2015, 22:14

Differences may not be audible, but this means that at least one of the two decoders (arcsoft and/or dcadec) is'nt bit-exact decoding the source...

Yes, but we can't know what without the sources.
Please send your samples to DcaDec developers.

By the moment the unique differences I see in my samples the DcaDec was the bit-exact decoder.

madshi

4th April 2015, 08:27

- Here is the full test files DTS-MA: https://www.sendspace.com/file/mtejw5
Thanks! :)

Here is what I get with that sample:

From Arcosft v1.1.0.0:
channel L MD5: d063bd2fa3fc061c53e355e95d0d13ba
channel R MD5: e5ddeb27e0d35932a9298f3802d50f44

From DcaDec
channel L MD5: fe53588e9dbe05b3b58bcdc820daa5ff
channel R MD5: e078126224c5c465b9ee2dff349935a3

And if I compare them with tools like VBinDiff as on the picture attached to my previous post, I see differences a well.
Could you please report this here?

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

It's great the external dependency for DTS-HD decoding is gone, if you also want to remove the Haali muxer dependency at one time maybe this project could be helpful:

http://sourceforge.net/projects/yamka
There are several MKV muxers available out there. I've no idea which one is "the best". In any case, I currently don't have time to change the MKV muxing. I added dcadec mostly because of the 7.1 decoding issues with ArcSoft. Of course the other advantages of dcadec are welcome, too.

By the moment the unique differences I see in my samples the DcaDec was the bit-exact decoder.
That's what the dcadec developer said, too. I had a couple of samples with which didn't decode bit-by-bit perfectly when comparing ArcSoft and dcadec, and the dcadec developer said then whenever he had this problem, and the original WAV files to compare to, it was dcadec which was bit perfect and not ArcSoft. But this is hard to proof if the original WAV files are not available, of course.

-------

So is there a consensus on dcadec yet? Should I make it the default DTS decoder in eac3to? Opinions?

NikosD

4th April 2015, 08:56

There are several MKV muxers available out there. I've no idea which one is "the best"

For me at least, I don't know for Stax76, the "issue" with Haali muxer is the dependency of the Haali splitter.

You have to install them both at the same time.

If you know a way to install just the muxer, please share.

Also, it's just another external installer dependency of eac3to that we could avoid, using any other equally good project.