In late 2012, I started using an Echo AudioFire 12 to route analog audio into my 2010 Apple MacBook Pro. On paper, the AudioFire 12 was exactly what I wanted: 12 analog inputs and 12 analog outputs converted to digital and sent across FireWire. I’m using outboard preamps, so I’m not particularly needing the A/D interface to offer built-in preamps. The AudioFire 12 didn’t offer anything fancy; it was an A/D interface with FireWire output.

Initially, all seemed well. Very occasionally when recording I got a spurious digital pop noise on a track. I thought I was probably overdriving something somewhere, and investigated possible causes as a background task.

After a few months, the popping noises increased. About a year after acquiring the AudioFire 12, I was using it for a series of recording sessions, some of which turned out flawless, while others were littered with pops, in some places so bountiful that it came across as a crackling noise.

I learned that these noises are called gaps: essentially, a brief lapse in successful transmission of audio data. In the recorded wave file, when you zoom in far enough, you can see that a normal audio wave is a generally smooth, continuous line. A gap introduces a sudden discontinuity; the wave line jumps from one point to another. Once you locate a gap in the wave file, you can manually fix it by repairing the wave line, making it smooth and continuous again. You can also use a number of software tools to repair gaps automatically.

So I was able to salvage my recording session data, but it was obvious that sloshing around with frequent gaps in recorded audio wasn’t an appealing path forward. Research on the web suggested a number of things to try different in configuring my system, but when all of those failed, I resolved that the problem almost certainly was an incompatibility between the FireWire chipset in the AudioFire 12 and the FireWire chipset in my computer. Had it been a full desktop computer instead of a laptop, I could have installed a secondary FireWire interface card that would hopefully be compatible, but that wasn’t an option for me.

MOTU 828

I decided to sell the AudioFire 12 and replace it with another interface. I had had good success in the past with an audio interface from MOTU (Mark of the Unicorn, based in lovely Cambridge, Massachusetts), and, not needing anything fancy, I bought an original MOTU 828 unit, reportedly the very first FireWire-based audio interface, with eight channels of analog inputs, only two of which sported built-in preamps.

The MOTU 828 was something on the order of 12 years old, but it worked perfectly. Its minimal ability for routing and monitoring audio felt a little archaic, and it lacked the convenient MIDI I/O tacked on to nearly every modern FireWire audio interface, but I was able to make do. It chugged away in service of my home recording studio for an astonishing four months before its internal FireWire chipset flaked out, connectivity between it and the computer failed, and it started emitting a high-pitched squeal which gave me a moderate headache as I tried to make it stop.

I read online that MOTU tech support could, as of 2011 anyway, replace the FireWire ship and refurbish an 828 unit for $75, plus shipping charges. I called MOTU the next morning only to learn that they no longer service the ancient original 828.

So I needed to buy another new interface. I ended up selecting a new interface from Focusrite.

Focusrite Saffire Pro 40

The Echo AudioFire 12 is fairly unusual; audio recording professionals favor using outboard preamps, and buy $2000 interface units that have no built-in preamps. For my needs, I wasn’t looking to spend $2000 on an interface, but, apart from the Echo equipment, I’m not aware of another <$1000 interface that isn’t cluttered with its own preamps.

Built-in preamps are not necessarily bad, but they almost certainly will not be as good as standalone preamps. I have a Focusrite ISA two-channel preamp that sells for $900. The Focusrite Saffire Pro 40 audio interface has eight built-in preamps, one on each input channel, and sells for $500. It doesn’t seem credible that these <$60 preamps would be designed and built as well as a $450 preamp from the same manufacturer. This does, though, get usable preamps into the hands of people who might not have bought them otherwise.

I’ve used the Focusrite Saffire Pro for all of about ten minutes and so far it sounds great. Or I suppose I should say, it doesn’t sound like anything in particular; it functions as an audio interace, converting between analog and digital signals. I have some extra built-in preamps should I need them, and the overall design is (not surprisingly) more modern than the old MOTU 828. It lacks clock input, but I don’t need to synchronize it with anything else at the moment. In addition to the eight analog inputs, it also has digital inputs through ADAT, so I could plug up a really nice A/D converter and use the Saffire just to feed the digital data to the computer over FireWire. The front-panel buttons feel cheaply made out of plastic. (The knobs and power switch feel fine.) I imagine that Focusrite could increase the price by $50 and use the same quality of buttons they use on the ISA preamps.

Basically, it’s a lot like many other similarly-priced interface units. I don’t find these extremely interesting in themselves, but rather, just a needful component in recording audio. They do though become very interesting when they don’t work correctly in one way or another. Hopefully this brand new Focusrite Saffire will function well for years to come.

Software developers who have been out of school for a while and apply for new jobs routinely bemoan that they have forgotten details of things like algorithms and data structures and other computer science topics that tend to pop up for discussion in interviews. Even software developers working in their current job can stand to be reminded of things they’ve been taught in the past but haven’t thought about for years.

Pilots undergo intense training before getting certified to fly in the first place, but then also must undergo recurrent training on a regular basis.

Instead of checking off having learned algorithm design in college and never thinking about it again, would it be useful for software developers to engage in regular recurrent training to refresh themselves on things they might be letting slip from their thinking?

Taking a full semester-long class might be overkill, and too much to expect out of the schedule of working professionals with families and responsibilities outside of their jobs. Maybe a twice a year spend a day or two being refreshed on things that should have already been studied in detail in the past.

A format of alternating between 15-minute lectures, 15-minute in-class exercises (done by individuals on their own laptops), and 15-minute review of solutions might be a good way to go.

How could such training be set up? Large companies could do it all in house, paying a small staff to be dedicated to administering such classes. Local community colleges could potentially offers this format of class to small companies and individuals in the area, as part of their alleged charter to foster continuing education.

In theory, it could also all be done online, with prerecorded lectures by especially great speakers, but spending the time to meet in person can sometimes be more motivating than watching videos.

In Selected Papers on Fun & Games, Don Knuth writes about his experiences playing an early computer game in the 1970s:

Clearly the game was potentially addictive, so I forced myself to stop playing — reasoning that it was great fun, sure, but that traditional computer science research is great fun too, possibly even more so.

Is this something we should keep in mind today, surrounded by countless opportunities to do something frivolous instead of something substantial?

I received an email from B&H Photo yesterday, advertising some new products and sales. After years of doing my minimal photo post-processing in Apple iPhoto, the reduced price on Adobe Lightroom 5 caught my attention. Reading the details more carefully, I was intrigued by the statement:

You can add … simulated film grain to images, great for breathing analog life into digital photos.

In the music production world, I’ve heard a lot of people talking about the virtues of running tracks through analog equipment to maintain or capture “analog warmth” in the face of sterile digital perfection. There are debates as to how needful an analog signal chain actually is, and some producers seem fine with totally digital production, but there are enough adherents to analog audio gear to suggest that there’s some legitimate basis to the claim. Several manufacturers sell analog summing mixers, to do a task in the analog realm that digital computers ought to be excellent at doing (adding things together).

While I’ve heard some photographers share a preference for working with film, I believe this is the first time I’ve seen a major vendor suggest that there might actually be something superior about film photography that digital photographers should consider simulating. So what exactly does this simulated film grain feature do?

I found an example from Mark at Digital Photo Buzz, showing the difference between an unaltered digital photo, the same photo processed in Adobe Photoshop to add “noise”, and the same photo processed in Adobe Lightroom (version 3) to add “film grain”. The processed photos appear at first glance to be blatantly inferior to the original, but then again, after looking at the processed photos for a bit, the original seems almost artificially perfect.

I’ve never done an explicit A/B test between my digital and film cameras, but I happen to have several similar shots taken on two separate trips to Cambridge, Massachusetts, one time with film and the other with digital:

Falafel Truck on Kodak 400 film

Falafel Truck on Canon 5D digital

Harvard University Library on Kodak 400 film

Harvard University Library on Canon 5D digital

(All photos taken with a Canon 50mm/1.4 lens. The film photos were taken with standard off-the-shelf Kodak 400 print film.)

The film photos, as presented, are higher contrast. This could be adjusted in post-processing if desired. I don’t really see anything significant that I would attribute to “film grain” in the film photos; the grain certainly isn’t as obvious as in the simulated grain photo produced in Adobe Lightroom. The digital photos, when viewed full-size, are more detailed, and generally seem like closer representations of what the scene actually looked like (as I recall).

But is one flat-out better than the other? Aesthetically, I kind of like the look of the film photos better. The digital photos may be more perfect, but the film photos seem to have some imperfections that come across well, maybe similar to the color added to sound running through a tube preamp. It’s hard to beat the convenience of digital over film, but perhaps I’ll start pulling my ancient Canon EOS-3 out more often…

Two days ago we received delivery of a new mattress. Upon initially lying down to go to sleep on it, I detected a strange odor and reasoned that it must be emanating from either the new sheets, the new mattress cover, or the new mattress, but was too tired to think much about it. The odor became increasingly bothersome throughout the night, and in the morning I determined that it was most likely coming from the mattress itself.

Some web searching suggested that this was not unusual, and that common wisdom was to let the mattress air out for a day or two (or four) before sleeping on it. This was the second mattress we had purchased from the same shop, and nobody had mentioned anything about this to us. The first mattress, though, was left unused for several weeks before we moved into the house, so it likely had time to air out on its own.

My web searching also turned up some unexpected information on the potential toxicity of mattresses.

In 1972, the United States federal government decided to help prevent burning cigarettes set mattresses ablaze by issuing 16 CFR Part 1632, Requirements for Mattresses and Mattress Pads. Accompanied by a prescribed test procedure, this government mandate required mattress manufacturers to construct their mattresses to be able to endure limited exposure to burning cigarettes without catching on fire themselves. Since traditional mattress materials were not inherently flame-retardant, manufacturers complied by adding flame-retardant chemicals.

In 2006, the government decided that guarding against burning cigarettes was insufficient, and expanded their mattress construction criteria to include guarding against various open flames in 16 CFR Part 1633, Standard for the Flammability (Open Flame) of Mattress Sets. The new test criteria involves exposing the mattress to open flame generated by a burner device for a total of 30 minutes. (Details are listed within 16 CFR Part 1633 itself.) Manufacturers complied to this demand of enduring a half-hour of fire by adding yet more flame-retardant chemicals.

So our mattresses are very unlikely to engulf us in flames. But what about the chemicals being added to the mattresses? Are these safe for us to sleep on night after night? Since the government cares so much about us not setting our beds on fire, surely they would have interest in what chemicals are employed to fire-proof the mattresses?

They did conduct some thorough research on the extent to which the various chemicals used in mattress construction could be absorbed by its users, but when it comes to actually making a decision on what chemicals go into the bed, they leave that up to the mattress manufacturers. The 16 CFR Part 1633 Questions & Answers document explains: