Log in

View Full Version : eac3to - audio conversion tool


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 [254] 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308

Boulder
22nd April 2014, 10:24
And something positive: Sonic is even slower :D

r0lZ
22nd April 2014, 10:31
Thanks everybody! That confirms that it's Arcsoft the culprit. I'll try with -libav. Thanks for the tip!

I'm not a specialist in audio decoding, but I wonder why ArcSoft is supposed to give better results than Libav. IMO, any decoder should give the same result, regardless of the techniques it uses. It's only when encoding that it is important to use a good encoder. Or am I wrong? What's the benefit of using "DTS reference code"?

Sorry for that newbie questions.

Richard1485
22nd April 2014, 10:43
is there a way to force eac3to to encode AC3 with libav instead of aften?

I second this request. It would be great to be able to do this and to be able to set dialnorm and DRC profile. While I know that some people (justifiably) consider dialnorm obsolete, I still like to use sometimes.

torturesauce
22nd April 2014, 11:06
Which version of dtsdecoderdll.dll you're using? IIRC, version 1.1.0.8 has problem with decoding DTS(-HD) 6.1.

Thank you! Yeah, I think it was 1.1.0.8. I replaced it with 1.1.0.1 and it worked like a charm!

filler56789
22nd April 2014, 11:21
I'm not a specialist in audio decoding, but I wonder why ArcSoft is supposed to give better results than Libav. IMO, any decoder should give the same result, regardless of the techniques it uses. It's only when encoding that it is important to use a good encoder. Or am I wrong? What's the benefit of using "DTS reference code"?

The so-called "reference code" is supposed to return a "bit-exact" decompression of lossy DTS. The bit-"exactness" is necessary for the correct decompression of DTS-HD Master Audio.

r0lZ
22nd April 2014, 12:45
The so-called "reference code" is supposed to return a "bit-exact" decompression of lossy DTS. The bit-"exactness" is necessary for the correct decompression of DTS-HD Master Audio.
I see. So, there should be no difference when decoding a "simple" (no HD) DTS 5.1. Right?

@Richard1485:
I second this request. It would be great to be able to do this and to be able to set dialnorm and DRC profile. While I know that some people (justifiably) consider dialnorm obsolete, I still like to use sometimes.
No need to uninstall ArcSoft, try "-libav", that will use libav for decoding and process quite a bit faster (but also single threaded).
And for the dialnorm, try -keepDialnorm :rolleyes:

Richard1485
22nd April 2014, 14:27
@r0lZ
What are you talking about? The post that you quoted refers to using libav as a decoder, not an encoder.

And for the dialnorm, try -keepDialnorm :rolleyes:

That keeps the dialnorm of an AC-3 track when extracting. It does not give the user the ability to set dialnorm (let alone a DRC profile) when encoding.

r0lZ
22nd April 2014, 14:37
Oops, mismatch! Sorry.

DoctorM
22nd April 2014, 21:23
You could always try Vobdnorm: http://www.coises.com/software/vobdnorm.htm

It requires the container to be VOB or MPG, but you can mux and demux from those formats as an extra step.

torturesauce
23rd April 2014, 01:55
Anyone knows how can I decode DTSWAV CD's that contain DTS-ES 6.1 audio? Can I do it somehow with Arcsoft and eac3to? MediaInfo cannot detect the sixth channel, reading it as regular DTS 5.1 (though it reads DTS-ES files from DVD's normally).

filler56789
23rd April 2014, 02:25
^ Give a try to bsconvert.exe from the AC3Filter Tools package,
and after converting the fake .WAV into a normal DTS file,
you can apply eac3to onto it.

http://www.ac3filter.net/wiki/Download_AC3Filter_tools

torturesauce
23rd April 2014, 10:41
^ Give a try to bsconvert.exe from the AC3Filter Tools package,
and after converting the fake .WAV into a normal DTS file,
you can apply eac3to onto it.

http://www.ac3filter.net/wiki/Download_AC3Filter_tools

Yes! That worked perfectly, thank you.

Richard1485
24th April 2014, 12:34
Madshi, could you comment on whether the information in the post quoted here is accurate or not (http://forum.videohelp.com/threads/363884-How-to-extract-7-1-ch-%288%29-DTS-audio-to-each-separate-audio-and-it-names-it?p=2315777&viewfull=1#post2315777)?

filler56789
24th April 2014, 14:18
^ Actually, that's just an "echo" of this post (http://forum.doom9.org/showthread.php?p=1675362#post1675362) by Bigmango.

kabelbrand
24th April 2014, 15:48
I recently switched to eac3to 3.27 and noticed the negative gain values applied when clipping occurs differ quite a lot from those applied by version 3.24

e.g. Downmixing a 5.1 source to Stereo (ProLogic): eac3to beep51.wav stereo.wav -down2

eac3to v3.24 [...] Applying -3,82dB gain...
eac3to v3.27 [...] Applying -9.84dB gain...

A sample source file and full logs can be found here:
https://docs.google.com/file/d/0ByNsn-r9w8BhS2VGRjJ0X1Y3d2M

Any ideas why the gain values differ so much? My apologies if the answer is already somewhere in this gigantic thread.

Groucho2004
24th April 2014, 15:54
e.g. Downmixing a 5.1 source to Stereo (ProLogic): eac3to beep51.wav stereo.wav -down2
Shouldn't that be "-downDpl"?

kabelbrand
24th April 2014, 15:59
Shouldn't that be "-downDpl"?

Yes, this is the 3.24 command line. I also tested with downStereo and downDpl. Please see the Google Docs link for all log files.

Groucho2004
24th April 2014, 16:10
Yes, this is the 3.24 command line. I also tested with downStereo and downDpl. Please see the Google Docs link for all log files.
When you look at the changelog you'll see that there have been changes to the downmix algorithms. However, madshi can probably shed more light on this.

tebasuna51
24th April 2014, 16:54
Madshi, could you comment on whether the information in the post quoted here
Mango wrote:
All versions of dtsdecoder.dll have some issues with some DTS-HDMA tracks (resulting in non-lossless output, sound corruption, etc...) .
dtsdecoder.dll 1.1.0.0 works fine for all tracks (including 6.0/6.1/7.1), but not 7.1 "strange setup" tracks....
is accurate or not?

Like I say many times dtsdecoder.dll 1.1.0.0 with eac3to decode the 7.1 "strange setup" tracks to wav 7.1 correctly, with low volume but with a correct mix.

The same job with Makemkv finish with a file with incorrect channels Ls-Rs from DTS converted to SL-SR channels in flac/wav.

Decode 7.1 "strange setup" with Makemkv (or DTS-HD StreamPlayer) is only recommended to edit the source and recode another time to 7.1 "strange setup".

tebasuna51
24th April 2014, 17:21
I recently switched to eac3to 3.27 and noticed the negative gain values applied when clipping occurs differ quite a lot from those applied by version 3.24
...
Any ideas why the gain values differ so much? My apologies if the answer is already somewhere in this gigantic thread.
There are a new method over 3.24, read in
http://forum.doom9.org/showthread.php?p=1600693#post1600693
Downmix improvements

- Use not normalized matrix to downmix and let the second pass do the normalize if necessary. [OK in 3.25]
Then the negative gain must be greater now.

And the differences between -downDpl and -downStereo, here http://forum.doom9.org/showthread.php?p=1600695#post1600695

Stereo
FL' = FL + 0.7071 x FC + BL + 0.7071 x BC
FR' = FR + 0.7071 x FC + BR + 0.7071 x BC
Dpl
FL' = FL + 0.7071 x FC + 0.8660 x BL + 0.5000 x BR + 0.7071 x BC
FR' = FR + 0.7071 x FC - 0.5000 x BL - 0.8660 x BR - 0.7071 x BC

Richard1485
24th April 2014, 17:30
^^ Thanks for the info, tebasuna, but there is more in the post than just the processing of "strange setup" 7.1 tracks. Is the bit about the Chinese API true?

madshi
24th April 2014, 17:48
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.

Groucho2004
24th April 2014, 17:50
Is the bit about the Chinese API true?True or not, the important question would be what the "Chinese API" does. If it's just a layer on top of the API of the decoder dll to make accessing its functions easier, I see no harm. I also wonder how the makemkv dev knows how madshi uses the library.

Richard1485
24th April 2014, 18:01
Thanks for clarifying that, madshi. It just alarmed me a bit because I've always relied on eac3to for decoding. It's a great tool. :-)

madshi
24th April 2014, 18:03
Some users have done DTS-MA bit perfection decoding tests with eac3to years ago and everything was bit perfect, except the "strange setup" tracks.

DarkSpace
24th April 2014, 20:04
About the "Chinese API" part, I'd just like to mention that perfect decoding of all tracks (even 6.0 and 6.1, or other problematic setups) sounds like a good point - if it works, which I have no idea of.
However, another great point is the ability to decode multiple tracks at once. I always found it more than just a bit annoying that I would have to decode one DTS-HD track at a time, then wait until that finishes, and then decode the second one: For one, it takes time, and another reason is that for all other types of audio, I can just type e.g.
eac3to input.m2ts 2:out1.flac 3:out2.flac 4:out3.flac -log=NUL
while with even just 2 DTS-HD tracks, this will fail. A temporary solution is, of course, to have eac3to just decode one track, then the next, and so on, but this sounds like a lot of effort for an inelegant solution, especially when a solution is available that sounds more elegant to me.

For reference, this is just my opinion, and I'm not trying to apply pressure on you or something like that. I'm aware that sometimes, I write stuff that is easily misunderstood :o

Yoshi
2nd May 2014, 14:31
Hello together,

I've been keen on posting here in regard to the great tool eac3to since quite some time but always been successfully discouraged by this registration hassle here. Well, I finally brought myself to do it at the end, so I want come to the point(s):

I almost love eac3to and use it regularly, however only almost since some oddities remain:

1. despite all the fuss which is been made about the so-called "HD" audio formats like TrueHD and DTS-HD MA, some older releases on DVD feature a higher dynamic range / unaltered mix compared to the Blu-rays. Examples would be Terminator 2 (CDS mix only on the first US DVD), Titanic (higher dynamic range on the first THX-certified US-DVD compared to the 3D BD), Fight Club (even higher DR-values for the rear channels on the US DVD compared to the UK Fox BD), Se7en (different mixes).

This is why I sometimes want to extract the DVD's audio and sync it to the Blu-ray picture. With the old, but in it's days similarly great tool "vStrip", this is no problem at all. However, eac3to keeps screwing it up and truncates the beginning of the AC3-file independent of the movie. During extraction it complains about a weird audio delay which could not be fixed, for example:

eac3to v3.27
command line: eac3to.exe "S:\SEVEN_SF\VIDEO_TS\VTS_01_1.VOB"
+"S:\SEVEN_SF\VIDEO_TS\VTS_01_2.VOB"
+"S:\SEVEN_SF\VIDEO_TS\VTS_01_3.VOB"
+"S:\SEVEN_SF\VIDEO_TS\VTS_01_4.VOB"
+"S:\SEVEN_SF\VIDEO_TS\VTS_01_5.VOB"
+"S:\SEVEN_SF\VIDEO_TS\VTS_01_6.VOB" 3: q:\se7en.ac3
------------------------------------------------------------------------------
VOB, 1 video track, 7 audio tracks, 5 subtitle tracks, 2:01:36
1: Joined VOB file
2: MPEG2, 576i50 (4:3)
3: AC3, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, 7ms
4: DTS-ES, 6.1 channels, 755kbps, 48kHz, 7ms
5: AC3, 2.0 channels, 192kbps, 48kHz, dialnorm: -27dB, 7ms
6: AC3, 2.0 channels, 128kbps, 48kHz, dialnorm: -27dB, 7ms
7: AC3, 2.0 channels, 224kbps, 48kHz, dialnorm: -27dB, 7ms
8: AC3, 2.0 channels, 128kbps, 48kHz, dialnorm: -27dB, 7ms
9: AC3, 5.1 channels, 384kbps, 48kHz, dialnorm: -27dB, 7ms
10: Subtitle (DVD)
11: Subtitle (DVD)
12: Subtitle (DVD)
13: Subtitle (DVD)
14: Subtitle (DVD)
[a03] Extracting audio track number 3...
[a03] Removing AC3 dialog normalization...
[a03] A remaining delay of +7ms could not be fixed.
[a03] Creating file "q:\se7en.ac3"...
Video track 2 contains 182498 frames.
eac3to processing took 50 seconds.
Done.


2. This refers to eac3to's output above: As far as I am aware, eac3to actually doesn't alter any audio information when only extracting it via selecting .ac3 .dts .thd, etc. as the file name. If so, it is however confusing that the dialog normalization is supposed to be removed when where is nothing to remove in this case.


3. Compared to MakeMKV, eac3to (sometimes) doesn't list all available playlists as reflected by the MPLS files. Is it an intended behaviour of eac3to to only list the main feature(s) when parsing a whole BDMV-structure? Some discs spread the bonus features across several m2ts-files via seamless branching so it would be more convenient to have them listed by eac3to as well instead of having to look for the single parts on your own.

4. This concerns eac3to's method to access Arcsoft's DTS Decoder where I want to quote two statements:

Like I say many times dtsdecoder.dll 1.1.0.0 with eac3to decode the 7.1 "strange setup" tracks to wav 7.1 correctly, with low volume but with a correct mix.

Logically, this is contradiction in terms: If a conversion of a lossless source is reproduced with lower volume, it isn't lossless and thus [b]not correct by definition. I doubt myself that this will really affect the audio quality whatsoever, but actually it is a similar academical thing like keeping the lossless source in the first place. I do this myself (converting it to FLAC), however I'm very well aware that I would most likely fail any blind test between properly encoded AC3 or DTS versus the PCM master.

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.

Being on the safe side at a chance of 0.99 something isn't the worst thing for sure. But why the apparent lack of motivation to get it correctly and reach the 100%? If the claims from the developers of MakeMKV are correct, what's their magic to get it done right where eac3to fails?

Besides, how am I supposed to handle those "weird 7.1 setups" then in combination with seamless branching? MakeMKV decodes it properly but screwes up the audio boundaries, at least if you intend to play it back via something like Dune. Eac3to on the other hand handles this correctly, but messes up the audio decoding in conjunction with the Arcsoft decoder. Great.


5. [BUG] In case of missing access rights, the root folder of c: for instance, eac3to doesn't warn about it and simply doesn't create the files.



Despite the points above, I have some other questions I somehow lack understanding correctly which concern eac3to, but are of general nature. I've been through most of this thread, but certainly not every page so I hope this hasn’t been covered yet. At least, I couldn't find a revealing explanation anywhere so far:


1. Seamless branching on Blu-ray: For all I know, when a feature is spread over several M2TS files, there seems to be a mismatch of video and audio frame-lengths which has to be taken into account in order to prevent summed up lack of sync. However, I don't understand why the several M2TS-files can't be considered as one continuous stream instead and besides that, I wonder how a stand-alone player behaves here.

On the example of "Escape Plan", spread over tons of M2TS and faked playlists, I only get a flawless result when using eac3to. With MakeMKV, although considered to be aware of seamless-branching, the resulting MKV has audio glitches on the original M2TS boundaries, at least when playing it back with a Dune 303D.

Eac3to seems to behave differently when it encounters seamless branching depending on the audio format: when dealing with DTS, it states "skipping identical DTS-frames (seamless branching)", but when dealing with AC3, a second pass is initiated. Where can I find an explanation about which format is treat which way and why?

Somewhere, I read about that MakeMKV would take care of the duplicated frames via timecode-adjustments within the Matroska container instead of altering the audio data. Despite the fact that it doesn't seem to work out for me due to the glitches, can anyone give me more information about that from his experience?

A special case seems to be TrueHD in conjunction with seamless branching (e.g. Monsters University). Why and when is it going to be fixed in eac3to?


2. This is regarding gain adjustments in order to prevent overflows. I understand that in most cases, one has to reduce the gain to prevent clipping when downmixing since the channel levels sum up, but I don't get the idea for this need when extracting a AC3- oder DTS-track into individual PCM-tracks. Since eac3to starts a second pass in this case as well while overwriting the first extraction result, I assume that eac3to asks the AC3- or DTS-decoder to output the audio at a lower volume. I am aware that audio levels (intersample peaks, etc.) can slightly change during lossy encoding and decoding again, but I wonder why some files require a gain of -6dB. I would expect that the encoded highest "volume value" within the lossy codecs would be "calibrated" to equal more or less 0dBFS once decoded so I really ask to be enlightened here.

Furthermore, how do AVRs deal with overflows when decoding lossy codecs? They don't have any chance for a second pass, either.


Cheers,
Yoshi

tebasuna51
2nd May 2014, 16:04
1. [BUG]...
However, eac3to keeps screwing it up and truncates the beginning of the AC3-file independent of the movie. During extraction it complains about a weird audio delay which could not be fixed, for example:
...
3: AC3, 5.1 channels, 448kbps, 48kHz, dialnorm: -27dB, 7ms
...
[a03] Removing AC3 dialog normalization...
[a03] A remaining delay of +7ms could not be fixed.

Is not a BUG is a feature.
Here eac3to does not truncate the beginning of the AC3 because only can delete/insert AC3 frames (32 ms).
Even if the delay was big than 32 ms can only be silence, or the DVD was wrong created.

2. ... If so, it is however confusing that the dialog normalization is supposed to be removed when where is nothing to remove in this case.
Yes, the dialnorm: -27dB must be corrected to -31dB to avoid 4 dB of useless attenuation.

3. ..eac3to (sometimes) doesn't list all available playlists as reflected by the MPLS files. Is it an intended behaviour of eac3to to only list the main feature(s) when parsing a whole BDMV-structure?
Yes, the features are ordered by duration until a limit (don't remember, maybe 10m.?)

4. This concerns eac3to's method to access Arcsoft's DTS Decoder.
This is a question with different opinions.
I say than MakeMkv convert wrong the 'strange 7.1 setup' to PCM or FLAC.

The 'strange 7.1 setup' can't be converted lossless to other standard format. You can only preserve the track, don't try to convert losless to other format because is not possible.

5. [BUG] In case of missing access rights, the root folder of c: for instance, eac3to doesn't warn about it and simply doesn't create the files.
This is a user problem with the OS.

1. Seamless branching on Blu-ray
Seamless branching is a complex problem and don't exist always a perfect solution (without recode) to extract tracks.
Read http://forum.doom9.org/showthread.php?p=1600694#post1600694

2. This is regarding gain adjustments in order to prevent overflows. I understand that in most cases but I don't get the idea for this need when extracting a AC3- oder DTS-track into individual PCM-tracks.

Yes, the lossy encode and decode can produce overflows than aren't in sources. You can safely include the parameter -no2ndpass when only want decode to PCM tracks because are only artifacts from the lossy process.

Yoshi
3rd May 2014, 16:56
Hello tebasuna51,

thank you for your response. I wanna quote your parts vice-versa:

Is not a BUG is a feature.
Here eac3to does not truncate the beginning of the AC3 because only can delete/insert AC3 frames (32 ms).
Even if the delay was big than 32 ms can only be silence, or the DVD was wrong created.

Well said. :) However, my resulting AC3 files become significantly truncated by eac3to and I’m not talking about milliseconds, but several seconds and almost a minute in one extreme case which keeps confusing me. For instance, in the case of the Titanic DVD, I only hear the end of the THX-trailer at the beginning.


Yes, the dialnorm: -27dB must be corrected to -31dB to avoid 4 dB of useless attenuation.

My point was that there is no dialnorm to be removed at all when saving the stream as AC3 because eac3to doesn’t alter the data but demultiplexes it only. Correct me, if I’m wrong.


I say than MakeMkv convert wrong the 'strange 7.1 setup' to PCM or FLAC.

In which way is the result wrong?


The 'strange 7.1 setup' can't be converted lossless to other standard format. You can only preserve the track, don't try to convert losless to other format because is not possible.

Why is this not possible?


Seamless branching is a complex problem and don't exist always a perfect solution (without recode) to extract tracks.
Read http://forum.doom9.org/showthread.php?p=1600694#post1600694

Thanks, but I’ve to admit that I don’t fully understand your explanation there. Maybe you better refer me to more basic material since I seem to lack basic knowledge. However, from what I do understand, this neither explains why stand-alone players apparently have no problem with seamless branching at all, nor that the fact alone that we face several files, is no reason for sync problems. DVD-Video also distributes the stream over several files where frames might be cut of, but since it’s considered one continuous stream, no issue arises when processing it.


Yes, the lossy encode and decode can produce overflows than aren't in sources. You can safely include the parameter -no2ndpass when only want decode to PCM tracks because are only artifacts from the lossy process.

However, the same would be true for all other lossy formats, be it MP2, MP3, Vorbis, ADPCM, whatever. And I’ve never heard about the requirement of 2nd passes when decoding them.

tebasuna51
4th May 2014, 12:53
- If there are undesired cuts at the begining maybe there are some corrupt data.

- eac3to change the field DialNorm (if is not -31 dB) when extract the AC3 tracks. Use -keepDialnorm if you want.

- The DTS 'strange 7.1 setup' channels don't have a channel layout equivalence in other standard 7.1 formats: wav, flac, aac, ogg, ...
Then can't be converted without remix surround channels.

- Is not the same extract than play. When play the container timecodes can order to the player delay (+ or -) the audio in file changes.
But we can extract part of a frame because the track results corrupted. We can recode but not a exact audio cut at video frames change.

- Each decoder can do differents outputs. Is not normal than a decoder outputs audio with volume over 0 dB.
Maybe you can put a feature request to libav decoder.

This thread is very big, if you want more detailed explanation over some points, already explained in this thread, you can open a new thread.

kabelbrand
5th May 2014, 18:07
There are a new method over 3.24, read in http://forum.doom9.org/showthread.php?p=1600693#post1600693

Then the negative gain must be greater now.

And the differences between -downDpl and -downStereo, here http://forum.doom9.org/showthread.php?p=1600695#post1600695

Thanks Groucho and tebasuna for pointing me in the right direction!

ndjamena
2nd June 2014, 15:40
With 16 bit in 24 bit Lossless audio conversion is there any way to skip the first pass if I already know what's inside, or at least do the first pass without encoding and a forced second pass? I was thinking maybe -down16 but then realised that would just turn the 24 bit track with 8 bits of zeros into a 16 bit track with 5 bits of zeros. Or is there any way to just reverse the process, start with 16 bit and if it encounters a 24 bit section restart at 24, if it winds up being 20 bit it can do a third pass and I can sit there feeling stupid.

DarkSpace
2nd June 2014, 16:16
With 16 bit in 24 bit Lossless audio conversion is there any way to skip the first pass if I already know what's inside, or at least do the first pass without encoding and a forced second pass? I was thinking maybe -down16 but then realised that would just turn the 24 bit track with 8 bits of zeros into a 16 bit track with 5 bits of zeros. Or is there any way to just reverse the process, start with 16 bit and if it encounters a 24 bit section restart at 24, if it winds up being 20 bit it can do a third pass and I can sit there feeling stupid.
When you know that you've got a 16-bit audio track, you can use -down16 in combination with the undocumented -dontDither option.
However, when you don't know what's inside, I know of no way to just restart encoding with 24-bit, you'll have to make do with 24-bit and reduce that to 16t-bit if eac3to later detects that the whole track is only 16-bit...

ndjamena
2nd June 2014, 23:52
-dontDither

Cool. If nothing else that'll come in handy with TV Shows.

DarkSpace
3rd June 2014, 00:24
Cool. If nothing else that'll come in handy with TV Shows.
Is it that common for TV shows to use 16-bit audio, but to signal 24-bit audio (or just to use TrueHD with a 16-bit audio source)? I don't own many TV series' BDs, so I'm curious.

Sparktank
3rd June 2014, 02:05
undocumented -dontDither

Is there anywhere that states all the available switches?

The wiki doesn't list "-dontDither", nor does anything when running eac3to.
http://en.wikibooks.org/wiki/Eac3to/How_to_Use#Command_Line_Syntax

cyberbeing
3rd June 2014, 02:52
Is there anywhere that states all the available switches?

Probably something close to the following string dump:
mb
test
lowPriority
progressnumbers
neroaacenc=
demux
skipbytes
no2ndpass
check
fix
shutdown
logPids
logMkv
logDts
analyzeBitdepth
checkPitch
nero
sonic
arcSoft
libav
downmix
down6
down2
downDpl
downStereo
phaseShift
mixlfe
normalize
2pass
seekToIFrames
full
float32
skip
down32
down31
down30
down29
down28
down27
down26
down25
down24
down23
down22
down21
down20
down19
down18
down17
down16
down15
down14
down13
down12
down11
down10
down9
down8
192000
176400
96000
88200
48000
44100
24000
22050
8
7
6
5
4
3
2
1
16
24
fast
steep
r8brain
23.976
24.000
24.975
25.000
29.970
30.000
47.952
48.000
50.000
59.940
60.000
changeTo
speedupTo
slowdownTo
FPS value
quality=0.
quality=0
quality=1
quality=1.0
quality=1.00
blu-ray
bluray
core
silence
loop
edit=?:??:??,*ms
edit=?:??:??.???,*ms
slowdown
speedup
override
dontRepairDts
dontPatchDts
keepFullRange
dontCrop
stripPulldown
keepPulldown
resampleTo
big
little
mono
double7
simple
check16bit
ignorePitch
decodeHdcd
keepDialnorm
dontDither
ms
dB
192
448
640
768
1536
log

Sparktank
3rd June 2014, 11:33
Interesting.

Groucho2004
3rd June 2014, 12:10
Someone already collected all documented and undocumented switches a while ago:
http://en.wikibooks.org/wiki/Eac3to/How_to_Use#Command_Line_Syntax
Unfortunately, this does not include the options of the latest version.

shearerc
18th June 2014, 23:01
Someone already collected all documented and undocumented switches a while ago:
http://en.wikibooks.org/wiki/Eac3to/How_to_Use#Command_Line_Syntax
Unfortunately, this does not include the options of the latest version.
Better than nothing, thanks

ndjamena
20th June 2014, 14:57
Is it that common for TV shows to use 16-bit audio, but to signal 24-bit audio (or just to use TrueHD with a 16-bit audio source)? I don't own many TV series' BDs, so I'm curious.

Not that I'm aware of, actually I asked as a feature request on the MakeMKV forum if the program could give a report at the end as to whether a 24 bit DTS-MA or TrueHD track turned out to be 16 bit or not during FLAC conversion. If that happens EAC3To going through both passes during the re-encode would be a waste of time. But of course Mike doesn't usually implement anything so it's unlikely to happen, which is why I had to find a way to justify getting the answer I got.

torturesauce
5th July 2014, 01:50
I converted a 24/44.1 6-channel DTS file to a FLAC using eac3to with Arcsoft DTS Decoder. The conversion went fine, but there's something weird: I played both files with foobar2000 and checked the waveforms with the Waveform Seekbar addon.

DTS:
http://i.imgur.com/t3Ia29S.jpg

FLAC:
http://i.imgur.com/XtkGNun.jpg

The LFE channel (on the bottom) is louder on the FLAC. Why is that so?

torturesauce
6th July 2014, 06:43
...and a REAL problem. There's a certain DTS-CD whose DTS-ES files I could extract properly with bsconvert, but once I put them in eac3to, it simply refuses to decode them with Arcsoft. It doesn't even produce an error. It just says:

DTS-ES, 6.1 channels, 0:04:58, 1235kbps, 44.1kHz
Remapping channels...
Decoding with ArcSoft DTS Decoder...

And that's it. Other DTS-ES files I've used work perfectly. I use Arcsoft 1.1.0.0.

Music Fan
6th July 2014, 10:39
I asked a question about thd+ac3 in another topic ;
http://forum.doom9.org/showthread.php?p=1685842#post1685842

I copy it here, the eac3to topic is more appropriate ;
is there a trick to mux a True HD track with an ac3 track (both having exactly the same duration) into a single .thd+ac3 file or this interleaved file can only be created from a single True HD track ?

It's just by curiosity, I understand that it's not very useful because if one really need to have another ac3 track (than the True HD track), it can be muxed into m2ts in addition to the .thd+ac3.
The only utility I see would be to avoid to increase the total bitrate (of a Blu-ray for example) if one need an ac3 track with a different mix than the True HD track.

I guess it is possible (but is maybe not available yet but could perhaps be added in eac3to), because just after having created the ac3 track from the True HD, thus just before interleaving them, there are 2 tracks. And I don't see the difference between taking this ac3 stream (existing as a temporary file) and another (already existing) for the interleaving operation.

tebasuna51
6th July 2014, 11:26
The LFE channel (on the bottom) is louder on the FLAC. Why is that so?
Yes, I can confirm than LFE decoded with Arcsoft 1.1.0.0 is 3 dB louder than the LFE channel decoded with Foobar2000 decoder or with the AviSynth NicAudio decoder.

There's a certain DTS-CD whose DTS-ES files I could extract properly with bsconvert, but once I put them in eac3to, it simply refuses to decode them with Arcsoft.
Please upload a sample (dtswav) before extract with bsconvert.

tebasuna51
6th July 2014, 11:38
is there a trick to mux a True HD track with an ac3 track...?
Nope, now you can create a thd+ac3 track with the ac3 created for eac3to with the thd input.

It's just by curiosity, I understand that it's not very useful...
I guess it is possible (but is maybe not available yet but could perhaps be added in eac3to)
Yes, it's not very useful...
I don't know if madshi can add this option.

Music Fan
6th July 2014, 12:15
Ok, and do you know how the interleaved ac3/True HD tracks are created by professional tools for Blu-ray's ?
Because I guess that unlike eac3to, they don't create an ac3 stream from the THD stream, they probably take 2 streams (even when they come from the same mix) and interleave them.

filler56789
6th July 2014, 13:22
...and a REAL problem. There's a certain DTS-CD whose DTS-ES files I could extract properly with bsconvert, but once I put them in eac3to, it simply refuses to decode them with Arcsoft. It doesn't even produce an error. It just says:

DTS-ES, 6.1 channels, 0:04:58, 1235kbps, 44.1kHz
Remapping channels...
Decoding with ArcSoft DTS Decoder...

And that's it. Other DTS-ES files I've used work perfectly. I use Arcsoft 1.1.0.0.

As a possible workaround, you could try opening the DTS-ES files with foobar2000, and then convert them to uncompressed WAV files (or perhaps to FLAC as well).

SeeMoreDigital
6th July 2014, 14:41
Ok, and do you know how the interleaved ac3/True HD tracks are created by professional tools for Blu-ray's ?
Because I guess that unlike eac3to, they don't create an ac3 stream from the THD stream, they probably take 2 streams (even when they come from the same mix) and interleave them.It would appear that tebasuna51's UsEac3To v1.0.0 is able to generate a 5.1Ch Dolby Digital stream from a 'vanilla' Dolby TrueHD stream and multiplex/interleave it correctly to provide a Dolby Digital core ;)

Music Fan
6th July 2014, 16:03
I don't need to get the core (eac3to can do it and also TSMuxer IIRC), I'd like to know if an ac3 stream and a THD stream without core can be muxed together to get a .thd+ac3 (which is usually done by re-creating the core from a THD track whose core has been removed).