- Your meta-search moment of the day
-
As of right now, a search on live.com for the term livewhacking returns exactly one result.
- A Blissful Installation
-
I've experienced software installer bliss.
Here's the scenario: I went out and downloaded an application so I could test its compatibility for a dev. I ran the installer, which popped up a UAC dialog. I confirmed the install, and then got an incoming e-mail. I read the e-mail which directed me to a webpage where I filled out a survey. The survey reminded me of a website I needed to read and then write a blog post about. After the blog post I noticed that my build window had finished compiling, so I checked in the code I was working on and started in on some new edits. Not long into this I got another e-mail from the dev, which reminded me that I had never finished installing that application.
Suddenly, I started sifting through the myriad of windows on my desktop looking for the installer that I had neglected. Not there. The installer wasn't even running, says taskmgr. So what happened? On a whim, I checked the Start menu, and there it was. My app, fully installed, ready for me to run, and patiently waiting for me to launch it on my terms.
I was shocked, to say the least. Where was the installer wizard? Where were the six dialog boxes to click through? I got none of that. No intro page telling me that yes, I've launched the installer, and I need to click Next to continue. No pages and pages of EULA text that nobody reads, but rather just clicks Next to continue (The EULA was available at install time, but the installer didn't need to rub it in my face). No installation summary that indicates that it's going to install one component (The Software) and that I need to click Next to continue. No demands that I shut down other apps, or focus-stealing confirmation page after the install.
And finally, no messing with other parts of my system. Where do you want me to put my icons in the start menu? Can I dump icons onto your desktop? How about your quicklaunch bar? Your startup folder? How about your documents folder? Is it okay if I change your browser homepage? Mind if I also install a toolbar, an IM program, and a keylogger while I'm at it? This installer didn't do any of that, nor did it even ask me about it.
It was surreal. Sparse. Minimal. I didn't know how to react at first. All the installer did was install the software. And it didn't even make a big deal of it. The application was just there, ready to start when I needed it, and not before. I guess what surprised me was that it had never even occurred to me that an installer could run without my hand-holding. Years of conditioning by needy installers had desensitized me to all of these unnecessary clicks. Not since the days of XCOPY installs on Win95 have I been able to multi-task while installing software. It's refreshing.
This is what I mean when I talk about software that Just Works.
- The ADD Stove
-
As you well know, people with peculiar quirks can have special equipment needs. There are plenty of examples such as ramps for those with wheelchairs, closed caption for the hard of hearing, and reality TV for the thinking impaired. Those of us with the Attention Deficit trait have the ADD Stove.
The ADD Stove comes with several front burners in large and small sizes. The stove lights up very quickly, and the burners come to full heat in seconds. Likewise, they cool down quickly, returning to room temperature within seconds of being turned off. The ADD Stove has some disadvantages. It can be difficult to keep the ADD Stove lit, as it has a tendency to go out partway through a meal. The stove can be slippery, and sometimes you have to pay extra attention to keep pots and pans from sliding off of the burners. Still, the stove is extremely efficient if you can keep it on task, and many users are very happy with their appliance.
User studies have found that the biggest disadvantage to the ADD Stove is so prevalent as to be considered an obvious design defect. The ADD Stove has no back burners. Instead, there is a large gap between the stove and the wall that pots and pans can easily fall into. Experts have speculated that this oversight is due to design compromises in putting so much functionality and attention into the front burners. Due to this defect, pots and pans which are pushed to the back burner will fall off the back of the stove where you can no longer find them.
Users of the ADD Stove are therefore cautioned never to push anything onto a back burner, lest they lose sight of it completely.
- You can't hear DC
-
Recently one of my team members found a bug in some old code while doing a code review. Our application was generating a sine wave to be rendered by the audio hardware. The sample format isn't important except to note that it is an unsigned value between 0 and MAX = 2*FS_AMP. The bug is in the following code.
| void GenerateSineWave(float buffer[], float frequency, float amplitude) {
// frequency in Hz, amplitude in range(0.0, 1.0)
float w = 2 * PI * frequency / SAMPLE_RATE;
for (int t = 0; t < NUMBER_OF_SAMPLES; t++)
float sample = sin(w * t) * FS_AMP // full scale sine wave
sample += FS_AMP; // Move into positive range
sample *= amplitude; // Scale to requested amplitude
buffer[t] = sample;
}
} |
So do you see the bug? After this code, we have a sine wave that oscillates between 0 and 2*amplitude*FS_AMP. For amplitude = 1.0, this is exactly what we want, but for any smaller amplitude, the wave is low-justified in the sample range.
What we really wanted here is a signal that is center-justified in the range, such as below. We were sending the wrong samples!
The fix is fairly simple. We want to scale (*= amplitude) before we translate (+= FS_AMP). Then we get a sine wave that oscillates between (FS_AMP *(1-amplitude)) and (FS_AMP * (1+amplitude)).
After fixing a bug in old code, the next question we have to ask ourselves is why we missed it. How come this bug wasn't found in a test pass when it was written, or any time in between? The answer is almost as subtle as the code that caused the problem. From an audio perspective, the bug had no impact at all.
The buffer generated by this buggy code was sent directly to the DAC on the hardware. The signal does not clip, and it's not distorted. All of the sine components are the same. If you got an FFT on each of the two sine waves above, they would differ only in the very first bin, the one corresponding to the DC component of the signal.
But you can't hear DC.
DC is essentially the baseline for a signal. The value from which the signal wave deviates in time. The measured level of silence. For a speaker, the DC level is the distance of the cone when unplugged. For the atmosphere, DC is about 14psi (or 1.0 atm) at sea level.
For a digital signal stored as numbers, DC can be any arbitrary value. In a computer which have a fixed minimum and maximum, we usually choose halfway between min and max because it offers the most dynamic range. This also explains why most audio formats use signed numbers for samples rather than unsigned. The center of the allowed range for a signed number is zero, and zero is a very easy number to work with. In the code snippet above, the bug would not manifest if we were using signed numbers, because the translation step for signed numbers is a no-op.
One other way of looking at DC is as a wave with frequency zero, and an infinite wavelength. Since zero is below the lowest frequency a human can hear (about 20Hz), you can't hear it. Q.E.D.
Epilogue: This bug does show up as a frequency component any time we dynamically alter the amplitude while streaming, so we fixed it.
- The Rules of Code Optimization
-
Steve Rowe recently talks about who you're really writing for when you write code. The argument he makes is essentially that your primary audience is not the compiler, but rather your primary audience is other developers. This is something I believe strongly.
Steve also makes a point about premature optimization, and how it affects readability. This reminded me of a list of the Rules of Optimization that I try to live by:
- The First Rule of Code Optimization: Don't.
Optimizing code has a negative effect on readability and maintainability. The vast majority of code doesn't need to run particularly fast, but it all needs to be maintainable. Even programs you think are one-off and temporary have a tendency to become permanent.
Most businesses want to keep costs down, but as a rule, hardware is cheap. Developer time is expensive. Don't optimize for the wrong variable.
If you believe that the First Rule doesn't apply to you, (by the way, you're probably wrong. Go read the first rule again) then it's time to consider the second rule.
- The Second Rule of Code Optimization: Don't yet.
Designing code and optimizing code are two very different operations. Your maintenance programmers will thank you not to mix the two. For both optimizing and maintaining code, it is far easier to start from a good solid readable design, than to start from code that was "written optimized". (and that's assuming you can even figure out what the latter was doing). Do not optimize code as you write it, unless you like rewriting over and over.
- The Third Rule of Code Optimization: Profile first.
Optimizing all of the code is almost never feasible, and is never worth it. It you're going to spend three developer days to squeeze 10 milliseconds of performance out of your code, it's probably better that you get those out of the inner loop of a column lookup, rather than the startup splash screen display code.
So which code is best to optimize? You don't know. You can generally make educated guesses, but there's your problem. They're just guesses. If you guess wrong (your first guess is almost always wrong), then you'll end up doing more harm than good by optimizing (remember the maintainability hit). So how do you know? Profile. Run tools that will tell you which code is spending most of the time. Optimize that code. Often, you'll find an answer you never expected.
Never optimize without profiling first.
Code optimization is sometimes a necessary evil, but do not forget that it is an evil. It obfuscates the true meaning of the code, and it takes developer time that could be spent on bug fixing or new features. Some applications (such as real-time audio) can't get by without optimizing, but most applications (card games, mail programs, web apps, etc) can get along just fine without unnecessarily complicating the code. And when you do need to optimize, have hard data to back up that you're optimizing the right place.
- Youtube on the Loudness War
-
Larry pointed me to a really cool video that graphically and audibly demonstrates the effect of the Loudness War, and what happens to samples under excessive clipping.
http://createdigitalmusic.com/2007/05/16/loudness-war-music-over-compression-demonstrated-on-youtube/
The createdigitalmusic link also gives a pretty good synopsis on the loudness war from the perspective of the production industry.
- Tweaking Legacy Installers
-
Last time I talked about legacy applications, I hinted at a hole in the UAC model that could be exploited by a social engineering attack. The issue lies in the "installers" category. Because it's a legacy app and doesn't have a manifest, Windows doesn't have any way of knowing whether an installer actually needs elevation to perform the install.
For the sake of backward compatibility to make sure that legacy apps just work, Microsoft decided that Windows should just elevate legacy installers by default. In most cases, this is the correct thing to do; legacy apps were developed primarily in a culture where every user was an admin, and most installers take advantage of that. So, Vista runs all legacy installers as administrator. The problem with this is that, if you're a power user, you know that not everything needs to run as administrator. The power user is savvy to the intricacies of ACLs and permissions, and knows that while his antivirus might need administrative privileges to install, the latest downloaded java game probably does not. And while you might be willing to trust the makers of that java game enough to run their silly software, you don't trust them to administer your machine.
The meat of the problem is that if Windows determines that a program is a legacy installer, then by default you're limited to only two choices: Run elevated, or don't run at all. This can be a real pain if you have a legacy program that isn't really an installer, but the heuristic treats it as one (Some archive programs are like this).
Fortunately the third option, run as a standard user, is available if you know what you're doing. On a per-app basis, you can set the __COMPAT_LAYER environment variable to suppress the installer heuristics. Just open a (non-elevated) cmd window, and type "set __COMPAT_LAYER=RunAsInvoker", and any legacy app you launch from that cmd window will run as standard user. As standard user, you can install your game applet with much less worry that it will install a rootkit or overwrite your registry. This is the recommended way to run legacy installers with low privileges.
If the recommended way doesn't work for you, you can instead shut off the heuristic entirely at a loss of some backcompat functionality. There is a switch in the group policy for Windows that disables auto-elevation for legacy installers completely. The backcompat problem is that legacy installers which really do need elevation will now crash on install, often with few clues as to why they didn't work. You have to remember to right-click the executable and select "Run as Administrator". If you don't, then you can waste a lot of time frustrated because "Vista doesn't work with this software!"
Disclaimer: As with all advanced system tweaks, make sure you Really Know What You're Doing before trying this. I am not responsible for any damage you may do to your computer. To flip the switch, run gpedit.msc, and open the tree to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Scroll down in the right pane to find "User Account Control: Detect application installations and prompt for elevation", and set it to 'Disabled'
So why didn't Microsoft just ship like this? Put yourself in the chair of my fictional Aunt Gertrude, as suddenly programs that worked fine on XP fail to install on Vista . How do you explain to Gertrude what it means when her program fails with strange and unhelpful errors messages? Even if you added a dialog saying to re-try as an admin, it wouldn't help much. We all know that users don't read dialogs. Vista broke Aunt Gertrude's program, and to the average user, that's all that matters.
- Categories of Legacy Applications
-
If you've used Vista, you've probably been exposed to the UAC dialog. It's the security dialog that pops up when the screen goes gray, and asks you permission to perform a task which requires admin-level elevation. The idea behind it is that once programs are written for Vista (with UAC in mind), they'll sort themselves into two categories: Trusted programs that require administrative privileges (and have to pass a UAC prompt) to do their jobs, and programs that run fine without administrative privileges.
The big problem with rolling out UAC is how to deal with all of the legacy applications that have to still work. I roughly divide legacy (pre-Vista) programs into five six categories:
- Programs that don't need or request admin privileges.
The majority of programs that run don't try to do anything forbidden like writing to system directories or opening . These programs will run fine under Vista.
- Programs that don't need admin privileges, but try to access protected areas.
Even a well-intentioned app might open a system registry key for full access when it only reads the key, or might write its settings to a config file in the program files directory, because that was perfectly OK under XP where everybody ran as Administrator. For these apps that didn't really need admin access, the system virtualizes these accesses. A virtualized program is allowed to read and write as if they're writing to the system, but those changes are virtualized under the user's AppData folder.
- Utilities that legitimately need to be able to modify the system.
Some programs are fully intended to administer the system, and cannot run properly in restricted user mode. Simply double-clicking this utility will cause it to fail, because the system doesn't know that it needs elevation. These legacy programs must be launched with elevated privileges in order to work. The three common ways to do this are to right-click the .exe and select "Run as Administrator", to select "Run as Administrator" in the compatibility tab of the program's properties dialog, or to run cmd.exe as administrator and launch from there. Any of these methods will get you a UAC prompt, of course. Fortunately most people don't need to run programs in this category very often.
Though many in the blogosphere would be quick to disagree, I'm actually glad that the UAC dialog is showing up here. The dialog serves two purposes for me. It is a warning flag whenever something is about to get access to my system's tender bits. It is also a reminder that whenever it isn't there, the OS is making certain that whatever's running can't get at my system's tender bits.
- Malware
Some programs we just don't want to allow admin privileges to. This is the class of programs for which UAC was invented.
- Installers
An installer is a special case of one of the previous categories which often needs more privileges than the program it installs. This is because installers have to set up directories, resources, and registry keys. Though it is possible to create an installer which does not need admin privileges, most legacy installers do need them and will fail without elevation, resulting in a bad user experience. The Vista planners recognized this, and made installers a special-case. Because most legacy installers will fail if they are not run elevated, Windows Vista will automatically elevate the privilege of any legacy installer.(after raising a UAC dialog, of course)
Eventually, application designers will write more Vista-aware programs, which understand how to work around the different privilege levels. A Vista-aware program can contain a manifest, which contains metadata on the program including whether or not it needs elevation. Because unnecessary UAC dialogs annoy users, software vendors will work to avoid them. In the ideal application world, then, the following happens with our five categories.
- Programs that run fine without elevation continue to run unchanged. They were already doing the right thing.
- Programs that don't need elevation but try to access protected areas will be fixed so that they fit into category #1. The registry access will be changed from full access to read-only, and the config file will be properly stored in the user profile's AppData directory.
- Legitimate Windows utilities include a manifest with the elevation bit set. When you try to launch the program, Windows shows a UAC dialog. The program is legitimate, and you intended to administer the box, so you click yes and the program runs with admin privileges.
- Malware in the post-Vista world will likely include a manifest with the elevation bit (because malware that doesn't is already blocked from affecting the system). Windows shows a UAC dialog, but you didn't intend to administer the system and you don't trust the source of the program, so you click no.
- Installers include a manifest. The few installers which legitimately need to write to system locations (drivers, system utilities, debuggers) set the manifest's elevation bit. Other installers leave the bit clear, and install without a UAC prompt.
Ideally, when the only programs that legitimately require elevation are system utilities and driver installers, the user will see very few UAC dialogs, and will be vigilant for malware whenever it rears its ugly head. What a wonderful world it will be, then. :-)
- Programs that explicitly check for a version of the OS.
Some programs would run just fine on the OS, except that they bind to one specific version to the exclusion of later versions. You may have seen this one, which pops up a dialog in setup on Vista saying "You must run this program on Windows XP". The program checks GetWindowsVersion equal to XP, rather than checking that it's greater or equal. For these buggy programs, there's Compatibility Mode. When you run a program in Compatibilty Mode for a given version of Windows, Vista will lie to the program and pretend to be that version, causing it to run correctly. To turn on Compatibility mode for a program, right-click the program
and select Properties. In the Compatibility tab, select "Run in
compatibility mode".
Next time: See if you can spot the social engineering hole in this model.
UPDATE: It seems I mixed up virtualization with compatibility mode. Fixed above (#2 and #6)
- More posts eventually!
-
It's that time of year, it seems. I was down with the flu last week, and I'm
trying desperately to catch up this week. I promise I'll get more posts up
soon. I'm doing some WASAPI playback library stuff right now and I'm just dying
to do a couple of articles about the new Vista audio APIs. I'm also trying to
figure out a way to work in some more usability stuff.
Meanwhile, to keep you occupied, here's a pretty cool demo of Vista's speech recognition engine. The guy in the video is trying to program perl - a task for which Vista SR is clearly not designed. He is apparently trying to make Vista look bad, but to me he really only manages to make himself look silly. From the video one can immediately conclude two things:
- Vista Speech Recognition is really quite good for documents and conversation.
- For programming, stick to the keyboard.
(Warning: NSFW. Contains F-bombs and other colorful verbal frustruation as the protagonist tries to make the parsing engine emit perl-shaped line noise. If you're at work, time to put on the headphones.)
http://www.youtube.com/watch?v=MzJ0CytAsec
- Digital Audio: Aliasing
-
Sampling a continuous waveform into discrete digital samples results in lost information. Discrete samples can only tell what the wave is doing at periodic instants in time, and not what's happening between them. The continuous sampled wave could be doing anything between samples. We simply don't know.
The problem here is that when we want to get back the data that we threw away and turn samples back into a continuous wave, we must interpolate between samples to find the lost information. Unfortunately, there are an infinite number of signals that could have produced the samples that we want. Fortunately, if we accept a small restriction on our continuous waveform, we can get back to one unique signal.
I think an example is in order. Consider the 7kHz sine wave below, shown over a 1ms interval.
If we sample this sine wave with a sampling rate of 10kHz, we get 11 samples in this interval (counting the endpoints), as shown below.
But when we play back these samples, you won't get 7kHz out of the speaker. What you hear is the 3kHz wave described by the red curve below.
So what happened? Notice that both curves produce exactly the same samples, when sampled at 10kHz. At this sample rate, there is no way to tell the difference between 3kHz, 7kHz, or even the 13kHz wave below.
This effect is known as aliasing, and these frequencies are aliases of each other. In fact, for any frequency f and sample rate S, all frequencies of the form (N*S ± f) for some integer N are aliases.
There is hope, though. For given f and S, there is one unique frequency of the type (N*S ± f) that is between 0 and S/2. Looking at the samples in the example above, the 3kHz wave is between zero and half the sampling rate. No other frequency between 0 and 5kHz can be produced from those samples, and the wave is unique. The frequency S/2, called the Nyquist frequency, is the upper limit of alias-free signal frequency.
All of the information lost from sampling a continuous waveform has a frequency higher than S/2. Therefore, the process of sampling is lossless, as long as all of the frequencies you're interested in are below half the sample rate.
But wait, you may ask. What if you're interested in preserving higher frequencies? Just increase the sample rate to more than twice the highest frequency you're interested in. The human ear can hear frequencies of up to about 20kHz, and it's no coincidence that CD Audio samples at 44.1kHz, providing bit-perfect representation of any frequency humans can hear.
There is one more problem when sampling. Sampling just your frequencies of interest isn't always enough. High frequencies don't just go away when you sample. This out-of-band noise (Noise because it's not part of the signal we want to preserve) in your continuous signal will still be sampled, only now it will alias down below S/2 and contaminate the digital signal you want to keep.
For this reason, any time you sample a continuous signal, you must first band-limit the signal with a low-pass filter to block (attenuate) all frequencies above the Nyquist frequency, so that there is no out-of-band noise at the sampling stage. More on what that means in another post.
- Clipping in popular music
-
Aside from the distortion artifacts, one of the biggest problems that results from clipping is a loss of dynamic range. Remember that the dynamic range of a signal is effectively the difference between the maximum output level and the noise floor. When you clip a waveform, you lower the maximum sample value, which lowers the output level and reduces dynamic range.
This can happen especially when you amplify a signal. Amplification increases all parts of a signal, including its noise floor and its maximum value. Normally, these two values increase by the same amount, so the ratio between them stays the same and dynamic range is unaffected. Unfortunately, a signal that is amplified too much has to clip at the top end, and that's when DR suffers.
So the moral here is don't overamplify your music, right? That seems easy enough. The problem is that popular recording studios don't listen. Recall that, superficially, louder music sounds better. Better sounding music sells more discs, and so it pays for the studios to master their music as close to the clipping level as possible. "But wait," the studio says, "most people are tone-deaf anyway. We can get it just a little louder than our competition if we clip a little bit off of the peaks." The competition responds in kind, clipping just a little more, and the result (as Larry scooped me on) is why popular music has terrible dynamic range.
The following articles tell the sad story far better than I can. I encourage you to give them a read.
http://www.mindspring.com/~mrichter/dynamics/dynamics.htm (mirror)
http://en.wikipedia.org/wiki/Loudness_war
http://www.prorec.com/prorec/articles.nsf/articles/8A133F52D0FD71AB86256C2E005DAF1C
http://www.austin360.com/music/content/music/stories/xl/2006/09/28cover.html
And one of my favorite illustrations: http://recforums.prosoundweb.com/index.php/mv/msg/4286/0/0/0/
And now you know why serious audio aficionados stick to the classics. :)
- Louder Sounds Better
-
Below is an example of the Fletcher-Munson Equal Loudness Curve. It is one of the most recognized graphics in audio engineering.
The horizontal axis is frequency of tones, and the vertical axis is actual sound pressure in dBSPL. Each point on a curve has about the same subjective "loudness" to the human ear. The low parts of the curves are the frequencies where the ear is more sensitive. Conversely, the high parts are where the ear is less sensitive and it takes more pressure to get the same 'loudness'. The dotted line at the bottom represents the threshold of hearing. Any frequency below that line can't be heard at all by the average human.
Consider an arbitrary waveform coming out of a speaker. That waveform has the frequency response shown in red on the diagram to the right. The blue line is the same waveform amplified by 20dB, and the orange line is amplified by 80dB. Notice that the louder signal aligns better with the flatter Fletcher-Munson curves at the top. There is less variation in sound at different frequencies, and the result is that the louder signal has a richer, fuller sound.
The opposite is also true. For quieter sounds, certain frequencies to which the ear is less-sensitive can seem to drop out of the signal, especially at very high and very low frequencies. The orange line has a very powerful bass, with low frequencies staying close to the same loudness as the middle. The blue line's bass is much less 'loud' than the middle frequencies. Many frequencies on the red line have completely dropped out, below the threshold of hearing.
The Fletcher-Munson curves illustrate an audio engineering example of why, to the human ear, louder sounds better. The higher the signal amplitude, the more frequencies are present, making the signal richer and fuller. You can also read this article, which discusses it from an audio production and musician's point of view.
A practical result of this is that when a person tries to compare two sounds, the louder one will often subjectively sound better regardless of their relative signal quality. Any time you want to compare sounds by ear objectively, you have to make sure they're the same level.
One final note: I hope this post does a little bit to explain why people are drawn to loud concerts, or to turning headphones up to extremely high levels, but there's a very dangerous flip-side. The orange line in my figure above peaks out at about 125dBSPL. A concert at that level may indeed sound good, but it is also at or above the threshold of pain, depending on the listener, and any prolonged exposure will likely cause permanent hearing damage. There are any number of guidelines about maximum safe listening levels, and I recommend you heed them. That set of headphones may sound mighty fine cranked up to 90dBSPL, but they are also doing irreparable damage to one of your most important and finely tuned sensory organs. Perhaps someday I'll do a post on exactly what happens when you destroy your auditory receptors. Trust me, it isn't fun.
- Vista Now Available
-
After months of waiting it's released. Go out and get yourself a copy already!
- How to drive on Snow and Ice
-
Ah, the winter storms are upon us once again. And once again, a disproportionate number of my extended neighbors are demonstrating their incompetence behind the wheel. It seems that no matter how many times the Puget Sound region gets snowed upon, people never learn how to drive in it. To that end, I've put together a set of helpful guidelines to help people understand how to drive on snow and ice.
- Don't.
If you don't absolutely, positively HAVE to be on the road in these conditions, then stay inside next to a nice warm fire with your car safely parked. I'm sure you can come up with any number of reasons why you think you have to drive in this crap, but remember that nearly all of the problems that you can have driving on snow and ice (accidents, getting stuck, freezing to death, etc) are a direct result of breaking rule 1.
- You can change direction, or you can change speed, but you can't change them both at the same time.
You only get so much friction with which to control your vehicle. You can use it to speed up, to slow down, or to turn. You don't have enough friction to do more than one of these things at a time. Remember, the fastest way to spin out is to turn the wheel and apply the brake at the same time. Maybe that's what you wanted to do, but unless you're 16 and in your dad's car in a deserted parking lot, I doubt it.
- Slow Down.
In a low-friction environment, inertia is king. For the next few moments, you will continue to go the same speed and direction that you're going now, whether you want to or not. The faster you're going when you decide that you don't want to go that direction anymore (such as, say, an object at rest in that direction), the less fun you'll have in the next few moments. Note there is one exception to the inertia rule, and that is that an object in motion will stop anyway if it encounters a larger object at rest. At this point, you do not want to be the erstwhile object in motion.
- Get off my bumper, you tailgating imbecile.
See discussion above.
- Don't you wish you lived somewhere warmer?
Did you know that there's a whole hemisphere of the Earth which is in summer right now? I bet it's not icy there.
- Just stay home.
The observant reader will realize that this is really just a restatement of rule 1, but it really is important enough to repeat. Stay safe, stay warm, and we'll all make it through to springtime. I'll race you there.
- Audio Fidelity: Clipping
-
In theory, an audio signal can take on any amplitude. There is no mathematical upper limit for how far from zero a sample can go, or how high the magnitude of a continuous wave can go. In practice, however, a digital signal's amplitude is limited by its number of bits, and even electrical components can only handle so much voltage without being damaged. Every real-world device has some practical maximum value that the signal can attain. Try to go past this maximum, and your signal will suffer. Clipping occurs when an audio device tries to output a signal whose amplitude is greater than its maximum value, and instead outputs the maximum value. Clipped waves have a characteristic "leveled off" top (or bottom) that looks as if the wave were just chopped off.
The best way to describe the problem with clipping might be by example. Here is a generic sine wave (click for larger image):
And here is the logarithmic frequency spectrum of that sine wave. The gray line represents a typical noise floor. Anything above the line is above the noise floor, and anything below the line generally won't be heard. As expected with a clear sine wave, we see a single spike at our fundamental frequency, and no other audible tones.
Now, here is the same sine wave doubled in amplitude and then clipped (admittedly, an extreme case, but not as uncommon as you'd think):
And the FFT of our clipped wave. Notice the clearly audible harmonics.
This is obviously a suboptimal listening experience - For every sound, you hear every odd harmonic. But it could be much worse. There is no good solution to limiting a signal level, and clipping is just one of several things that a filter can do when it tries to produce a signal that is too hot. A much worse outcome (common in poorly designed older digital filters which store samples as CPU integers) will overflow and "wrap" instead of clipping. The sample jumps from INT_MAX to INT_MIN (or vice versa), and the speakers represent this as a full-scale impulse, resulting in a "pop" that can damage your hardware (and your ears!).
One alternative to clipping, known as soft clipping, involves using a complicated function to "compress" the wave as it gets near the maximum value. Compressing the wave this way still introduces distortion, but it doesn't have the hard "edge" that clipping does.
Clipping and soft clipping introduce errors into a signal. For this reason, you want to do it as little as possible during intermediate steps. With the new audio engine in Windows Vista, all internal signals are stored as floating point numbers. Valid output samples are between -1.0 and 1.0, but intermediate steps between digital filters can be outside that range, and the data type handles it just fine. At the last possible step, the audio engine performs another kind of limiting (which I'll let JJ describe), converting to integer (if necessary) and sending to the audio codec. This is an improvement over all integer digital processing, which has to apply limiting at each stage.
Fidelity series index