Repository navigation
Automatic Audio Delay Correction #2528
Description
The fewer issues I have to read, the more new features I will have time to implement, so I ask that you please try these things first
- Check out all the menus and keyboard shortcuts. Maybe the feature already exists?
- Try with the newest version from GitHub
- Read the documentation and FAQ, Known issues, Troubleshooting to see if the feature already exists
- See if someone already suggested this under Issues or Discussions
Description
Hi and thanks for this WONDERFUL app! I've been using it for close to 2 years and can safely say it's blown most of the "competition" out of the park. On Normal Cut mode, you get truly frame-accurate lossless cuts, with every codec, including some of the exotic ones, supported, which is something not all editors can do. It's also very fast. However, there's room for improvement, and one of the ways it can be made better is by the addition of this one feature, which most similar apps have. That's the automatic audio delay correction.
Usually, most of the cuts made using LosslessCut have very high "delay relative to video" values in the audio, and it can be so bad that the audio is behind by a whole second. The audio and video durations sometimes aren't the same. That is so even if the cuts are accurate. Remuxing the file using Avidemux or VDRD usually brings these values down or eliminates them, completely. This also makes the duration for all the tracks the same, even if the only thing done was a simple remux.
Here's an example. This file was cut using LosslessCut, and has the problem I am describing. MediaInfo:
General
ID : 1 (0x1)
Format : MPEG-TS
File size : 420 MiB
Duration : 6 min 10 s
Overall bit rate mode : Variable
Overall bit rate : 9 498 kb/s
Frame rate : 29.970 FPS
Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 6 min 10 s
Bit rate mode : Variable
Bit rate : 8 446 kb/s
Maximum bit rate : 18.1 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 29.970 (30000/1001) FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0 (Type 0)
Bit depth : 8 bits
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.136
Time code of first frame : 00:00:00:00
Stream size : 373 MiB (89%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio #1
ID : 257 (0x101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 6 min 11 s
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : -245 ms
Stream size : 17.0 MiB (4%)
Language : Portuguese
Service kind : Complete Main
Dialog Normalization : -23 dB
compr : -0.28 dB
cmixlev : -3.0 dB
surmixlev : -3 dB
dmixmod : Lo/Ro
ltrtcmixlev : -3.0 dB
ltrtsurmixlev : -3.0 dB
lorocmixlev : -3.0 dB
lorosurmixlev : -3.0 dB
dialnorm_Average : -23 dB
dialnorm_Minimum : -23 dB
dialnorm_Maximum : -23 dB
Audio #2
ID : 258 (0x102)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 6 min 11 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : -261 ms
Stream size : 8.49 MiB (2%)
Language : English
Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
Format : AVC / AC-3 / MPEG Audio
Duration : 6 min 10 s
List : 256 (0x100) (AVC) / 257 (0x101) (AC-3, Portuguese) / 258 (0x102) (MPEG Audio, English)
Language : / Portuguese / English
Service name : Service01
Service provider : FFmpeg
Service type : digital television
Notice how the duration of the audio and video tracks isn't the same, and also the very high "delay relative to video" values on the audio tracks. Now, take a look at the MediaInfo log for the same file remuxed using Avidemux:
General
ID : 1 (0x1)
Format : MPEG-TS
File size : 422 MiB
Duration : 6 min 10 s
Overall bit rate mode : Variable
Overall bit rate : 9 547 kb/s
Frame rate : 29.970 FPS
Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 6 min 10 s
Bit rate mode : Variable
Bit rate : 8 493 kb/s
Maximum bit rate : 18.1 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Full frame 16:9 image
Frame rate : 29.970 (30000/1001) FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0 (Type 0)
Bit depth : 8 bits
Scan type : MBAFF
Scan type, store method : Interleaved fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.137
Time code of first frame : 00:00:00:00
Stream size : 375 MiB (89%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio #1
ID : 257 (0x101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 6 min 10 s
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : 11 ms
Stream size : 17.0 MiB (4%)
Language : Portuguese
Service kind : Complete Main
Dialog Normalization : -23 dB
compr : -0.28 dB
cmixlev : -3.0 dB
surmixlev : -3 dB
dmixmod : Lo/Ro
ltrtcmixlev : -3.0 dB
ltrtsurmixlev : -3.0 dB
lorocmixlev : -3.0 dB
lorosurmixlev : -3.0 dB
dialnorm_Average : -23 dB
dialnorm_Minimum : -23 dB
dialnorm_Maximum : -23 dB
Audio #2
ID : 258 (0x102)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Duration : 6 min 10 s
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Delay relative to video : 3 ms
Stream size : 8.48 MiB (2%)
Language : English
Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
Format : AVC / AC-3 / MPEG Audio
Duration : 6 min 10 s
List : 256 (0x100) (AVC) / 257 (0x101) (AC-3, Portuguese) / 258 (0x102) (MPEG Audio, English)
Language : / Portuguese / English
Service name : Service01
Service provider : FFmpeg
Service type : digital television
This made the duration for all the tracks the same, brought down the audio delay values. BUT, since Avidemux doesn't support the same wide range of codecs and formats that LosslessCut does, thanks to FFmpeg, this got rid of the DVB Subtitle present in the original file that LosslessCut had preserved from the original file. The same also applies to/for some other codecs like Dolby E, etc. that LosslessCut can work with, but Avidemux can't.
So, it'd be so wonderful if this feature was implemented in the upcoming build/release version for LosslessCut. It's such a vital and basic feature for video editing programs, and its addition to LosslessCut would truly set it apart from everything. Again THANKS, and best of wishes.
Activity
AmBintroGoof99 commentedon Sep 5, 2025
Please, take a look at this. It's causing so many headaches. Also, sorting this out will make the app even better!
mifi commentedon Sep 6, 2025
Hi. Have you tried changing advanced settings like
avoid_negative_tsand see if that makes any difference? see https://github.com/mifi/lossless-cut/blob/master/issues.md#cutting-times-are-not-accurateI'm suspecting the duration difference is a side-effect from the cutting process, and it could be a limitation or bug in ffmpeg. Does it happen with all files or only certain types?
Whenever I cut files with normal mode, I always get a black portion of video before the first keyframe after the cut, so I'm not sure how you're seeing frame-accurate cuts in this mode?
AmBintroGoof99 commentedon Sep 7, 2025
Thanks for responding! Yes, I've tried everything! The results are the same using every mode, and any file (except with Normal Cut mode, I've found that the cuts are actually frame-accurate like VDRD...done my testing and still doing).
What I'd like to see implemented is LosslessCut automatically normalizing, handling audio delay the same way Avidemux does. I'm assuming it can be done using FFmpeg because Avidemux too uses FFmpeg's MPEG-TS muxer (this also works on Avidemux's other muxers).
AmBintroGoof99 commentedon Sep 7, 2025
When you remux the files cut using Normal Cut mode with a program like Avidemux or VDRD, both fix the high audio delay values that LC's output came out with. And if you then play them back to back, side by side, you'll notice that LosslessCut's outputs are frame-accurate. I've tried this out by cutting the same file using the exact same cutpoints using VDRD-TVSuite and LosslessCut's Normal Cut mode. They are exactly the same with regards to the frame-accuracy. LC's outputs do the weird duration differences and the audio delay values, but you can tell it's almost exactly the same thing VDRD outputted.
You just need it to deal with these high audio delay values and correct any abnormalities, so the frame-accurate cutting abilities are more "visible".
AmBintroGoof99 commentedon Sep 7, 2025
@mifi If you want to, I can privately share some of the files I've tested these on, so you can see for yourself.
mifi commentedon Sep 12, 2025
Ok you can send to losslesscut@mifi.no
mifi commentedon Nov 1, 2025
Did you send a file? I forgot
AmBintroGoof99 commentedon Nov 3, 2025
Hi, and am soooo incredibly for forgetting about this. It's just a lot happened to me after I wrote in my last message, and this somewhat disappeared from my mind. I'll be sending them immediately after also submitting some more useful data about the files. I'll also be including an FFprobe log in addition to the MediaInfo ones. So, these are the logs for the faulty file.
FFprobe:
And the MediaInfo:
And for the fixed file...FFprobe:
MediaInfo:
Notice how the fixed file no longer has any errors, unlike the faulty one. Even though it lost the DVB subs. But still.
mifi commentedon Nov 4, 2025
Thanks for sending over. You probably already tried it, but I opened the faulty file in losslesscut and then simply remuxed it to .mov inside losslesscut. Then the output file no longer has the "Delay relative to video" metadata. I don't know if that did anything though wrt to the audio sync. I don't really know how to test for the audio sync either, because if it's just 245ms, it's so short that my eyes/ears cannot really notice it either
AmBintroGoof99 commentedon Nov 4, 2025
Thank you so much for responding. Yes, but .mov isn't always ideal for storing HDTV captures, especially when they contain codecs/formats like DVB Subtitles, Teletext, or audio only encapsulated within transport streams.
I don't know what I can do to help you out further with this, but it really would be so great if LosslssCut comes to be able to do this.
I also have some other files with such problems that I can go into detail about, if you'd like.
mifi commentedon Nov 6, 2025
This is really ffmpeg-specific internals, so it's a bit out my league unfortunately. If someone can find an ffmpeg command that can auto correct these delays, then that would be something I could consider adding to LosslessCut but I'm quite clueless how to test this (especially how to verify whether or not the delay is fixed)
AmBintroGoof99 commentedon Nov 6, 2025
Thank you! The way I'd tell they are fixed is by either looking for the "delay relative to video" part to see if it's still there, or look at the value that's next to it. For example, on some of these files, the section and the values don't always disappear, but they're "normalized."
What about LosslessCut's ability to "fix" errors within files, especially .ts? I have one .ts file with MPEG2 video, a few MP2 audio tracks and Dolby E audio. It initially had some errors unedited. I cut the redundant parts out of it with LosslessCut, and the cuts were frame-accurate (I used the Normal Cut mode). However, only about half of the Dolby E audio was preserved. I remuxed the uncut .ts file using VDRD, and got back to LosslessCut again to make the cuts again. This time, not only were the cuts frame-accurate like the first time, but also all the audio tracks, including the Dolby E were preserved in full length.
There were also times when clips cut from that same file or other files using LosslessCut had lots of errors, including audio delay-related, and simply remuxing the files using Avidemux and/or VDRD got rid of the errors completely.
AmBintroGoof99 commentedon Nov 6, 2025
Also, I don't mean to compare LosslessCut with other "competing" apps in a negative way when referencing them. LosslessCut was and is easily the best one around. A lot of well-known apps, and even VDRD most likely wouldn't stand a chance next to it if they were still in development today.
It's just that LosslessCut would become truly untoppable if these features were figured out and added to it.
mifi commentedon Nov 7, 2025
Interesting. Hmm like I said I'm not really experienced with this, but if I run this command, it brings the delay (according to mediainfo) down to a few ms:
Notice the
-itsoffset 0applied all the audio/subtitle tracks. Does that solve your problem?Probably related #216
AmBintroGoof99 commentedon Nov 7, 2025
Thank you soo very much for your help. However, that command only got me the following error:
I also tried with
-map 0but that didn't help, either.Sorry if am bugging you with this.
AmBintroGoof99 commentedon Nov 7, 2025
Should the value for
itsoffsetbe0for the audio delay values to go down automatically?mifi commentedon Nov 7, 2025
are you on windows? if so, maybe you need to convert single quotes into double quotes. you can ask chatgpt also about these kinds of command errors
AmBintroGoof99 commentedon Nov 7, 2025
Yes, on Windows 10. Will try that out tomorrow. Hopefully it'll work this time, and a more stable, straightforward solution will be found for this.
AmBintroGoof99 commentedon Nov 9, 2025
@mifi Hello again, kind man! I just tested the command again with double quotes instead of single, and this time, it worked! THANK YOU SOO MUCH! It worked almost exactly as I expected. It even worked with some little-known, exotic format/codecs like Dolby E.
However, it does seem to have a bit of a problem with DVB and Teletext [subs], in particular, it seems. Because, whenever I'd also map, include them to be carried over to the output, in the resulting file, the video would be unplayable. As soon as I modified the command to exclude the said track[s], it'd go back to normal. I'd really appreciate you "investigating" this, if possible, and also adding this to the app's GUI so that we don't have to run this command every single time for this specific task/operation, PLEASE! I guarantee you it's a touch EVERYONE would love added to their video.
Let me know if you need additional sample files of what worked and didn't work with this command. Again, THANKS SOOO MUCH! You truly are wonderful!
AmBintroGoof99 commentedon Nov 9, 2025
I'm testing this command on multiple files with different codecs and formats to see how it works on different stuff. On one file, it brings the value from -400 to 400ms, not to something like 1 or 20, for example. On others, it brings the value down from -300 to zero, or to 18ms. Some have the values fixed, but aren't played back by some media players. I would do my own research but I don't know where to post this to get a good answer. Hopefully, a solution will be found. This is working almost perfectly, with a few problems to be figured out and worked around.
mifi commentedon Nov 11, 2025
Ok so it's not a silver bullet. TBH I don't know exactly how that command works. I've tried chatgpt but i cannot figure out why
-itsoffset 0even makes a difference. this needs more research and knowledge to solve. I think it's basically the same as #216 (you want to adjust individual tracks offset, right?) - so i'll close this issue but discussion can continue here and in #216AmBintroGoof99 commentedon Nov 11, 2025
Thank you for your help! I will probably have to reach out to FFmpeg developers about this, or even to the Avidemux developers lol.
I'm sure this is close to getting a solution. Thank you for your help. I will keep you updated on new info on this, and hopefully the fix will be added to LosslessCut once it becomes available.
Also, just to clarify, will you be notified if a new comment/reply to this is posted?
Again, thanks soooo much! You are awesome!
AmBintroGoof99 commentedon Nov 11, 2025
And yes, I want the delay normalized/corrected/fixed, you name it! lol...on all tracks, basically, but all of that done automatically, with a simple remux. The way it's done with Avidemux and VideoReDo. Thank you very much!
mifi commentedon Nov 11, 2025
If you have a file that has a delay which is more noticeable, like 1 second, it would be much easier to test/debug it. Because the 200ms delay in the file you shared is not really visible to me. Especially due to the fact that it’s a concert recording (which could already have delays due to speed of sound propagation). And it’s hard to see lips moving at all.
AmBintroGoof99 commentedon Nov 11, 2025
I'm pretty sure I have files with delay that severe. I'll look up and share a few with you.
I have also tried looking at the logs produced by both Avidemux and VDRD to try and get an idea of what they did with the tracks to achieve what am after, but it's too complicated for me to understand.
AmBintroGoof99 commentedon Nov 11, 2025
My understanding is that they are reconstructing the DTS/PTS in anything they're fed with.