Today’s IMDb Studio Briefing contains a quick notice that Toshiba has started selling HD-DVD, but only in Japan at this point. The HD-XA1 is expected stateside within a month. Toshiba’s official press release on the new unit provides a lot of juicy technical details. Nice to know that it supports just about every kind of optical disc that came before it.

The player spec page contains scant mentions of a new HD-DVD-ROM computer drive. I have not seen anything new on qosmio.com about that new laptop that should be equipped with the new technology.

Today’s IMDb Studio Briefing reports in “Sony To Release Hi-Def Movies — With No Players” that, well, Sony plans to release movies in Blu-ray format before — well before — players are available, as in, movies in May, players by November (optimistically). The most incomprehensible part is that I will probably be one of the first consumers to procure such a disc just because I just have to have a sample of every kind of multimedia out there. My biggest question is whether or not there will be computer drives capable of reading Blu-ray discs.

Check out this piece of x86 ASM arcana:

  lea   edx, [edx+1]

What on earth? This appears to be functionally equivalent to:

  inc   edx

So, what, was the compiler/assembler or possibly the original coder just trying to show off with a single overachieving x86 instruction like lea? Actually, a closer analysis of the surrounding ASM instructions may reveal what is happening here:

  cmp   ebx, value
  mov   al, [edx]
  lea   edx, [edx+1]
  mov   [edi], al
  lea   edi, [edi+1]
  jz    address

The conditional branch at the end of the block depends on the flags set by the comparison at the start. Per my understanding, neither mov nor lea modify flags but inc probably would (I can never find a good x86 reference– that includes flag data– when I need one). Why not perform the comparison just before the conditional branch? Mine is not to question why. But I imagine that someone will comment that this is an obscure optimization trick for original Pentium machines or some such.

More fine FMV photos, just for the delicious irony…

Those wacky programmers over at LucasArts have traditionally employed more acronyms than the most bloated of bureaucracies. They started out with SCUMM (Script Creation Utility For Maniac Mansion). Then there was SMUSH and INSANE, 2 other game engines. I think GRIME was another engine, developed for Grim Fandango. I probably have some of those details at least a little incorrect but I’m too lazy to do the research right now, and I know the ScummVM hackers will perform any corrections for me. (Update: Sure enough– check the comments for clarification.)

Why do I care about any of this? A number of games based on the SMUSH engine contain FMV files with the extension .san. This apparently stands for Smush ANimation. Many years ago, shortly after I gained interest in studying game-related multimedia formats, I received a request to study the SAN format. Some reverse engineering work had already been done and put into ScummVM but it was not quite complete and was also quite rough around the edges– the kind of RE work where ASM is more or less converted directly into C. I never could quite make heads or tails of it and sometimes thought it might be easier to just start over with the raw binary.

I think it’s finally time to get serious and and put the SAN format to rest! Who’s with me? Good, now let’s get down to business. First things first, samples! I have organized SAN samples from 11 different titles (although Outlaws and The Dig are represented twice in the count because of their demos): http://www.mplayerhq.hu/MPlayer/samples/game-formats/la-san/. That directory also contains the file TGSMUSH.DLL which is allegedly capably of playing every known variation of SMUSH files.

The SAN files have a pretty straightforward FourCC-chunk format that we multimedia hackers have all seen in dozens of formats before. What coding methods does the format use for audio and video compression? That’s the big question. Not unlike other game-specific FMV formats that evolved over time as their creators refined the concepts (I’m thinking of Westwood VQA and Interplay MVE), SAN went through a few iterations. It apparently employs a range of coding techniques. One audio codec is called VIMA — most likely an abbreviation for variable IMA ADPCM — that Cyril has done an amazing job of documenting. As for video codecs there are a number of codecs and subcodecs at work and the details are still not entirely clear. There is some RLE and there appears to be some vector quantization. Further, based on the RE work already in ScummVM it appears that SAN might use hierarchical VQ, also seen in Sorenson Video 1, as well as gradient blocks, also seen in Gremlin Digital Video (though still not documented in the Wiki).

For your inspection you can find the source for the ScummVM SAN video decoder here: http://omega.xtr.net.pl/misc/smush/. The binary DLL is also available as mentioned previously. Cyril has started a new page on Smush. I think we have all the resources we need to attack this. Let’s see what we can come up with.

As of this writing, the MultimediaWiki has catalogued just north of 100 video codecs. I believe these each to be legitimate, unique video codecs. I know that the original FourCC list has dozens upon dozens more FourCCs. However, my base criteria for adding a new codec is proof that it exists, either by a binary (or source code) codec module or by collected samples. There are a few codecs for which the MPlayer archive has samples but we only know their FourCCs. These include AVUI and ViVD. I know that binary codec modules exist in a number of web collections that would verify that some of those more obscure FourCCs exist. But many of the websites seem to be slow, inundated by pop-ups, and written in some kind of Cyrillic text. I don’t have the patience for any of that. But if you do, the Wiki could use your help.

“Sappy” may be a bit unfair– this stuff probably contains no sap at all to speak of.

I used to think that it would be too far-fetched to write a computer program to determine the solution(s) to one of Pickover’s more linguistic puzzles, such as the puzzle for 2006/03/22; find letters to fill in positions 1, 3, and 5 to form an actual word:

1 n 3 i 5 n

I decided to call in the help of a program I had only heard of — Ispell — that I previously had no use for because I’m the most awesome spehlurr I personally know. However, I researched it, installed it, and determined that I could use it to come up with a list of plausible puzzle solutions.

Read the rest of this entry »

Big Brain’s puzzle for the weekend of March 11-12 was essentially an anagram puzzle. Using the following 12 letters:

e c m a o n s a d e l k

form an 8-letter (English) word and a 4-letter (English) word. One word tastes good and the other carries stuff. Usually, I am at a loss to write a program that can re-sort letters and find what look to be valid words. However, I recently found an anagram generator. Go to the homepage of the GNU MP Bignum library, scroll way to the bottom and find “Demo 2 — Find Anagrams”. One day, I hope to understand how big numbers pertain to computing anagrams. Anyway, insert those 12 letters and you will find an impressive list of anagrams, including the correct answer for the puzzle! For added enjoyment, insert your name or those of your friends (the Guru’s name anagrams to “Hemimeridae larceny”).

Your reign of terror-logic will not last long, Pickover. We have technology on our side.

A few weeks ago the Guru saw fit to defend AVI’s honor. I thought this would be a good opportunity to pen this ode to Apple’s QuickTime file format. As many of my open source multimedia brethren well know, I’m QuickTime’s biggest fan in our little community.

Read the rest of this entry »