demuxing audio from avi takes 10 min?

[bananacreamandpeca]

When I demux the audio.mp3 from a 700MB avi.
Why does it take so long (10 minutes)?

Demuxing isn't a difficult process is it?
Is de demuxing process re-encoding the audio??????

[setarip_old]

Hi!

1) What software and procedure(s) did you use to demutliplex the audiostream?

2) The amount of time required for virtually any procedure is at least partially dependent upon your system configuration. What CPU do you have in yours? How much RAM?

[bananacreamandpeca]

Hi,

1) I use VirtualDubMod.
When I open the video, it says the source-audio has a bad VBR-header,
I schoose to keep the VBR-header.
Then I choose "Stream/Streamlist" from the menu,
hit "demux" and save it as .mp3, then hit enter.
It takes 10 minutes to complete. Virtualdub is set to DirectStreamCopy

2) I have a AthlonXP 1600+ system. 256MB ram. Windows XP.

[Skelsgard]

I came across that issue with the 1.5.10.1 version.
If you have this version, switch to 1.5.10.2

Cheers.

[setarip_old]

When I open the video, it says the source-audio has a bad VBR-headerDo you encounter the same lengthy process if you initially create your .AVI with CBR .MP3 instead of VBR .MP3?

I have a AthlonXP 1600+ system. 256MB ram. Windows XP.If you're going to be doing video/audio/graphics processing on a regular basis, I strongly suggest increasing your RAM to at least 512Mb...

[CWR03]

If you're going to be doing video/audio/graphics processing on a regular basis, I strongly suggest increasing your RAM to at least 512Mb...
I'd like to interject that if you're running Windows XP you need at least 1 GB of RAM. The OS itself is a memory hog.

When I open the video, it says the source-audio has a bad VBR-header,
I schoose to keep the VBR-header.
You should click "No." VirtualDubMod always claims a bad header with VBR audio. Clicking "Yes" means you're not demuxing the audio in direct copy mode.

[squid_80]

Ugh, I remember how painfully slow demuxing audio was with virtualdubmod. Thankfully virtualdub 1.7.0 has an export raw audio option which is much quicker.

[Schnoodledorfer]

You should click "No." VirtualDubMod always claims a bad header with VBR audio. Clicking "Yes" means you're not demuxing the audio in direct copy mode.

Wrong! "No" means you are telling vDubMod to pretend it is CBR (and write headers that way), even though it is really VBR. "Yes" means don't pretend VBR is CBR. That is all.

I demuxed an AVI file several times. In general, it was slightly quicker when I clicked on "Yes", presumably because the headers were not being changed.

Either way, vDubMod will not write all of the headers completely correctly, leading to utilities reporting the file duration incorrectly, but the files will still play correctly. I use mp3directcut to open and re-save the files (making no other changes). It saves the file out with completely correct headers. I did this in my test, and the saved files were exactly identical (bit for bit), whether I said yes or no in vDubMod. I verified this by hashing the files. So, either way (yes or no), the audio is not actually being changed. MP3DirectCut could still tell that the audio was really VBR, even if I had clicked on "No" in vDubMod.

Saying "No" tells vDubMod to pretend that the audio is CBR, instead of VBR, when it muxes (not demuxes!) the video file. This, as the program clearly states, will cause a loss of synch. Why would anyone want to do this? The only reason is that the original specs for AVI didn't consider the possibility that VBR audio would be used, so by writing headers as if the audio were CBR, you are staying closer to the original decades-old AVI specs at the cost of loosing synch.

To avoid the Yes/No question, you can use AVI-Mux GUI (http://www.alexander-noe.com/video/amg/), which doesn't see the need to issue warnings about VBR audio in AVI files, but which (again) writes demuxed MP3 headers so that they still need to be cleaned up (but the file will still play OK).

Personally, I think this is just a matter of trying to combine outdated (the AVI container) with newer (VBR audio) technology , so I prefer to use something newer and better than the AVI container. The problem is inertia (including everyone else's), but oh, well.

[Schnoodledorfer]

Is de demuxing process re-encoding the audio??????

No. Something else is wrong.

[CWR03]

Wrong! "No" means you are telling vDubMod to pretend it is CBR (and write headers that way), even though it is really VBR. "Yes" means don't pretend VBR is CBR. That is all.
Are you sure? VirtualDub and VirtualDubMod have reverse messages. VirtualDub prompts you to keep the header, VirtualDubMod prompts you to rewrite it, meaning no direct stream copy when demuxing if "Yes" is clicked when using the latter. Perhaps you have confused the two.

[Schnoodledorfer]

Are you sure? VirtualDub and VirtualDubMod have reverse messages. VirtualDub prompts you to keep the header, VirtualDubMod prompts you to rewrite it, meaning no direct stream copy when demuxing if "Yes" is clicked when using the latter. Perhaps you have confused the two.

Argh!!! :mad: We're both right! And naturally that means we're both equally wrong, too! :rolleyes: At least that's the case with vDubMod.

The issue with vDubMod is you can set in preferences if you want vDubMod to emulate NanDub by default. (I forgot about this.) If you don't have it set, the question is: "Do you still want to rewrite the header?" If you have it set (I did), the question is: "Do you really want to keep the VBR header?" So basically the preference setting just swaps the meanings of the "Yes" or "No" buttons.

I wouldn't say vDub's message is reversed compared to either of the vDubMod messages. vDub doesn't give you any choice -- it's going to rewrite the headers (pretending VBR is CBR) if you don't re-encode. The only message it gives is a warning message that recommends that you do re-encode. There is only one button: "OK", which closes the message.

Finally, Nandub doesn't give you any choice either -- it keeps the VBR headers and doesn't give you any message.

[bananacreamandpeca]

Im going freakin insane right now....

I demuxed an mp3 from avi video with vdubmod (direct stream copy),
it freaking had no bad vbr header whatever message.
The audio in the original (avi video that is) is OK.
Then I used MKVmerge to merge the demuxed mp3 into MKV with video.

Guess what? The audio seems to be distorted (maxed) and has glitches.

WHAT [edit] IS THIS?
Wich [edit] piece of software destroyed the audio????

DEMUXING IS NON_RECOMPRESSING OR -TRANSCODING RIGHT????

WHAT [edit] IS WRONG ?

IM GOING INSANE IM GOING INSANE

WHY IS VIDEO SOOOOOOOOOOOOOOOOOOOOOOOOOOOO DIFFICULT?????

I downloadd another version of vdubmod 1.5.10.2 (all inclusive pack.zip) for this as suggested.

[bananacreamandpeca]

Isnt demuxing supposed to be losless?

And why cant I just rip the AC3 out of a vob? without having to freaking transcode the AC3 to some other Samplerate?

Wich demuxer can rip just the AC3 1:1 without these vague options of persisting to transcode the damn audio to another bitrate before I can demux to AC-3??????????
Sounds strange right? Isnt besweet supposed to be all that?

[bananacreamandpeca]

If I demux a vbr-mp3 audio from avi to WAV.
And encode the freakinn audio to CBR mp3.
Then use this CBR mp3 to mux with a re-encode of the video.

Is this better than trying to Mux VBR-mp3 with video?????

[Schnoodledorfer]

If I demux a vbr-mp3 audio from avi to WAV.
I would save it as .MP3, not .WAV (just demux). Saving it as .WAV just adds a header for programs that were written to read .WAV files, but not .MP3 files. I don't think there are many of those programs around anymore.

Internally, it's still an .MP3. vDubMod (I assume that's what you are using) doesn't save it as an uncompressed .WAV file.

If you have a program that will encode from the compressed .WAV file, but not an .MP3 file, then ignore what I said. But be careful, I think vDub warned against saving VBR mp3 as a .WAV file. I'm not sure how vDubMod would handle it.

And encode the freakinn audio to CBR mp3.
Then use this CBR mp3 to mux with a re-encode of the video.

Is this better than trying to Mux VBR-mp3 with video?????

If you are going to mux it into an AVI container, the people who wrote vDubMod would say "yes". I disagree, unless you are going to do cutting and joining later. Personally, I am muxing to .MP4, not .AVI, so I'm avoiding that issue. Also, I get to create chapters that way.

The issue is that each time you re-encode there is normally some quality loss. You can try re-encoding and see what you think.