| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > Codec Discussion > Tag: 2000 Problem |
| Posted by: Niccolo MAC Aug 20 2005, 02:49 PM |
| I just downloaded VirtualDub 1.6.10 from the official site. I also got the AC-3 ACM Decompressor 0.8 from the official site. My problem is that even after installing the ACM codec VirtualDub still can't read AC3 audio. I get a VirtualDub Error message which states that "No audio compressor could be found to decompress the source audio format. (source format tag: 2000)" I already tried uninstalling AC-3 ACM Decompressor 0.8 and re-installing it but no luck. I also tried uninstalling AC-3 ACM Decompressor 0.8 and installing the 0.7 version instead, but I still get the same error message. What's wrong??? Thanks in advance for everyone's help. |
| Posted by: fccHandler Aug 20 2005, 03:04 PM |
| Did you reboot after installing? If not, try that. Can you see "AC-3 ACM Decompressor" in VirtualDub's Audio / Compression list? If so then it's definitely installed, but it might fail to function if your AC-3 stream is messed up somehow. |
| Posted by: Niccolo MAC Aug 20 2005, 03:17 PM |
| I rebooted after installing. I can also see AC-3 ACM Decompressor in VirtualDub's audio/compression list. The decompressor is also visible in Windows XP's add/remove programs list. The video file's ac3 stream is fine, as I can play the movie with Windows Media Player using Vigovsky Alexander's AC3 Filter v0.70b. By the way I had AC-3 ACM Decompressor 0.7 installed on my old harddisk, and it always worked flawlessly. Then my harddisk failed and I lost everything, and now that I downloaded and installed the latest versions of VirtualDub and AC-3 ACM Decompressor I got this problem. |
| Posted by: fccHandler Aug 20 2005, 03:32 PM |
| In that case AC3ACM isn't recognizing it as AC-3 for some reason, maybe because of the AVI stream header... (I think Valex's filter is a little more forgiving about that.) Can you open the AVI in VirtualDub's hex editor, maximize its window, take a screen shot and post it here? Better yet if you could email me a piece of the beginning of the AVI (it has to be less than 2MB though). |
| Posted by: Niccolo MAC Aug 20 2005, 05:26 PM |
| Since my hard disk is brand new I don't have any other movies with AC3 audio stream in them. I never tried any other ac3 movie in it, so I don't know how your decompressor works on other movie files. How can I post the requested screen shot? |
| Posted by: fccHandler Aug 20 2005, 05:58 PM |
| Upload the picture somewhere on the web and post a link to it here. If you don't have your own web space, there are a lot of free image hosting sites. Here's a list I saw on Doom9's forum: http://forum.doom9.org/showthread.php?t=96362 |
| Posted by: Niccolo MAC Aug 20 2005, 10:36 PM |
| Thanks, you're very helpful! http://img378.imageshack.us/img378/9112/tag2000problem3fa.jpg |
| Posted by: fccHandler Aug 21 2005, 05:36 AM |
| Well damn. I can see the video header ("vids" and "XVID") but it's followed by a big empty "JUNK" chunk so the audio header isn't visible in this picture. Can you scroll down to offset 1000 and post another picture starting from there? I'm looking for the header which begins with "auds". Alternatively, use VirtualDub in "direct stream copy" mode to save the first 50 frames of the movie, and email it to me. (Hopefully it will be less than 2 MB in size.) My address is given in the "Readme.txt" file of AC3ACM.zip. |
| Posted by: Niccolo MAC Aug 21 2005, 10:10 AM |
| Ok found your e-mail address and e-mailed you from the first frame to the first key frame (240 frames total). It came to 1.3 Mb. Just a simple question, you can't cut an avi file anywhere except from a key frame to another key frame right? Unless you're re-encoding the video stream at the same time? If you open the movie file with GSpot you will notice something strange in the Audio section. The FS is given as 47999 Hz! I think it should be 48000 Hz. I think you're right, there must be something wrong with my file. Pity I don't have another movie with AC3 audio to try VirtualDub with... |
| Posted by: fccHandler Aug 21 2005, 01:53 PM | ||
| Thanks for sending the clip. GSpot is right. The AVI header for the audio stream is incorrect. It's actually 48000 Hz, stereo 192 kbps AC-3. I didn't see anything wrong with the AC-3 audio itself, only its header. So... I thought I could rip out the raw AC-3 and remux the video and audio with VirtualDubMod, but AC3ACM still won't recognize the audio! That's very strange, because I know I did it right. So now there are two problems. One, the original AVI has a bad header, but that can be fixed by demuxing and remuxing. Two, something is still wrong with AC3ACM rejecting the fixed version. I'll post again when I figure out what's going on...
Right, except for one thing. In "direct stream copy" mode the cut has to start on a key frame, but it doesn't have to end on a key frame. P.S. I changed your picture into a link, because it was making the thread too wide for my desktop. |
| Posted by: fccHandler Aug 21 2005, 07:55 PM |
| OK, where to begin... It turns out that there is a long standing compatibility issue between VirtualDubMod and AC3ACM. It's probably been there for years. The first problem of the "bad header" involves the WAVEFORMATEX header in the AVI you sent me. In this case the wrong field is the "nSamplesPerSec" field, which was set to 47999. You can't use VirtualDub to fix it though, because if you save a WAV from VirtualDub the bad header stays with it. You have to use VirtualDubMod to "demux" the AC-3 stream, then remux the raw .ac3 with the original video using VirtualDubMod. That fully rebuilds the WAVEFORMATEX header. The second problem I found today is that VirtualDubMod also writes a bad field in its WAVEFORMATEX header! In this case it's the "nAvgBytesPerSec" field, which AC3ACM expects to be equal to the AC-3 bitrate * 125. VirtualDubMod's number is just a little bit off, and that causes AC3ACM to reject the audio. I can't believe this hasn't come up before now. Maybe it has, and I just misinterpreted the signs. Valex warned me a long time ago that the validation checks in AC3ACM were too inflexible, and I argued the contrary. Well, here's proof that Valex was right... Since I don't know if VirtualDubMod will ever get fixed, I've changed AC3ACM to ignore the "nAvgBytesPerSec" field if the "nBlockAlign" field is equal to 1. (I think it always is with VirtualDubMod.) The new AC3ACM is http://fcchandler.home.comcast.net/AC3ACM. Just remember you have to remultiplex the movie with VirtualDubMod first, to fix the original bad header. Let me know if you any problems. |
| Posted by: Niccolo MAC Aug 21 2005, 08:14 PM |
| Thanks a lot! I'll try it out tomorrow! |
| Posted by: squid_80 Aug 21 2005, 10:19 PM |
| fccHandler: Have you ever seen vdubmod write an incorrect value for cbSize in the WAVEFORMATEX header? Seems there are some programs that put 18 (or sizeof(WAVEFORMATEX)) in there instead of 0. I thought vdubmod was the culprit but now I'm not so sure. |
| Posted by: fccHandler Aug 22 2005, 04:14 AM |
| My copy of VirtualDubMod (1.5.4.1 / 2180) doesn't do that. But VirtualDub-MPEG2 does, if you save a WAV in DSC mode from a .VOB with AC-3 audio. The reason... There is no official documentation for how to put AC-3 into AVI files. So, a long time ago when I wanted to add AC-3 DSC support to VirtualDub-MPEG2, I downloaded a bunch of examples from various places (typically P2P). I used these as templates for the DSC support in VirtualDub-MPEG2 and for testing AC3ACM. For some reason, all the AVIs I could find had cbSize = 18, so I just imitated that in VirtualDub-MPEG2. But like you, I've always suspected that some tool somewhere was goofing up the header. (In fact, there's a little notation to that effect in the source code of VirtualDub-MPEG2.) I still don't know what program goofs them. Heck, it could even be VirtualDub 1.3c if you believe what's being posted in http://forums.virtualdub.org/index.php?act=ST&f=2&t=10349&hl=! |
| Posted by: squid_80 Aug 22 2005, 06:51 AM |
| Hmmm, ProjectX does it as well but I suspect it's just imitating like virtualdub-mpeg2 (since I don't think projectx has been around that long). |
| Posted by: squid_80 Aug 22 2005, 11:15 AM | ||
I took a look at virtualdubmod's cvs, and in ac3filesrc.cpp:
But the build of vdubmod that I have (1.5.10.1 2439/release) uses 0 for cbSize. Also it gives the correct value for nBlockAlign. Maybe it's just old builds (like your 1.5.4.1) that are bad. |
| Posted by: fccHandler Aug 22 2005, 12:42 PM |
| Oops, it looks like they did fix it in the later version. Serves me right for using ancient software... |
| Posted by: Niccolo MAC Aug 24 2005, 06:59 PM |
| fccHandler: Finally I had a chance to try what you told me. It worked! Thanks again |
| Posted by: bcarpman Aug 25 2005, 02:34 PM |
| As a newbie and former lurker, sorry for the stupid question, but I've been having the same issue for a while now with many files. Does reinstalling the new AC3 decompressor solve the problem (it didn't for me)? Or do I still have to go through the procedure of demuxing the audio as explained earlier in the post? If anyone has a minute to explain this procedure so that there is a final solution to this problem, it would be greatly appreciated. thanks |
| Posted by: fccHandler Aug 25 2005, 03:06 PM | ||
That depends. Look at the "File Information" in VirtualDub (or use GSpot) to see the properties of the AC-3 audio. If anything looks strange there (like the 47999 Hz sampling rate we discussed) then you'll have to demux and remux with VirtualDubMod. If that doesn't fix it, then I'll probably have to get a sample of the AVI to investigate why it fails. |
| Posted by: squid_80 Sep 1 2005, 05:22 AM |
| fccHandler: Just following up the vdubmod/nBlockAlign issue, there's an option in vdubmod under preferences->vdubmod->avi called Enable Frame mode. When it's turned on VDubmod will use the ac3 frame size for nBlockAlign, else it uses a value of 1. I guess I must have had it turned on. |
| Posted by: fccHandler Sep 1 2005, 05:55 AM |
| That's interesting. AFAIK nBlockAlign is supposed to be equal to the smallest atomic unit of audio, either the size of an uncompressed sample or the size of a compressed frame. I believe that nBlockAlign = 1 should only be used if the block size is unknown, or variable. |
| Posted by: squid_80 Sep 1 2005, 06:26 AM | ||
Using the ac3 frame size for nBlockAlign makes perfect sense to me. But not everyone thinks the same: http://forum.doom9.org/showthread.php?p=242026#post242026
|
| Posted by: phaeron Sep 1 2005, 07:12 AM |
| In theory, yes, nBlockAlign should be the atomic data unit size. If the AC3 format for WAVEFORMATEX is defined as nBlockAlign=1, though, then that's what should (or even must) be used, even if different values of nBlockAlign make more sense. You can't just pick a random nBlockAlign value. I don't know if there is a defined standard for the AC3 format in WAVEFORMATEX, though. The DirectShow documentation would be the most likely place, although as you well know, there is often a large difference between what standards say and what's actually out there in practice. It doesn't help that much of the original MMSYSTEM and VFW documentation is difficult to find. In general, most of the new video/audio technologies are being created with little regard for general editability; invisible decoding delays, false key frames, and nBlockAlign=1 all make it more difficult to treat compressed formats as opaque. Unfortunately, part of the reason for this is that it's hard to design general APIs and file formats without making them overly complex and fragile (i.e. TIFF). |
| Posted by: fccHandler Sep 1 2005, 03:15 PM | ||
FWIW, I've never seen one. It wouldn't surprise me if the standard we use today was entirely invented by alexnoe, or maybe Nandub's author. |
| Posted by: squid_80 Sep 1 2005, 10:03 PM |
| My money's on Nandub being the first. IIRC it wasn't very good at it anyway, didn't the interleave value need to be a multiple of 32ms to avoid cutting a frame in half? I highly doubt there's a defined standard too, especially since tag 0x2000 (which everything seems to use for ac3) is actually defined to WAVE_FORMAT_DVM with the comment "FAST Multimedia AG" in mmreg.h. |
| Posted by: squid_80 Sep 1 2005, 10:30 PM |
| Actually, I think the "correct" way to do it could be to use a WAVEFORMATEXTENSIBLE header instead of plain old WAVEFORMATEX. I've got a program to generate this from a raw ac3 stream, vdub will mux it but can't do anything else (no acm codec for tag 0xFFFE) and the resulting file plays ok with WMP. Would adding handling for WAVEFORMATEXTENSIBLE in virtualdub (and ac3acm, removing the comments wouldn't be hard |
| Posted by: fccHandler Sep 1 2005, 11:28 PM |
| I don't have anything that supports WAVEFORMATEXTENSIBLE. It's rather pointless for me to implement support in AC3ACM if nothing else I have works with it. |
| Posted by: squid_80 Sep 2 2005, 12:39 AM |
| Yeah, I thought at least cooledit would work but it bombed. WMP and MPC both work with the muxed avi though. I was just after your opinions, not necessarily requesting that you and Avery go ahead and implement it - just if you think it sounds right and if so I'll have a crack at it myself and see what happens. It just bugs me using a method that doesn't seem quite right, and no-one can give a good reason why it is the way it is. |
| Posted by: fccHandler Sep 2 2005, 01:23 AM |
| It is the Right Thing™ to do, because there's no other way to specify channel-to-speaker mappings in a multichannel WAV file. But there's another reason I abandoned it; I don't currently have 5.1 speakers. |