eac3to - audio conversion tool

[rapscallion]

Thanks, I understand that but it doesn't answer my questions re the wav files. Which processing gave me the lossless wavs?

[nurbs]

Both of them in a way. If you decode the TrueHD you get exactly what was in it. If you decode the AC-3 you might not get exactly what's in it (assuming they can be decoded to an arbitrary bitdepth), but 24 bit is close enough as in no audible difference from the source.
Of course if you encoded the AC-3 from the TrueHD there is a loss during the AC-3 encoding.

[Inspector.Gadget]

If you're making a DTS-HD MA track, the you should ONLY go TrueHD -> WAVs -> DTS Encoder. Going TrueHD -> AC3-> WAVs-> DTS encoder is converting lossy to lossless whether you re-encode or take the TrueHD core, because either way you're discarding the lossless MLP data.

[rapscallion]

......which is the logic I was using from the start. Thanks.

However, what really puzzles me here are the substantially smaller wav files (and DTS-MA files- 2.5gb vs 3.8gb) when going from TrueHD -> WAVs -> DTS Encoder, then when going TrueHD -> AC3-> WAVs-> DTS encoder.

Logically, I would think all the files would be larger in the first lossless option. Additionally, the first option results in 16 bit wavs, the second in 24 bit. I think you guys can appreciate my reasoning, even if it's way off base.

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ?

[Inspector.Gadget]

24-bit PCM (16 bit + 8 bits padding) is generated by decoding AC3 to 24 bit, for no quality gain (and in this case, quality loss versus MLP to WAV). Decoding straight to WAVs nets you only the real 16-bit data.

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ?

Yes. Original to lossless to lossy is preferable to original to lossy to lossy.

[nurbs]

Originally Posted by rapscallion

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ?

You should always use the first option.

About the filesize. IIRC wav filesize is simply bitdepth * sampling rate * duration, so with the same duration and sampling rate a 24 bit file is 50% larger than a 16 bit file. 0.8 GB *1.5 = 1.2 GB

24-bit PCM (16 bit + 8 bits padding)

AFAIK it's not padding, it's actual information, insofar as the 24 bit file is a more accurate representation of the AC-3 file than a 16-bit wav would be even if the source of the AC-3 was only 16 bit. Of course it probably won't make much difference.

[Thunderbolt8]

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?

Originally Posted by Thunderbolt8

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?

Yes, gap detection means that eac3to looks for audio gaps in relation to the video stream (i.e. container timecodes), so once you demux audio there is no reference video stream (i.e. container timecodes) anymore.

[rapscallion]

In case you all missed this last question in an earlier post today :

"Another question is, when encoding a DTS file should the rear channels (5.1) be attenuated to -3db or should that be left alone (unchecked) ? From what I've read movie theater tracks are boosted by 3db for the rears so theaters then attenuate them by the same. But BD tracks are not boosted, so should be left alone? Is that correct ?"

Edit : Found this in the Surcde (which I don't use) manual :

7.2 
The Attenuate Rear Channels 3 dB Option

The original standard for Surround Sound in movie theaters was to attenuate 
the rear channels by 3 dB. 

So, in mixing for theaters, studios have their rear channel monitors attenuated 3 dB.

Home theaters, on the other hand, have the rear channels at unity gain. 
So, a mix that was made with the rear monitors attenuated 3 dB will 
have rear channel levels that are 3 dB too high for home theater. 

This option takes care of that difference. So, in general, you use this option
if creating a DVD-Video using a Surround master that was originally mixed for movie theaters

So, for tracks from BD discs everyone leaves the -3db option unchecked, right ?

[Snowknight26]

eac3to incorrectly reports the resolution for one of the playlists on a Blu-ray of mine:

C:\unzipped\eac3to>eac3to.exe E: 1)
M2TS, 2 video tracks, 8 audio tracks, 4 subtitle tracks, 1:36:07, 112.806p
1: Chapters, 35 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: h264/AVC, 480p24 /1.001 (20:11)
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48khz)
5: DTS Master Audio, English, 2.0 channels, 24 bits, 48khz
(core: DTS, 2.0 channels, 24 bits, 1509kbps, 48khz)
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz
7: AC3 EX, French, 5.1 channels, 640kbps, 48khz
8: AC3 EX, Spanish, 5.1 channels, 640kbps, 48khz
9: AC3 Surround, English, 2.0 channels, 192kbps, 48khz
10: AC3 Surround, French, 2.0 channels, 192kbps, 48khz
11: AC3 Surround, Spanish, 2.0 channels, 192kbps, 48khz
12: Subtitle (PGS), English
13: Subtitle (PGS), French
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), English

Is that some CGI movie from Pixar?

[Snowknight26]

It is. Seamlessly branched, too.

[Abradoks]

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?

Originally Posted by Snowknight26

It is. Seamlessly branched, too.

Then take a look at the last few lines after muxing, eac3to 3.17 should be reporting the correct fps there, nothing to worry about.

Originally Posted by Abradoks

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?

I believe you are the first to mention this.

[Thunderbolt8]

Originally Posted by honai

Yes, gap detection means that eac3to looks for audio gaps in relation to the video stream (i.e. container timecodes), so once you demux audio there is no reference video stream (i.e. container timecodes) anymore.

is there any chance to save a gap file which then can be used when I process only the audio track alone later on?

[Snowknight26]

Originally Posted by honai

Then take a look at the last few lines after muxing, eac3to 3.17 should be reporting the correct fps there, nothing to worry about.

A cosmetic issue is still an issue.

[tebasuna51]

Originally Posted by Abradoks

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?

Welcome to lossy encoders/decoders.
Yes it is know, to avoid overflows, when convert from frequency domain to time domain, many decoders attenuate a little bit the output.

You can use the -normalize parameter if you want.
And, of course, the use of ArcSoft decoder is always recommended.

Decoding ac3 sometimes eac3to detect overflows and make a second pass attenuating the signal.

[Thunderbolt8]

Originally Posted by Thunderbolt8

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?

for some strange reason the subtitle file for this movie is about 4 seconds out of sync after remuxing. the movie consists of 2 m2ts files, the first one only being 7-8 seconds long. still, no apparent relation to those 4 seconds of subtitle delay. the fps rate of this movie is listed as 26.744fps (even though the value added to the header is 24/1.001), maybe this affects the subtitles here?

[crasus]

v02 The video framerate is correct, but rather unusual.
a03 Extracting audio track number 3...
a03 Removing AC3 dialog normalization...
a03 Applying (E-)AC3 delay...
a03 A remaining delay of -13ms could not be fixed.

The BluRay has two audio tracks. An ac3 640kbps one and a DTS-HD one with a core of 1536kbps. I get a delay could not be fixed message on both. Is there any way to correct it? ArcSoft DTS is installed and fully functional with eac3to (latest version).

Thank you!