Posts: 631
Threads: 88
Joined: 2019 Jan
Thanks: 548
Given 836 thank(s) in 342 post(s)
Country:
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.
Posts: 432
Threads: 27
Joined: 2015 May
Thanks: 61
Given 82 thank(s) in 68 post(s)
Country:
I use MPEG Video Wizard which is just a lot easier to do NLE without re-encoding.
Posts: 608
Threads: 79
Joined: 2015 Feb
Thanks: 395
Given 425 thank(s) in 207 post(s)
Country:
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?
Posts: 896
Threads: 162
Joined: 2015 Apr
Thanks: 224
Given 490 thank(s) in 258 post(s)
Country:
@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
Posts: 608
Threads: 79
Joined: 2015 Feb
Thanks: 395
Given 425 thank(s) in 207 post(s)
Country:
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?
Posts: 2,052
Threads: 56
Joined: 2016 Dec
Thanks: 162
Given 1011 thank(s) in 614 post(s)
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