VirtualDubMod, BeSweet and Bitrate Questions

[Scintilla]

Builds of the default distribution of LAME introduce an encoder delay of 576 samples, end of story.

Wait a minute? Does that really mean, after compressing my video, the audio gets delayed for 576 samples?
That would explain my impression, that the compressed video has a different synching than the uncompressed.

Yes, isn't it amazing how much 30-50ms can do to your syncing after compressing? I might need to stick to PCM audio after all...

Where did you get 30-50ms? 576 samples is only 13ms assuming a standard CD-audio sample rate of 44100 Hz.

And what happens when you create the MP3 with BeSweet and mux it in with VDub(/Mod) without recompressing?

[Scintilla]

Sorry for the double post, but I just thought of something else...

Does your "Interleave options" screen look something like this?



Especially the last two options being checked.

[Kero777]

Thanks for your reply!

I just went and checked over 30 AVI files with MP3 audio and VdubMod always reported the MP3 audio length being ever so slightly shorter or longer.

I did the same thing. My friend that has also used Lame told me that they realized a slight difference in sync between lossless and compressed. When checking their files in Streams>Report, their audio is at least 30ms shorter than the video. Like I mentioned before, I've seen some up to 500ms difference (half a second!)

My guess is that it is a bug in reporting or it is simply normal behavior. Is your video actually out of sync?

Yes, it is out of sync. Unfortunately, I do not think it is a bug because when I loaded my my "test" uncompressed version back into Vegas (or just used the original project file) and then imported my compressed DivX/XviD, I compared the streams and there is a difference. I know now why the compressed will show up longer (how lame adds the extra silence before and at the end), but why does V-DubMod report the audio to be shorter than the video when it should be longer? I even tested the "cut off audio stream when video stream ends function" and nothing. It looks like my video is playing slightly faster than the uncompressed one and then sometimes slower. Loading them both up in Vegas, the compressed video stream does show the silence at the beginning where the silence in generated from Lame, but then for some reason the Lame audio gets ahead for the rest of the video and the last second little bit gets cut off and the audio stream is a straight line (Gets cut off. I tested the middle of my AMV that doesn't end slowly). But, there is definitely difference in the music streams because the two audio streams, one compressed and the original exported from Vegas, do not match up.

[post-it]

.. let us ignore the current problems and try something a little wierd ( from a newbe's point of view, I'll explain later if this works ... )

.. try exporting your AMV from Vegas by Doubling the Frame Rate of the Video.
( i.e. if it was 24 frames per second, change it to 48 frames per second. )
.. leave the Audio in WAV form PCM.

.. When you play that back through Media Player is it "in-sync" ???

?

.. there was 50.00 fps (PAL) and 59.940 (Double NTSC) which were the closest. I tried both of those options and as far as I can tell, yes, it is exactly in sync.

anubisx00 Scintilla and trythil can help me on this one ( just in case I get distracted again. )
.. Save whichever Doubled Video Speed Encode and have Virtual Dub drop the Frame Rate of your AMV to 24 frames per second..

.. now, is the Virtual Dub encode in-sync with the Audio ??
1) if yes .. then Vegas is stretching a frame or two and throwing your timing-off when Exporting at 24 frame per second.
2) if no .. then the Audio actually "is not" aligned to the Video.

.. this test is designed to verify if a possibly problem might be "in" one of your effects/affects/transitions and Vegas is covering it up! ... but if the sync "is off" then Virtual Dub can go frame-by-frame and narrow-down where the error might be.

[Kero777]

Where did you get 30-50ms? 576 samples is only 13ms assuming a standard CD-audio sample rate of 44100 Hz.

Because that's what the report on VirtualDubMod shows. For example, using one of the test avi's I created from a short segment in my AMV, my video stream could be 00:00:14:598, but the audio shows up as 00:00:14:558. A 40ms difference. The weird thing is, the number seems to vary with each different video I try. It will stay the same difference if it's the same video whereas another might be a 50ms difference each attempt to get it to match with the video and another only 32ms.

And what happens when you create the MP3 with BeSweet and mux it in with VDub(/Mod) without recompressing?

I still get a mismatch. I'm not sure if they are the same exact numbers, but I am going to check right now with a short segment of my AMV. Okay, my results:

Original file exported from Vegas with PCM audio: 00:00:14:598
Compressed audio with VirtualDubMod: 00:00:14:558 Muxed in: Same
Compressed audio with BeSweet 00:00:14:655 Wait...

[insert and insane amount of dots here while she goes to experiment with many things]

Muxed in with BeSweet: 00:14:598! I tested this out in Vegas again and there still is a difference even when I convert the new mp3 file back to wav so Vegas won't have any errors (although when I do that, the length is different again!). It's Echoing some. The sounds vibrations are still seen apart. And the one with compressed video and audio has a different length than the uncompressed when shown in Vegas, but this is sort of little. I probably took a look at the MP3 from BeSweet earlier on today and got too frustrated because of the bigger difference in length and didn't try it, but honestly I can't remember if I did it or not!

Sorry for the double post, but I just thought of something else...

Does your "Interleave options" screen look something like this?



Especially the last two options being checked.

Yes, and it looks just like that. Thank you to the extreme, Scintilla! You've helped me so much on these forums. It seems that after using BeSweet to convert the audio, VirtualDubMod seems to detect the differences in the audio and fix the length, but not when you use VirtualDubMod itself? Strange... I think it's really is a lot better than what it was, but I'm still going to do a couple of more tests. The video looks more in sync, but still very, very slightly off. I cannot tell right now though because my eyes have been glued to the computer all day. If I can I will try to make an MP3 or Wav of the two audios on top of each other and then upload it and post it here.

Post-it, I will try your idea as well. Thanks sooo much! That is very clever. I never would have thought of that. Thanks to the rest of you for replying. If I don't reply again tonight then I will tomorrow. I am dead tired again.

[Kero777]

I came across something kind of weird today. I decided to put my uncompressed version into VirtualDubMod and look for a scene change. There was a very good, obvious one at frame 30. I took the compressed version of the video, with uncompressed PCM audio and put it into V-Dub and there was a 1 frame difference... the scene change started at 31st frame. I thought "How does that happen? During the encode to XviD/DivX?" I tested this out by taking the uncompressed video and only compressing the audio. I tried both ways: using VirtualDubMod and then BeSweet. The scene change was at 30 frames. Hmmm...

It seems as though the new version with the BeSweet audio is only 1 frame off from the original (Frame 900 will be 901, Frame 607 will be 608, etc). I'm pretty sure it was more before. I don't know how I notice the difference in timing with just a 1 frame difference (I must have really good vision or it's how I preview everything 800 times before I decide it's right. ). Does this happen to anyone else?

Thanks, everyone. I love these forums.

[Qyot27]

Something that occurred to me: did you use XviD to encode the video, and if you did, did you use B-frames (B-VOPs as I believe it says in the configuration) and not choose the Packed Bitstream option? I doubt this would do anything, but XviD's way of dealing with B-frames is to insert a decoder lag at the very beginning of the video. Packed Bitstream is the way DivX does it - it involves a different method. I'm wondering if using Packed Bitstream wouldn't correct this problem?

[Qyot27]

Something that occurred to me: did you use XviD to encode the video, and if you did, did you use B-frames (B-VOPs as I believe it says in the configuration) and not choose the Packed Bitstream option? I doubt this would do anything, but XviD's way of dealing with B-frames is to insert a decoder lag at the very beginning of the video. Packed Bitstream is the way DivX does it - it involves a different method. I'm wondering if using Packed Bitstream wouldn't correct this problem?

Even though it's obvious, this only is the case for using AVI as the container, as that's the only reason the hacks exist in the first place. The other way of testing it would be to mux the video into MP4 (making sure to remove N-VOPs when doing so) or MKV (making sure the --native-mpeg4 option is set for mkvmerge), and see if the sync is still off.

[Kero777]

Something that occurred to me: did you use XviD to encode the video, and if you did, did you use B-frames (B-VOPs as I believe it says in the configuration) and not choose the Packed Bitstream option? I doubt this would do anything, but XviD's way of dealing with B-frames is to insert a decoder lag at the very beginning of the video. Packed Bitstream is the way DivX does it - it involves a different method. I'm wondering if using Packed Bitstream wouldn't correct this problem?

Qyot27, you figured it out! Thanks so much! I preview my video and it looks exactly like the original. When checking frames in VirtualDubMod, it seems to be dead on now!

I was following the guides here: http://www.animemusicvideos.org/guides/avtech/xvid.html. I could have misread something and didn't select that option. Re-reading it now I see that it says these two separate things about BVOPs (underlining my concerns):

Max consecutive BVOPs specifies the maximum amount of these B-Frames that can appear in a row. DivX 5 only encodes 1 B-Frame in a row. XviD's default is 2 which is the highest you should go (as each extra B-Frame increases the processing power needed to decode). However, there is a compatibility concern. DivX5 can decode 2 B-Frames in a row but not when Packed bitstream is selected. This guide recommends keeping 2 B-Frames and deselecting Packed bitstream but if you want to keep things really compatible with DivX 5 and some hardware players then you may want to reduce the max BVOPs to 1.

And

Packed bitstream is a function established by DivX 5.1 which in theory allows better decoding and reduces bad audio sync. This is true until you start using more than 1 B-Frame. If you use 2 B-Frames this should be deselected in order to ensure that people will be able to watch this encode correctly using the DivX 5 decoder.

Should I now reduce the "Max consecutive BVOP's" to 1? I did my tests with 2 and it was fine, but if I don't reduce it to 1, what will happen exactly? Compatibility/sync issues for people who don't have XviD?

Here is my exact setup for my XviD videos compatible with DivX now that I have selected Packed bitstream :



This should be my last question on this topic (I hope! ). I cannot thank you enough.

[Scintilla]

Should I now reduce the "Max consecutive BVOP's" to 1? I did my tests with 2 and it was fine, but if I don't reduce it to 1, what will happen exactly? Compatibility/sync issues for people who don't have XviD?

I would say yes, reduce it to 1, but be aware that this will hurt your compressibility somewhat.

However, that page is a few years old by now, and the newer versions of the DivX decoder may not have this problem anymore. I would suggest installing a copy of the DivX codec (version 5 or later), encoding the video with FourCC DX50 (DivX should then be the first choice to decode this instead of XviD, assuming you don't have ffdshow or have its DX50 support disabled), and playing it back to see if there are any problems.