|
|
| banny69 |
| Posted: Nov 14 2005, 10:04 AM |
 |
|
Unregistered
|
Cheers squid, the plan worked beautifully.
Banny |
|
| Henning |
| Posted: Nov 16 2005, 06:29 AM |
|
|
Unregistered
|
Thanks a lot, squid, now the problem is gone.... 
Using VirtualDub's hex editor and changing the wBits field to zero really did the trick: all of a sudden Virtual Dub no longer complains about an "unknown tag 0055", the program now tells me that the file was encoded using the Fraunhofer codec...
I was a bit uncertain, though, because VirtualDub's file information window still showed a difference in playing length between the video part and the audio part: the video was significantly longer (more than one minute) than the audio. But after decompressing audio to a .wav-file (using VirtualDub) they both were of the same lenth again.
Now I no longer need Goldwave to decompress the "unknown tag 0055" problem .avi-files to .wav-files... Hopefully we have found a solution to the problem that has "plagued" us for quite some time!
Thanks to you, farcus, too, for bringing up this problem again!
Henning
PS: I hope I could make myself understood: English is not my mother tongue. |
|
| squid_80 |
| Posted: Nov 16 2005, 10:22 AM |
|
|
Advanced Member
Group: Members
Posts: 594
Member No.: 13813
Joined: 22-January 05
|
Can anyone actually create these files on their own system from scratch or are they all "second hand" files like the one I had? Just so we can narrow down the problem to either a bad build of the lame acm codec or nandub (which flat out refuses to process audio for me). |
|
| Mark |
| Posted: Nov 18 2005, 01:56 AM |
|
|
Unregistered
|
I can create these files on my system using WinDVR 5 (Intervideo) which came bundled with my Plextor video capture device.
The strange thing is that I have had NO problems at all with these AVI files until this past week. Up until a few days ago I could create a file with WinDVR and Virtualdub would have no problems with the file.
The only two changes (that I can remember, or track down) on my system since the time that Virtualdub would read the files and the time it wouldn't read the files are the installation of Winamp 5.111 (lite), and Mozilla 1.7.12.
I used RegMon to see what Virtualdub was doing when I tried to load these files. Virtualdub seems to be loading the Lame ACM (version 0.9.1) without any problems.
Suspecting that Winamp was the problem, I uninstalled the new version and tried Virtualdub with no Winamp on the PC. No luck. I installed the previous version of Winamp I was using, and still, no luck. (I haven't played with Mozilla since I find it hard to believe that Mozilla would affect audio CODECs.)
If anyone would like me to create some files I'll be happy to send them along for some testing.
Mark
|
|
| farcus |
| Posted: Nov 18 2005, 03:25 AM |
|
|
Unregistered
|
| QUOTE (Mark @ Nov 18 2005, 10:56 AM) | (I haven't played with Mozilla since I find it hard to believe that Mozilla would affect audio CODECs.)
|
I wouldn't imagine that Winamp would affect your codecs either. |
|
| Mark |
| Posted: Nov 19 2005, 01:59 AM |
|
|
Unregistered
|
I solved the problem!
Of course, this works on my machine but might not work on yours. But, it's worth a try.
Here's what I found: Something messed up the Fraunhofer MP3 settings in my registry. The decoder showed up in GSpot, but NOT in the Audio Codecs section of the "Sounds and Multimedia Properties" control panel. Reinstalling Windows Media Player (ver 9) didn't solve the problem.
This solves the problem:
I copied l3codecp.acm (version 3.3.0.44) to C:\Winnt\system32
and entered the following into the registry:
| CODE | [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"msacm.l3acm"="l3codecp.acm"
"msacm.l3codec"="l3codecp.acm"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\drivers.desc]
"l3codecp.acm"="Fraunhofer IIS MPEG Layer-3 Codec (professional)" |
Now Virtualdub has no problem with the files with MP3 audio.
A few notes:
I got the l3codecp.acm file out of the Windows Media Player 10 install package. Tip: You can extract the files that are included in mp10setup.exe by the following command line, without installing the Media Player: mp10setup.exe /T:c:\extract /C
I had the LAME ACM CODEC installed on my system, but for some reason Virtualdub didn't seem to like how it decoded MP3s, didn't use the CODEC, or for some other reason wasn't happy with it. Virtualdub also wasn't happy with ffdshow MP3 decoding.
So, the moral of at least this one story: The Fraunhofer CODEC LOOKED like it was installed properly to SOME applications (GSpot), AND there was a version of l3codecp.acm in the system32 directory. BUT, something messed up the registry settings and Virtualdub wasn't able to use the Fraunhofer file to decode the MP3 audio.
Hopefully this will help someone out there!
|
|
| squid_80 |
| Posted: Nov 19 2005, 05:40 AM |
|
|
Advanced Member
Group: Members
Posts: 594
Member No.: 13813
Joined: 22-January 05
|
I think this is a different problem to the one Farcus, Henny, Banny69 and I have experienced. We have avi files which contain mp3 streams with incorrect headers. With the original messed up headers, the fraunhofer codec refuses to handle them. If the header is fixed with a hex editor, they work correctly. If you'd read the whole thread you'd see where it was stated the Lame ACM codec CANNOT decompress, it has compression features only. |
|
| vinnie97 |
| Posted: Mar 23 2006, 11:41 AM |
|
|
Unregistered
|
Thanks to Squid if you're still around! This anomaly was actually preventing TMPGEnc from loading the audio portion of an AVI file. Setting the appropriate value to 0 (at initially 10 in my case) in VirtualDub's hex editor sorted the problem.
It might be worth stickying this topic or entering it into a FAQ somewhere...I thought there was no end in sight until I gave this solution a try on a whim.  Thanks again! |
|
| squid_80 |
| Posted: Mar 23 2006, 01:06 PM |
|
|
Advanced Member
Group: Members
Posts: 594
Member No.: 13813
Joined: 22-January 05
|
You're right that it's not uncommon, there's been a few people with the same problem. But what I would really like to know is where these files come from i.e. What program is creating these buggy headers? The signs seem to point to Nandub but I can't reproduce the errors on my system. |
|
| vinnie97 |
| Posted: Mar 23 2006, 07:19 PM |
|
|
Unregistered
|
Well...strange thing is that even though TPMGEnc didn't report any errors, the resulting AVI to MPG file still had no audio.  I'll have to keep investigating in my particular case. |
|
| Gable |
| Posted: Mar 25 2006, 06:26 PM |
|
|
Unregistered
|
After many hours of experimentation and searching the net, I found a solution to Tag 0055 audio problem with VirtualDub. The problem appears not to be related to the number of MP3 codecs you have installed. The problem is that the codec that encoded the audio in MP3 format was not writing a strictly correct MP3 header. Apparently VirtualDub checks the header more carefully and detects the malformed header. That is why VirtualDub can't process the audio.
Workaround in VirtualDub:
1) Open the video file that was causing problems.
2) Select "Direct Stream Copy" in the Audio menu.
3) Select "Save WAV..." from the File menu and save the audio to a WAV file. This WAV file contains the audio in the format it was in the AVI file.
4) Convert this WAV file to an uncompressed WAV file using another program (I used iTunes for this but other audio programs that can convert audio formats would probably work as well). It seems many audio programs are less picky about the malformed MP3 header.
5) Go back to VirtualDub and select "WAV Audio..." from the Audio Menu. Open the converted WAV file.
6) Now proceed as you normally would in VirtualDub
I'll leave it to others to implement the correct fix for this problem:
a) Tracking down the programmers who wrote the codec that is producing the malformed headers and get them to ensure they are writing strictly correct MP3 headers.
 Ensure that VirtualDub itself can understand all correct variations of MP3 audio headers. |
|
| squid_80 |
| Posted: Mar 26 2006, 02:14 AM |
|
|
Advanced Member
Group: Members
Posts: 594
Member No.: 13813
Joined: 22-January 05
|
Yes, we've figured that out already. It should be noted that it isn't virtualdub that has a problem with the header, rather it's the fraunhofer mp3 acm codec refusing to handle streams with bad headers. Virtualdub is not at fault here.
Uncompressing the audio via a program dedicated to handling mp3 simply removes the fraunhofer codec from the toolchain. Trying to open the wav file with any program that uses acm codecs will (unless the program is poorly written) fail similarly to virtualdub. On the other hand if it is opened via directshow there's no problem.
I still prefer the hexedit fix, since it's quick and easy and solves the problem for that file once and for all in case I ever need to edit again. |
|
| phaeron |
| Posted: Mar 27 2006, 12:23 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
There are some incredibly broken problems out there writing AVI files. I've seen WAVEFORMATEX structures in AVI files that had nAvgBytesPerSec=0 and nBlockAlign=0, which is about as illegal as you can get.
Now, the real question:
Can anyone think of any problems that would be caused by auto-correcting the wBitsPerSample value of MP3 streams to 0, as the Fraunhofer codec outputs and expects?
If not, I can add code to do this on load on the in-memory format.
|
|
| squid_80 |
| Posted: Mar 27 2006, 02:04 AM |
|
|
Advanced Member
Group: Members
Posts: 594
Member No.: 13813
Joined: 22-January 05
|
I can't think of any problems caused by changing something to an expected value. I already patched my own build of avisynth to do the same thing and it's not giving me any troubles.
Heh, looks like you were right in more ways than one:
| QUOTE | .....
// 11KHz, this becomes a tenth of a second. Needless to say, the
// F-IIS MP3 codec is a royal piece of sh*t.
... |
|
|
| phaeron |
| Posted: Mar 27 2006, 02:11 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Hmm? I don't think rejecting wBitsPerSample != 0 is the fault of the Fraunhofer ACM codec. That codec introduced the 0x0055 wave format and thus defines it by behavior, and I don't see any reason why other programs should generate a gratuitously incompatible format.
|
|
