VirtualDubMod, BeSweet and Bitrate Questions

Kero777 · Post by **Kero777** » Thu Sep 06, 2007 10:12 pm

Sorry for the double post.

Even with the extra samples because of the Lame Mp3 encoding, VirtualDubMod is telling me that my audio is off because it is too SHORT. That doesn't make sense to me either.

*Runs into a brick wall*

post-it · Post by **post-it** » Thu Sep 06, 2007 11:39 pm

trythil wrote:
post-it wrote:.. the time before your Audio begins Encoding depends on "the Encoder."

Raduim requires 50 milli-seconds to start and then Encodes "Real-Time"

LAME was never that stable; it can vary from 10 ms to 500 ms before Encoding begins 0_0
Stop spreading misinformation.

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

Read the source code (libmp3lame/encoder.h, libmp3lame/lame.c) to verify this.

.. Radium was put to the test back in 1999 and stated that, "yes, MP3's are directly editable."

this test was completed and varified eight (8) years ago with no excuses as to why it works the way it does. The length of the WAV is exactly the length of the MP3. The faster your computer the faster then Encode. Everything Encoded by Radium is Directly Editable. Radium works in Real-Time Mode; always has, always will.

Radium was Real-Time before that name "Real Time Mode" had any meaning. End Of This Non-Sense - in real time

trythil · Post by **trythil** » Fri Sep 07, 2007 12:29 am

Kero777 wrote:Is there a way around the silence without quality loss or a cut file so it syncs up pretty darn close to the original file?

Short of calculating the encode/decode delays yourself (as you know, many MP3 decoders introduce their own delay) and adding the appropriate amount of blank video, I don't know of one.

However...if you're as close as your screenshot says you are, it's close enough. A 29 millisecond discrepancy probably isn't going to kill you, especially not over a video the duration of a typical AMV. (To put it into perspective: At 29.97 frames per second, one frame is around 33 milliseconds long.)

post-it wrote:nonsense

You neither read nor understood my reply. The amount of delay inserted by an encoder pretty much has nothing to do with encoding time, so there's no point in showing encode time graphs.

Your assertion about the padding introduced by LAME (which, from your post, I'm now doubting had anything to do with padding at all) is misleading, as it implies that there is a random factor involved in that padding. There isn't.

trythil · Post by **trythil** » Fri Sep 07, 2007 12:42 am

Quick question for Kero777:

Can you describe your current muxing procedure? It sounds like you've done several things, and I'm having difficulty figuring out exactly what it is you're now doing.

I don't know why VirtualDubMod's muxing is giving you that behavior; you may want to ask a VirtualDubMod developer about that. (Assuming any are currently active.) Avery Lee (VirtualDub's developer) might also know.

Kero777 · Post by **Kero777** » Fri Sep 07, 2007 11:38 am

trythil wrote: ...if you're as close as your screenshot says you are, it's close enough. A 29 millisecond discrepancy probably isn't going to kill you, especially not over a video the duration of a typical AMV. (To put it into perspective: At 29.97 frames per second, one frame is around 33 milliseconds long.)

Thank you for replying again (Sorry for the late reply. I was exhausted and went to bed) I checked the frame difference of mine and it's about a frame and a half... it really bothers me because I can clearly see the difference.

I will try doing what you said and contact the VirtualDub/DubMod developers to see if they know something...

trythil wrote:Can you describe your current muxing procedure? It sounds like you've done several things, and I'm having difficulty figuring out exactly what it is you're now doing.

Of course I can.

Sorry if I was vague. Here is what I am doing:
1) Exporting the video with sound from Sony Vegas (I tried exporting the audio separately, but same results... even using BeSweet)
2) Following E&A's Technical Guide to make an XviD/DivX file by going through the first pass.
3) If the first pass is good enough, I go to Streams> Full Processing Mode> Compression > Lame MP3 > 192kbps CBR. Then I select direct stream copy and select Okay.

When it is done, it is a frame in a half to two frames off. SOME other music conversion codecs don't seem to add any silence in the beginning, but the quality isn't half as good.

Any ideas from anyone? Please? I'm running out of them.

Keeper of Hellfire · Post by **Keeper of Hellfire** » Fri Sep 07, 2007 12:16 pm

trythil wrote: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.

Kero777 · Post by **Kero777** » Fri Sep 07, 2007 12:43 pm

Keeper of Hellfire wrote:
trythil wrote: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...

I've been fooling around with the "delay" option... but just like before it just sets the audio off more, even with negative values like -30 and messes up the audio too, it seems. You can see how much the video and audio differ by going into VirtualDubMod opening your fully compressed video and then going to Streams>Report. The example one I've been practicing on is pictured above.

This is killing me! Who ever figures this one out... Oh, my gosh ... I wouldn't know how to repay you! I obsess over these things.

post-it · Post by **post-it** » Fri Sep 07, 2007 1:15 pm

.. 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" ???

?

Kero777 · Post by **Kero777** » Fri Sep 07, 2007 1:30 pm

post-it wrote:.. 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" ???

?

Thanks for replying again.

I didn't have an option to double 23.976 exactly, but 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.

NeoQuixotic · Post by **NeoQuixotic** » Fri Sep 07, 2007 6:55 pm

Kero777 wrote:Sorry for the double post. Even with the extra samples because of the Lame Mp3 encoding, VirtualDubMod is telling me that my audio is off because it is too SHORT. That doesn't make sense to me either.

http://i211.photobucket.com/albums/bb10 ... reams4.png

*Runs into a brick wall*

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. Although when checking an AVI with WAV audio, the lengths matched perfectly. I also get slightly longer audio streams when using BeSweet with LAME and shorter with LAME ACM.

My guess is that it is a bug in reporting or it is simply normal behavior. Is your video actually out of sync? Because as far as I can tell, any AVI file with MP3 audio will have minor discrepancies in length between the audio and video stream. So unless the sync is actually off, I think you can ignore VdubMod's report.