I recently encoded some Hi8 and MiniDV tapes, but I seem to have only gotten an audio sync error with the MiniDV encodes. I am trying to create smaller files for USB, so that is why this step is necessary. The audio appears to be streaming little early in the encode, but I have no idea why. As the original DV file does not have this issue. I have tried searching the forum for similar issues, but have come up empty handed. I was wondering if I could get some help on this. I have attached the debug file.
The first thing I would recommend, is to try whether enabling "Config->Input->Decoding->CFR output" helps.
Also mediaifno reports:
Delay : 634
Delay : 634 ms
Delay : 634 ms
Delay : 634 ms
Delay : 00:00:00.634
Delay : 00:00:00.634
Delay, origin : Stream
Delay, origin : Raw stream
Delay relative to video : 0
Delay relative to video : 00:00:00.000
Delay relative to video : 00:00:00.000
since the delay relative to video is zero, there should be no delay.
And the only delay that gets added for the muxing is to compensate the encoder delay.
Which 41ms in your case.
This looks all fine.
To check that the intermediate files are okay, you could enabled "Containers->General->Keep intermediate files" and check the length of the extracted and reencoded files.
The audio and video reencoding calls seems correct and I can see no 'warnings' or similar in the log that would directly idicate a problem.
Does the delay stay constant form the beginning to the end or does it seem to change?
(29.04.2024, 12:36)Selur Wrote: The first thing I would recommend, is to try whether enabling "Config->Input->Decoding->CFR output" helps.
Also mediaifno reports:
Delay : 634
Delay : 634 ms
Delay : 634 ms
Delay : 634 ms
Delay : 00:00:00.634
Delay : 00:00:00.634
Delay, origin : Stream
Delay, origin : Raw stream
Delay relative to video : 0
Delay relative to video : 00:00:00.000
Delay relative to video : 00:00:00.000
since the delay relative to video is zero, there should be no delay.
And the only delay that gets added for the muxing is to compensate the encoder delay.
Which 41ms in your case.
This looks all fine.
To check that the intermediate files are okay, you could enabled "Containers->General->Keep intermediate files" and check the length of the extracted and reencoded files.
The audio and video reencoding calls seems correct and I can see no 'warnings' or similar in the log that would directly idicate a problem.
Does the delay stay constant form the beginning to the end or does it seem to change?
Cu Selur
Hi Selur,
I actually already had "Config->Input->Decoding->CFR output" enabled.
As for the comparing file lengths:
Original file: 1 h 2 min 34 s 251 ms
Intermediary File (.wav): 1 h 2 min 33 s 891 ms
Intermediary File (.aac): 1 h 2 min 33 s 891 ms
Output File: 1 h 2 min 34 s 357 ms
I have attached the debug file for this job.
I don't know if this matter, but the original files were transferred via WinDV instead of captured by analog means.
(30.04.2024, 05:31)Selur Wrote: I see no problem in the processing.
Only thing I spotted in ffmpegs output was:
[avi @ 00000200b3581a40] Switching to NI mode, due to poor interleaving
So you can try whether:
using Vapoursynth instead of Avisynth (no clue why you use it)
using AviSource (Filtering->AviSynth/Vapoursynth->Misc->Source->Prefer AviSource for .avi input)
using another audio encoder
remuxing the content to mkv using mkvtoolnix before feeding it to Hybrid, or
makes a difference.
If the delay is constant throughout the file you could also try adjusting the audio delay in the audio tab.
Seeing
Delay : 634
Delay : 634 ms
Delay : 634 ms
Delay : 634 ms
Delay : 00:00:00.634
Delay : 00:00:00;19
Delay : 00:00:00.634 (00:00:00;19)
Delay_DropFrame : Yes
Delay, origin : Stream
Delay, origin : Raw stream
Time code of first frame : 00:00:00;19
and if the delay of 634ms seems about right, you can try this (inverted to -634ms) as a delay value for the audio.
Cu Selur
I did try Vapoursynth the other day, and still got the same results with Avisynth. I use Avisynth because it seems to be recommended by The Digital FAQ for de-interlacing old video footage. I'm not opposed to using Vsynth though. Just haven't come across it being recommended for my line of work. But maybe I am out of the loop?
Anyway, I used Vsynth again a few minutes ago, and checked the box for "Prefer AviSource for .avi input". But I got the same results. I tried Avisynth with the 634ms delay (already had the "Prefer AviSource..." option enabled), but I still got a mismatch in sync. After writing this, my results came back for trying Vsynth under the same conditions mentioned before, but with 634ms delay. Just to see if it was related to any de-interlacing by Avisynth coupled with the delay. And I still received the sync issue.
I put the clips in Adobe Premeire and the difference in sync is about 9 frames (or 300.3ms). Considering my results were the same before with a 634ms delay. I'm going to try a longer delay and see if that gets me close to what I'm looking for. I will report back with my findings.
So, this is interesting. I added 5,000ms to the audio delay, and I got the same sync results as before. Meaning, the audio did not move from where it was before. Very odd. Here is the debug file.
remuxing the content to mkv using mkvtoolnix before feeding it to Hybrid
+
?
In your MiniDVSsyncDelayIssues where you wrote that you used 5000ms you did not adjust the audio queue:
F:\Captures\tests\MiniDV test footage.avi;0;aac;2;bitrate;160;FDK;low complexity;32000;0.00;;-41;3754.251;pcm;0;1;don't change;;false;;false;2;false;;;;true;false;;;true;48000;unknown;pcm;afterburn_nolimit;false;true;false;;1/1;;0;0;;None;54:_:15;10;20;0;1000;12;false;;pcm;false;3;;;;;2.82;16;-n;4;GPU;NVIDIA CUDA;;2;false;F:\Captures\tests\MiniDV test footage.avi;true;false;;;false;2;;;-1;;
the audio queue entry did reflect your change, so this did nothing.
Looking at the passthrough debug output, I noticed tons of:
