Dave Riepe and Jeanine Fritz have turned the Boulder Outdoor Cinema into a local institution.  Every summer on Friday and Saturday nights, they show great current and classic movies on the back of a downtown building.  You bring your own chair (or couch or blanket), and they supply the movie, popcorn, opening acts, the works.  A number of years ago, Dave asked me if it were possible to show trailers of the coming attractions before the feature, just like a “real” movie theater.  It sounded like a fun project, and I was happy to give it a shot.

Like many problems, this one sounds simple at first, but becomes increasingly complicated the deeper you get into it.  Dave wanted to show trailers for the next three movies before the main feature.  If you think about this for a minute, you realize that you’ll be repeating each trailers a number of times – the first week you’d show trailers 1, 2 and 3.  Next week you’d show 2, 3 and 4, the next week 3, 4 and 5, etc.  You could just generate individual sequences with all the trailers you need, but that’s (A) a lot of editing work, and (B) all that repeated data takes up a lot of space, requiring multiple DVDs to get through the season.  Another problem is that some movies are shown in widescreen, and some are shown in fullscreen.  The projector is framed differently for each type of movie, and reframing the projector between the coming attractions and the feature wouldn’t be professional.  Add a number of other technical, programmatic and legal issues, and you can see how this became a very interesting project.

After a few years of refinement (and thanks to some very clever software), all of these problems were neatly solved.  The DVD specification allows for a limited amount of primitive programming, so to solve the multiple-instance problem, mini-playlists were developed.  These allow one instance of each trailer to be placed on the DVD, but each trailer can be accessed as many times as necessary.  With further work, this also allowed the coming attractions to be shown in widescreen or fullscreen as the main feature requires.

The current iteration of the Coming Attractions DVD is highly automated, to make the projectionist’s life as easy as possible.  It allows the operator to set up the night’s show with one click, automatically pauses on black, starts the show with another click, automatically plays the 3 trailers, plays a short informational animation about the outdoor cinema, pauses on black again while the operator switches to the main show, and later on plays a longer animation for the intermission.  All from one DVD that is used all summer long.

A few words about tools:  for general video capture and editing, I use the Video Toaster from Newtek.  It’s billed as the fastest editing system in the world (which it usually lives up to), and it’s iphone-easy to use.  My DVD authoring software of choice is DVD-lab PRO, from a small company called Mediachance.  Unlike most drag-and-drop DVD software, which typically limit you to the few templates they’ve provided, DVD-lab exposes every level of the DVD specification to the user, while still being intuitive to use (which is quite a trick).  It’s a bit more expensive than the cheapest ones, but for a few hundred dollars its feature set is competitive with high-end packages costing ten thousand or more.  It’s that good, and highly recommended for serious DVD authoring.

Another interesting aspect of this project was obtaining the trailers themselves.  Most DVDs will throw the theatrical trailer on as a bonus feature.  But some don’t, which often happens when they’re not sold as a “special edition” disc.  What’s worse is that a DVD will sometimes include trailers for other movies, but not bother including the trailer for the film on that disc, which often leads to a (usually) fruitless hunt through other discs trying to find the trailer for this one.  And before the days of YouTube, Apple and other trailer sites on the internet, there weren’t a lot of options if you couldn’t put your hands on a specific trailer.  Since I have a strong dose of “the show must go on”, there were a number of times in the early days when given no other option I sat down and handmade a trailer for the movie in front of me.  It was a lot of work, but also a lot of fun, and I’m especially proud of those editing jobs.

See you at the movies!

• Boulder Outdoor Cinema
• Newtek (video editing systems)
• Mediachance (DVD authoring software)

My first space “work” was with, what was back then, large-scale DRAM memory chips.  (By “large” I’m talking 4096 bits per chip; this was the very beginning of the personal computer revolution.  You kids get off my lawn!)  Shrinking the circuitry was increasing the capacity of these devices by leaps and bounds, but unfortunately this was also causing an alarming rise in random, radiation-induced errors.  Smaller circuitry carries a smaller amount of charge, making it increasingly susceptible to the charged particles that are always zipping around and through us.  A charged particle hits a memory cell, and suddenly what was once a “1″ is now a “0″, and your bank balance (or anti-lock braking system or rocket ignitor) is now better or (more likely) worse than you left it.

At the time, IBM researchers found that most of these errors were coming from impurities in the chip packaging itself, which is a solvable problem.  But a small number of errors were caused by cosmic radiation; high-energy particles generated by supernovae and other events in deep space.  The earth’s atmosphere and magnetic field shield us from most of these particles, but a few will always get through.  While reading about this in high school, it occurred to me that this could be a serious problem for computers in space.  So I wrote up an experiment proposal for NASA’s Space Shuttle Student Involvement Project, and was accepted as a finalist.  (While presenting my work at NASA Ames, an engineer asked me if he could blame all of his bugs on cosmic rays.  I replied with what I had calculated as the error rate for a single 4kb chip: “Sure, once every sixteen years.”)   The problem remains, but most hardware manufacturers consider it a one-in-a-million event, and pretend it doesn’t exist.  Crashes due to software bugs are vastly more common.

Thus it is interesting to hear of a new long-term study by Google on DRAM errors.  Google has so much computing capacity that it is uniquely positioned to perform such research (and it’s gratifying that they take the time to do so).  Surprisingly, the study found error rates 15 times higher than previously expected, but they also found that most of those errors were coming from the same group of chips, suggesting that manufacturing variability is a cause.  The study also found that age is a factor, with error rates sharply increasing at 20 months.  This could be due to chip designers cutting their silicon margins to the bone, knowing that due to Moore’s law, commercial hardware has a very limited lifetime these days.

What I took away from that early work was that nothing is perfect.  If you’re programming a computer and you put a byte of data into memory, the chances are extremely good that you’ll get the same byte back.  But it’s not 100% guaranteed.  And if it’s VERY IMPORTANT that you get the same byte back, you should invest in fault tolerance of some sort.  Spacecraft computers work around this problem with special hardened construction, redundant “voting” systems, and error-correcting codes in memory (which are an effective solution to the DRAM error problem, though it costs an extra 25% to store the correcting information).  I sometimes  wonder why these reliability lessons from space aren’t incorporated more into our everyday machines, but until software quality improves, it’s usually cheaper to just reboot.

• DRAM study turns assumptions about errors upside down (via Ars Technica)