Audio stutter with merging after cutting and re-encoding

[Sotee]

I have a video, I cut it in parts (on keyframes only), then re-encode these parts and merge them together. A slight video jitter appears on each part transition and the audio stutters sometimes after it for a fraction of a second.

If I re-encode the whole merged video again the video jutter is gone, but now there is an additional audio stutter every time exactly on each part transition, which makes it even worse for watching.

Is there any way I could go around this or the moment I re-encode the first time is the moment I lose the possibility to create a fluent video (with audio)?

[ricardouk]

There's no info on what kind of source file you have or tools you use, can you provide a sample and more info? Is the end goal to reencode the parts in to 1 file or do clean edits without video conversion in to 1 file?

you can use Virtualdub2 or Avidemux to edit mp4 videos and with carefull keyframe cuts you can join all of the parts in to 1 file without any video or audio conversion.

if that doesnt help you can open the file with virtualdub2 and export the video to Cineform, open the cineform export on Virtualdub2 and do the edits and export to your favourite video format.

Hope it helps

[Sotee]

I use avidemux to cut the parts, then re-encode with handbrake after some cropping and finally merge these with mkvtoolnix. The goal is to achieve a fluent video, but I can't manage to do that. Source is bluray.

[ricardouk]

can you provide a short sample with the problem? I never used any bluray disc but i'm not sure avidemux can properly do "clean" audio cuts with bluray audio formats as it does with video "keyframe" cuts. Have you tried virtualdub2? I'm no expert in the audio field so wait for other opinions.

[Sotee]

The problem is not in the cuts or the merging, it appears after re-encoding the cuts and merging them.

To clarify:
1) If I cut with avidemux and merge with mkvtoolnix - no problem
2) If I re-encode after cutting and then merge - the problem appears

If I extract the mka from the created mkv, there is no problem with its sound - there is no stutter. The stutter appears when combined with the video, because the video receives jitter on transition after the re-encoding.

[ricardouk]

Hi, english is not my native language so i might have some problems understanding/replying, if you have no problems with step 1 why not stop right there, why are you trying step number 2? what is your end goal? are you "clean keyframe" cutting in setp 1 and in step 2 you're "fine tuning" your edits for the final video? Sorry for any trouble understanding your problem.

[Sotee]

I wrote above I am cropping thus re-encoding and going to step 2). If it's not clean keyframe cut step 1) will fail.

[Sotee]

Actually the keyframe (I-FRM) is only the start [A]. The end one [B] is a P-FRM.

[sneaker]

Note:
1. Video and audio frames usually have different lengths. It's unlikely they align 100% on your cut points.
2. Certain audio formats have things like encoder delay/pre-roll and padding. This makes it difficult to cut and re-append audio without glitches depending on the format.
3. mkvmerge has 2 different append modes (see mkvmerge doc about --append-mode option). With the non-default append-mode and manually setting fps in mkvmerge you may receive more "clean" timecodes (at the expense of av sync in some cases)
4. I'm not sure avidemux can cut all Blu-Rays correctly. I expect problems with open GOPs.


I don't know why you split, re-encode and then later re-append. I would not re-recommend this.

[Sotee]

I split, because I want different crops, not a single crop. I tested different audio formats with no success.

[sneaker]

I split, because I want different crops, not a single crop.

What exactly do you mean? Does the encoded resolution switch between the parts or only some have bigger black bars than other parts (like Dark Knight on Blu-Ray is always 1920x1080 but the bar size changes)? If you want a result like the Dark Knight Blu-Ray I recommend using AviSynth.

I tested different audio formats with no success.

Basically all lossy audio formats are affected. Also, if you cut the source you already get the problem if the source audio format has the problem. Don't split the audio even if you decide to split the video.

[Sotee]

Same resolution, different crops - for example scene A crop 100 pixels from top, scene B 100 from bottom.

I can't use the source audio since the final video length is different (10s larger) due to the re-encoding and jitter on transition.

[sneaker]

Use AviSynth.

[Sotee]

Okay, I found the problem - it was a container issue.

I managed to cheat it with demuxing with tsMuxer and then merging again with mkvtoolnix. The file ended up with the intended length (no extra 10s) and there aren't any video/audio stutters, but the synchronization is not 100% accurate this time (there is some +/- ms noticeable only at certain times when characters are speaking). This is better than previous version however.

If I manage to fix this too somehow, I'll update the thread. Anyone with a theoretical knowledge why this happens?

[sneaker]

Yes. It's not a container issue per se. Like I said mkvmerge has 2 different append modes. The non-default one will probably get you a similar result as your TS experiment (manually setting fps in mkvmerge can also "clean" the timecodes). But like I also predicted with the same AV issues.

[abolibibelot]

You could do the trimming and the cropping in a single step with a relatively simple Avisynth script, as suggested above. Then do the encode with MeGUI or ffmpeg (Handbrake doesn't accept an Avisynth script as source). If you never used it, provide more information about the format of the source video and how you want to crop it, so someone can help you design a template script.

[Sotee]

The A/V synchronization issue came from first part which had some strange start, so I just cut some frames from it, re-merged and now all is fine.

The whole process was:
1) Cut all parts with avidemux
2) Custom crop each and encode with handbrake
3) Merge with mkvtoolnix, demux with tsmuxer and merge again with mkvtoolnix

mkvmerge has 2 different append modes (see mkvmerge doc about --append-mode option).

Yes, I tested it with other stuff and adding --append-mode track (the non-default append option) in additional options in mkvtoolnix output window seems to do the same as step 3) from above.

[abolibibelot]

The whole process was:
1) Cut all parts with avidemux
2) Custom crop each and encode with handbrake
3) Merge with mkvtoolnix, demux with tsmuxer and merge again with mkvtoolnix

Which, again, could have been done in fewer steps and with no intermediate files and with more control using Avisynth and ffmpeg. Avidemux could still be useful to conveniently visualize the trimming points, and set them on key frames – but since you are reencoding anyway you should be able to cut anywhere, regardless of the frame type in the source video. (Avidemux can also directly encode as MKV but it's reportedly not as reliable as other methods.)

Quick 'n' dirty example :

video = FFVideoSource("X:\path\to\the\source video\Name of the file.mp4") # requires the ffms2.dll source plugin (other source plugins can be used depending on the format of the source)
audio = FFAudioSource("X:\path\to\the\source video\Name of the file.mp4")
source = AudioDub(video,audio)
chunk1 = source.Trim(0,10500).Crop(0,20,0,-10).AddBorders(0,14,0,16)
chunk2 = source.Trim(15800,20300).Crop(0,8,0,-12).AddBorders(0,10,0,10)
chunk1 ++ chunk2 # for this to work the resolutions have to match, so the net result of the cropping + adding of borders should be the same for each chunk

Then save this script as "Name of the file.avs" (if you save it in the same directory as the source video file you can omit its complete path inside the script), then run the ffmpeg command to encode :

"X:\path\to\ffmpeg\ffmpeg.exe" -i "X:\path\to\the\script\Name of the file.avs" -c:v libx264 -crf 20 -preset slower -c:a aac "Name of the file [trimmed, cropped].mkv"

You can preview the result of the script with either VirtualDub2 or AVSPMod (which acts as an Avisynth GUI and suggests functions or settings relevant to each function).

[hello_hello]

I split, because I want different crops, not a single crop. I tested different audio formats with no success.

As others have said, use an Avisynth based GUI rather than Handbrake. In case you do, I'll shamelessly plug my CropResize script so you don't have to worry about calculating the correct cropping to prevent distorting the picture if you resize.

I'd recommend MeGUI, as it's Script Creator adds the standard stuff to a script for you (so you don't need to know anything about AVisynth), but it also makes it easy to modify the script manually.

After you open a source with MeGUI's Script Creator, if you don't use it to crop or resize etc, the script MeGUI creates will look something like the first screenshot. For the second, I added 3 lots of Trim and CropResize, to crop frames 5474 to 11632 differently from the rest. The Script Creator has a video preview and it displays the current frame number at the top. When you've added the cropping you can encode the video in one go, no splitting beforehand necessary.

The video should be exactly the same duration after encoding, even if you split the source video first, so I don't know what's happening there.
10 seconds is quite a bit to be out.

[hello_hello]

Okay, I found the problem - it was a container issue.

I managed to cheat it with demuxing with tsMuxer and then merging again with mkvtoolnix. The file ended up with the intended length (no extra 10s) and there aren't any video/audio stutters, but the synchronization is not 100% accurate this time (there is some +/- ms noticeable only at certain times when characters are speaking). This is better than previous version however.

If I manage to fix this too somehow, I'll update the thread. Anyone with a theoretical knowledge why this happens?

Most extraction programs write any audio delay to the extracted audio so it can be applied again when adding it to the encoded video. TSMuxer appears not to do that, so it could be the cause.

Have a look at the source file with MediaInfo to see if it reports an audio delay.

MeGUI has a HD Streams Extractor under the Tools menu. It extracts with eac3to, and it adds silence to account for any delay when extracting.

[Sotee]

since you are reencoding anyway you should be able to cut anywhere

If you aren't cutting the start of each part on a keyframe there will be A/V synchronization problems even with re-encoding.

[poisondeathray]

since you are reencoding anyway you should be able to cut anywhere

If you aren't cutting the start of each part on a keyframe there will be A/V synchronization problems even with re-encoding.

Not in those cases; (when you use avisynth, or any video editor that decompresses the file)

Because the "cutting" is done in the uncompressed domain . The file is already "decoded" before cutting. There are no "keyframes" in that state; or another way to look at it is every frame is a "keyframe" now, so you can cut anywhere

Since you are re-encoding the whole file anyway, that's the "better" way to do it since you can cut anywhere. And you are less likely to have join issues or glitches. Also, it's faster than manually cutting physical files and encoding each, then appending each. You can do it all in 1 go with 1 script

[Sotee]

The file is already "decoded" before cutting.

Oh, that explains things, thanks.

Any GUI version of AviSynth without scripts and such, or some alternative?

[poisondeathray]

Any GUI version of AviSynth without scripts and such, or some alternative?

Not really;

avisynth requires scripts, it's a script language of sorts . There are semi- GUI's for it like avspmod, but you still have to write scripts; it's more of a previewing mechanism. But you can see how your "edit" is working and so forth. You can see how much to crop or resize etc... and adjust

Or you can try some free,open source NLE's like shotcut .

But I would recommend learning avisynth basics when you have time - it's very useful for many types of A/V manipulations

[Sotee]

every frame is a "keyframe" now, so you can cut anywhere

Btw, what's the difference between this way and encoding with HB with keyint=0 and RF0, and after that doing the cutting with a GUI program when all frames are I-frames? Is it faster with AviSynth?

[poisondeathray]

every frame is a "keyframe" now, so you can cut anywhere

Btw, what's the difference between this way and encoding with HB with keyint=0 and RF0, and after that doing the cutting with a GUI program when all frames are I-frames? Is it faster with AviSynth?

Yes faster;

Typically you don't want to want to keep the CRF 0 intermediate (large filesizes), so you'd have to encode that again to the final format

So using avisynth you don't have to encode the physical CRF 0 intermediate, then cut it, then encode a 2nd version . ie. You don't waste time encoding a middle step, and you don't need large HDD space for the intermediate

You specify the cuts in the script, using a preview method like avspmod and encode the script directly.

[Sotee]

Yes, but it will be faster only for closed GOPs, right? If the file is open GOP then you can't avoid the middle step?

[poisondeathray]

Yes, but it will be faster only for closed GOPs, right? If the file is open GOP then you can't avoid the middle step?

Theoretically if it's closed GOP, you can cut the file directly without any of this

(But many blurays use open GOP, especially AVC ones)

[Sotee]

However, you can't ever cut the file directly on non-keyframes (be it GOP or not) without the risk of corruption. Speaking of which reminds me to ask whether such tool (for checking a video file for corruption) exists?

For example, many files (that are not properly cut) would display white squares at random parts/times - is there any way to check for the existence of such possible corruption?

[poisondeathray]

However, you can't ever cut the file directly on non-keyframes (be it GOP or not) without the risk of corruption.

Yes, a true keyframe, or IDR frame for AVC.

An open GOP "i" frame, which is misidentified as an "IDR" frame by many software. That's the problem. You can't cut on those

Another problem is you might have thousands of frames in a BD before you reach that true IDR frame. The frequency of IDR frames is not high enough for where you WANT to cut.

Speaking of which reminds me to ask whether such tool (for checking a video file for corruption) exists?

For example, many files (that are not properly cut) would display white squares at random parts/times - is there any way to check for the existence of such possible corruption?

I don't know of any that can do this with any accuracy