Time to flush the pipeline. :)
Besides the usual slew of bug fixes, there are two fairly major changes in this version. One is the addition of code to properly read files that have variable bit-rate (VBR) audio. You still can't write such files, for various reasons, but they should preview and decode now, and more importantly, you can convert them to non-VBR. (Contrary to popular opinion, making this work isn't just a matter of not rewriting the header. The method of doing sample-to-byte and byte-to-sample conversion is different.) The other change is that, in addition to putting in a workaround for the quirk in the Creative MP3 codec, VirtualDub now also stores the name of the audio codec as well as the selected compressed wave format in order to ensure that the selected codec is used, and not another codec that also supports that format. I still don't recommend having more than one MP3 codec installed — crossfading in Windows Media Player seems to be a rather common liability — but it should work a bit better now for the unsuspecting.
A tertiary side change is that the help file has been converted from a zipped collection of files to a standard Windows HTML Help file (.chm). It took a bit of hacky batch file code to get this to work — some dork made the HTML Help Compiler return 0 on failure and 1 on success — but it turned out to be fairly painless once I found out how to generate the project files and to launch hh.exe, and now full-text search is available.
Hit (Read More...) for the changelog. Barring major problems, I'll re-release 1.6.13+$ANY_MINOR_FIXES to 1.6.14/stable.(Read more....)
Ever had an AVI file that you couldn't delete, because every time you tried, you got an Access Denied or "file is already in use" error?
In Windows, it's not normally possible for a file to be locked by an application after that app exits, and very not possible for the app to have the file locked after the system has rebooted. Nine times out of ten this is caused by the Windows XP Shell Media Extension (shmedia.dll), which provides statistics and thumbnails for media files. Problem is, sometimes shmedia gets stuck on a file, and since it runs inside of Explorer, that file is effectively locked until you restart or logoff. And even that doesn't help, because after restarting, opening the folder causes it to lock the file again. Using Process Explorer from sysinternals.com is the easiest way to confirm that Explorer is holding the file open.
Deleting the file via the command-line, rather than navigating to the folder in Explorer, should work. If you're not a fan of the command-line and don't DEL the file that way, an alternative solution is to temporarily unregister shmedia.dll (regsvr32 /u shmedia.dll), restart, delete the file, and then re-register the extension (regsvr32 shmedia.dll). This is cleaner than hacking the registry to blow away the extension. I always just leave it unregistered, though, because I don't need it.
Note that there is a bad bug in older versions of VirtualDub's frameclient that can exacerbate this problem and cause it to happen for all AVI files, not just broken ones. It only happens if you have manually installed the AVIFile frameclient using auxsetup.exe and also enabled proxy mode via the proxyon.reg file; it doesn't happen if you just use VirtualDub itself, so most people won't run into this. Uninstalling the frameclient or turning off proxy mode are sufficient to fix the problem. This bug was fixed a while ago in version 1.6.0, so if you use proxy mode and are experiencing this problem, installing the frameclient from a newer version is sufficient.
A slightly different problem that can occur is when the AVI file can't be found, but it still seems to be taking space. One culprit of this is a damaged FAT32 filesystem, if you are using an older system and had a system failure while writing an AVI file. Usually the damage is relatively harmless, just some clusters lost in an orphaned chain. Normally Scandisk or Chkdsk will catch this on the restart, but if by chance it doesn't, running a manual check will fix up the drive. The other common cause is Norton Protected Recycle Bin, which squirrels the deleted AVI file into a different Recycle Bin that most people miss, and has a habit of accumulating an ungodly amount of files. Just flush Norton (or its Protected Recycle Bin) and you'll get your space back.(Read more....)
For years, I've been receiving reports about a mysterious problem with VirtualDub hanging during a save operation. The program's UI was still responsive, so the application hadn't totally died, but the processing pipeline jammed up such that the render couldn't make any progress or be aborted (a "livelock"). I had initially assumed that this was a deadlock caused by thread synchronization issues, which wouldn't lock the UI because VirtualDub's UI runs in a separate thread, and this was reinforced by the livelock log messages in recent versions indicating that the audio thread was stuck in a system call. However, I could never find the culprit or reproduce the problem. This was very frustrating for me, because it was a long-standing issue that made my program unusable for some people, and which I couldn't fix.
I recently found out which software triggers the problem and why — it's the Creative Labs MP3 codec (ctmp3.acm), and it's because of peculiar notifications being sent by that codec. It comes with the software that ships with certain SoundBlaster Live! sound cards; in particular, installing the PlayCenter application will also install the codec. Either renaming the driver file temporarily, uninstalling it, or lowering its priority in the Sounds and Audio Devices control panel so that another MP3 codec has priority will work around the problem. I think I have a viable workaround that I can put into VirtualDub itself, but why this codec causes a lockup is an interesting question in itself.(Read more....)
Stupid Windows trick of the day.
If you're a developer, you've probably found yourself on a system where a program is hanging or crashing, but don't have a debugger handy. Worse, if you're stuck in an area with no internet access — say, on a laptop in a moving car, like I was today — you can't download Debugging Tools for Windows either. So what do you do?
Use the NT system debugger (NTSD.exe). It's a bit raw, being a simple command-line debugger, but all you need to know is ~ to list threads, ~n prefix to select a thread or ~* prefix for all threads, and kb to dump a thread stack. Oh, and q for quit (always important, although only vi makes this hard). What's great about NTSD is that it's installed on every Windows XP system, so it's always available.
(In case you're wondering, I was debugging a crash in WinDVD 3's audio decoder, which turned out to be caused by it trying to use 3DNow! instructions on a Pentium M CPU. Serves me right for grabbing a random DVD player software install disc while heading out the door.)(Read more....)
Resizing an image to a different size requires a basic image processing technology called a resampler. This is one of the elementary operations in any image processing toolkit. Yet, I've seen many, many cases where people get resampling algorithms subtly wrong, slightly wrong, or even blatantly wrong. Some of these were even in supposedly professional image processing applications! It isn't that hard to create a quality resampler. It does take some careful thought, and a little ingenuity to implement, but doesn't cost a lot of performance and makes the resampler act a lot more consistently.
I will freely confess to having committed violations of all the rules I'm about to outline in various older versions of VirtualDub, where sometimes you would see a line of pink pixels on the right, or the image is a tiny bit larger or smaller than it's supposed to be, etc. All of these should be worked out in modern versions and the resize filter should obey all of the rules. If you think there is a violation, feel free to ask about it.(Read more....)