V8 Ultimate: Clip positioning discrepancies in audio upon rendering AVI to MP4 (RESOLVED)

[tanguero]

I have a clip of an old family video from which I'd like to remove a few words' worth where the narrator says something better not shared with other family members with whom I plan to share the edited video. Nothing novel or difficult, one would think.

I did this by creating cuts in the video clip to remove the offending part. In fact, by removing about 1 second (rather than, say 0.1 second) I was able to make the first part of the previous sentence flow into the second part of the following sentence pretty convincingly (by luck).

The problem is that the rendered video is off by just enough of a fraction of a second (say 1/4 to 1/3 second) that the offending word does come through, and my sentence fine tuning just sounds like a nonsensical sentence in the rendered version, since the word breaks were 2-3 words off on each of the two cuts.

In the preview, it plays perfectly in all cases. Playing as project hearing the end result sounds perfect, playing each clip one at a time in "clip" mode also sounds perfect in that the start and end points are exactly where I intended them to be. Zooming in to see individual frames and looking at the waveform it is also perfect.

Everything is on the main track (no overlays) and nothing is overlapped on the main timeline. The project properties are also set to be identical in terms of fps (29.97). My source material is 480p 29.97 fps 4:3 AVI, rendering to 480p 29.97 fps 4:3 MP4/H.264.

Yes, I could cut the source clip into 2 separate clips manually and delete the offending part manually and import them separately but of course, that's the most basic thing that a video editor like VS is supposed to let you do, and it seems too basic a defect to be an undiscovered weird bug.

I'm hoping that I'm either missing something obvious, or perhaps there's some tricky workaround that someone else has already found.

[tletter]

The problem is that the rendered video is off by just enough of a fraction of a second (say 1/4 to 1/3 second) that the offending word does come through

Suggest editing the sound in Audacity and then adding it back into your VSP.

tletter
https://www.youtube.com/user/tletter

[lata]

From Share --- Try deselecting Smart Render, does that improve things?

[tanguero]

From Share --- Try deselecting Smart Render, does that improve things?

No, exactly the same. I repeated it with a test on a small section of the file and it is 100% reproducible with simple test cases.

The general problem is that the audio starting and ending times are shifted about 1/2 second later than the video. Note: they are NOT out of sync!! The audio starts 1/2 second after the video starts (but in sync) and 1/2 second of the audio that corresponds to the deleted part at the end of the clip, continues into the following unrelated clip (which then continues with its own audio after the first 1/2 second, also in sync).

With further tests, I narrowed this down to an interaction in rendering between the AVI decoder and the MP4 encoder in the rendering process. I say that because:
- If I render to MPEG-2 instead of MP4/H.264, I do not see this problem.
- If I convert the raw AVI into MP4 first and use that as my source material for further editing in VS, I do not see this problem, even for subsequent rendering to MP4/H.264.

This gives me two reasonable workarounds, both of which involve an extra recoding. But it seems to be a real bug. I did see somewhere a reference to audio interleaving in AVI every 15 frames (which matches my "guesstimate" value of about 1/2 second), so the bug may be related to that, but that's of course speculation on my part.

Given the scarcity of current use cases with DV-originated AVI files at 720x480, I doubt we'll see a fix for this anytime soon, or at all, but hopefully my notes here, and others' comments, will serve to document the issue and workarounds for others who may encounter this. I edited the title to reflect the use case that seems to elicit the problem.

[lata]

Thanks for the additional info
If you were to split audio, that will mute the video clip and place an audio clip on one of the sound tracks.
Does that also render with this audio shift.

[tanguero]

If you were to split audio, that will mute the video clip and place an audio clip on one of the sound tracks.
Does that also render with this audio shift.

A good thought, and one that I would have thought had a better than even chance of working. The results were quite unexpected:

- If I split the audio from both adjacent clips and rerender (with smart render off in all cases just to eliminate that variable), the result is exactly the same (~1/2 s audio overlap--didn't help);
- If, however, I then move the audio transition point even as little as 1 frame to the left (that's just 0.03 s, which would be imperceptible) the problem disappears! Even odder: if I move the audio transition point 1 frame to the RIGHT (which in theory would be adding a little MORE of the already intrusive audio track, the problem also disappears! As it does if I overlap the audio tracks by as little as 1 frame (also imperceptible). Note that in all these cases by "move" I am not time shifting the audio relative to the video (i.e., I'm not using the white cross pointer); I am only shifting the starting or ending point of the audio relative to the video (the black asymmetric arrow pointer).
- And if I move the audio transitions back to the original aligned-with-video locations (explicit move, not by using Undo), the problem reappears--go figure!

Bottom line on this "split audio" suggestion: It doesn't solve the problem directly, but it does give a tool for a simple alternative workaround.

[tanguero]

Oh, and one more experiment that I did with a weird result: I moved the endpoint of the audio of the first clip 1 frame to the left and left the starting point of the audio of the 2nd clip alone (so I had 0.03s of silence at the transition--imperceptible on preview, of course). Result: the rendered video has, quite unexpectedly, a full 0.5s (approx) of silence at that point ("removed," to boot, from the 2nd clip, notwithstanding that it was the 1st clip whose audio I "shortened").

So this bug and this particular workaround has its very specific idiosyncrasies as well, and I'm sure I haven't explored all of them in the limited testing I did.

[lata]

I dug out a few older recordings from my Pana GS 400 Mini DV camcorder to try a few tests
The recordings did not have any voice content just background noise.
The DV-Avi used interlacing Lower Field First which is normal for those types of video
Using Video Studio Mpeg4 defaults to Frame Base / Progressive, rendering this did have a discrepancy in the length of the video by a few frames, the audio was also out of sync but again only a few frames, the first frame being muted / flat lined.
I then created a new Share Mp4 profile to use Frame Based, now rendering was better same duration as original, although the audio had shifter 1 frame with the first frame again muted, flat lined.
Even so playback and the 1 frame shift was not noticeable.

Can you check your settings to make sure that Interlacing is same as original, maybe that will improve things?

[tanguero]

Hi Trevor, thanks for your followup experiments. I did as you suggested, but the problem remains the same. I wouldn't have expected a difference, since interlacing issues should affect things over a frame or two, as you saw, rather than 1/2 second, but it was easy enough to check out.

Specifics on what I tried: Confirmed my AVI was interlaced lower-field first with MediaInfo, changed the "Ulead MPEG-4 vio Driver" encoder Frame Type option from "Frame Based" to "Lower Field First" ("Upper Field First" being the only other option of the three available).

Incidentally, the problem with the audio starting point being out of sync seems to be specific to this Ulead MPEG-4 vio encoder. It's the only option under the MPEG-4 rendering button, but if I choose "AVC/H.264" as my video output (which suprisingly creates an .m2t extension file), the bug disappears (regardless of whether I choose Frame Based vs. Lower Field First, or H.264 vs. MPEG-2). This uses the Ulead MPEG.Now Encoder. And, as I mentioned at the start, a couple of other encoders I tried like .wmv also don't exhibit this problem.

A side question (that may well deserve its own thread): What's with "AVC/H.264" as a rendering output video choice at the same level as "MPEG-4"? The former is a compression scheme and the latter is a container format. They are not mutually exclusive as they refer to different layers of the protocol. The encoders behind those buttons both seem to offer various MPEG encodings, but with an overlapping set of options. And incidentally, I can change the .m2t extension created by the AVC/H.264 selection to .mp4 and the result plays back just fine. Googling .m2t vs. .mp4 offers relevant information, but none explains the odd labelling of these two rendering choices in VS.

[lata]

AVC/H.264 are used for Bluray files Transport Stream
I have a Panasonic AVCHD camcorder that records to MTS Bluray compliant files
Editing those using VS and render to Same as Clip or AVC/H.264 produces a file using m2t extension and should be Bluray Compliant
Using those files to burn a Bluray Disc should not require rendering again although the files extension is now changed to use m2ts, I believe required by the Bluray player to recognise the file as a compliant BD, and that’s about all I know about those files.

[tanguero]

Well, I narrowed down the bug to a very-easily applied workaround, easy enough that I'm labelling this RESOLVED (even though the bug still exists). Apparently, this problem occurs when the audio sampling rate is set to 32 kHz (which I chose since my source material was at that rate so made no sense to resample higher). If I change the encoder settings to choose audio oversampling at 48 kHz, the problem disappears. I also checked all the other available audio sampling rates (24 and 44.1 kHz) and they are all fine--only 32 kHz presents the bug.

Obviously, there is no clear connection between the 1/2 second audio boundary error and the few microseconds of difference in sampling intervals--it's probably the extra comma in line 2,455 of the source code.

So I decided to go the extra mile and try other encoders at 32 kHz. Turns out that very few have this option (MP4 is one of them)--most of the others show 48 kHz as a greyed-in non-changeable audio sample rate. The only two that I found that did allow a 32 kHz option were MP4 audio (creating an .m4a audio-only file), and AVI. And both do present the problem and if I change the sample rate to anything else, the problem goes away. The time offset is the same in the case of .m4a and somewhat less but still noticeable in the case of .avi.

*** Moral of the story: Don't use 32 kHz as an audio sampling rate in your final rendered file, even if your source material has that sampling rate, and you should not run into this bug. ***