eac3to - audio conversion tool [Archive] - Page 179

loekf

22nd May 2009, 12:13

Maybe a stupid question, but is there a way to force eac3to into silent mode ? I haven't been able to find any commandline option to disable to "buzzer" sound after an error has occurred or the other sound after completion.

I'm using eac3to in a video transcoding tool I'm writing and these sounds are, I won't say annoying.... , but not preferred... ;-)

TinTime

22nd May 2009, 12:16

I think you can just delete the two wav files that eac3to uses.

Xorp

22nd May 2009, 17:38

If a Blu-ray has multiple 7.1 tracks, lets say all three lossless/uncompressed varieties, and I want to downmix to 5.1, does it matter which one I use? I'm guessing the PCM track might better since the layout is more straight-forward.

Snowknight26

23rd May 2009, 07:25

How can there be clipping when encoding an E-AC3 track to AC3? Isn't the E-AC3 track decoded to floating point before being fed to libAften?

tebasuna51

23rd May 2009, 09:57

How can there be clipping when encoding an E-AC3 track to AC3? Isn't the E-AC3 track decoded to floating point before being fed to libAften?
Yes, when you decode a lossy format to float you can have artifacts over the Max. value (can't be present at original source).

If you only decode and recode (without downmix, resample or other audio change) you can safely use the new -no2ndpass parameter because any clip is a encoder artifact.

Snowknight26

23rd May 2009, 19:22

If you only decode and recode (without downmix, resample or other audio change) you can safely use the new -no2ndpass parameter because any clip is a encoder artifact.

So this would be the libAften's fault?:

eac3to v3.16
command line: eac3to.exe ..\temp\asd.eac3 ..\temp\asd.ac3
------------------------------------------------------------------------------
E-AC3, 5.1 channels, 1:40:23, 640kbps, 48khz
The Nero decoder doesn't seem to work, will use libav instead.
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "..\temp\asd.ac3"...
Clipping detected, a 2nd pass will be necessary. <WARNING>
Starting 2nd pass...
Decoding with libav/ffmpeg...
Remapping channels...
Encoding AC3 <640kbps> with libAften...
Creating file "..\temp\asd.ac3"...
eac3to processing took 7 minutes, 42 seconds.
Done.

Mtz

23rd May 2009, 21:10

madshi, can you implement extracting the subtitles from HDTV recordings? The subtitles can be viewed if playing the files with VLC.

Here (http://www.sendspace.com/file/a2ep4l) is one example with DVB Subtitles.
TS, 1 video track, 4 audio tracks, 8 subtitle tracks, 0:02:40, 50i
1: h264/AVC, 1080i50 (16:9)
2: MP2, English, 2.0 channels, 256kbps, 48khz, -903ms
3: MP2, Polish, 2.0 channels, 256kbps, 48khz, 18ms
4: MP2, Hungarian, 2.0 channels, 256kbps, 48khz, -149ms
5: MP2, Czech, 2.0 channels, 256kbps, 48khz, -68ms
6: Subtitle (DVB), Dutch
7: Subtitle (DVB), Serbian
8: Subtitle (DVB), Slovenian
9: Subtitle (DVB), Croatian
10: Subtitle (DVB), Swedish
11: Subtitle (DVB), Danish
12: Subtitle (DVB), Romanian
13: Subtitle (DVB), Norwegian
[v01] The video track contains the (probably incorrect) "full range" flag. <WARNING>
This subtitle conversion is not supported. <ERROR>

Here (http://www.sendspace.com/file/ktzc52) is one example with teletext subtitle and DVB Subtitle.
Here (http://www.sendspace.com/file/yovv7y) is one sample with teletext subtitle.
Here (http://www.sendspace.com/file/oegamw) is one TRP file with no subtitles.

Also, the audio delay is not correct on all files.

enjoy,
Mtz

tebasuna51

24th May 2009, 02:37

So this would be the libAften's fault?:

Fault?
For what fault?
For what libAften?

All is ok.

Snowknight26

24th May 2009, 02:49

You said that if there is any clipping when decoding then reencoding (in one step), its the encoders fault. So in this case its libAften.. which isn't plausible.

tebasuna51

24th May 2009, 03:27

The clip is at decoder pass (not encoder) and is normal with lossy formats.

StephenB

24th May 2009, 11:50

The clip is at decoder pass (not encoder) and is normal with lossy formats.

Do you know why it happens though?

Is this because the decoder is not quite compliant?

tebasuna51

24th May 2009, 15:06

Do you know why it happens though?

Is this because the decoder is not quite compliant?
Because is lossy compression.
If the source file have some peaks at 0 dB, some of them are encoded/decoded to obtain peaks between -0.1dB (no problem) and +0.1dB (clip to -> 0 dB)

The clipped peak recover the original volume, maybe the problem is in the peak at -0.1 dB.

If you want exact translation you need lossless encoders.

StephenB

25th May 2009, 11:04

Because is lossy compression.
If the source file have some peaks at 0 dB, some of them are encoded/decoded to obtain peaks between -0.1dB (no problem) and +0.1dB (clip to -> 0 dB)

The clipped peak recover the original volume, maybe the problem is in the peak at -0.1 dB.

If you want exact translation you need lossless encoders.

Well, I do understand that lossy codecs are not exact.

But it seems to me that a well designed encoder would not exceed the clipping limit on any signal it encodes.

After all, all compliant decoders should obtain the same (non-exact) result (at least with standard floating point hardware), so it seems to me that the encoder algorithm can/should prevent the clipping.

StephenB

27th May 2009, 16:33

Madshi,

It looks like SOPHOS antivirus software is generating a false positive on EAC3TO V3.16 You can see this here:

http://virscan.org/report/aa2d3e03ec288e0f26c03f7f9438f232.html

Jeff Flowerday

27th May 2009, 22:53

Madshi,

It looks like SOPHOS antivirus software is generating a false positive on EAC3TO V3.16 You can see this here:

http://virscan.org/report/aa2d3e03ec288e0f26c03f7f9438f232.html

Well then report it to them as a false positive not madshi, he has no control over their virus scanner.

jruggle

28th May 2009, 04:43

Well, I do understand that lossy codecs are not exact.

But it seems to me that a well designed encoder would not exceed the clipping limit on any signal it encodes.

After all, all compliant decoders should obtain the same (non-exact) result (at least with standard floating point hardware), so it seems to me that the encoder algorithm can/should prevent the clipping.
An AC-3 encoder actually has very little control over this. I guess it could, in theory, imploy an internal decoder and clipping detection, try to determine the frequency of clipped areas, then add bits to those frequencies using delta bit allocation, hoping removing bits from other places would not cause clipping elsewhere. I very highly doubt that Dolby's encoder even does this, as it would be very impractical, not completely reliable, and would decrease the quality.

It is explictly mentioned in the AC-3 specification that the output signal from the decoder may exceed 100%. Here is the exact text from A/52B section 7.9.4:
"Since the output signal consists of the original signal plus coding error, it is possible for the output signal to exceed 100 percent level even though the original input signal was less than or equal to 100 percent level."

It is up to the decoder what to do about this. Most will probably clip the results though. The specification mentions it so that those implementing a decoder will not assume a certain output range in their calculations.

StephenB

28th May 2009, 15:57

StephenB

29th May 2009, 14:17

An AC-3 encoder actually has very little control over this. I guess it could, in theory, imploy an internal decoder and clipping detection, try to determine the frequency of clipped areas, then add bits to those frequencies using delta bit allocation, hoping removing bits from other places would not cause clipping elsewhere. I very highly doubt that Dolby's encoder even does this, as it would be very impractical, not completely reliable, and would decrease the quality.

It is explictly mentioned in the AC-3 specification that the output signal from the decoder may exceed 100%. Here is the exact text from A/52B section 7.9.4:
"Since the output signal consists of the original signal plus coding error, it is possible for the output signal to exceed 100 percent level even though the original input signal was less than or equal to 100 percent level."

It is up to the decoder what to do about this. Most will probably clip the results though. The specification mentions it so that those implementing a decoder will not assume a certain output range in their calculations.

It still seems odd to me that professionally mastered AC3 tracks on commercial disks would be encoded so that every AC3 decoder on the planet has to clip.

ron spencer

29th May 2009, 23:19

quick question...if I am changing 640 AC3 to 448 with EAC3to and the 640 is stated to have bit depth of 24 bits, will the encode via libAften to 448 reduce bit depth to 16 automatically or must it be specified first?

thanks

-rs

Snowknight26

29th May 2009, 23:29

Lossy formats don't have a bit-depth.

TinTime

29th May 2009, 23:30

The AC3 decoder (the Nero one anyway) decodes to 24 bits. It's not the AC3 itself that's 24 bit. If encoding to AC3 just pass it the best quality audio possible - 24 bit in this case. There's no need to reduce to 16 bit.

tebasuna51

30th May 2009, 01:34

If you use eac3to to recode ac3 640Kbs to 448Kbs the decoder (at least libav) suply audio samples with 32 bits float, and the Aften encoder (libaften) read these 32 bit float to obtain the ac3 stream.
The ac3 stream don't have a fix bitdepth, the quality is measured in bitrate instead.

Ryu77

30th May 2009, 14:29

I had some recent difficulty re-authoring a disc with a TrueHD track and the only thing I can pin it on is EAC3to. I will explain more so you can let me know if this is normal behavior for this application.

I demuxed a Dolby TrueHD (TrueHD+AC3) track with EAC3to and then re-encoded the video, after that remuxed back together with tsMuxeR.

My Pioneer SC-LX81 AVR made some spluttering noises and the audio was quite garbled (bitstreamed from LG BD370). My PS3 seemed to decode the audio and send the AVR the LPCM track with no problem.

So I decided to take the disc to work and on 4 other AVR's in the store, the info display showed "DIAL NORM -27" (I think that was the number, I could be off a little but I am sure it was in it's twenties). The AVR's at work seemed to be able to play the audio ok. However, I have never seen such a large number show up on my AVR. It is usually somewhere between +8 and -8 (from memory???). After doing some reading it appears that -27 could be the default dialog normalization figure before any metadata changes are made. This suggested to me that maybe EAC3to removed the dialog normalization when demuxing. To further solidify my thoughts, I remuxed the same tracks, only this time avoiding using the demuxed (thd+ac3) track from EAC3to, instead I loaded the original m2ts file into tsMuxeR and selected the TrueHD track that way.

This time it played without any problems at all, except now no DIAL NORM notification comes up on my AVR. To sum this post up...

Does EAC3to remove or alter dialog normalization when demuxing? I am aware how this could affect encoding but surely it shouldn't be removed or altered when demuxing, should it?

tebasuna51

30th May 2009, 15:09

Does EAC3to remove or alter dialog normalization when demuxing?
Yes, change any value of Dialog Normalization to -31 dB
I am aware how this could affect encoding but surely it shouldn't be removed or altered when demuxing, should it?
The change only affect this field value in headers (and CRC), is a lossless change without reencode.
This change can't be the source of your problems.

TinTime

30th May 2009, 16:11

If you want to keep the existing dialnorm value then you can use the -keepDialnorm option with eac3to.

A value of -27 is very usual.

As to whether the original value should be kept or not when demuxing, opinion is divided. It's really personal preference. I keep it myself.

Ryu77

30th May 2009, 23:07

Yes, change any value of Dialog Normalization to -31 dB

The change only affect this field value in headers (and CRC), is a lossless change without reencode.
This change can't be the source of your problems.

Well it obviously was the source of my problem as my receiver didn't like the audio track with the dialog normalization removed. Once remuxed with the dial norm untouched my AVR played it without any issue.

If you want to keep the existing dialnorm value then you can use the -keepDialnorm option with eac3to.

Thank you, I forgot about that command. I always thought this wasn't a problem with demuxing though. I always thought this was only removed for re-encoding purposes. Now I know different. :D

tebasuna51

31st May 2009, 00:18

Well it obviously was the source of my problem as my receiver didn't like the audio track with the dialog normalization removed. Once remuxed with the dial norm untouched my AVR played it without any issue.
Nope, can't be the problem.
The DialNorm isn't removed, is changed to a valid value (-31).

When the receiver read a -27 dB value in DialNorm make a global attenuation of 4 dB.

When the receiver read a -31 dB value in DialNorm make a global attenuation of 0 dB.

Maybe is other problem related to the demux-remux.
:logfile:

Ryu77

31st May 2009, 01:13

Nope, can't be the problem.
The DialNorm isn't removed, is changed to a valid value (-31).

When the receiver read a -27 dB value in DialNorm make a global attenuation of 4 dB.

When the receiver read a -31 dB value in DialNorm make a global attenuation of 0 dB.

Maybe is other problem related to the demux-remux.
:logfile:

Thank you for your help but as mentioned earlier when I muxed with tsMuxeR only (avoiding EAC3to), the disc created played with no problem at all. So that leaves the only different viarable as EAC3to.

Another oddity I noticed is that when I extracted the AC3 stream from the TrueHD+AC3 track with tsMuxeR, which was originally demuxed with EAC3to, the dial norm registered as +4 on my AVR. Why this reverted back with the core stream, I have no idea. Maybe tsMuxeR altered the metadata back to it's original state somehow.

If you still want the log file, I can post that when I get home from work later today. I thought that the problem was pretty clear cut (and solved) but I can certainly post it later. I posted this as I had originally forgotten about the "-KeepDialnorm command" that TinTime reminded me of. Now that I know that it exists, I will use it to keep the audio as the studio intended.

peterjcat

31st May 2009, 12:46

Does EAC3to remove or alter dialog normalization when demuxing? I am aware how this could affect encoding but surely it shouldn't be removed or altered when demuxing, should it?

eac3to removes dialnorm by setting it to -31dB, which is the right way of doing it but the Pioneer receivers are known not to deal with -31dB properly for some reason. Use the -keepdialnorm tag in relation to every Dolby (DD/TrueHD) track you want to demux and you should be fine.

tebasuna51

31st May 2009, 14:58

eac3to removes dialnorm by setting it to -31dB, which is the right way of doing it but the Pioneer receivers are known not to deal with -31dB properly for some reason.

Nope, the problem in Pionner receiver was when the value is set to 0 dB, but this was corrected at:
v2.85
...
* AC3 and E-AC3 dialnorm removal now uses "-31db" instead of "-0db"

The -31dB must work fine on all players/recievers.

TinTime

31st May 2009, 17:38

The -31dB must work fine on all players/recievers.

Yep. My Yamaha amp works with -31dB but not 0. Or rather, it works with 0dB Dialnorm but is really quiet, as you would expect.

eac3to removes dialnorm by setting it to -31dB, which is the right way of doing it but the Pioneer receivers are known not to deal with -31dB properly for some reason. Use the -keepdialnorm tag in relation to every Dolby (DD/TrueHD) track you want to demux and you should be fine.

Pioneer amps must be able to handle a value of -31dB surely? This is a valid value. What if the source already has a value set of -31dB? Then the -keepdialnorm switch won't make any difference.

rapscallion

31st May 2009, 18:24

I have both the Sonic 4.2 and 4.3 versions and have been using 4.3 since it came out.

I have read somewhere (don't remember where, but on a forum) yesterday that a number of people have had problems with ver 4.3 decoding DTS to AC-3 and that 4.2 was more stable and the one to use.

Can anyone comment on this and confirm if it's true or not?

Ryu77

31st May 2009, 23:00

Nope, the problem in Pionner receiver was when the value is set to 0 dB, but this was corrected at:
v2.85
...
* AC3 and E-AC3 dialnorm removal now uses "-31db" instead of "-0db"

The -31dB must work fine on all players/recievers.

What about TrueHD? As mentioned earlier it was only the TrueHD track that caused the problem. When I extracted the AC3 core with tsMuxeR from the same problematic track the core somehow reverted back to dial norm +4. Also, my Pioneer AVR didn't display a dial norm fugure, it was one of the AVR's at work that showed something like -27 but the wierd part was they seemed to manage to play the audio.

I don't know what caused the problem but all I know is when I used tsMuxeR exclusively to handle the demuxing that everything was ok.

rack04

31st May 2009, 23:05

Why does eac3to remove the fullrange flag from h264 streams?

honai

1st June 2009, 00:05

Because there are almost always wrong, mostly due to a bug in the old Tandberg h.264 encoder that most European tv stations use.

Ryu77

2nd June 2009, 00:29

Just to follow up on my previous posts...

I tested the disc created with the audio track (Dolby TrueHD) demuxed with EAC3to and then remuxed with tsMuxeR (after re-encoding video) on an Onkyo TXNR906 at work (again) and the display showed DIAL NORM -27dB. This same disc is the one that was spluttered and garbled on my Pioneer SC-LX81 (SC-07 in the USA). Strangely enough the disc displaying -27 seemed a little louder at the same volume setting on the Onkyo AVR.

However, the disc created with the audio track demuxed/remuxed exclusively with tsMuxeR didn't display anything at all on the Onkyo AVR but displays DIAL NORM +4 on my Pioneer AVR (and plays perfectly on both).

Another point is, it was said earlier that EAC3to doesn't remove dialog normalization but instead changes it to -31. If that is the case, why does the Onkyo AVR display -27? Also, why does the Dolby Digital core extracted from the same TrueHD track revert back to +4?

Also, another interesting note. I tested Transformers with a regular Dolby Digital track and it displayed DIAL NORM +4 on both the Onkyo TXNR906 at work and my SC-LX81 at home... ??? So that would indicate that they both indeed use the same measurement system. Maybe my Pioneer AVR didn't like the DIAL NORM -27 metadata setting. It also seems that EAC3to may have handled this TrueHD track different to usual.

SomeJoe

2nd June 2009, 01:31

Ryu77

2nd June 2009, 02:17

Ryu77,

I've had issues with Dolby TrueHD and my Pioneer receiver for a long time. (See this (http://forum.doom9.org/showthread.php?t=143986) thread). I'm virtually certain the issue is some kind of metadata in the TrueHD stream that's being altered by eac3to, tsMuxer, or one of the other common tools that happens to cause the audio on the Pioneers to not play back properly.

I'm going to try again with the latest tsMuxer, and use the -keepdialnorm option on eac3to and see if it fixes the problem.

Gotto go dig out the Iron Man BD for the 57th time ... :rolleyes:

Hello Joe,

I did state above that when using tsMuxeR exclusively (avoiding EAC3to) to demux/remux that the TrueHD track plays without any problem on my Pioneer SC-LX81 (SC-07). I have authored a few discs with TrueHD and DTS-HD MA and they all play fine. Previously I used tsMuxeR to do the demuxing. It was only recently that I started using EAC3to to handle the demuxing and that is when the TrueHD problem occured.

I do like the ease of use that EAC3to offers when locating the main movie playlist and also I believe it handles seamless branching better. However, I am not sure what it is doing to the dialog normalization to make my Pioneer AVR to reject the track. So for the time being I may need to stick with tsMuxeR for all the work. :)

simps

2nd June 2009, 16:14

Hi,

I have a DTS-ES 6.1 24bits track, and I would like to convert it, to a 2CH AC3 192.
Is this the correct command line for it, or am I missing something?

eac3to c:\a\a.dts c:\a\a.ac3 -down2 -normalize -192

Do I have to worry about that 24bit, and use -down16 too?

Thanks.

DoomBot

3rd June 2009, 13:54

Ryu77,

I've had issues with Dolby TrueHD and my Pioneer receiver for a long time. (See this (http://forum.doom9.org/showthread.php?t=143986) thread). I'm virtually certain the issue is some kind of metadata in the TrueHD stream that's being altered by eac3to, tsMuxer, or one of the other common tools that happens to cause the audio on the Pioneers to not play back properly.

I'm going to try again with the latest tsMuxer, and use the -keepdialnorm option on eac3to and see if it fixes the problem.

Gotto go dig out the Iron Man BD for the 57th time ... :rolleyes:

Does this happen on every movie with TrueHD or is from movie to movie with TrueHD i ask because im having what seems to be the same problem, theres movies that are messed up and others that are not and im using a Pioneer receiver aswell. If the audio has problems do you hear it right away meaning through out the movie or is it parts of the audio during the movie?

I take it you have no problems with DTS-HD Master or PCM audio when demuxed and then remuxed?

73ChargerFan

5th June 2009, 05:44

In the log file, if the command was for something like stream 1) please list the .m2ts files that would be reported when listing 1), e.g. 00000.m2ts+00183.m2ts+00184.m2ts

mrr19121970

5th June 2009, 08:03

isn't your request already catered for ?

eac3to v3.03
command line: "E:\TVIX\eac3to\eac3to.exe" "R:\" -LOG="D:\DEMUX\Test1\PASS1_LOG.LOG"
------------------------------------------------------------------------------
1) 00211.mpls, 1:56:54
[105+149+107+109+110+113+114+116+117+119+120+122+123+126+127+129+130+132+134+136+137+139+140+142+143+145+146+148+133].m2ts
- h264/AVC, 1080p24 /1.001 (16:9)
- TrueHD, English, multi-channel, 48khz
- TrueHD, German, multi-channel, 48khz
- AC3, Spanish, multi-channel, 48khz
- AC3, English, stereo, 48khz
- AC3, English, stereo, 48khz
- AC3, English, stereo, 48khz
- AC3, English, stereo, 48khz
- AC3, Portuguese, multi-channel, 48khz

73ChargerFan

5th June 2009, 20:07

That is an BD inquiry. This is the log file I'm talking about:
eac3to v3.16
command line: eac3to 1) 1: chapters.txt 2: taken.mkv 4: taken.dtsma
------------------------------------------------------------------------------
M2TS, 2 video tracks, 6 audio tracks, 6 subtitle tracks, 1:33:25, 24p /1.001
1: Chapters, 24 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, 5.1 channels, 24 bits, 1509kbps, 48khz)
5: AC3, Spanish, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
6: AC3, French, 5.1 channels, 448kbps, 48khz, dialnorm: -27dB
7: AC3, French, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB
8: AC3, English, 2.0 channels, 224kbps, 48khz, dialnorm: -27dB
9: DTS Express, English, 1.0 channels, 24 bits, 96kbps, 48khz
10: Subtitle (PGS), English
11: Subtitle (PGS), English
12: Subtitle (PGS), Spanish
13: Subtitle (PGS), French
14: Subtitle (PGS), English
15: Subtitle (PGS), English
Creating file "chapters.txt"...
[v02] Extracting video track number 2...
[a04] Extracting audio track number 4...
[v02] Muxing video to Matroska...
[a04] Creating file "taken.dtsma"...
[a04] Audio overlaps for 8ms at playtime 0:14:32. <WARNING>
[a04] Audio overlaps for 6ms at playtime 0:24:29. <WARNING>
[a04] Audio overlaps for 6ms at playtime 0:46:23. <WARNING>
[a04] Audio overlaps for 6ms at playtime 0:48:28. <WARNING>
[a04] Audio overlaps for 12ms at playtime 1:06:57. <WARNING>
[a04] Audio overlaps for 5ms at playtime 1:12:37. <WARNING>
[a04] Audio overlaps for 8ms at playtime 1:25:07. <WARNING>
[a04] Starting 2nd pass...
[a04] Realizing DTS gaps...
[a04] Creating file "taken.dtsma"...
Added fps value to MKV header.
Video track 2 contains 134392 frames.
Video track 3 contains 134392 frames.
eac3to processing took 20 minutes, 46 seconds.
Done.

marklar

6th June 2009, 08:20

Hi madshi,

do you plan to add VobSub format support of subtitles to eac3to? It was already disscussed here that it is not supported. But is it planned?

Thanks!

wildchild22

7th June 2009, 02:50

I have a bug report for eac3to when using seamless branching blurays and .w64 audio extension. eac3to creates a w64 file then it detects the gaps and re writes the w64 file. The first file is 4.5 gigs but after it re-writes the w64 file it is only 465 megs. It seems to only write the gap information up to the first gap then it stops. Using the same file with the dts or pcm file extension creates a file the correct size.

DoomBot

7th June 2009, 15:14

Where is madshi, we need him back on eac3to fixing W64 and what ever is wrong with truehd after demuxing and using Pioneer receivers the truehd thing kills me more.

DoomBot

8th June 2009, 01:53

Hello Joe,

I did state above that when using tsMuxeR exclusively (avoiding EAC3to) to demux/remux that the TrueHD track plays without any problem on my Pioneer SC-LX81 (SC-07). I have authored a few discs with TrueHD and DTS-HD MA and they all play fine. Previously I used tsMuxeR to do the demuxing. It was only recently that I started using EAC3to to handle the demuxing and that is when the TrueHD problem occured.

I do like the ease of use that EAC3to offers when locating the main movie playlist and also I believe it handles seamless branching better. However, I am not sure what it is doing to the dialog normalization to make my Pioneer AVR to reject the track. So for the time being I may need to stick with tsMuxeR for all the work. :)

Your right about EAC3to doing something to the demuxed file with truehd, i have tried many movies with truehd demuxing with EAC3to and then muxing them with tsMuxeR and most dont work correctly but when doing the same movies only through tsMuxeR and avoiding EAC3to they all work perfectly. So i sure would like to know what EAC3to is doing to mess the truehd files up.