DVD Main Title Size: Where the Gigabytes Go

For my personal edification, I've been surveying my DVD collection in terms of how much each movie uses on disk. This is the main feature only, none of the extra fluff, but it does include wasted space taken up by language tracks which I do not speak. This is movies only, not TV shows.


So far I've found 187 movie DVDs around the house. There are discs my son has reduced to coaster status, and I've no idea where ⅔^rds of the Indiana Jones trilogy ended up. I feel that is enough to get some feel for what the average movie uses on disk and how it correlates, if at all, with quality.


So some stats:

• Disks: 187 disks
• Average size of Main Feature: 5.10GB
• Largest Main Feature: 12.94GB over 2 Disks: The Return of the King
• Largest Main Feature on a Single Disk: 7.60GB King Kong
• Smallest Main Feature: 3.08GB Sleepless in Seattle (which had plenty of room for both Thai and Korean subtitles)
• Total GB: 948

Some surprises:

I have the Superbit version of Panic Room, the cheapest Superbit title I could find. Sony claims that Superbit is great because they fill up the whole disk with movie, making it as uncompressed as possible while allowing for both a Dolby Digital and a DTS soundtrack. Well, Panic Room clocks in at a measly 5.66 GB, leaving nearly 2 GB of room which could have been used for less compression. Having said that, the picture quality is quite good as it is. My other Superbit title, Adaptation, leaves around half a gig of empty space on the disk. Is it false advertising if you claim the highest quality DVD, and it turns out you could have made it even better by using less compression?

And how did Pirates of the Caribbean end up with only 3.61 GB? It was a special effects blockbuster with a huge marketing budget. They couldn't spend some tweak time getting a better picture?

Breakfast At Tiffanies is just the opposite, despite being quite pedestrian in its appearance, having only mono sound, and being none too long at 115 minutes manages to use up 7.18 GB. Where does it all go?



The disks that have the most movie on them tend to be major blockbusters: The Lord of the Rings, Minority Report, etc. where a lot of tweaking time can be spent getting everything to fit, or are just plain long (Patton). Disks with the lowest space usage tend to be catalog romantic comedies originally released pre-DVD. The studios didn't spend much time getting the highest quality disk, perhaps in the hope of coming back in a few years with a "Widescreen Collector's Edition", such as was the case with The Big Lebowski (3.54 GB), L.A. Story (3.57 GB), and Sleepless in Seattle (3.08 GB). By way of comparison, a short exercise DVD "Post Natal Yoga" clocks in at 3.94 GB.

[UPDATE: Here's a histogram of number of disks per size. The cut off for a single-sided, single layer disk, 4.7 GB minus a few trailers, is pretty obvious. I'm a bit surprised by the shape of the curve; if I had had to guess beforehand, I would have thought that there would have been two peaks, one just below the maximum capacity of a single layer, and another just below the maximum for a dual layer. But once you get passed the minimum for a single layer, it's almost as if it's following a random uniform distribution.]
[UPDATE: Updated for more disks surveyed.]

Logitech Tech Support Driving Me Up the Wall

I had written this entry weeks ago, meaning to do some more research before posting it, and I had forgotten it with my busy work schedule, but this blog entry: ill-Logitech seemed so similar to my experience I thought I should post this.

Before I begin this in earnest, I like Logitech products. I have owned many of their products: speakers, Harmony remotes, game pads, and cameras. They make the kind of gadgets I love to own. I am also not angry with Logitech or their tech support person who was courteous if pointedly unhelpful. This is just a story of spinning one's wheels in the pursuit of technological promise. I am also not including the text of actual exchanges with the tech support person at her request; you will have to rely on my characterizations of what happened. If anybody at Logitech is interested, this is Incident: 061224-000580

Now in earnest. I came across a cool racing simulator for the Mac, Redline by long time Mac gaming house Ambrosia. I had a good time playing it from the keyboard of my MacBook (1.83 GHZ Dual Core, 2GB RAM), and had some idea that if I added a steering wheel I could enhance my fun, and maybe give my wife, who's learning to drive, some simulated road time.

I went Googling and found that Logitech's MOMO racing wheel was well regarded and people had used it to play Redline on their Macs. I took a deep breath (maybe not literally) and ordered one from Amazon. It came, and like a kid at Christmas, I scrambled to unpack it from it's hefty box, mount it firmly on my desk, plug it all in and fire up Redline. Open up Options, Analog Controls, and what do I see but that the Force Feedback controls were disabled. Oh, it could see the wheel. I could calibrate the steering and braking, assign the horn beeping to one of the buttons on the wheel, etc, but I was denied the joys of having my steering wheel lose resistance when spinning out on ice, or stuttering in my hands when I slammed into a canyon wall at 120 MPH.

First things first, replug, restart, reboot, always greyed out.

I did notice that the motors in the wheel were working as whenever I plugged it into a USB port, the wheel would spin itself back to center.

Then I went to the Redline support forum, and found other people with the exact same problem, and others for whom the wheel worked as advertised.

And by advertised, I refer you to Logitech's Product Page which gives the following requirements:

• PC with 166 MHz or faster Intel Pentium® or compatible AMD® processor
• 64 MB RAM
• 20 MB available hard disk space
• CD-ROM drive
• USB port
• Windows® 98, 2000, Me, or XP
• Mac® OS X 10.2.3 or later*

* Requires game that supports force feedback. Check with developer

Needless to say my MacBook exceeds these specifications in every way, excepting the PC part or the Windows part. And the developer certainly says Redline supports force feedback.

I posted onto the forum and exchanged some information with the Ambrosia people, but they didn't know what was happening, and the copy of the wheel they had in house was working fine. I began to wonder if it was a bad batch of wheels or an incompatible firmware.

I sent Ambrosia the USB Prober trace for the wheel:


Low Speed device @ 3 (0x1D100000): ............................................. Composite device: "Logitech MOMO Racing "
Device Descriptor
Descriptor Version Number: 0x0110
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 8
Device VendorID/ProductID: 0x046D/0xCA03 (Logitech Inc.)
Device Version Number: 0x0019
Number of Configurations: 1
Manufacturer String: 4 "Logitech "
Product String: 24 "Logitech MOMO Racing "
Serial Number String: 0 (none)
Configuration Descriptor
Length (and contents): 41
*** omitted raw descriptor ****
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0x80 (bus-powered)
MaxPower: 80 ma
Interface #0 - HID
Alternate Setting 0
Number of Endpoints 2
Interface Class: 3 (HID)
Interface Subclass; 0
Interface Protocol: 0
HID Descriptor
Descriptor Version Number: 0x0100
Country Code: 33
Descriptor Count: 1
Descriptor 1
Type: 0x22 (Report Descriptor)
Length (and contents): 87
*** omitted raw descriptor ****
Parsed Report Descriptor:
Usage Page (Generic Desktop)
Usage (Joystick)
Collection (Application)
Collection (Logical)
Report Count............ (1)
Report Size............. (10)
Logical Minimum......... (0)
Logical Maximum......... (1023)
Physical Minimum........ (0)
Physical Maximum........ (1023)
Usage (X)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (10)
Report Size............. (1)
Logical Maximum......... (1)
Physical Maximum........ (1)
Usage Page (Button)
Usage Minimum........... (1)
Usage Maximum........... (10)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Usage Page (65280)
Usage 0 (0x0)
Report Count............ (4)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (1)
Report Size............. (8)
Logical Maximum......... (255)
Physical Maximum........ (255)
Usage Page (Generic Desktop)
Usage (Y)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
Report Count............ (3)
Usage Page (65280)
Usage 1 (0x1)
Input................... (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Bitfield)
End Collection
Collection (Logical)
Usage 2 (0x2)
Report Count............ (7)
Output.................. (Data, Variable, Absolute, No Wrap, Linear, Preferred State, No Null Position, Nonvolatile, Bitfield)
End Collection
End Collection
Endpoint 0x81 - Interrupt Input
Address: 0x81 (IN)
Attributes: 0x03 (Interrupt no synchronization data endpoint)
Max Packet Size: 8
Polling Interval: 10 ms
Endpoint 0x01 - Interrupt Output
Address: 0x01 (OUT)
Attributes: 0x03 (Interrupt no synchronization data endpoint)
Max Packet Size: 8
Polling Interval: 10 ms


I would think the data in this probe log would be useful to tracking down where the device was failling to be recognized. For example, the USB standard for Physical Input Devices indicates to me there should be another "PID" interface which could be used through a driver to cause a force feedback action.

Regardless, I thought it best to not bother Ambrosia too much; they are a small house and might not have the resources to track down such an obscure problem.

I e-mailed tech support at Logitech and shortly got a response asking me to perform a variety of actions, most of which were reasonable, of the "is it plugged in?" variety, but one really stuck in my craw and seemed to be an open invitation to give up bothering Logitech and go away. The tech support asked me to test the wheel with a PC game! And if I didn't, no tech support for me.

First of all, it's a near fluke that I own a PC. It will give you a hint to know my PC's network name is SCORNED. Second of all, they didn't say "Download this tester app from our website." They didn't even say, "Here's a list of games which we know work. Try a demo." No, they told me to find an unspecified game to test it on what could well have been my non-existent PC. Or no tech support for me.

Well, I mulled on that for a week or two. Meanwhile, I got an e-mail saying that if they didn't hear from me within 120 hours they would assume I was happy and close the incident.

I won an Amazon gift certificate in a drawing at work, so I looked around and found a popular game for the PC, GTR2, which was known to work with the Logitech MOMO, and I bought a $20 copy.

Of course, the MOMO wheel worked on the PC. I wasn't very impressed by how hard the force feedback was, but it was definitely moving, and the green force feedback lamp on the wheel was lit. In passing, I prefer Redline to GTR2. Realism is good and all that, but it's a lot more fun bouncing off of canyon walls than sliding around some ugly Formula 1 track.

I e-mailed Logitech support, confident that they would now be interested in "The Mystery of The Wheel That Didn't Work on a Mac." Not very much. They asked me to uninstall and reinstall Redline. I know uninstalling is second nature to PC people, but what exactly does that mean on a Mac? I trashed my preferences and overwrote the Redline application with a clean copy. Still no force feedback.

I e-mailed Logitech support with this datum, and was told it was obviously an application specific problem and I should go bother Ambrosia. I downloaded a cute little game called Jammin' Racer which has a picture of the Logitech Momo in their instructions. None of the promised rumbling. The lack of force feedback was not application specific.

I e-mailed Logitech to let them know I had disproved the application specific theory, and offered to do whatever USB Probing they would need to trace down the problem. I also asked if I could blog about this experience. The support tech said they preferred not, and (I'm paraphrasing) I should get lost. Actually, she said I should go bother Mac support. (Who is that? Apple support?) She did mention there was only 1 version of the firmware, so that shot down my working theory that some people had one firmware and force feedback, while others had a different firmware and none.

Warning, Mac programmger voodoo ahead. There is a ForceFeedback framework amongst the system frameworks, and I modified Apple's USB Notification Tool example to find the MOMO wheel and try to extract information about it. Surprisingly, the "FFIsForceFeedback" routine returned true, but the "FFCreateDevice" routine returned FFERR_NOINTERFACE, which I take it means the MOMO does not match the profile of a USB force feedback device. This is probably where Redline and Jammin' Racer fail.

I cannot say who is at fault for the wheel not working properly. The ForceFeedback framework is not well documented, and is probably not a priority at Apple. It's possible there is a hardware incompatibility between the USB ports on my MacBook and the MOMO. It's possible the MOMO is not properly following the PID specification. It's a complicated system with many failure points; I just know I paid for a force feedback wheel and didn't get one.

[UPDATE:] Reader Jonas writes to point out that perhaps the problem is with the LogitechForceFeedback.kext extension
/System/Library/Extensions/LogitechForceFeedback.kext/
which (apparently) comes pre-installed with OS X. His research indicates it is PowerPC only.
[Update 2:] Jonas gets back to me and tells me the kext included with Mac OS X 10.5 developer releases works to bring force feedback support to Intel based Macs according to the forums.

It's Time for Carbon Apps to Support RTF on the Clipboard

I don't know when the 'styl' resource was defined, but I do know it is very, very old. For those not in the know, back in the days of the Mac II, if you wanted to copy and paste bold/italic/underlined/colored/text from your application to another, you put both a 'TEXT' Handle on the clipboard, and a Handle filled with individual style records (the 'styl' flavor), with each record corresponding to a range of the raw text in the 'TEXT' resource. You could even put in foreign words and phrases by switching to lets say a Japanese font. This was what was done in 1987, it was what was done in 1997, and it is what most Carbon apps still do in 2007. I fired up iTunes Friday, copied something from a dialog, and looked at what was on the clipboard: a 'TEXT' resource and a 'styl' resource.

Well, what's wrong with it?

Here is an individual style record from TextEdit.h:
struct ScrpSTElement {
long scrpStartChar;
short scrpHeight;
short scrpAscent;
short scrpFont;
StyleField scrpFace;
short scrpSize;
RGBColor scrpColor;
};
And here are the things you can put in a StyleField:
normal = 0,
bold = 1,
italic = 2,
underline = 4,
outline = 8,
shadow = 0x10,
condense = 0x20,
extend = 0x40
What's wrong?

• No superscript or subscript, not even one level. Try pasting data from a scientific app to MS Word. H⁺₂SO₄^-2 becomes H+2SO4-2.
• It takes an old fashioned QuickDraw font ID, not an ATSUI ID, so it may be difficult to map to the fonts you're actually using.
• No paragraph alignment information. You can have any justification you want as long as it's left.
• Text encoding is by necessity implied by the QuickDraw font encoding.
• The OS has to go through and endian swap every element before pasting across Rosetta.

So what is the alternative?

There is nothing preventing you from supporting the 'RTF ' (Rich Text Format) flavor on the clipboard. It's a Microsoft invention, so you know Word will like it, and it satisfies all the problems I enumerated above. Plus, it's the favored flavor of any Cocoa application, so your text should be more accurately transferred to newer applications.

It's just a matter of implementing it. As I was already mixing in Cocoa into my Carbon application, I built up an NSAttributedString, extracted the string's content using the RTFFromRange:documentAttributes message and stored that raw data in a Handle. When I, inversely, wanted to paste, I extracted styled text information from an NSAttributedString created from the data in an RTF Handle. I did it all in a day for my application. (Sorry, can't share the code.) This has the added advantage of using the exact RTF flavor Cocoa applications get for free.

Alternatively, you could pretty easily create simple RTF documents from scratch using the description of the format in O'Reilly's RTF Pocket Guide. Parsing such documents looks to be a lot harder, but doable, just ignore the tags you aren't interested in.

I could hardly be happier with the result. My users will be getting a nice little present come the next release, and I'm one step closer to expunging the last bit of QuickDraw from my application. If you are maintaining a Carbon application which has anything but the simplest text formatting requirements, do your users a favor and look into supporting the 'RTF ' clipboard flavor.
[Entry has been edited for content since first publication]

The Freedom of EV-DO

My dad is an interesting, and smart guy. He left retail banking 20 years ago to start a software company in his basement, then transitioned into brokering the sale of small planes. And for much of that 20 years, he's sat in that basement, making sales call after sales call. I can't estimate how many thousands of times he's told a prospect to check "w w w dot global dash air dot com." As his phone, his computer and his dial-up Internet connection were in that basement, and he couldn't afford to be away from them, the basement became a prison of sorts.


And then a piece of technology came along to change this. He bought a Dell laptop (a Dell Inspiron E1405), and more importantly, he signed up for Sprint wireless broadband and bought a Sprint Mobile Broadband USB Modem. Suddenly, when combined with a healthy number of cell phone minutes, his business was located not in his basement, but wherever he happened to be. He could visit his friends in West Virginia and Florida. He could spend a week in my basement. He could even hang out with my mom while she was watching grandbabies all over the greater Twin Cities area. Technology has set him free.


And the EVDO modem is faster, even in Dad's rural basement, than his soon-to-be-cancelled dialup. He could stop waiting for the phone company to bring DSL one more mile out of town.


This is the sort of thing technology should be doing all the time. As an engineer, I am always on the lookout for ways to improve the lives of my users. The EVDO engineers at Sprint and elsewhere have markedly improved the lives of my Dad and others like him. It's why a lot of us got into engineering in the first place. Congratulations and thanks to them.

Netscape Plugin Development in XCode

A desperate Google searcher emailed me today asking about getting together an XCode project for a Netscape style plugin. Since this, apparently, is not well known, there is a NetscapeMoviePlugin project in the standard set of examples installed with your developer tools.


/Developer/Examples/WebKit/NetscapeMoviePlugIn/


One thing I would not recommend is using any of the QuickTime API calls in that plugin, they are laughably out of date. Nor was it obvious, to me, how you add things like JavaScript properties. But it is a start for an XCode project.

And I won't get started on what a sorry state of affairs that something so archaic as Netscape plugins are still used to add functionality to Mac browsers.