Rocky says rip it out, so I'm gonna do that, and probably remove thdmerge from the distribution. It's sad, because it means generating bluray-compatible muxes with eac3to is more difficult. He says it's fine in DGDemux because while we gaps-correct both, neither one is delay-corrected. It would sti...

You could not write the same delay (+1001ms) in the AC3 file name, and the same delay (+1001ms) would not need to be specified for the AC3 track when muxing. Again, eac3to corrected the AC3 track (to within 9ms). So, the THD track and AC3 track created by eac3to are 992ms out-of-sync. So you are sa...

Darn, it's not working good with -destpath. I'll fix that tomorrow.

I may just remove the automaticity and have the user do it by hand if needed. Let's see.

Re-download 3.49_test and see if it pairs things up better.

I just dropped a thd+ac3 with DELAY on mkvtoolnix and it split them and gave them the same delay. So we're good, right?

OK, sorry, I got delay vs gaps confused again. Don't forget I'm a stooge. Yes, streams are not delay corrected but are gaps corrected. Best would be if I wrote the same delay in the AC3 name but until that happens, you can do it manually as below. If you have to load them separately in mkvtoolnix, w...

Peter wrote: ↑

Fri Feb 02, 2024 4:03 pm

eac3to does not correct the THD delay.

I believe that is wrong.

So, when muxing, a +1001ms delay needs to be specified for the THD track that eac3to created (just like on the original disc, since it wasn't corrected).

Umm, no.

The small difference in delays is inconsequential. I'll look into logging an error.

OK, all I gotta do is check only the first part of the file name: 00000 - 4. So should be a Sunday picnic. In case yer wondering, Britney suggested that. And here I thought she was just a dumb blonde. I shudda known there was a reason why DG keeps her around. Not what yer thinking!

Looks like Peter may have found the cause. I'll check that and report back.

Hmm, that's a great point. Thank you for the thorough report, Peter . Just in time for the 3.49 release. But who coded that? Was that you, Sherman ? Nah, I take full responsibility. I would make excuses but you wouldn't believe them anyway. In my defense, it works for 2: out.thd 3:out.ac3, just not ...

Your wish is my command.

Thank you for your report. Try this: http://rationalqm.us/eac3to/eac3to_3.49_test.rar * Fixed -destpath option when it is the last option on the command line. * Stopped eac3to from generating the log file twice. * The new rules for the log file location are: 1. The -log path is used if present. 2. I...

I needed the full command line.

Please show me a screenshot of the destination directory after the failure. The file names have to be as I specified. Thank you.

Can you give me the actual command line that UsEac3to runs? I think it may be using some of that funky _%*blah syntax and that is confusing things.

I'll decline then. Anyway, it would be unlikely to ever reach a point where its priority rose above other things, given our workload.

It shouldn't matter which version you use. Do you get this message at the end: "Merging THD and AC3 for [filename]" If so, is there an error message: "Could not execute thdmerge.exe. Is it missing?" The .thd and .ac3 files must both be present with the same names except for the extensions, which mus...

I would guess that the thdmerge.exe file is not present. Try taking it from our distribution and placing it in the same folder as the eac3to.exe used by UsEac3to. If that does not work, please ask about it in the UsEac3To thread at doom9.

Sorry for the rant, guys. I cleaned up after myself. Be careful trusting my judgment. I'm a stooge!

@SomeHumanPerson

Nothing is ruled out. Tell me more about your use case for Dolby-E. Thank you.

Yes they are different formats, and yes, typically one doesn't want to demux raw LPCM. SomeHumanPerson clearly stated " At most, for LPCM, it should be wrapped to RF64 WAV (.wav or .w64)."

Not sure if the -test switch is even relevant anymore but I use it occasionally just to make sure the version is correct and noticed the noted lines below today. Just an FYI as it doesn't seem to affect eac3to functionality. Thank you for the report. I couldn't find those strings in eac3to and I ha...

Cool, I'll make a release this morning. Thank you for your testing and patience.

Please re-download and try again.

-destpath="d:\My Folder\"

You always must give the quotes.

I'll fix it now. Thank you for testing.

The quote syntax will be supported.

i forgive u