VirtualDubMod, BeSweet and Bitrate Questions

[Kero777]

I haven't been so frustrated in a very long time. I've been trying to figure this out for two days straight. I appreciate all your suggestions, but I have tried everything that was suggested about the audio sync at least 10 times each. I made sure everything was checked off, even in that "Preload MS" button under streams and NO luck with Lame MP3. I definitely did try clicking the button "Change so video and audio durations match" and I THOUGHT it would work, but the frame rate is the same. I cannot even set the audio track to delay to the appropriate time because it will just come out too short or too long. Do you think this could be some sort of glitch? Of course other types of Audio like CCITT-A LAW works perfectly (I checked the audio wavs and the uncompressed and the compressed sync EXACTLY the same). I was browsing on the site to see if anyone had the same problems and nothing that was suggested for them worked for me. I did notice that the people who used this method tended to use VirtualDub 1.6 or higher. I use VirtualdubMOD 1.5.10, but I don't think that would make a difference. I did notice that VirtualDub has a specific pull down menu for "Audio" and there is a "Source Audio" option checked which I'm not sure if I have.

Scintilla, could you please give me a link to the Radium MP3 codec? I searched on google, but I couldn't seem to find a working link. It doesn't seem to be used a lot for AMVs though... In fact, I've never seen anyone use it. Everyone uses Lame. I really hope I don't need to stick with uncompressed audio. It takes up so much more space...

If anyone wants to experiment with this with one of their clips I'd be forever grateful (trust me!). Here is what the example file looks like before I encode the audio (It makes no difference if the audio is attached to the video or not. Same results for me):



And After the Lame MP3 Encode:



You can see the difference when I import into Vegas (Yes, I dared to import an MP3 into Vegas for a pic )



The other codec (CCITT-A LAW) that I tried out matches the Uncompressed Wav 100%. I used this method before and I always could have sworn that the sync was slightly off (If I can figure this out I will re-encode them) and now I know it is. Could there be something I'm not clicking or that I'm missing/messing up? Please, please, respond if you can. I really don't want to have to stick with PCM audio for my final. Thanks a lot for reading this and trying to help me out.

[Scintilla]

If you're encoding with BeSweet, make sure you're not using the "Change Frame Rate" functionality.

As for Radium, you can get it <a href="http://icrontic.com/download.php?d=86">here</a>.

[post-it]

If you're encoding with BeSweet, make sure you're not using the "Change Frame Rate" functionality.

As for Radium, you can get it <a href="http://icrontic.com/download.php?d=86">here</a>.

=3 hehe, I thought I was the only one who ever used Radium 3 ^___^; used it for years.

[Kero777]

If you're encoding with BeSweet, make sure you're not using the "Change Frame Rate" functionality.

As for Radium, you can get it <a href="http://icrontic.com/download.php?d=86">here</a>.

Thanks for replying again.

It's not selected. The weird thing is BeSweet is still adding 65 milliseconds to my audio. Some at the beginning and some at the end. (Yes, it really does make a huge difference in timing!)

Thank you for the link as well. I was reading up about it and every single person that used it in the past said that they hated it and the quality wasn't half as good as Lame.

Does anyone have any more suggestions for me to try, please? Otherwise I'm going to keep the PCM... I'm such an unlucky person ... or maybe just pretty stupid... There's GOT to be a way to fix this... *Tries it again after about the 100th time trying*

[post-it]

Yikes! ... that's version 1.263 .. there was a flaw in that design, the "Joint Stereo IS" X_X

the flaw was first noticed when used with Virtual Dub 1.3b's introduction. Do Not Use "IS"

[Kero777]

Yikes! ... that's version 1.263 .. there was a flaw in that design, the "Joint Stereo IS" X_X

the flaw was first noticed when used with Virtual Dub 1.3b's introduction. Do Not Use "IS"

For the Radium? Thanks for that information just in case!

This is the weirdest thing... Maybe I have an older version of Lame that does this... but then again I got everything in the AMVAPP so I have no idea what's going on. I'm... so... frustrated... Grrrr....

Changing the bitrate seems to make a difference with how much shorter/longer the conversion is... but nothing is close enough to the way I want it. This is making no sense to me what-so-ever. Why would that make a difference? The lengths seem to be random.

[post-it]

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

Radium Encodes are predictable and can be re-duplicated over and over and over ^_^
which means; if the Audio is off Sync, just adjust the "Delay" in the set-up section.

[Kero777]

if the Audio is off Sync, just adjust the "Delay" in the set-up section.

Thanks again for your replies, Post-it... but I have tried that (with Lame at least). No luck. I even tried exporting uncompressed from Vegas and importing into Audacity and Winamp and exporting from them to see if those programs would make a difference, but I still get a silent delay ranging from 30ms-100ms at the beginning and a small amount at the end. It throws my timing off too much. *Sigh* I guess I'm kind of stubborn about Lame working because of the horror stories I've heard about other codecs. I'll probably be up all night again trying to figure this out. I didn't spend all that time on my videos for the timing to be off and for my audio to sound not-so-good.

[trythil]

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

[Kero777]

Thanks for telling me that very useful information, Trythil! I read about it on a couple of different webpages. Here is a good link: http://lame.sourceforge.net/tech-FAQ.txt From what I understand, the silent samples put at the beginning and end of the Lame file are the number of samples that need to be skipped at the beginning and end to come out with the exact number of samples from the original .wav file. But what I don't understand is how everyone tweaks it so the audio matches their video length exactly or pretty darn close. Some AMVs I examined in VirtualDubMod which contained the Lame Codec had their video dead exact to the ms of the audio and some were off by as little as 1ms-40ms and some were in the low and high hundreds. 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? Maybe I'm just being paranoid and it doesn't put off my sync as much as I think ... but as much as half a second seems like a lot of time...