Stuff

VirtualDub 1.6.15/stable is out with a series of bug fixes. There are no new features in this build.

For those of you using a recent beta of Windows Vista, including the just-released beta 2, you may notice severe problems when attempting to use VirtualDub with Aero Glass enabled -- specifically, that the display keeps resetting over and over. The problem is that the way that VirtualDub displays video is incompatible with the Vista Desktop Window Manager (DWM), and the DWM disables Aero Glass in response. Unfortunately, some semi-recent changes to the DWM have made the problem much worse: when the DWM attempts to disable Aero Glass, it resets the display and that also causes VirtualDub to reset its display mechanisms, tripping the DWM again, and resulting in a loop of resets. Click on another window to escape the loop. The workaround is to go to Options > Preferences > Display and either turn off DirectX or enable Direct3D. The technical issue is that VirtualDub uses the same window handle for GDI and DirectDraw rendering, which the DWM really doesn't like; I will be working on fixing this for 1.7.0.

If you're a frequent watcher of Internet-sourced video files you may have noticed an interesting characteristic of the video stream of some AVI files, namely an unusually high frame rate of 120 fps. Such a frame rate might seem useless and utterly wasteful, given that film sources run at 24 fps, video sources run at up to 30 frames/60 fields per sec, and computer refresh rates not generally higher than 85Hz.

Ah, but there is reason to this madness.

The reason for the 120 fps frame rate becomes clear if you look at the data in the stream itself, namely that at least 75% of the frames are empty. Basically, someone came up with the innovative idea of using null frames in AVI to achieve variable frame rate in order to accommodate both 24 fps and 30 fps within the same file. A 24 fps portion uses a frame density of 1/5, whereas a 30 fps portion uses 1/4. The need for mixed 24/30 comes from recording video which has both telecined and non-telecined video, and applying inverse telecine to the appropriate portions.

VirtualDub can process these videos to some extent, but there are some shortcomings. Attempting to recompress or filter the video will result in a 120 full frames per second. Also, attempting to play the video will result in a mind-numbingly slow frame rate because VirtualDub will still attempt to blit/flip at 120 fps. You can, however, direct stream the video, and you can use frame rate conversion in this mode to remove some of the null frames and drop the video stream to a more ordinary frame rate. I'm working on improving support for sparse video streams in a future version.

Semi-recent versions of VirtualDub have an audio filter known as "center cut." This filter attempts to isolate the central components of the incoming signal and separate them from the side signals. The result is a stereo output with the ambience, and a mono output with the foreground sounds and vocals. To test this filter in VirtualDub, enable advanced audio filtering, then add input/center cut/output/discard filters to the filter graph, in that order (or swap discard and output).

Someone asked me by email if I could describe this algorithm, and I thought it would be blog-worthy.

Disclaimer: I'm not an audio researcher and am not familiar with the audio literature, so excuse me if I use the wrong terms or fail to acknowledge past work, as I am not familiar with existing advanced algorithms for vocal removal. I came up with this algorithm one day after a discussion about vector projection in lower-division math class, so I didn't do any research before devising the algorithm.

I wanted to hack together a particular variant of expression evaluator, but wanted an editor a bit more substantial than the usual Notepad I use for quick hacks. So I fired up Visual Studio 2005, and on a whim, decided to select "CLR Console Application." And so VS2005 set up a sample console Hello World! application for me. C++/CLI is still C++, so the source code file mostly looks the same, just that it uses .NET console commands.

Oh, and the project comes with an icon, a resource script, stdafx.cpp/.h, an assembly info module, and a readme. I guess I can deal with that for a throwaway project.

I try to convince myself that I'm a assembly/C++ luddite and I should try to learn more of this .NET stuff. Every time I do, I see stuff like this that makes me cringe. Why does a Hello World application require the common controls library, shell API, and remote procedure call runtime??

Here's what I get from a good old fashioned Win32 Hello World app made by VS2005, for comparison: