MaximumPC Puts 256kbps AAC to the Test

Now that Apple has begun to release tracks in DRM-free 256kbps AAC through the iTunes Store, the listening tests are on. MaximumPC gathered 10 people, and had those people select 10 familar tracks, which they then encoded at both 128kbps AAC (which is the current iTunes Store offering), and at 256kbps, which is the new DRM-free bitrate. They then asked their ten subjects (in a double-blind experiment) whether they could tell the difference between the two tracks after repeated listens.

But they also threw a twist into the mix, asking subjects to listen first with a pair of the default Apple earbuds, then with a pair of $400 Shure SE420 phones. Their theory – that more people would be able to tell the difference between the bitrates with the higher-quality earphones – didn’t quite pan out.

The biggest surprise of the test actually disproved our hypothesis: Eight of the 10 participants expressed a preference for the higher-bit rate songs while listening with the Apple buds, compared to only six who picked the higher-quality track while listening to the Shure’s. Several of the test subjects went so far as to tell they felt more confident expressing a preference while listening to the Apple buds. We theorize that the Apple buds were less capable of reproducing high frequencies and that this weakness amplified the listeners’ perception of aliasing in the compressed audio signal. But that’s just a theory.

Also interesting is that the older subjects (whose hearing is supposedly less acute) did a better job of telling the tracks apart consistently than did the younger participants. Could it be that the younger generation has grown up on compressed music and doesn’t know what to listen for? Or it could be an anomalous result (the sample size was so small).

Readers who feel, as MaximumPC did going into the test, that 256kbps is still too low for anything approaching real fidelity, will likely cringe at the results. I’m not cringing exactly, but do wonder why they didn’t bother to give the subjects uncompressed reference tracks to compare against.

Notes: Remember that 128kbps AAC is roughly equivalent to 160kbps MP3, since the AAC codec is more efficient. There’s apparently some suspicion that the iTunes store uses a different encoder than the one provided stock with iTunes. Testing for both bitrate and headphone differences throws variables into the mix that shouldn’t oughta be there – would have been better to give everyone the good phones and focus on the bitrates, without confusing the matter. 10 people is a pretty small sample group – not small enough to be meaningless, but not large enough for substantial findings. Not that we need MaximumPC or focus groups to tell us how to feel about codecs and bitrates…

Music: Les Chauds Lapins :: Ces Petites Choses

Bike Commute, Pushing Codecs

Had a few ideas about ways to present multiple views of GPS data in a multimedia project, part of which involved videotaping my bicycle commute along the Ohlone Greenway from handlebar-eye-view, then speeding up the 27 minutes of footage to a more watchable five minutes. Mounted a camera with a very sturdy professional cam clamp left over from a long-ago project and set off. Hit a bunch of snags, and am not sure whether they might be show stoppers for the whole project. What I had hoped would capture a lovely ride turned into a struggle with the outer limits of the most advanced codec technology, and ended up looking like total dooky.

Problem #1: Because camera is rigidly attached, it picks up every little bump in the road. This mounting method is inherently shaky.

Problem #2: Because camera is on handlebars rather than on my head, the camera view doesn’t track my line of sight, which is very disconcerting for the viewer (or maybe just for me, since it doesn’t match my experience at all).

Problem #3: Video doesn’t account for a human’s peripheral vision, which accounts for so much of the experience not shown here. Again, disconcerting (makes it seem much more dangerous than it actually feels).

Problem #4: The natural side-to-side pumping action of bicycling adds to a seasick, high-motion effect not actually experienced by the rider.

Problem #5: Once the footage was speeded up, pauses at stop signs pass by in a blink, making it look like I ride with total disregard for both death and the law. Not so! Though I do do some rolling stops, I’m actually very careful at intersections, especially because the Ohlone Greenway cuts across streets a ways away from the “real” intersections, so most drivers aren’t in the headspace to be expecting cross-traffic (despite zebra stripes and big yellow warning signs). I wear an orange safety vest and treat those intersections with kid gloves.

Problem #6: Video codecs rely on data similarities between frames, and none of them perform well under high-motion conditions. What could have more motion than shaky footage played back at 5x? Thought I could convey a beautiful morning experience, but this looks completely pixelated and smeared-out, even though I used the usually gorgeous h.264 codec. Of course, YouTube also apply their own compression, but my local version doesn’t look much better than this one. The only version that came out looking passable was the version with no compression at all — and it’s 750 MBs.

The footage is also a bit over-exposed, but that’s operator error rather than endemic. Hope to have access before long to a helmet-mountable lipstick camera, which should help a lot with problems 1, 2, 3, and 4, but will do little for problems 5 and 6. Back to the drawing board.

Music is “High Water” by Bruce Lash – Bruce gave me permission to use his stuff in projects back when I was at Adamation, and he now offers a bunch of downloadable music free for personal use.