The number is 240. In learning how YouTube works its magic so that MobyGames may one day take user’s video submissions, Trixter has been doing his own poking at the video giant to determine what parameters the site uses to transcode user videos. What he learned: 240 lines, 240 kbps, 240 frames in a GOP. His best guess for why things are the way the are: …”it sure seems like the YouTube guys were taking blind stabs at encoding parameters (ie. ‘Hey, let’s set everything to 240 and see what happens!’).”
Author Archives: Multimedia Mike
First Digital Pictures
If Michael can show off the very first pictures from his new digital camera, then so can I… where “new” is roughly July, 2003. I was organizing thousands of digital photos from the last 6 years and found what must be the first pictures from my current digital camera, based on the filename. And wouldn’t you know, the pictures were of felines:
It’s all coming back now — I invested in the Canon Powershot S400 back when I was fostering a family of 5 kittens and their mother for the local animal shelter.
So it has come to this– posting cat pictures. Eh, it’s a holiday. Above was Scooter. He was the bravest of the litter. This was feeding time:
As you can plainly see, I’m not a very good photographer. Plus, I had a phenomenal amount of difficulty adjusting to this new camera, which was a substantial feature upgrade from the S100 I had purchased 2 years earlier. Many of my earliest photos can out very blurry or with saturated colors until I learned how the camera expected to be used.
Bash Too Smart For Its Own Good
So I’m running the latest Ubuntu release in a virtual machine under my main Windows XP machine (it’s a blessing that I no longer need to choose between operating systems these days– I can run them all simultaneously on the same machine if I wish). Today I noticed a feature of Bash that for all I know has been in place for over a decade. I just have never seen it enabled by default in any distribution before. I had to do some research — indeed, one of the first problems in Unix is learning how to ask the right question — but I eventually figured out that the feature is called “Programmable Completion”.
Tab completion is God’s gift to command line navigation. It’s something I always take 10 seconds to carefully explain to anyone who is struggling with the Unix command line for the first time since navigating through a filesystem is agonizing without it. Programmable completion takes tab completion and tries to make it smarter. I first noticed this peculiar behavior on my Ubuntu VMware session today. If there are 2 files in the current directory, xyz.tar.gz and xyz.tar.bz2, then typing ‘tar zxvf x<TAB>’ automatically completes xyz.tar.gz while ‘tar jxvf x<TAB>’ automatically completes to xyz.tar.bz2. I noticed this, thought it was an interesting touch, thought for a moment about how it might work, and immediately wondered what would happen if the underlying mechanism isn’t aware of a mapping that I need.
It didn’t take long before I ran into that eventuality. I was trying to play some impossibly obscure formats with xine. I navigated to the necessary directories only to find that they were apparently empty of any files. I never realized just how important tab completion is to me. Now I’m reading pages of documentation trying to figure out how to disable programmable completion entirely. (It would probably be enough to ask the desktop terminal emulator to run my own Bash config files on startup– I don’t understand why I have to specifically configure such programs to do this.)
Effectively, Bash is making a decision here about what files it thinks I want to see. I’m surprised a Linux distribution would program that kind of behavior by default. How condescending is it when a Microsoft OS tells you that there are entire sets of files that you don’t need to see? Maybe that’s not a fair comparison, as the programmable completion feature is more akin to a list of file filters in a “File Open…” dialog box. Thing is, there’s no obvious way to select “show all files”.
Computer programs get into trouble when they try to anticipate what a normal user needs. More often, such programs have the effect of shaping end user behavior to account for the educated guesses that the computer makes.
ISO Compromise
Engineering is about trade-offs and compromises. One of the most fundamental trade-offs to be made when designing a storage format is whether multi-byte numbers will be encoded as little or big endian numbers. But have you ever studied the data structures involved in ISO-9660, the standard filesystem format for optical discs? It seems that the committee tasked with developing this standard were unwilling to make this one tough decision and specified all multi-byte numbers as omni-endian. I just made that term up. Maybe it could be called bi-endian or multi-endian. The raw detail is that multi-byte numbers are stored in little endian format and then in big endian. For example, 0x11223344 is stored using 8 bytes: 0x44 0x33 0x22 0x11 0x11 0x22 0x33 0x44.
Do any other filesystems take this compromise? I am not that versed. I have studied the odd game-related optical filesystem; I had to write a manual ext2 searching tool for a sysadmin class; I also had to try to recover a virus-corrupted FAT16 filesystem (to no avail; that virus cleanly chewed up some of the most important sectors).
Anyway, if I were to go ahead and try for a new FUSE driver for ISO-9660 (or modify an existing driver), I would want to go after the main format. Plus, I would want to natively interpret that CISO format on the fly. Further, I would use this as a platform to understand what is so special about the apparent ISO-9660 data ripped from a Sega Dreamcast GD-ROM.
Are there any other ISO bastardizations to target for such a tool?