How to use eac3to to edit AC3 to avoid transcoding

[bendermac]

This is something that has bugged me for a while now and it seams many of you don't know how to handle AC-3 audio, without the need to transcode to lossless (FLAC, DTS-HD MA,PCM) after it was synced. In order to sync an AC-3 audio track to a new source, just use eac3to to edit the AC-3 audio. A long time ago zeropc showed me this technique, which he was teached by jj666. Now the method itself wont be always perfect, but the tracks I've heard so far or even edited myself are pretty good. Most of the time you wont even notice a thing. Editing an AC-3 audio track needs to be done in 32ms frame window. This means the audio sometime wont be synced down to the level you might want it to be. It usually drifts between 2ms to 31ms. Nothing the average listener will notice

How do you edit an AC-3 track with eac3to?

It's rather simple

1. transcode the AC-3 to WAV and import into your audio tool of choice and sync it to the new source
2. keep notes of the editing timecodes (hours|minutes|seconds|milliseconds) and delays you needed in order to sync the audio - I recommend to work with multiple track lines
3. create the proper cmd lines for eac3to to edit your original AC-3 audio so it will synced

use the initial delay if needed

eac3to source.ac3 target.ac3 +/-value

then use your editing timecodes + delay values

eac3to movie1.ac3 movie2.ac3 -edit=0:10:00.000,100ms
eac3to movie2.ac3 movie3.ac3 -edit=0:45:43.123,-54ms

and so on

eac3to will add silence if you add -silence at the and of the command line if required

eac3to movie3.ac3 movie4.ac3 -edit=0:50:00.000,50ms -silence

If you don't use the -silence cmd, eac3to will loop the audio for the given delay. so experiment what would work better for the edit.

If the original AC-3 audio has a DialNorm Flag and you want to keep it (I always did keep them), make sure to use -keepdialnorm cmd at each cmd line

eac3to movie3.ac3 movie4.ac3 -edit=1:05:00.450,24ms -keepdialnorm

If you use eac3to to edit DTS audio from a DTS LaserDisc add the -dontpatchdts as well to keep the file in it's original 20bit. If you leave it out, eac3to will automatically patch it to 24bit.*

You can create a batch file and after a few minutes you'll get a synced and transcode free audio file.

I hope this little guide will help you on your future projects, as I believe you shouldn't always transcode unless it's absolutely needed.




*Info provided by borisandoris

[spoRv]

Thanks for the guide! I'd like to move it to the Restoration guides subforum, if you don't mind.

Just a note: while a 2ms out-of-sync wouldn't be noticed by anyone except (maybe) a meta-human with superpowers, a 20+ms (or even bit lower) would be noticed by almost anyone; I remember, when I worked on Halloween resync, that the safe limit to avoid sync problem recognition is, IIRC, just around 20ms, probably 15ms; so, if the sync in your AC-3 track is off more than 20ms, I'd suggest to use the "usual" methods instead.

[BDgeek]

Hi bendermac, thanks a lot for this guide!

I'd appreciate some help to clear out some doubts. Does this method work for DTHD tracks?

I tried it but the output tracks is idential to the input track (I used windiff to compare the files). But when I tried the track converted to w64, it worked fine.

To make things clear, what I need to do is remove the first 167ms of Batman 89' DTHD BD to sync with the UHD.

First I tryed applying a -167ms delay in MKVtoolnix, but after demuxing the track I discovered the actual applied delay was -213ms. I get this same result if I apply any delays value between the ranges of -200 to -100ms.

I noticed this happens all the time with MKVtoolnix, the applied delay with DTHD track varies a wide range from the specified value. For DTS-HD MA tracks the intervals are smaller but still there. Only in w64 the delays is fixed to what was specified.

Does anyone know a way to make this work without transconding the track? I mean to do is to the remove the first 167ms from the track.

Thanks a lot!

[Chewtobacca]

Code:

eac3to input.dtshd output.dtshd -167ms

Mux the result, and check the sync.

[bendermac]

@BDgeek

Yes, works with DTSHDMA as well. But a DTS frame is only 12ms, while the AC3 frame is 32ms.
If you use a DTSHDMA and you need to edit it - Not talking about an initial delay - , I recommend to transcode to wave. Then you no framesize limits. Export to FLAC (remux to MKV) or PCM (for BD usage) if you don't have a DTSHDMA encoder.

[BDgeek]

Thank you both Chewbacca and bendermac for such valuable contributions!

I'm still learning a few basic tricks on eac3to and ffmpeg (haven't dealt with command prompt since 1995 and in those days I didn't do much else besides playing games at the PC)
For now, I couldn't make it work besides converting to w64, otherwise the resulting delay range is far too removed from the ideal 167ms.


Bendermac,

could you please share why you choose to leave dialog normalization on?

I mean, is it just a matter of preserving the original track as much as possible or there's more to it?
I've always heard it's best to remove dial .norm., it's a default feature on EAC3TO and the user FAQ recomends not to disable it, hence my question.

Thanks again!

[Chewtobacca]

I've always heard it's best to remove dial .norm., it's a default on EAC3TO and the user FAQ recomends not to disable itm, hence my question.

It's recommended to remove dialnorm when decoding; otherwise, the dialnorm will be be baked into the resulting track.  When extracting, one can opt to retain dialnorm; it's just preference. (When editing, the bulk of the track is left untouched, so you can retain dialnorm.)

[BDgeek]

Thanks a lot Chewtobacca,

BTW, when decoding with EAC3TO a lot of times it detects clipping and applies a second pass with some volume ajusting to aviod this clipping. In you opinion, is it a positive or negative thing (specially if one is going to work on the track later to sync to another source)?

I mean, should I avoid this second pass? BTW how does ffmpeg handles this? I couldn't figure out

[Chewtobacca]

Of course, avoiding clipping is positive.

[BDgeek]

Ok, thanks chewie!

sorry to keep rolling into this, but I'd just like to understand it better

If clipping can be avoided just by lowering the volume on the track, so it's not really a 'baked in' thing right? I mean, it's a fixable issue.

Because making a parallel to video, if there's white clipping on an SDR source for instanace, now matter how dim you can make the picture on image editors or display settings, the information is lost for good.

I assumed audio clipping worked the same way