Archive for February, 2008

omg set -o vi!!!

February 27th, 2008

I just found out bash has a vi input mode. I think my life has changed permanently. No more annoying Alt+b.

set -o vi

Now hit Esc and you're in command mode, standard vi. I haven't played with it long enough to figure out what the restrictions are yet, given how you're only editing one line. But copy/paste doesn't seem to work.

video playback on the iAudio F2

February 26th, 2008

I have one of those mp3 players that make an iPod look like a Boeing 747. It's actually the smallest media device I've ever owned. It's fabulous, 20h of music playback and tiny and light as it is (40 grams) I barely even feel it in my pocket. And yet the displays on those things keep getting bigger. My old iRiver iFP-899 has a tiny screen that can display 3 rows of text in monochrome. I've had the Cowon iAudio F2 for a couple of years, and half the surface area is dedicated to the screen. The other half is filled with buttons, which are still rather small. But as it happens the thing actually has a color display that's able to display, well... your holiday pictures in miniature. I got the thing to play music, so I really didn't put much stock in what the display is like. But I have to say a color screen is a step forward, these devices are becoming ever more sophisticated.

So much so that the latest gimmick is movie playback. I know what you're thinking. One of those larger hand held thingys where the whole area is just a display, must be ridiculous to watch video on that tiny thing. But no. My teensy player actually has video playback too if you can believe it. I thought the whole thing was just silly so I never even tried it. But curiosity gets to you eventually, so I thought I'd check it out.

It is pretty amazing that you can get video playback on that tiny thing at all, so obviously scaling the image is a little bit more than you can expect from the playback capability. That means you have to transcode every video you want to put on it. I found handy instructions for this without looking very long. It turns out the video decoder on the player is a little temperamental, so you have to post process the transcoded files, but it's still very easy to do. I threw together a quick script that does it in one step. We're using mencoder to transcode, so whatever it is mplayer is capable of playing (which is *everything*) you can now put it on your player. (Just make sure you have mplayer with mp3lame and xvid encoding capabilities.)

#!/bin/bash

home_path=`dirname "$0"`

input="$1"
temp="tmp.avi"
output=`basename "$input"`
output="iaudio_$output"

[ -f "$temp" ] && rm "$temp"

mencoder -ofps 12 -vf scale=160:128 -ovc xvid -xvidencopts bitrate=384:max_bframes=0:max_key_interval=1 -oac mp3lame -lameopts cbr:br=128 -of avi -o "$temp" "$input" &&
$home_path/i7remux-0.1/i7remux -i "$temp" -o "$output" &&
rm "$temp"

Run this from the location where you desire the output file to be created, and supply the video file you want to transcode as argument. This will create an avi file encoded with xvid and mp3, in 160x128 pixel dimensions. You will also need the i7remux program to perform the mentioned post processing on the video file, so just download the full package:

Execute the classic ./configure && make inside the i7remux-0.1 directory and you're all set.

The resulting video file will be playable on the iAudio F2 as well as the iAudio 7 (and possibly other models if they use the same video format, haven't checked). And now for the big moment. *drumroll* Who says you need a gigantic plastic disc to watch a movie?

Yep, that's Gladiator, all 2 hours and 28 minutes of it. The file size is 543mb, which means I can fit in about 10 of those babies in the 4gb of memory. Notice the ungodly waste of precious pixels because the movie doesn't fit the aspect ratio of the screen.

So how does it play? Surprisingly well, actually. It tends to stutter a bit in the beginning, but if you let it run for a bit or fast forward it goes away. From there on it behaves like a normal video player. You now have a fully equipped cinema for ants.

I haven't checked the battery life for movie playback, but I imagine it's probably quite disastrous.

Ps. If you're wondering how to get the DVD movie into a file to begin with, you may find undvd useful.

't Amsterdamse Concertgebouw

February 21st, 2008

The swanky atmosphere Sunday morning was slightly impaled by a grammar blooper in the program. But never mind. Wikitravel proclaims:

Concertgebouw

Famous for its orchestra and its accoustics (among the top ten in the world), this is the world's most frequently visited concert hall.

I have to say I'm starting to suspect it's the staff authoring this glowing review. Personally I wasn't all that impressed with the acoustics. The large performance hall is a venerable interior with profuse decor, however the technological realization seems to have evaded modern technology. The chamber orchestra was not heard terribly well in the rear half of the hall, which seems a bit amateurish from a sound technology perspective in this day and age.

But for just 15 bucks it wasn't bad value for money, even though I expected more from the venue.

The Ambler Warning

February 12th, 2008

Every detective story or for that matter, spy novel, has the same overreaching goal: to give you an interesting puzzle to solve. A story is being told - you have to pay attention, and while you're taking notes you're also continuously assembling a repository of information and scouring it for relationships and patterns. And once you link two facts together, you've understood a part of the puzzle. A couple of factors determine why this is fun. First of all, the content of the puzzle should be fun, that is if you're putting together a puzzle of the Eiffel Tower, you will have fun if you like the Eiffel Tower. Then there are different ways of creating a puzzle, deciding what the pieces will be, how clear or faint the connections are going to be and so on. And finally there are different ways of giving you the pieces, at a certain pace, in a certain order. In as much as there are dependencies between the pieces, such that one will not help you without having a certain other piece, you can craft a complicated scheme. All these factors vary from story to story, some puzzles are fun, some are not.

This process of solving a puzzle is actually very intuitive. It's the same process by which we learn things. The difference is that when learning we're trying to understand an incidental truth, which isn't governed by any person's capricious decisions to make it so. And it could well be beyond your ability to solve. It may also be that no one has solved that puzzle. A man made plot, on the other hand, is a puzzle created specifically for our enjoyment, where the creator makes all the decisions, limits the scope appropriately, and deliberately sets the difficulty at a certain level.

A spy novel is always about deception upon deception, and as a reader you participate. Not only is the character in the story being deceived, you are as well. The author will be meticulous about telling you facts that point to a certain conclusion, but it's actually a decoy. Equally, he will mention facts that don't have any apparent use at the moment, but they will explain something further along, and if you're careful, keep you from walking right into a trap. It's really just a mind game.

The Ambler Warning was actually published in 2005, based on an unfinished manuscript Ludlum was working on when he passed away in 2001. In other stories of his that I've read he generally likes to run a chronological race, with very economical use of facts. This requires efficient reading, because rarely is anything said twice. The socio-political setting of the story also lets certain bits of information permeate from the surroundings. And when it comes to giving up information, Ludlum keeps you from seeing very far into the horizon. Most of the time he lets you guess and suspect things that won't be revealed for a long time yet. This puts you into a mode of forensics, trying to make what you know go as far as possible. It culminates in the economical resolution of some question, solving it with the least amount of facts possible. At other times he likes to keep you starved of new facts for a while, causing you to go back over what you already know and dig for new deductions in vain, before he finally drops something significant that has a big impact, but which changes so many existing variables that you get overwhelmed by the amount of information you have to process.

In The Ambler Warning we get a different kind of story telling. For one thing, only pieces of the timeline are accounted for, the rest isn't told. But it's enough to make sense of, again playing on the economical use of information. Secondly, the pieces are not told in chronological order. There is a leap from chapter one into what chronologically is the third chapter, but told in a different order.

This changes a lot of the assumptions of a continuous story, the fact book keeping takes on a different model. Since it's not chronological, you can't keep the chapters completely self sufficient, you have to make some modest references to chapter three in order to maintain a smooth reading experience. And as shown in the figure, this builds certain expectations about chapter three. But it does mean that you have to stack up certain facts from chapter two whose meaning you don't yet know, and won't, until you reach chapter three. This is a different mode of puzzle solving than I've seen in other Ludlum books, but it's pretty interesting.

The plot and the characters are actually a bit below par. I wonder if this is the influence of the editor who shaped an unfinished manuscript into a novel. And the conspiracy holds up nicely until the resolution. In fairness, this is very common. Authors build expectation with a meticulous use of detail, but then fail to make the conspiracy live up to those expectations. It's a difficult thing to do, and what they pull off is impressive enough.

data representation makes the difference

February 11th, 2008

You probably remember ethereal, right? Yeah, the gtk packet sniffer that has been around forever, but people like me who are pretty lame about networks tried it and didn't know what to do with it. In principle it's all very simple: you capture traffic and then you look at the data. Erm... kay. Well, in practice I had a tough time getting something out of that. Even a simple http request when split into an array of tcp packets doesn't really enlighten me that much when I have a little chunk of it here and the next there and so on. There are so many of them that I'm looking for the needle in the haystack.

This is a lesson in user interface design. ethereal is now called wireshark, and it's the same exact gui window that it always has been (with some minor incremental improvements). Here's the difference though. They figured out that data visualization goes so much further when you actually give a thought to representation.

The before picture, googled for an old screenshot of ethereal:

The window is split into three panes. The top one is the one you'll look at first, this is the list of packets we captured. Notice how small the scrollbar is and just imagine we have a large chunk of traffic in front of our eyes. Scroll up, scroll down, sort by protocol, whatever. In the other two panes you have info on the packet that is selected right now. In the middle one you have nicely structured info, in the bottom you have the raw data. This is the way to look at packet content. Btw tcp packets can be up to 1.5kb in size, so it's not exactly a sizable amount of content.

Gear up for the after picture:

Yeap, colors. Really, that's all I had to say. People underestimate what a difference it makes to have the same exact output in contextual coloring. The same data just jumps up at you if you know it's gonna be in red and you don't have to parse the whole chunk of text to get to it. Notice how the old version and this one have the protocol column just the same, but how much easier is it now to spot different types of traffic? It makes a world of difference.

wireshark has another brilliant addition that I don't remember from years ago. You right click on a packet, like the tcp packet selected in the screenshot above that belongs to an http stream, and go Follow TCP Stream. What you now get is a new window with aaaaall the packets that belong to this conversation assembled and you can observe the whole thing in one place. Fabulous. You can also filter the data (on message level, not packet level mind you) on host if you like. It's fantastic.

If you thought *that* was bling, this will really blow you away. wireshark does not only assemble http conversations, it assembles a lot more protocols. For instance, I saw a talk the other day where the guy was demonstrating how he sniffed a voip conversation and then reassembled the whole thing to a simple audio file with a few clicks!

These two features, packets colored by protocol and packet assembly, alone make wireshark about 200% more useful than it used to be. And think about what has changed here. It's still the same data. The only difference is how you represent it.