It's not straightforward (and it's off topic), but as I understand it, clipping can be a consequence of (a) issues with the encoding (b) the way in which the decoder supplies its output to eac3to: libDca became the default decoder because it sends its output in 32-bit, giving eac3to more headroom with which to work than Arcsoft, which works differently.  Clipping that is baked into the PCM master used to create the DTS-HD MA cannot be "fixed" in the same way, although there are filters that attempt to improve it.  If you want any more detail, you'll have to ask madshi.

With video, it depends on whether the clipping takes the form of (a) a hard cut-off or (b) spikes outside the TV range that result in lost information in certain circumstances on certain displays.  The former cannot be fixed (just smoothed out by filters).  The latter can be fixed in AviSynth.

I do want to add one note to this excellent guide:

I utilize the -dontpatchdts option when working with 20-bit 44.1khz DTS LaserDisc audio in order to preserve the stream as is. eac3to will automatically pad these to 24-bit if you do not use that option. Not sure if it affects the audio, but I always make it a goal to keep these streams as original as possible with no extra processing included. I've yet to run into a DTS LaserDisc with dialnorm but I guess its possible.

I use MPEG Video Wizard which is just a lot easier to do NLE without re-encoding.

(2022-10-25, 04:57 PM)borisanddoris Wrote: I do want to add one note to this excellent guide:

I utilize the -dontpatchdts option when working with 20-bit 44.1khz DTS LaserDisc audio in order to preserve the stream as is.  eac3to will automatically pad these to 24-bit if you do not use that option.  Not sure if it affects the audio, but I always make it a goal to keep these streams as original as possible with no extra processing included.  I've yet to run into a DTS LaserDisc with dialnorm but I guess its possible.

Info added to 1st post

Getting started on the LA Confidential ac3 track and a quick question @bendermac (or anyone else), when you talk about the 32ms window are you saying each edit needs to be a multiple of 32?

And another question, when making your list of edits, I take it each timecode is based on the time after the previous edit? So if I cut 5 seconds at say 30:00:00 so that that point becomes 29:55:00 and then another edit is needed 2 seconds later I would use 29:57:00 at the timecode?

The way I do it is to drop the SYNC track in Premiere, and the TO BE SYNCED TRACK in as well. I then begin to align them and note each point for an edit and actually cut/delay as I go. This way, the timecodes I get don't need additional math done to get them right when I moved on to the second phase of the project in eac3to. I actually use an Excel sheet to keep track of all the edit points and the +/- delay needed but can always consult back to my Premiere timeline if something is off or if an edit is too noticeable. Sometimes I'll move the edit point itself slightly so that it is better hidden. It took me some time to get the hang of it for sure, but the important part of this is to document, make edits as you go in your non-linear editor, and then make sure to test each output from eac3to to ensure a smooth transition. I did a project recently that had over 25 edits, but then a week later did one with only 4. Hopefully LA Confidential is an easy one for you to start with.

@alexpeden2000

You need to do it like borisanddoris said.
32ms is the size of the frame of a AC3 file. So if your actual delay is for example +36ms, you will go out of sync by +4ms

Ok, trying to do the LA Confidential edits using the Useac3to GUi - the first edit (a cut) worked fine but the second one (adding some silence at the start) doesn't seem to work. This is the cmd line I'm using:

%_.ac3 -edit=0:00:00.000,10ms -silence -keepDialnorm


It processes fine but the output file is the same length as the input one. Just wondering if I'm going wrong somehwere?

10ms is too short a value for an edit considering an AC-3 frame is 32ms, eac3to is most likely rounding it down to the nearest integer value (ie zero). 10ms is less than a quarter of a video frame so should be imperceptible in playback, unfortunately with the lossy codecs you have to be a bit looser when it comes to edits (or re-encode the track).
The only way to get a delay of that value would be to apply it as an overall delay when muxing to mkv, assuming the final target is an mkv file