New Year's Resolutions -- for Microsoft

For better or worse, I've been a Microsoft fan since Windows 3.1. Microsoft is far from perfect, but the alternatives were always so much worse. Can you imagine a dystopian future where we're all running IBM's OS/2 2004 and Lotus Notes Express? Brr. I get a chill just thinking about it. The other contenders have similar glaring flaws. Oracle*? Intel? Sun? Apple? Thanks, but no thanks. To quote Winston Churchill:

Many forms of Government have been tried, and will be tried in this world of sin and woe. No one pretends that democracy is perfect or all-wise. Indeed, it has been said that democracy is the worst form of government except all those other forms that have been tried from time to time.

Microsoft succeeds not because they're an evil monopoly, but because they release decent products that are relatively easy to use. Most of the time.

Personally, I think Microsoft's biggest enemy isn't Google, Linux, Yahoo, or the relegation of PCs to a niche. Microsoft's biggest enemy is Microsoft. The company has grown so large that it can't turn the massive battleship fast enough to respond to competitive pressures. The BusinessWeek article Troubling Exits at Microsoft outlines the scale problems Microsoft faces:

Some workers express frustration that Microsoft is so busy protecting its PC-based businesses that it comes up short when competing on the Web. Take the customer relationship management (CRM) market -- software that companies use to track sales and customer service activities. Microsoft targeted it 2 1/2 years ago with a traditional software package, Microsoft CRM. Today roughly 4,000 companies run the software for nearly 100,000 staff. Not bad, but Microsoft hasn't been nearly as successful as Salesforce.com Inc., a trailblazer of Web-based CRM software, with 308,000 users at 17,000 companies.

The secret to Salesforce.com's success: the speed with which it can update its software. Microsoft last updated its original CRM software in January, 2004, with plans for a new version in first quarter, 2006. Meanwhile, Salesforce is constantly fixing bugs and adds features without interruption to the customer or added expense. All customers need to do is open a Web browser to run the program. Microsoft CRM boss Brad Wilson argues that business software is complex and best sold as a package that customers run on their own computers. "This is really about business process where you've got multiple steps," Wilson says. "It is a much more extensive thing that often requires a lot of people, a lot of time, and a lot of resources."

Perhaps most tellingly, it's been five years since the release of Windows XP. That's the longest gap between Windows releases ever.

There's also internal criticism at the Mini-Microsoft blog, which if anything, is evidence that corrective forces are already at work within Microsoft. Microsoft, the company everyone loves to hate, has adopted transparency and blogging aggressively. So aggressively, in fact, you'd almost mistake them for a Web 2.0 company. For example, Scott Koon says the product manager for ASP.NET is the best thing going for it. I agree. I can point to a dozen Microsoft blogs off the top of my head that are absolutely amazing-- incredibly smart, articulate people any talented developer would be privileged to work with.

But blogging and transparency alone won't be enough. What else can Microsoft do to shed the bureaucracy problem? If you were Microsoft, what would your new year's resolutions be? Here are a few of my suggestions:

• For Windows products, release betas earlier and to larger audiences. Incorporate substantial user feedback before the product ships. Office 12 and Visual Studio 2005 are good examples of how to do this-- but make sure there's ample time to actually implement the suggestions and not just defer all the suggestions to some unspecified future release.
• For web-based solutions, do away with formal releases entirely and treat them as works in progress, ala Atlas.
• Stop being shy about releasing service packs. Why does Visual Studio 2003 have no service packs after nearly 3 years? Because it's bug free? Yeah.
• Don't let eeyore design your products.

  .. if you reward people for demonstrating that they excel at process excellence then, well, hell, forget if you actually ship features. Look at all these pretty, beguiling graphs about promising features! And fetch me a crop of dithering middle managers! If you openly reward and promote people for killing work by bemoaning the risk and the testing cost and localization impact of each feature and interrogating a DCR as if it were Dan Brown shackled in-front of a wild-eyed, hot-poker wielding Pope, well, everyone is going to grab pitchforks and jump on that "No can do! No can ship!" bandwagon.

  It makes me think of how many feature meetings I've had and what a small percent of those features have actually ever shipped. Not that every feature is a good idea, but it's damn near wake-worthy sometimes for a feature to actually get out into shipping bits. Que Eeyore: "Oh no. Now we have to support it. I suppose a hotfix request will come in any moment now..."

Most of these suggestions are ways to speed up the software development cycle at Microsoft. The hallmark of Web 2.0 companies is that they evolve faster, as ex-Microsoft employee Mark Lucovsky, who now works for Google, so famously pointed out:

When an Amazon engineer fixes a minor defect, makes something faster or better, makes an API more functional and complete, how do they "ship" that software to me? What is the lag time between the engineer completing the work, and the software reaching its intended customers? A good friend of mine investigated a performance problem one morning, he saw an obvious defect and fixed it. His code was trivial, it was tested during the day, and rolled out that evening. By the next morning millions of users had benefited from his work. Not a single customer had to download a bag of bits, answer any silly questions, prove that they are not software thieves, reboot their computers, etc. The software was shipped to them, and they didn't have to lift a finger. Now that's what I call shipping software.

I think Microsoft is doing the right things-- but they need to do them a lot faster. Company size and red tape be damned. Otherwise that much-maligned dinosaur advertising campaign for Microsoft Office is going to seem awfully prophetic in retrospect.

* What's the difference between God and Larry Ellison?

Of White Elephants and Gifting

My favorite holiday tradition is the white elephant gift exchange. If you don't have these in your family or at your workplace, you're missing out on a lot of fun. Maybe I'm easily amused, but it's consistently the most fun I've had during the holidays. As an adult, anyway. The rules for a white elephant gift exchange are simple:

Everyone brings a gift already wrapped. Gifts should all be valued at roughly the same amount, usually $20 or $25. The gifts are strictly anonymous -- no one should know which gift you brought. All the gifts are placed on a large table, and each participant draws a number.

The person with #1 picks out a gift and opens it so all can see what it is. The person with #2 can either "steal" any unwrapped gift or choose a wrapped gift from the table. The game continues for each subsequent player with the following rules:

1. If someone steals your gift, you can steal someone else's gift, or choose a wrapped gift from the table.
2. A gift can only be "stolen" once during a turn.
3. The turn ends when a gift is opened.

After the last turn, the person with #1 can opt to put back the gift and "steal" according to the rules. This starts the gift exchange again and ends when someone chooses or is forced to take the gift given up by the person with #1.

The real fun of a white elephant party is in the stealingtrading. Most white elephant parties are notorious for the yearly modifications to the rules to lubricate the trading process. Here's a clever one I recommend: have an "obvious" gag gift with a hidden $50 gift card in it. This encourages trading of the weirder gifts, which otherwise tend to languish with the original person who opened them. And no trading is no fun! The best white elephant parties have a good mix of gifts: some tacky, some bizarre, and some genuinely useful. When buying a white elephant gift, try to pick an interesting item that falls into one of those three categories. And put some thought into it-- don't just bring yet another bottle of wine, or the DVD du jour. Boring!

After participating in white elephant parties at Vertigo and my previous job, I began to wonder about the origin of the term "white elephant". The best answer I found was in this blog post:

white elephant

1. A costly possession requiring so much upkeep that it becomes a burden.

2. Something no longer wanted by its owner.

In [Thailand], the rare albino elephant was sacred, and each new one born belonged to the king. Moreover, it was forbidden to kill such an elephant or to use it for work. Therefore, the story goes, whenever the king wished to punish an obnoxious courtier, he'd make him a present of one of these pale pachyderms.

It was a gift to be dreaded, however. Recipients could neither use the elephant nor get rid of it -- and inevitably went broke trying to keep it fed. Nowadays, the expression white elephant is used to apply more generally to any burdensome possession.

It's a great story, but it's amost certainly anecdotal. And white elephants aren't actually white. Because they're mostly hairless animals, albino elephants read as more of a mottled grey or pink, as you can see in this closeup photo.

Perhaps the best thing about white elephant parties is that they relieve us of the gifting burden. Buying a completely inappropriate gift for someone is way easier than trying to figure out what they might actually like. My wife and family complain that I'm notoriously hard to buy for. That's what happens when you grow up and realize that you're still a big kid with, er.. a lot more money. If you're trying to figure out what to buy for someone like that, I highly recommend Kevin Kelly's Cool Tools list. He digs up some amazing, obscure stuff. But what else would you expect from the ex-executive editor of Wired?

I tend to enjoy the wackier side of the white elephant gift exchange. Here are some memorable white elephant gifts from previous exchanges:

• a full-sized top hat
• Henna tattoo kit
• Bottle of Jack Daniels
• Unopened boxed copy of Windows 3.1
• Barbie calendar
• Handheld blood alcohol level tester
• Cow flashlight (complete with moo sound effect)

What are some of your most memorable white elephant gifts?

Seven Habits of Highly Effective Programmers

Philip Chu's Seven Habits of Highly Effective Programmers is witty, eloquent, and peppered with illustrative real world anecdotes:

Upon joining an early-stage startup called Neomar, I found myself in two months of design meetings for a wireless internet portal that was due to launch in six months. Eventually we got tired of meeting and finally started coding. Within two weeks, my part of the project had no resemblance to the original design, and the first wireless connection test two months later revealed a fundamental misunderstanding of the wireless protocol.

At Nichimen Graphics, a small 3D graphics software vendor, I was put in charge of porting the flagship product from SGI workstations to Windows NT. After six months, the port was so incomplete and crash-prone that I was reluctant to give the first "alpha" build our test group. Fortunately, the QA manager insisted, and the resulting bombardment of bug reports forced me to immediately focus on the problems that prevented the testers from exercising the application in any meaningful way. Left to my own devices, I would have worked on what seemed to be the harder and more important core 3D issues, and probably delayed too long on seemingly mundane issues like the user interface, load-save functionality, and compabilility with all the varieties of consumer hardware we were planning to support.

On a contract with a previous employer, I was asked to look over a piece of code that no one else had time to attend to. At first, I thought it was a mess and didn't know what was going on in there. Then I gradually figured out what the code was doing, and I grudgingly admitted the code wasn't too bad. And then I eventually realized that I had written the code two years ago. Note to self: need more comments.

It's a short but high quality read. Based on that piece, it's easy to recommend the rest of the articles at Philip's site*, including What I Learned at MIT, and Management Means Never Having to Say You're Sorry.

* which feels remarkably like a blog, but totally isn't. No RSS for you!

PC Racing Sims

I've been a PC racing game enthusiast since the day I wrapped my hands around my first force-feedback wheel in 1999-- the classic wire driven Logitech Formula Force. There's something about a quality steering wheel with physics-driven force feedback effects that really delivers on the sensation of driving.

I spent many hours tooling around the tracks in Viper Racing and Sports Car GT. These games had a great combination of physics and force feedback. Nothing turns me off faster than arcade driving games where you pilot a rubbery box around a track, bouncing off walls and fellow motorists with impunity. What's the point of fantasy driving without some semi-realistic risks? But that doesn't mean I'm a Grand Prix Legends masochist, either. Those guys are nuts:

When the creators of the ever-popular NASCAR series of racing simulations, Papyrus, decided to create a historical Grand Prix racing simulation, many people were confused. "How could a racing simulation modeled after the 1967 Formula 1 Season be fun?" they asked. To put it bluntly, it's fun because it is harshly and at times brutally realistic.

With few of the safety features and engine restrictions required on today's race cars, the 1967 Formula 1 season was one of the most dangerous in Motorsports history. Increased horsepower, no down force, rock-hard bias-ply tires, fuel tanks placed not only in the cockpit with the drivers, but specifically fabricated and molded in such a way as to surround the driver, and seat belts... what were those? The conventional wisdom in those days was that it was better to be thrown from the car during an accident than be belted into it. Considering the drivers were actually sitting in the middle of a 40 plus gallon, thin-walled, aluminum fuel tank filled with very exotic and volatile fuel, who could blame them?

I've gone through a succession of force feedback wheels since then, finally settling on the excellent Logitech MOMO Force.

Unfortunately, this particular model isn't available any more. But the more recent Logitech Momo Racing Force wheel is similar and highly recommendable. And that's just the tip of the iceberg. Here's a comprehensive wheel roundup to get you started. As with all things PC, there's lots of esoterica available, such as the ECCI Trackstar 6000.

Of course, a nice wheel isn't doing me any good if it's collecting dust. Although I dabbled a little bit with Colin McRae Rally 2004, I haven't been following the PC driving sim scene very closely for the last few years. Over the holiday, though, I had some time to really immerse myself. And I found some outstanding next-generation racing sims:

• rFactor (downloadable, review)
• GTR FIA racing (review)
• Richard Burns Rally (review)
• Colin McRae Rally 2005 (review)
• GT Legends (review)

Unfortunately, I also found that most of the racing games I'm interested in are barely released in the US any more. I suppose it's the NASCAR factor. Or maybe europeans are just more enthusiastic about motorsports as a whole. For example, rally racing-- which I find hugely entertaining-- barely even registers as a sport in the US. Searching for the word "rally" on the EB Games website produces 30 hits on mostly NASCAR titles. Irony of ironies. Racing in a circle is about the farthest thing imaginable from rally racing. The only title in my list that's currently available from EB Games is GTR. You'll have to scour eBay or Froogle, like I did, for the others.

One of the downsides of having a dedicated wheel peripheral is the extra work it takes to lug it out and hook it up before you play. The temptation to play racing games with the keyboard-- even though it sucks for controlling driving games-- is strong. I played through most of Colin McRae Rally 2004 on the keyboard in between coding sessions for this very reason. I was too lazy to drag out the wheel then put it away when I was done! I enjoy racing games too much to let this happen again. What I really need is a dedicated PC racing rig.

Although I was a little put off by the $18,500 price tag on the Virtual GT simulator, it's.. uh.. a starting point:

I'll keep this in mind for the gaming wing of my mansion. In the meantime, some humbler but more realistic choices:

• Hotseat Racer $589 (review)
• Playseats Racing $249-$299 (review)
• Virtual Racing Chassis $389 (review)
• VRX Base $?
• Sparco Racing Cockpit Pro $549-$699 (review)

The Hotseat is my pick of this litter, but after you factor in shipping, it's close to $750. Whereas I can get the Playseat for $249 at Target. Even with shipping and tax, that's less than one Xbox 360!

At some point I'll probably kit it out with the optional LCD bracket advertised on the playseat website, and some rear speaker stands. I can make it as temporary or permanent as I need to. But it's definitely getting some screen time in the giant Vertigo conference room first.

Web Typography Hack: sIFR

Although I'm no fan of MacromediaAdobe Flash, I have to admit the sIFR JavaScript / Flash typography hack is remarkably well thought out and quite effective. Here's a small GIF movie of it in action:

It always bugged me that our only alternative for decent web typeface rendering was the misconceived <font> tag, or even worse, a bunch of hand-constructed image files masquerading as text. This is the best solution I've seen so far. It's in use on a few high-profile sites such as ABC News; check out the headline for this ABC News article on Don Ho, for example.

Heck, it's almost enough to get me to enable Flash again. Almost.

Mike Davidson, the original progenitor of the sIFR technique, recently handed the reins of development for sIFR to Mark Wubben, who is working on sIFR 3.

The CSS Zen Garden and ASP.NET

The CSS Zen Garden site isn't exactly new news these days, but I've been digesting the excellent CSS Zen Garden book over the last few months and we now have an opportunity to pursue a completely CSS-driven site layout on one of our projects.

Although everyone has used stylesheets before for trivial things like colors and font sizes, switching to completely CSS-driven layout is a more daunting proposition. Consider the actual Zen Garden HTML, before and after a stylesheet treatment:

HTML	HTML with CSS Stylesheet

That's one radical makeover.

The book does a fantastic job of breaking down a number of the CSS stylesheets and focusing on particular areas of interest within each one. I highly recommend it. It's fun to click through these to get a visual sense of what's possible, and what still works in IE6. Here are the examples presented in the book, in order by section:

Layout
Backyard, Entomology, White Lily, Pret-a-porter, CS(S) Monk, Not So Minimal

Imagery
Japanese Garden, Revolution!, Deco, No Frontiers!, Coastal Breeze, What Lies Beneath

Typography
Oceans Apart, si6, Release One, Dead or Alive, Blood Lust, Golden Mean

Special Effects
This is Cereal, Gemination, Bonsai Sky, Tulipe, door to my garden, Elastic Lawn

Reconstruction
Hedges, Radio Zen, South of the Border, Corporate Zenworks, Open Window, mnemonic

It's admirable how the Zen Garden puts the holy grail of separating content from presentation squarely in view.

But I'm a little uncertain how this will work in practice under ASP.NET 1.1 and 2.0. Ideally the user controls will emit a bunch of <div> tags and ultra-simple HTML, then we let the CSS file have its way with position, graphics, sizing, and even hiding elements. The one example I can find of someone retrofitting pure CSS layout on an existing ASP.NET 1.1 site is.. rather scary. And there are pages and pages of advice on CSS gotchas, starting with the most important rule: develop in Firefox first, then fix the inevitable CSS compatibility bugs in IE6 second.

Although this approach has a lot to recommend it, I still worry that we're trading one set of problems for another. Has anyone gone the full CSS Zen Garden route with an ASP.NET 1.1 or 2.0 site yet?

Automated Hard Drive Defragmentation

I tend to ignore defragmenting my hard drive until I belatedly realize it probably looks like swiss cheese by now:

Wouldn't it be nice if the operating system took care of defragmentation all by itself in the background when I'm not using the computer? Ah, to dream. Until that happens, there's at least one simple workaround.

Windows XP includes a disk defragmenting utility in Start, Programs, Accessories, System Tools. What's less commonly known, however, is that XP also includes the command line version of this utility, defrag.exe:

C:\>defrag c: -f
Windows Disk Defragmenter
Copyright (c) 2001 Microsoft Corp. and Executive Software International, Inc.

Analysis Report
    279 GB Total,  116 GB (41%) Free,  12% Fragmented (8% file fragmentation)

Defragmentation Report
    279 GB Total,  116 GB (41%) Free,  0% Fragmented (0% file fragmentation)

C:\>

It's easy enough to hook up automated disk drive defragmenting using defrag.exe and XP's task scheduler. Just go to Start, Control Panel, Scheduled Tasks and click "Add Scheduled Task". You'll need to edit the task properties manually to set up the proper command line syntax, as pictured here:

I assume the defrag utility needs to run as an administrator, so set the "Run as" section appropriately.

If you have more than one drive, you can set up multiple scheduled tasks, or use this Windows Script Host file to defragment all the drives in one swell foop:

Option Explicit

Dim sh, fso, d

Set sh = WScript.CreateObject("WScript.Shell")
Set fso = CreateObject("Scripting.FileSystemObject")

For Each d in fso.Drives
    If d.DriveType = 2 Then
        sh.Run "defrag " & d & " -f -v", 1, true
    End If
Next

I'm sure commercial disk defragmenters do a better job, but this one's good enough-- and it's free! However, you may want to complement defrag.exe with SysInternals' PageDefrag utility. Some crucial system files, such as the registry hive, are always locked while the OS is running. But with PageDefrag, you can defragment those files at boot time.

Client vs. Developer Wars

The 69 page e-book Client vs. Developer Wars documents one web design company's struggle to formulate a rational development process:

Up until the middle of 2000, Newfangled's development process was much like that of every other web development company. The process started with the "planning/strategy phase," followed by "design," then "programming/testing," and finally "launch/maintenance." Like most web developers, we thought our process was carefully thought out and logical. However, while the process seemed to make sense, it didn't work. No matter how hard we planned, our projects would slowly degrade and unravel.

The downward path of our projects was not due to lack of effort. At one point we were creating generic screen illustrations prior to development that showed how all the proposed content, features, and functionality of a site would fit together. These documents were usually 20-40 pages long even for relatively simple sites. They took a long time to write and even more time to review with clients. In fact, we were investing so much time in planning that clients often grew impatient, wanting to "see something" instead of just discussing the site and reviewing specifications. Yet we knew that if we rushed the planning stages, we would pay for it later. Unfortunately, even when we thoroughly completed the planning stages, problems would still surface, usually in the final stages of the project.

This, to me, is another indictment of dysfunctional specifications. I learned long ago that clients won't listen to what you say, and they certainly won't read what you write. You're much better off putting that wasted effort into a working model and setting it in front of the client. Let them play with it for a while. Refine the working model based on that feedback, then keep turning the crank on this cycle until you run out of resources.

And that's exactly what Eric Holter proposes in this e-book:

Our first prototype was a desperate attempt to document our projects more effectively. We had already been writing information architectures in order to provide our clients with site details. Using an HTML model of the site instead of a printed document was simply an effort to more effectively communicate the details of a site. As we started to use this HTML prototyping method, we discovered that it was doing so much more than documenting. It was enhancing our ability to communicate with our clients.

When they had questions about how something was supposed to work we reviewed the prototype and discussed the issue in its context. It was during these interactions around the prototype that we began to realize that our clients were able to give me much more detailed feedback about how they wanted a site to work. If they had an expectation about how a particular feature would function, it would generally be discovered at this early stage. We could then deal with the expectation appropriately. If there were technical limitations or cost issues discovered, we could work them out and provide viable alternatives before they became crises and before they had already been developed differently.

We found that building a comprehensive, simple HTML model of the site helped to solve many of my problems. The prototype also performed the function of a technical specification (we began to add programmer notes to the pages) that accurately described the structure, content, and features of our sites.

Yet because we translated the specification into a familiar HTML model, it was something our clients could grasp. Additionally, clients spent more time looking at prototypes. They considered them more carefully than paper documents, because they understood what they were looking at. We were able to get the kind of detailed feedback that we used to get only after a site was almost complete. This solved many of the problems that stemmed from our clients' exaggerated expectations. By using the prototype to define and specify sites, we were able to communicate and educate our clients in an effective proactive manner. This improved the overall flow of information, which resulted in positive relational dynamics with our clients.

Yes, some of the advice will be old news to agilists, but give the guy a break: this was written five years ago. They call it grayscreen prototyping. I think it's a reference to the old default gray background color of Netscape 4.7x. So the implication is that we're talking about low-fidelity HTML layouts -- so basic that they don't even specify a background color.

There's nothing magical about the solution proposed here, but it's solid advice written well. Recommended. And if you're not into the whole reading thing, you can even download a 16 minute video presentation that covers the whole shebang.

The Story of SkiFree

Laurent Bourgeois sent in an amusing link to the story of SkiFree in the words of Chris Pirih, the original Microsoft programmer who wrote it:

I wrote SkiFree in C on my home computer, entirely for my own education and entertainment. One day while I was playing with it at work, the program manager for Windows Entertainment Pack happened to look over my shoulder and immediately decided he had to have this game. I called it WinSki, but the Microsoft marketroids hated that and decided, for inscrutible marketroidal reasons, to call it SkiFree. After some token resistance I let them have their way. Since the program was not originally a Microsoft product, Microsoft licensed it from me and paid me some trivial one-time fee (something like 100 shares of MSFT stock, no royalties) for its use.

SkiFree was intended to run on a 386 PC with VGA display. Such computers were not very powerful, nothing like modern PCs that can do 3-D rendering at millions of textured polygons per second.... No, in those days there wasn't even any such thing as a "video accelerator" -- the VGA was just a dumb pixel buffer hanging off the excruciatingly slow ISA bus. This made it pretty challenging to get good performance out of even simple sprite-oriented animation! Windows didn't help matters any by introducing several layers of abstraction between the program and the video hardware.... I discovered that it was worth almost any amount of preprocessing (on the "fast" 386 CPU) to reduce the amount of video I/O (over the slow ISA), so I designed a fairly clever algorithm to combine overlapping objects/erasures and blt minimal regions in each frame. The result was perfectly flicker-free transparent sprite animation at reasonable speed even on very slow computers, such as an old 286/EGA machine I found in the testing lab. Nowadays one would probably just render the sprites back-to-front in a memory buffer and blt the entire window on each frame.

Chris kindly provides an updated 32-bit version of SkiFree on his page as well.

I definitely remember SkiFree from the Windows Entertainment Pack. What's particularly scary is that many of these games have their own highly detailed Wikipedia pages already-- including a page on SkiFree. The infinite monkeys have been busy!

Evidently SkiFree evolved from an earlier text-mode skiing game Chris wrote for a VAX:

And it was influenced by Activision's Atari 2600 Skiing cartridge:

Which brings us to the venerable SkiFree-- Windows 3.0 gaming at its finest.

Variable Bit Rate: Getting the best Bang for your Byte

I'll probably never buy music from iTunes, or any other online music store, because they all use constant bit rate audio encoding formats. Once I heard the incredible difference in fidelity between variable bit rate (VBR) and constant bit rate (CBR) encoding, I can never go back. And if I'm spending my own money to "own" this music, why pay for the crappy encoded version anyway? I'd rather buy the CD with the raw, uncompressed versions of the music and rip it myself.

Having perfect audio fidelity, however, is not my goal. If I wanted that, I'd go for a lossless audio compression format. They achieve 50 percent compression ratios, but that's still pushing 20 megabytes for the average song. Interesting for archival purposes, but way too big for every other possible use.

What I really want is the best bang for the byte: the smallest file size I can achieve while retaining cd quality. Of course, "cd quality" is in the ear of the beholder. Here's how I judge it: A/B listening tests between the raw WAV file and the encoded file on nice headphones. And to my ear, the best bang for the byte is variable bit rate MP3 files with an average bitrate of at least 160 kbps. Constant bit rate MP3s at 160 kbps do such a poor job of capturing the dynamic range of the music that it isn't even a contender. Sure, I could just encode everything at extremely high constant bit rates like 256 kbps or 320 kbps, but I can't hear the difference to justify the extra filesize. Remember, it's all about bang for the byte!

WinAmp displays the bitrate of a song in real time, which gives you a way to roughly correlate the encoder's decisions to the music. For areas of silence, it'll dip down to 32 kbps, and for areas of high energy, it'll peak up to 320 kbps:

There are some downsides to variable bit rate encoding, however. The encoder has to make complicated decisions about bitrate instead of mindlessly encoding everything at the same bitrate. That means the encoding uses complex algorithms that take quite a bit longer-- at least two times longer than constant bit rate encoding, possibly more. And you want a really smart, high quality encoder, too. Choice of encoder has always been a critical factor in how your music sounds. If you've got a lot of "unknown" MP3s, you may want to check them out with the EncSpot tool. It will tell you what encoder was used and estimate the resulting quality of the file:

MP3 isn't the only audio encoding format in the world. But it is the most ubiquitous. The good news is that variable bit rate MP3 fares surprisingly well against the hottest new audio encoding formats. A recent multiformat 128 kbps listening test puts VBR MP3 on par with the newer AAC format, and squarely ahead of both ATRAC3 and WMA. Only the newest MPC and Vorbis formats statistically outperformed VBR MP3 in listening tests. Interestingly, both of these formats are natively variable bit rate.

I use the free Audiograbber GUI to rip CDs. It uses the well-respected LAME encoding engine under the hood. You can also use LAME at the command line. Here's LAME encoding a standard 128 kbps CBR MP3 file. It took 15 seconds:

Here's LAME encoding a VBR MP3 at quality level five. It encoded a ~153 kbps average bitrate file in 20 seconds. Most of the frames are encoded at 160 kbps.

Here's LAME encoding a VBR MP3 at quality level three. It encoded a ~218 kbps average bitrate file in 26 seconds. Most of the encoded frames are 224 kbps.

One thing to keep in mind about variable bit rate encoding is that it's, well.. variable. If you need predictable filesizes for every song you encode, VBR is definitely not for you. I happened to pick the outlying song on this particular CD; the average bitrates range from 129 kbps to 216 kbps:

The goal is to achieve at least 160 kbps average. Some songs will need more, some might need less. There's something magical about that extra 32 kbps; the difference between a CBR MP3 at 128 kbps and 160 kbps has always been unusually large to my ear.