While editing, I noticed the audio thumbnails didn’t accurately reflect what was playing. After a few sanity checks, I found a workable solution, but not an ideal one.
When extracting the audio, the audio thumbnail was properly synced. I have to emphasize, the 2 audio tracks sound exactly the same, as they should. Only the audio thumbnails differ. Extracting audio and linking it to the video track manually worked fine, so I have to assume it’s because of how the mp4’s audio was stored, but as far as I can tell it’s ordinary AAC. Anyone else encounter this issue?
I can’t reproduce this with the 25.04.3 appimage and a randomly selected clip from one of my cameras. The thumbnails look identical between the extracted and grouped clips, and appear to be synchronised to what gets played.
Can you reproduce it with other clips created by a different device?
Okay, I tried a different clip with the same ffmpeg settings, and it didn’t show a delay. After looking through MediaInfo, I think I found the culprit.
The working video had these values at 13ms. I have to assume Kdenlive’s audio thumbnailer doesn’t account for this delay. The delay is necessary, as the audio is in sync with video during actual playback, and whatever Kdenlive uses to extract audio recognizes this and extracts the correct stretch of audio. At that point, it no longer has any delay metadata as a standalone .wav file, and the audio thumbnail renders correctly.
I know Kdenlive’s audio thumbnail generation was recently updated, could this have been an oversight? Either way, it’s out of my depth, and it’s manageable with only 1 file having this issue. Would love to see a fix in the future still.
Alright, bug filed, here’s the link if anyone feels like taking a crack at it. The original video I had this problem with came from Steam’s game recording feature. At the start of the clip I was toggling Fullscreen on and off a bunch to get the game window to the correct resolution, but that’s the only unusual circumstance. I guess that threw off encoding enough that the video stream was shorter than the audio stream, creating a delay. That’s total speculation, but ffmpeg preserved the delay even after transcoding to mkv with mp3, vorbis, opus, and PCM audio codecs. That, in combination with the metadata showing the delay, makes me think this is an intended feature for container codecs.[1]
But also, I’ve done enough baseless speculation as-is. I’m way, way, WAY out of my depth here. ↩︎
