Lame MP3 Encoding SLOW in VirtualDub

[Zach]

I've always used Lame for MP3 encoding my plain audio (music from my CD's), but now with my (relatively) new DivX player and soon-to-be mass conversion of my mpeg2/AC3/LPCM files from my DVR, I installed, the DirectShow filter and ACM filter so I could use it in VirtualDub.


It works great, but it's incredibly slow!

For testing purposes, I have a roughly 500 MB wave file (49:36 mm:ss). Converting it offline (with lame.exe) to 128 kbps CBR, it only takes 1:24 minutes:seconds.

Okay, but if instead I let VirtualDub do the conversion, it takes over 12 minutes!

Is this a VirtualDub issue? Or is this a Lame DirectShow/ACM issue (whereby I should take this question to HydrogenAudio)?

Edit: This is with VirtualDub v.1.6.19.

[LoRd_MuldeR]

Make sure you use an up-to-date build of LameACM:
http://www.rarewares.org/files/mp3/lameACM-3.98b4.zip

Also make sure you select "Lame MP3", not "MPEG Layer-3" in VDub/VDubMod ;)

If it still is slow, you might want to compare the encoding speed with Avidemux, which has a built-in LAME encoder...

[Zach]

Make sure you use an up-to-date build of LameACM:
http://www.rarewares.org/files/mp3/lameACM-3.98b4.zip
I did.

Also make sure you select "Lame MP3", not "MPEG Layer-3" in VDub/VDubMod ;)

I did.

FWIW, I know that I frequently state in most of my posts that I'm a video noob, but the same classification doesn't apply to my audio expertise. In fact, I work with audio for a living. (I'm a Principle DSP Design Engineer.) ;)


Alright, I take either no one has this issue, or more likely, no one has bothered doing a benchmark comparision. I guess I'll take my query to HyrdrogenAudio.

Thanks!

[squid_80]

What are the exact steps you do in virtualdub? Are you converting it using save avi, save wav or export raw audio?

[Zach]

First, I am feeding a little AviSynth script to VirtualDub:

video_original = AviSource( "test.avi" )
video_noaudio = KillAudio( video_original )
audio = WAVSource( "test.wav" )
video_dubbed = AudioDub( video_noaudio, audio )
return video_dubbed

(For what it's worth, the test.wav was just demuxed from the original test.avi earlier, and examining it inside CoolEdit, aka, Adobe Audition, there's nothing strange about it.)

Now, if I re-encode the video (Full-Processing, Compression=DivX 6.6.1 Codec [2 Logical CPUs]) and just do a "Direct stream copy" of the Audio, the conversion takes 3 minutes (for the ~50 minute video/audio stream).

If instead I also do a "Full processing mode" of the audio and set the compression to Lame MP3 (44100 Hz, 128 kbps CBR, Stereo):

http://img521.imageshack.us/img521/2091/lamevb5.jpg

...the same AVS file (using the same video compression/settings in VDub) takes 15 minutes to convert.

Converting the wave file offline (with lame.exe) only takes 1:24 minutes:seconds, so I'm wondering why it takes 11 extra minutes to do it inside VirtualDub.

Oh, and the wave file is also 44.1 kHz stereo, so it's not like I'm inadvertently resampling the audio, not that that would justify the 11x slowdown even if I were.

[squid_80]

Now, if I re-encode the video (Full-Processing, Compression=DivX 6.6.1 Codec [2 Logical CPUs]) and just do a "Direct stream copy" of the Audio, the conversion takes 3 minutes (for the ~50 minute video/audio stream).3 minutes? That seems very quick to encode ~50 minutes of video. In fact that's somewhere around 400fps. What frame size does the video have?

If instead I also do a "Full processing mode" of the audio and set the compression to Lame MP3 (44100 Hz, 128 kbps CBR, Stereo):What happens if you choose mpeg layer-3 128 kBit/s, 44100 Hz instead of lame?
How long does it take to perform Save WAV instead of Save AVI?
How long does it take if you do direct stream copy for video and full processing for audio?

[Zach]

3 minutes? That seems very quick to encode ~50 minutes of video. In fact that's somewhere around 400fps. What frame size does the video have?

It's 352x240, but it's already a DivX stream, so I guess the encoder is just repacking data the most part. <shrug> (This is really a question for the makers of DivX--I'm not privy to what they do behind the scenes. :p)

What happens if you choose mpeg layer-3 128 kBit/s, 44100 Hz instead of lame?
Can't. The format list is empty, even with the "Show all formats" checked. I suspect this should be normal as Microsoft's internal MP3 codec (straight from Fraunhofer) is only a decoder and not an encoder.


How long does it take to perform Save WAV instead of Save AVI?
1:41 (minutes:seconds)


How long does it take if you do direct stream copy for video and full processing for audio?
2:43 (minutes:seconds)


Interesting. It's still almost twice as long as an offline conversion, but a far cry from the 11x slow down. I wonder why VirtualDub finds it so difficult to merge the streams together.

[DarkZell666]

If you set full processing for the video, it's actually reencoding it completely (no matter what the original video format was).

So basically, this is what you're observing :
1 - Video Full proc. + Audio Copy = ~3'00
2 - Video Full proc. + Audio Full proc. (LAME) = ~15'00
3 - Video copy + Audio Full proc. (LAME) = 2'43
4 - lame.exe (audio alone) = 1'24

Result 1 just doesn't look right compared to results 3 and 2 (which look perfectly normal). In fact, results 1 and 3 are so close I suspect you actually did the same manipulations by mistake ;)

[Zach]

In fact, results 1 and 3 are so close I suspect you actually did the same manipulations by mistake ;)

1 & 3 are non-comparable, so your conclusions are either biased or faulty. ;) You're just getting hung up on the numbers and not thinking the context through.

Well, I can't prove it to you... obviously. You'd have to be here looking over my shoulder. But I assure my measurements are correct and I'm not making some dumb "mistake."

Video+Audio = 15 minutes
One or the Other = ~3 minutes



It's hard to mess up on the video because "Full Processing" is on by default, and audio is just copy by default. And if I don't set the compressor, I end up with a 1.5 GB file! It's hard not to notice that, ya think?

About full processing always reprocessing, I always assumed that was the case, too, until squid_80 questioned the time. This video clip is one of my test video clips that I use to play around with AviSynth when experimenting with various filters. I have literally re-encoded it over 250 times over the last year, and this 50-minute video clip always takes around 3-5 minutes to encode depending and what I'm doing to it in AviSynth. As God as my witness, I tell you no lie. (What motive would I have to lie anyway?)

Okay, well, never mind then. I'll figure it out on my own.

[LoRd_MuldeR]

It's 352x240, but it's already a DivX stream, so I guess the encoder is just repacking data the most part. <shrug> (This is really a question for the makers of DivX--I'm not privy to what they do behind the scenes. :p)

That is not the case! Avisynth/AVISource() will decode the input video (no matter what formt it is) and send it to the host-application (VirtualDub) as raw/uncompressed data. Therefore VirtualDub can not do "Direct Stream Copy" with AviSynth input - it would create an uncompressed AVI file, probably various Gigabytes in size! So you will have to use either "Full Processing Mode" or "Fast Recompress". Both of them do a complete re-encode of your video!

You can avoid that the following way: Open your AVI file directly in VirtualDub (if it opens via AVISource(), it will open in VirtualDub too). Then goto "Audio" -> "Wave Audio..." and choose your WAVE file - this will replace the original Audio stream with the Audio stream from your WAVE file. Now set Video to "Direct Stream Copy" - that is important! And finally set Audio to "Full Processing Mode" and choose the Compressor you want.

[squid_80]

This video clip is one of my test video clips that I use to play around with AviSynth when experimenting with various filters. I have literally re-encoded it over 250 times over the last year, and this 50-minute video clip always takes around 3-5 minutes to encode depending and what I'm doing to it in AviSynth. As God as my witness, I tell you no lie. (What motive would I have to lie anyway?)

Okay, well, never mind then. I'll figure it out on my own.I'm sorry but there's just no way it could take 3-5 minutes to compress 50 mins of 352x240 video into mpeg4. You say it takes 2:43 to do direct stream for both - that means it's only taking 15s to do the divx encoding. Something is just not right. I say open the .avs script in virtualdub and post a screenshot of what you see when you go to file->file information.

EDIT: Wait, it is remotely possible to get that sort of speed if your source if very lightly compressed e.g. mpeg1 or mpeg2, not mpeg4 and minimal mpeg4 compression options are used. There's still something not right though:
How long does it take to perform Save WAV instead of Save AVI?
1:41 (minutes:seconds)
1:41 + ~5 mins for encoding video to divx (according to you) = ~6.41 mins. This should be the longest time you see if both video and audio are set to full processing mode (which you have to do if you're loading an avisynth script into virtualdub, otherwise you end up with uncompressed data).

[Zach]

First, it turned out to be a Vista issue, I suppose, because now I'm back on XP, and the Lame audio multiplexing issue in VirtualDub is now gone.

Second, it's rather of rude and arrogant of you guys to consistently assert that I'm either making up my benchmarks or am repeatedly making some dumb mistake even after I assure that I am not. To that end, I took some screen shots in VirtualDub.

As I stated originally, how or why DivX is re-encoding the file so quickly is a question for them, not me.

(To remove all "well, it must be a AviSynth thing," I loaded both the AVI and WAVE files directly in VirtualDub, and then I proceeded to encode.)

File Information
http://img244.imageshack.us/img244/7003/fileinfokq3.jpg


Video (Full Processing, DivX), Audio (Direct Stream Copy)
http://img244.imageshack.us/img244/3958/01directcopybd2.jpg


Video (Full Processing, DivX), Audio (Full Processing, Lame MP3)
http://img244.imageshack.us/img244/7199/02lamemy6.jpg


For what it's worth, using just direct copy for the audio...

Fast Recompress : 2:05 (DivX selected in compression settings)
Direct Stream Copy : 0.04 (yes, four seconds)


Moral: Next time you are so sure of yourself, don't be.

[Zach]

And for good measure, here's the original AVS script where I'm back to my original "about 3 minutes" to encode.

http://img244.imageshack.us/img244/2011/avsinfoep3.jpg
http://img244.imageshack.us/img244/1618/03avszn2.jpg

(The resolution increase is just two 16 pixel borders I'm adding to the top and bottom to make it DVD compliant. When I originally made the video eons ago from a VCR tape recording, I made a typo when resizing it. The tape is in the city dump now with two years of garbage on top of it, so I'm stuck with error.)

[DarkZell666]

Hmm, it's not so much about being rude, it's more about a very uncommon situation that needs very precise information (more than a rough "it's 3 minutes for this, 15 for that") to be pinpointed.

What makes this so uncommon is this insane rendering rate (500fps+ !!!). This is usually my muxing rate (not my encoding rate), so if you actually own a Core 2 Duo E6850 (or AMD equivalent), this explains your encoding speed (320ish*y resolution is fast indeed, just not usually over 200fps in my case). Who said giving hardware information was useless ? :rolleyes: (no sarcasm here, I really thought myself giving hardware information was irrelevant most of the time ... until today :D).

In fact, things might have been clearer by posting screenshots of vdub's (low) performance under Vista (but I actually see no mention of vista in the whole thread until your last posts, so how anyone could have guessed is beyond me ;)).

I understand your frustration, but how frustating is it to help someone that doesn't give enough useful information ? So far so good, you fixed your problem, but how did you gather it was a Vista issue ? Did you read some info elsewhere ? Or did you just have a gut feeling somehow ? (never underestimate the power of intuition©).

[Zach]

First, you can tell it's Vista from the screen shot which I posted BEFORE you guys launched into your OT chides about my video encoding being done incorrectly since "speeds like that are impossible" (paraphrasing).

Second, this thread was about the audio processing path, but you guys got hung up on the video processing and wouldn't let up regardless of my assurances that I was correctly processing the video.

Last, did you miss my opening statement?

First, it turned out to be a Vista issue, I suppose, because now I'm back on XP, and the Lame audio multiplexing issue in VirtualDub is now gone.

That's the only reason I am assuming it was a Vista issue. For reasons unrelated to this MP3 problem, I ditched Vista and reinstalled XP. Once I got everything reinstalled and backed-up last night, I tried the above encode again, but this time it didn't take 15 minutes like it did under Vista. <shrug>


And yes, I'm overclocking my E6600 to 3.33 GHz. But that is truly irrelevant. My query was about why encoding the audio takes only 1.3 minutes offline but 15 minutes in VirtualDub. You guys, instead, got hung-up on my video processing speed.

Anyway, rest assured that I don't believe any malicious was intended on your part. But put yourself in my place. I repeatedly told you I was encoding the video correctly (I should I know was there), and you repeatedly countered with that I was not (you would not know since you weren't there). You assuredness directly implies one of only two things: I'm either a liar or I'm a bubbling idiot. How is that not offensive? ;)

[squid_80]

Maybe next time we'll all just keep quiet and not bother to help you at all.

How long does it take to perform Save WAV instead of Save AVI?

1:41 (minutes:seconds)We established it wasn't the audio encoding that was slow, which left either the video encoding or muxing. The extreme numbers for the video encoding seemed to be pointing to the culprit and I asked for screenshots to know what sort of video we're dealing with, you disappear for 3 days then come back calling us a bunch of knobs because you've solved the problem by ditching vista and reinstalling XP. Heck, why didn't we think of that rather than asking for more information and examining test results?

[Zach]

Maybe next time we'll all just keep quiet and not bother to help you at all.
With all due respect, considering the grief your "help" has caused me, I would view that more as a favor than a threat. :p Thanks for offering!

[DarkZell666]

First, you can tell it's Vista from the screen shot which I posted BEFOREWrong, so many people use customized visual themes nowadays, it could have been a WindowBlinds or StyleXP theme for all I know, so, as you never explicitely specified it was Vista, it could have been either ^^

And yes, I'm overclocking my E6600 to 3.33 GHz. But that is truly irrelevant. That was the most relevant info you could have given as an explanation to the fast encoding times (which nobody seemed to understand, no doubt on that one). The people who actually got involved into this thread obviously have non-overclocked CPU's, or weaker CPU's or rarely encode such low-resolution stuff, but we needed a way to relate to your situation somehow.

What I'm trying to say is "Help us help you !". When you expose a problem to someone, you usually expose the problem AND the context it's happening in (how do you want us to think an unknown context through ? ...).

Personally, I didn't really doubt what you reported, I only wanted to be sure that you extensively tested several times over, "just in case" you actually did make a mistake (this happens more often than not around here, even on the geekish side of the population ;)).

Actually, this might not even directly be a Vista issue, so could someone else that has Vista installed try a similar encoding scenario ? (using DivX 6.6.1 + lame acm 3.98b4 + vdub 1.6.19 preferably). In fact, Zach, did you try different vdub or lame acm versions ? Maybe those you tried actually have a bug that was introduced recently, the only way to find out is to have a try ... ^^'

Other than that, the fact the ACM version is slower than the cli version (about 2x in video copy mode) doesn't surprise me much ... I'm not sure ACM allows proper multithreading mechanisms (VFW has limitations regarding this, so ACM could have the same). This could well be the best you'll get out of it :) (not to mention vdub add's it's own synchronisation overhead ...).

** Philosophical time **
With all due respect, considering the grief your "help" has caused me, I would view that more as a favor than a threat.Well ... he didn't trash your files or insult you did he ? If you take being questionned as a grief you really must be one unhappy man ... questions reflect misunderstanding, and any misunderstanding needs clarifying. Man, it's just so simple sometimes ...

[Zach]

What I'm trying to say is "Help us help you !". When you expose a problem to someone, you usually expose the problem AND the context it's happening in (how do you want us to think an unknown context through ? ...).

Alright, enough with all the double talk to try to save face. Just explain to me once and for all how my video encoding speed related to my long audio encoding speed.


** Philosophical time **
Well ... he didn't trash your files or insult you did he ? If you take being questionned as a grief you really must be one unhappy man ... questions reflect misunderstanding, and any misunderstanding needs clarifying. Man, it's just so simple sometimes ...

Are you being obtuse on purpose? I had no problems whatsoever with you asking questions. I even happily did more benchmarks to answer the initial questions. But then when you refused to believe my answers, I'm just suppose to--what?--smile and pretend you are still being helpful and ignore the gross insulting of my intelligence?


---

Listen, I don't want to turn this into a flame war. You can respond to the above, and I will read it, but I won't respond to this thread anymore. I'll give you the last word if you want it, and then I'll just go away in peace.

[setarip_old]

@ (beleaguered)Zach

Hi!

Probably in no way related to your situation, but you stated:The format list is empty, even with the "Show all formats" checked. I suspect this should be normal as Microsoft's internal MP3 codec (straight from Fraunhofer) is only a decoder and not an encoder.Yet, in your post #12 to this thread, the first screencap indicates that the audiostream was compressed with "Fraunhofer IIS Mpeg Layer-3 codec".

Would you please enlighten/indulge me? Thanks.

[Zach]

@ (beleaguered)Zach

Hi!

Probably in no way related to your situation, but you stated:Yet, in your post #12 to this thread, the first screencap indicates that the audiostream was compressed with "Fraunhofer IIS Mpeg Layer-3 codec".

Would you please enlighten/indulge me? Thanks.

The difference between Vista and WinXP.

[Zach]

Would you please enlighten/indulge me? Thanks.

You know, it just dawned on me what me what you are implying.

First, why do I need to enlighten you? And second, what the hell is it with you people around here? Do you all get together at some secret meeting and discuss how far you should go at offending someone in a single thread? :mad:


Not that need to explain myself to you as this has nothing to do with Lame, but when I created the video over two years ago, I had Roxio installed along with its $10 MP3 add-on (link (http://www.roxio.com/enu/products/cineplayer/mp3/overview.html)). That plug-in, at least at the time, installed the full version of Fraunhofer's MP3 encoder--not the crippled version shipped with WinXP. And apparently with Vista, one doesn't even get a crippled version of the MP3 codec.

And for that matter, Sherlock, those VirtualDub entries don't indicate anything reliable about the original source. DivX 6.6.1 didn't exist 2 years ago--I believe I used DivX 5, but I don't remember--but yet there VirtualDub is saying it's DivX 6.6.1. No, that's only because that's what the FourCC code is registered as on my current (2007) system.

The tool I actually used to create the avi out of the original mpeg2 was Pegasys' TMPGEnc 3.0 Xpress (link (http://tmpgenc.pegasys-inc.com/en/download/te3xp.html)). If you have any more insulting questions, take it up with them and Roxio.

[setarip_old]

You know, it just dawned on me what me what you are implying.Zach, there was absolutely nothing implied in my post.

As a latecomer to this thread, I very directly pointed to differing items in two of your posts in hopes of better understanding the underlying reason(s) for the varying results you alluded to.

BTW - I referred to you as "(beleaguered)Zach" because I wanted to lighten things up a bit, since your postings made it clear that you believed you had been treated unkindly/unfairly by other posters to this thread.

Your most recent response to me:First, why do I need to enlighten you? And second, what the hell is it with you people around here? Do you all get together at some secret meeting and discuss how far you should go at offending someone in a single thread?...If you have any more insulting questionsmakes it clear (at least to me) that you incorrectly believe "everybody's out to get you".

I can only speak for myself when I say that this is not the case.

Additionally, there is nothing in my post that anyone else could possibly construe to be "insulting"...

[kypec]

I totally agree with setarip_old and other posters here. I pity Zach. With his attitude like that I suppose he's not getting along well with people in real life. :scared:
I would be flattered if so many skilled helpers paid attention to my thread and kept asking more and more questions to identify the problem of mine. There are many true gurus around here and if you feel "insulted" by their questions then don't come here to seek for help in the first place.

[Boulder]

If it still is slow, you might want to compare the encoding speed with Avidemux, which has a built-in LAME encoder...@Zach: this is something you didn't do, and it was suggested in the very first answer to your original post. At least it would have showed whether the problem lies in VDub or not - something that might have been useful information for Avery Lee, the author of VirtualDub.

[neuron2]

I'm closing this because the original poster appears no longer interested in it and there is no longer any constructive exchange.