SpazBlog

A progress report on v1.2. It is pretty close to being done, I think, and could use some more testing before I let it go.

Here's an updated version of the changelog so far:

v1.2:

- Aspect ratio is now displayed as a fraction. IE, 4:3 instead of 1.333(...). It checks fractions with denominators up to 100.
- Added support for command line options/switches.
- Updated usage info.
- Added support for SMP (HyperThreading, dual core, dual processor) for the actual encoding via -smp switch.
- iPodDrop now targets the iPod screen rather than TV by default. Still maintains correct aspect ratio.
- Added new switch, -tv, that uses OLD default behaviour and tries to max out res.
- Added better handling of content with aspect ratios less than 4:3 (such as 1:1). iPodDrop now stretches them to 4:3 under the assumption that they are probably SVCD or some other such format.
- Added new switch, -allowtall, that allows aspect ratios less than 4:3 to remain unchanged.
- Bugfix to better handle relative paths in Windows
- Added logging. iPodDrop now logs how long it took to encode each file to encodes.txt in the log directory.

As you can see, there is some new stuff since the last post. v1.2 has turned into a rather large update compared to v1.1, and I'm pretty happy with it.

To respond to Avery's post (I'm not ignoring his changes in v1.2, just trying to avoid feature creep):

Right-click menus are definately a good idea. I'll try to slot them in for v1.3 or something. Probably I'll set them up the first time the program is run, and when I get an installer I can have it done there. The problem with this approach, of course, is that I have to specify filetypes to show the menu for. Since my app is an interface for ffmpeg, I don't really know what formats it supports. Certainly I can add all the common ones.

I've been thinking about a GUI for a while now. Originally I was trying to get this thing in a workable state as fast as possible, and for that, console was the way to go. However, the program DOES keep getting more and more sophisticated. I'd like to think that I've been influenced by NITI's autonomic background when I decided to make this program try to figure out the best default behaviors for everything. Most applications don't do anything without setting up many command-line switches, and the default behavior isn't very useful. iPodDrop tries to do as much as possible with no user input (beyond providing the filename), and if a user doesn't like the default behavior, THEN the switches allow them to tweak that.

But I'm getting off on a tangent again. GUIs. I don't really want to go the full GUI route quite yet. iPodDrop is actually my second media encoding app. The one I wrote about shortly after the iPod came out fizzled. I went too complex too fast without any planning (not that iPodDrop has much planning beyond features-planned-for-next-release) leading to a huge amount of work before the app could really do anything at all. (iPodDrop actually got a huge shortcut in the beginning by borrowing a bunch of functions from my old app, allowing a faster start). GUIs are a lot more work than a console app, so I have been avoiding writing a GUI.

There are two plans I've been formulating. The first involves what is printed to the console itself. I intend to simplify the console output by capturing all the FFMPEG output, and parsing it to produce a (text-based) progress bar and ETA. The program would still not be a GUI app, but would be much more friendly.

The second is sort of a launcher. A small GUI shell that calls iPodDrop. Perhaps it is kind of silly to write a front-end for a front-end, but the idea is to provide a standard Windows file browser dialog, possibly allowing dragging into the window too, and a few checkboxes/radio buttons that just set the command-line switches.

Even writing the frontend for iPodDrop, you'd still see the iPodDrop console after you hit "go", but the progress bar would be in the console window already. This is somewhat of a hybrid solution, but might be good enough.

An eventual possibility would be to take the whole shebang and convert it into a full GUI app. See, the beauty of going with the GUI shell first is that you can make iPodDrop a GUI app by shoving its code into the shell itself and doing something else where you normally do "Console.WriteLine()". Provide some sort of feedback where the console output used to be (Labels? Message boxes? Depends on context), turn the progress bar into a GUI element, and boom.

Right now it looks like what is likely to go into 1.3 is explorer context menus, and the hide-ffmpeg-and-show-progress-bar bit. The installer is still a possibility, and the GUI shell might make it in. Depends how long it takes to do the progress bar bit. My old GUI encoder had the progress bar and ETAs working with ffmpeg, but it was a bitch to do and was prone to crashing. Luckily iPodDrop waits for ffmpeg to finish while in a tight loop (Albeit with a sleep command so that it only loops a few times a second), which would make the progress bar a LOT easier.

You know what? I am afraid that one day if iPodDrop is in more general circulation, I'll be bombarded with questions better directed to the ffmpeg team. Hiding away ffmpeg's output to reduce complexity will only exacerbate that.

Damn it. Another long post when all I intended to do was post the changelog.

Most of you probably know how the XBOX never really took off in Japan. Well, I just saw some sales figures for the week before christmas, and it is quite striking.

The PS2? 97,475 units sold.
The Xbox? 141 units sold.

But, you might say, surely this is because the XBOX 360 is now out? Well sure, to a point. How many units did the 360 sell? 5,674.

Microsoft has failed again in Japan despite all their efforts to avoid the fate this time around. For the interested, here is the full list:

1) 597,628 - Nintendo DS
2) 161,332 - Sony PlayStation Portable
3) 97,475 - Sony PlayStation Two
4) 36,646 - Nintendo GameCube
5) 35,764 - Nintendo GameBoy Advance SP
6) 19,261 - Nintendo GameBoy Micro
7) 5,674 - Microsoft Xbox 360
8) 906 - Nintendo GameBoy Advance
9) 141 - Microsoft Xbox

EDIT: This post is WAY longer than I intended it to be. I'm tempted to just say "That was why scroll wheels were invented" when it comes to the amount of space this is going to take up on planit, but then that would be rude :P If anybody knows how I can do a "sanity barrier" type thing with Blogger where it only shows part of the blog post on planit and the rest via a link, let me know in the comments. And comment on the app while you're at it ;)

I know I said last post that it would probably be a long while before a v1.2 ever arrived, but, well, something came up and now I've been busy working on v1.2.

I remembered that one of my buddies actually bought a 60GB iPod with Video. So I suggested to him that he try my app. Problem is, while my app is designed to max out the res to play back on a TV, he didn't have the cables, and only wanted to watch stuff on the screen.

Well, I made him a custom hacked up build of v1.1 that encoded to 320x240 (changing the 240 based on aspect ratio, so 16:9 content would give 320x180 video). Also hardcoded ffmpeg to start up with 2 threads to take advantage of HyperThreading on his CPU.

It worked great. He's using it, and reports that not only is my app encoding 3x faster than the convert that the rest of the world seems to use (Videora iPod Converter, and this is odd because both my app and Videora use ffmpeg, albeit different builds compiled by different people), but my app also properly handles non-four-by-three aspect ratios (like 16:9). Videora just stretches everything to 4:3, ruining widescreen content, while my app properly calculates the correct res (The iPod can do letterboxing by itself).

Well, that hacked up build was working for him. Problem is, he had a suggestion. He wanted iPodDrop to keep a log file of what it was encoding, and how long it took. That seemed like it was something that would do well to be in my mainline build, but I didn't want to keep having to hack him up a custom version over and over again. My solution? Integrate optional support for the changes to his version into the mainline version ;)

The end result is that in the upcoming v1.2, you can enable SMP support with a commandline switch (Uses 2 threads to take advantage of HyperThreading, dual core, or dual procs), and you can tell the app to target an iPod screen rather than a TV screen.

I actually will probably make the iPod screen target the default behavior, since this feature now makes my app suitable not just for myself and the few others who use the iPod on a TV, but EVERYBODY who plays video on their iPod. The minority like myself can use a commandline switch to target a TV instead. The switches still work with shortcuts, so you can have switches and still drag and drop.

Here is the current-to-date changelog for v1.2, pretty much what I've described above:

- Aspect ratio is now displayed as a fraction. IE, 4:3 instead of 1.333(...). It checks fractions with denominators up to 100.
- Added support for command line options/switches.
- Updated usage info.
- Added support for SMP (HyperThreading, dual core, dual processor) for the actual encoding.
- Added ability to output for iPod screen resolution instead of TV resolution.

As you can see, I fixed aspect ratios while I was at it. I was tired of seeing stuff like 2.2222222222222222222222. Now that shows up as 20:9 like it should.

Other changes I'm thinking about for v1.2 are the log file suggestion, and also changing how the app treats content that is less wide than 4:3. Like 1:1. My guess is that 1:1 content is probably going to be 480x480 or 480x576, which would be SVCD res. And when you decode SVCD content, you squish it down to 480x360 for display (Like anamorphic content, sort of). The actual display isn't 1:1, it is just stored like that. So I think that if a ratio that is less wide than 4:3 is detected, the app should just squish that down to 4:3. I'd also provide an option to leave the ratio untouched, in case you somehow manage to get such content (I have a 480x480 video file that for some reason really is 1:1 for display).

I have to be careful about such options, because if you add special case options like that, you start destroying the point of the application, the ability to drag and drop (even onto shortcuts). I think that in this case, though, the default handling is more correct, and the switch would be available just in case you have very rare content, so that you can type out the command by hand (Or have a shortcut already handy?).

Anyhow, I haven't received any comments on any of my past blog posts about iPodDrop, so I'm assuming that nobody downloaded it. That means that my buddy Dan is now my first official regular user, which is quite exciting for an app that I originally wrote to be super simple for myself :) I'm truly surprised at how crappy Videora is, considering how most of the rest of the world seems to be doing. My app is super simple an doesn't have a fancy GUI, and yet it is still somehow faster, more correct, and easier than Videora. Maybe I should do up a website and try to spread the word some. Maybe somebody else might find the app handy.

To talk a bit about the point about this having started to be so simple... The first version of the app was something on the order of 125 or 150 lines. It did exactly what I wanted it to do. But then I noticed some areas that could use some improvement, and so version 1.1 clocked in at about 175 lines (lots more rewriting than new stuff). And now here I am with a partially completed beta 2, and it is up to 275 lines already. Most of it seems to be dedicated to the new handling of command line arguments, since I need to handle commandline switches now. This program is rapidly growing way beyond what I intended for it, and I'm sort of proud of how that happened. It is almost like my little program is growing up. Lots of the original internal simplicity is giving way to more complex logic to deal with situations that I wouldn't normally run in to, but somebody else might. I've tried to keep it simple on the outside, though ;)

If you have any suggestions for v1.2 or later, drop it in the comments, I'd be interested to hear what other people think about this little app. Oh, and sorry for the long post about a version that isn't even out yet, I'm just rather pleased with how much more useful v1.2 is than v1.1 already :)

OK, so maybe it isn't that exciting. But version 1.1 of iPodDrop is done.

Download link: http://teknews.net/~guspaz/iPodDrop_v1_1.zip

Here's the changelog ripped right from the readme file (Oh yeah, it has one of those now too):

V1.1:

- Code cleanup and refactoring. Doesn't affect users, but makes the code easier to work with.
- Encodes video 40% faster with similar quality due to changes to the ffmpeg command line parameters.
- Now waits for user to press a key when an error occurs.
- Added error checking for bitrate parameter.
- New icon! No more default crap. Now you get CUSTOM MADE crap!
- Filled in AssemblyInfo file. This covers stuff like version number, and the info in the Windows Explorer properties dialog like the desciption.
- Switched from a debug build to a release build, as if it matters.
- Included this readme file.
- Removed the shortcuts, since Windows doesn't support relative shortcuts
- Other things I'm probably forgetting. I'll write them down as I do them next time, promise.

So, no huge changes on my part, but the 40% boost in encoding speed is rather nice. With all the cleanup and refactoring, though, a heck of a lot of the code changed.

I haven't found a solution for the shortcuts yet (which have now been removed). Windows is stupid and doesn't support relative shortcuts at all. I looked in to batch files, but there is trouble getting the right working directory with that method. I suppose I could go with Windows Script, but that is something I'd rather not rely on. If I eventually do up an installer with NSIS or something, I can have it create absolute shortcuts.

I got most of what I wanted to get done in 1.1 into this release. Next release might go for some more error checking and possibly an installer. But this version is working pretty darned well, so I don't think the next version will be coming out anytime soon. I mean, I wanted to write an app to make it easier for me to get video onto my iPod for TV playback, and I've accomplished that. v1.1 added some stuff that makes it better for me, and some other stuff that I just ended up doing along the way. But unless a bug pops up that gets in my way, v1.1 is doing its thing just fine.

I am pleased to announce the release of iPodDrop v1.0, an extremely quickly written iPod video encoder utility that I've thrown together over the last four hours or so.

There isn't NEARLY as much error detection as there should be, and it is probably easy to mess it up. There are lots of places where it is making assumptions that could cause trouble if you do strange things to it. However, when used exactly as intended, it seems to work fine. I mean, it doesn't actually check that the output video is ipod compatible, it makes assumptions that you've fed it 16-bit video and such things. So normal MPEG-4 stuff downloaded off the net should encode fine, but if you tried to give it exotic content, it'd encode it to a format that the iPod might not support.

What it does is simply determine the resolution of the input video, sees if the resolution needs to be shrunk in order to be decoded by an iPod, if so figures out the highest resolution with as close an aspect ratio as possible that can be decoded on an iPod (the iPod's screen is 320x240, but it can output higher resolution to a TV), then runs ffmpeg with a bunch of hardcoded parameters that are known to produce working iPod video in the QuickTime format.

The application itself has two parameters, the video bitrate (optional, defaults to 2mbit), and the source filename. All other encoding parameters are hardcoded in (only one you'd be able to change anyhow is sound settings, which I've locked at 160kbit stereo AAC), because the goal of this program is to work with drag-and-drop.

That's right, just drag an AVI file (or another format ffmpeg can decode) onto the executable in Explorer and it just starts encoding "_ipod.mp4" in the same directory as the source file. It defaults to 2mbit, but I've provided a variety of shortcuts that you can drag/drop onto that use a few different bitrates.

The obvious intention behind this is to make it stupid-easy to make high quality iPod videos destined to be played back on a TV. All you have to do is drag and drop a video file onto it (The icon, I mean, since it is a console app) and it does it's thing.

Download v1.0 Here

EDIT: OK, none of the shortcuts will work for you, but you can look at them and make your own. I can't figure out how to make relative shortcuts in Windows, so when I release v1.1 I'll switch to relative paths in BATCH scripts. The app itself can work from any directory though, it is only the shortcuts for alternate bitrates that are broken (And again you can make your own, takes all of 30 seconds)

Yes, I do intend to introduce future versions. This version is barely tested and was done super-quick to get something working. I will probably tweak the encode parameters to get some more speed out of it (SMP support might be nice, might not need some of the slow settings used, need to implement a push-any-key-to-continue for exit conditions), and to fix any bugs I encounter while using it. For now, this version works in most cases, so should be a good first release for such a quickly written program. I just dragged two random files onto it (The "Doctor Who Christmas Invasion" special, and an episode of "American Dad", and both output files played back on the iPod just fine. It might even run on Mono under Linux. It isn't really using anything particularly special.

Now that I've got this thing working and usable, I am going to collapse into bed onto my new memory foam mattress topper.

# posted by Guspaz @ 4:26 a.m. 0 comments

I've been pondering on a method of scaling down video under a certain number of overall pixels while maintaining aspect ratio. I came up with this:

width = sqrt(pixels * aspect)
height = sqrt(pixels / aspect)

So far that seems to work rather nicely. Is this correct, or is there a better way?

I'm not too thrilled with Apple's accessory planning.

I buy an iPod with video. It costs me $400 after tax and student discount. Turns out that it comes with no accessories save for a USB2 cable. I must admit I was pretty pissed off. Here I am spending all this money, and there is no dock, no power adapter, no video cable, no nothing. And Apple charges ridiculous fees for said devices ($40 for a video cable when you can buy generic ones for $2).

Well, I got over it. The iPod charged off my laptop's USB2 port, and while slow (slower than a power adapter would be since the adapter charges at half the amperage), it worked. It was fine.

Well, today is Christmas. And my parents decided to buy me some iPod accessories. I got a dock and power adapter along with an stereo 3.5mm to stereo RCA cable. Unfortunately, I can't use the dock's S-VIDEO out, since my TV only has one S-VIDEO plug that is already in use by the satellite, but it allows me to set up a permanent installation with the existing composite video cable I made. I might eventually buy an S-VIDEO/Audio switch to allow the use of S-VIDEO, but the minor gain in quality over composite may not be worth the cost.

Now, here's where the problem occurs. See, Apple's power adapter is braindead. I open the packaging, and it doesn't come with a cable. It requires the use of my existing USB2 cable to charge the iPod. So I will constantly have to remove the wire from the dock/charger and plug it in to my iPod.

Of course, since I have a laptop, plugging the dock in to my laptop doesn't really make sense. But if somebody had a desktop, they'd run in to another problem: there is no way to hook up a power adapter and computer to the dock or iPod at the same time. To charge the iPod you would have to unplug your desktop from the dock and plug in the charger, and then reverse the process when you want to sync again. This, of course, totally defeats the purpose of a dock (simplicity and lack of cable-swapping).

I think that with only one cable, the best solution to my problem is to leave the iPod in the dock (next to the TV) normally, and hold my laptop next to the dock while syncing so as to only have to unplug the cable from the power adapter. Syncing doesn't take THAT long. Still, this is all a big hassle. DAMN YOU APPLE!

Last time I talked about Hamachi, I posted the method that people assumed Hamachi was using for NAT traversal. It seems that UDP punching, which is already used in other apps like Skype, isn't anything new. It also only gets about an 80% success rate for the reason that a comment to my last post suggested: Some firewalls and NAT devices don't like having their UDP streams redirected from the mediation server to eachother. This also, it turns out, is not the method that Hamachi uses (Hamachi gets something like a 95 to 97 percent success rate, not 80).

The latest hypothesis about how Hamachi does it is via synchronised connections. The idea is that the mediation server would be use to synchronize the two computers to have them send UDP packets to eachother as close to simultaneously as possible. Presumably the mediation server synchronizes the clients, the clients then send UDP packets to the mediation server, the mediation server figures out what kind of NAT is being used to determine what public UDP ports will be opened when the clients send data to eachother. The clients are then instructed to send UDP packets to eachother at exactly (or close enough) the same time to the ports that are expected to be open.

Each client sends a UDP packet, which results in (hopefully) the guessed port being opened in expectation of return data. Since the packets are sent at the same time, the port should be open by the time each packet eventually arrives at its destination.

This concept is similar the the STUN protocol, but a bit different.

The thing is, this is how people GUESS Hamachi does it. The author of Hamachi won't tell because his business model relies on keeping the protocol under wraps. It is unfortunate, since 97% effective NAT traversal would be a big improvement over current techniques, and would really benefit the public.

The first support for SMP in modern games have started showing up as patches. Both Quake 4 and Call of Duty 2 now both sport patches that add support for multithreading.

FiringSquad has an article up that shows some pretty impressive performance increases in the graphics rendering subsystem. Their article is flawed, however. They're running timedemos of Quake 4, which only uses the graphics and sound subsystems. AI and physics aren't enabled in timedemos, and physics simulation can be one of the most CPU intensive tasks in modern games.

I'd rather have seen them post benchmarks taken with FRAPS in real-life situations. Less reproducible, perhaps, but timedemos are useless for testing CPU performance.

Well, somebody has come up with something that I have to say is incredibly cool. It also seems to render all other VPN software obsolete. It is called Hamachi, and to sum it up it is free fully encrypted peer-to-peer VPN software that can create a connection between even two fully NAT'ted computers with no open ports.

The encryption is public/private key, and the peer-to-peer aspect means that there is no server involved (Computers on a Hamachi VPN send data directly to eachother). It gets past NAT by using UDP and a mediation server. The idea as I understand it is that the client sends bootstrap UDP packets to the mediation server, opening a port on the NAT router (which expects replies by UDP). The mediation server then reports to the second computer which outgoing port is open on the first computer, and the second computer can then send data directly to that port. Repeat for vice-versa and you instantly can get through almost any NAT router and many firewalls. The program then encapsulates the original TCP packets inside a UDP datagram. After all, there is zero need for a TCP transport layer, because if a packet is lost or mangled, the TCP data stream will perform the usual resending. In other words, it behaves exactly like TCP because the end point computers think they are using TCP. Of course you can also encapsulate UDP packets, that is just even simpler.

Now, that is certainly the coolest part of the software, how it can create a connection between two computers with no open ports. But there are other cool things. For one thing, when you set up a computer with Hamachi you actually get a permanent IP on the 5.x.x.x network. Technically they are internet IPs, but they have never been assigned, and probably never will be (I think IANA owns them). So effectively they are non-internet and non-LAN IPs. So all computers using Hamachi have their own permanent Hamachi IP.

Another cool thing is that even though everybody has "public" IPs on the Hamachi network, communication is totally private and solicited because you create LANs involving specific computers on Hamachi. You add a bunch of computers to a LAN and then they only send data to eachother, ignoring all data from foreign computers.

Also? Full public/private key encryption, with the public key being required to join a LAN.

And they made it dead simple, with almost no setup required. Heck, it even has an instant messenger like function that lists the computers on the various LANs you are part of, along with their online/offline status. Here's a great screenshot:



And get this: IT IS CROSS PLATFORM!! There are current Windows and Linux clients out, and a Mac OS X client is coming as soon as the Windows and Linux clients exit beta (They are apparently in very late almost-done beta).

I just can't get over how cool this is. I mean, I know that only people from NITI read this blog, but damn, why use TunnelVision when you've got Hamachi?

The guy apparently intends to introduce a shareware version that adds additional professional-level features that a business might require, such as running the software as a service. The core functionality, though, what I've described above, that is free. Because most people won't want this running as a service.

Seriously, check it out, this is the coolest VPN software I've ever seen: http://www.hamachi.cc.

Also the guy is in Vancouver.

EDIT: Oh, and another cool thing, when you run the software it behaves like a network card. It even creates a virtual NIC in Windows, so really Windows apps have no way of knowing that they are not over a LAN. It even shows up in Network Connections, though I guess under Linux it just shows up under ifconfig. Of course it is a NIC that only supports TCP/IP. No IPX.

EDIT2: Actually, it DOES work with IPX. My bad.

Over the last few days I've started getting massive amounts of spam to my novasearch.net address. I've had this address redirecting to my GMail account for some time now. All of a sudden, TONS of spam mail has been arriving at my GMail account via my mail server at novasearch.net. We're talking going from 10 or 20 emails per day to about 100.

The emails are sent in clusters a few minutes apart, and seem to be from a botnet. The funny thing is that I blocked out a botnet that was spamming the almost dead NovaSearch forums (I had a "test" forum set up they were spamming for some reason). I guess this is some sort of revenge?

Of course, why they were spamming the test post section of a dead forum that nobody uses is beyond me.

I recently purchased a super cheap camcorder AV cable and rewired it to work with my iPod (to play video on the TV. The cable's ground and video pins needed to be reversed). Problem is, the base of the prong on the cable is ever so slightly wider than the plastic ring around the heaphone jack in the iPod. This means that when the AV cable's plug is fully inserted into the heaphone jack, its base comes in contact with the iPod's metal shell and causes video image quality issues (As in, it horribly blurs it beyond recognition).

I've been trying to think of a way to fix this, and I need some advice on how to fix this with things found around the home. One idea I had was to paint a very thin ring of nail polish onto the edge of the base of the connector, but I'm worried that it might scrape off over time and enter the iPod's innards. Another idea I had was super thin strips of electrical tape applied on top of the ring, but I think that'd be a bit thicker (and less neat) than I'd like.

Any suggestions? Some material I can find in the home that I can paint on that won't cause problems? Or advice for making super thin strips of electrical tape (We're talking 0.5 to 1 millimeter wide)?

Right now the problem can be solved by pulling the connector out of the ipod a hairs width, but this is really a kludge and prone to the slightest movement pushing the cable back in contact.

This guy has taken a bunch of pictures of the same scene from two slightly different angles. He then swaps the two images several times a second to create a surprisingly effective stereographic effect without any sort of glasses or crosseyed tricks:

http://www.well.com/user/jimg/index.html

Warning: While the link itself is SFW, some of the sub pages are NSFW.

It works much better on some images than others, but on the ones that it works on, the image really looks 3D. It works by tricking the brain into thinking it is seeing both images, even though the images only switch a few times a second.

A strange side-effect is that the images even look 3D through one eye, which is just a strange feeling, when the image on the screen looks 3D, but the room you're sitting in doesn't (since one eye is closed).

I read on Digg that there was a new bot available for MSN Messenger that did natural-language parsing to tie in to the Encarta encyclopedia (Add it to your MSN list, encarta@conversagent.com) and I was surprised by one of its answers:

Guspaz says:
What is the airspeed velocity of an unladen swallow?

Encarta® Instant Answers says:
What do you mean? An African or a European swallow?

Guspaz says:
African.

Encarta® Instant Answers says:
Based on recent scientific studies, the average cruising airspeed velocity of an unladen African Swallow is roughly 11 meters per second, or 24 miles an hour.

Guspaz says:
How do you know so much about swallows?

Encarta® Instant Answers says:
Well, you have to know these things when you're a good robot, you know.

Undaunted, I pressed further:

Guspaz says:
How do you know so much about swallows?

Encarta® Instant Answers says:
Well, you have to know these things when you're a good robot, you know.

OK, should we get back to the kind of questions I was designed to answer? :-) What is the largest country in the world? If you don't know, just ask me.

It also could maintain state between questions, which impressed me for some reason, even though it was a simple trick:

Guspaz says:
Who is the Prime Minister?

Encarta® Instant Answers says:
Which country or state would you like to know about?

Guspaz says:
Canada

Encarta® Instant Answers says:
Paul Martin (2003- ) is the Prime Minister of Canada.

I also tried to find a few more pop culture references:

Guspaz says:
What is the answer to life?

Encarta® Instant Answers says:
Forty-two.

Guspaz says:
What is the captial of Assyria?

Encarta® Instant Answers says:
It depends when. Assyria had successively four capitals: Ashur (or Qalat Sherqat), Calah (or Nimrud), the short-lived Dur Sharrukin (or Khorsabad), and Nineveh.
Any other question, bridgekeeper?

Guspaz says:
What is your favourite colour?

Encarta® Instant Answers says:
Hmm... Good question. You know what? I think I'm gonna say red.

Hopefully somebod will go and play with it to discover a few more, and post them either on planit or the comments here :)

Visited NITI friday. I hoped to catch the co-ops before their semester ended, but it seems they went on a trip to Halifax just the day before. Also many people were working from home.

I seem to recall that Pat said they'll be back on the 13th and around until the 23rd, so I'll have to try to stop by again sometime during that window.

I just found this incredibly... stupid. It turns out that if you move the xbox 360 even slightly while it is turned on (tilting it, actually), it makes a VERY loud noise and gouges a big chunk out of the DVD in the drive, all the way around the disc.

You might actually want to tilt the unit, since it is designed to stand both on its side, and down flat.

Anyhow, check out the report here: http://www.llamma.com/xbox360/news/Xbox-360-Game-Disc-Scratched.htm

Watch the video. Yeah, it is WMV, but it is worth it. You won't believe how loud the noise is, or how little movement it takes to destroy a disc.

This isn't an isolated incident either. the guys at llamma.com only tried it out after it happened to them on another 360. I'm having trouble believing that Microsoft didn't pick this up in QA. I guess they decided that replacing a few scratched discs was cheaper than using a different DVD drive.

UPDATE: Microsoft has said that they WILL NOT replace scratched discs, because they burried a warning on page 11 of the manual that says "Remove the disc before moving the console or tilting it between horizontal and vertical positions".

A software uninstaller on the Windows platform should be a simple affair, right? All the application needs to do is delete the files and registry keys, very simple. Well, when I tried to uninstall Call of Duty 2, it decided that not only did it need the usual bloated uninstaller that takes half a minute to load as it extracts temporary files, it decided it needed to VALIDATE the install before it could DELETE it. The process of validation took upwards of five minutes. So stupid. Somebody needs to be slapped.