Resurrecting files

Comments Off on Resurrecting files

Last week I talked about how the producers of Toy Story 2 nearly lost a year’s work by accidentally deleting files. Unplugging the machine is about the worst thing you can do after entering an inadvertent rm *. There are, however, things to do even if you’ve deleted the only copy in the world of a file.

First, heed the advice in The Hitchhiker’s Guide: Don’t panic! In fact, don’t do anything until you have a clear idea of what to do. Your file is only mostly dead. The bits are most likely still there, but there’s no longer a file directory entry claiming and protecting them, so they’re fair game for any application to devour them. Any useless action could make exactly that happen.

The right utility can put those bits back into a file, but it has to be the first one to get at them. If you already have it right at hand, that’s the best case. If not, download it on some other computer and put it onto a USB stick or CD-ROM. Don’t let anyone touch the afflicted computer while you’re getting ready.

A popular utility for this purpose is TestDisk. It’s available for most modern operating systems and runs as a command line utility. Here’s a case study in its use, along with the companion utility PhotoRec. Command line programs make the least use of system resources and so aren’t as likely to make something get written out to the disk. The downside is that they aren’t as user-friendly. I’ve just downloaded TestDisk and found that it assumes you know a few things about disks and partitioning schemes. It can be a little intimidating for a user, especially one whose job is on the line if those files disappear for good. If it’s recovering files on a device using the old FAT16 file system, it may show you short uppercase file names. It doesn’t work 100% of the time. I created a short text file called lazarus.txt and deleted it, then used TestDisk to recover it. It found something called _AZARUS.TXT, which I copied only to find just a decayed pile of mouldering bits.

There’s some discussion here of the ultimate doomsday scenario, typing in rm -rf /*. Last time I said you should think three times before doing rm *. If you’re ever tempted to type in rm -rf /*, seek immediate psychiatric counseling. The article includes suggestions to use TestDisk and PhotoRec, but we never learn how much if anything the unfortunate soul could salvage.

Becoming an expert with these utilities clearly takes a bit of work, but if you’ve practiced a bit you might still be able to get yourself out of a jam. If you’re so inclined, you might even become an expert on them and be a consultant or local hero. They can call you Miracle Macs.

What’s deadlier than the Death Star? The rm *


A year’s worth of production on Toy Story 2 was nearly lost due to user error and a bad backup. The video “Toy Story 2: The Movie Vanishes” gives a fanciful telling of how this happened, but it’s mostly possible to separate fact from creative elaboration. A tweet from @DisneyPixar confirms the authenticity of its source. It’s also on the Toy Story 2 Blu-Ray DVD combo pack.

Leaving aside the clever but silly stuff about the characters vanishing one by one, we can extract this account: A great many critical files for the production of Toy Story 2 were on a single Linux or Unix computer. Someone who shall remain nameless (and probably jobless) mistakenly entered “rm *” on the directory with these files. An emergency call was made to the sysadmin to just yank the plug out of the wall; this was done about 20 seconds from the time of the entry of the command, most of the files were gone. Worse, the backups for the past month were defective to the point of uselessness. Fortunately, the technical director, Galyn Susman, had been working at home and had all the files there. They physically transported the computer to the studio to copy all the files back.

I’m hoping the video takes serious liberties with what happened for the sake of entertainment. If not, the amount of stupidity that happened is staggering. Let’s assume, for the sake of a lesson in what not to do, that they really did all these things.

First, the Linux/Unix command line is dangerous. rm * will delete all the files from your directory. Think three times before hitting Return after typing it.

Second, if you do enter a mistaken rm *, DON’T UNPLUG THE COMPUTER, YOU IDIOT!! That will just damage the file system and won’t be quick enough to save any files. Hit Control-C. It’s much faster and safer, though even that will probably be too late.

But it took 20 seconds to delete all the files. That says there were a lot of files. It also says they were all in a flat structure with no subdirectories, since rm * doesn’t remove subdirectories. OK, maybe the command was really rm -r *, but the makers of the video were trying to keep things simple and dramatic. If you type rm -r *, think four times. If it’s rm -rf *, make it at least six.

Then, instead of bringing a drive to Galyn’s house and copying the files onto it, they wrapped her computer — the one with the only copy in the world of a year’s worth of work — in blankets and drove it in a car to the studio. Cue Christine Lavin singing “What were you thinking??” But at least they had an offsite backup, even if it was by chance.

OK, I’m not being fair. It’s a video for entertainment, and they really didn’t do quite all of those stupid things, other than not verifying their backups. I hope. But there are still lessons to learn.

1. If you have critical, valuable files, keep a backup of them and occasionally verify that the backups are good. This doesn’t have to be an elaborate check. Just look at the backup drive and list the directory, making sure current backups are there and have plausible file sizes (> 0).

2. Keep an offsite backup. With an operation like Pixar, security considerations apply as well; you don’t want to give backups to just anyone. But by the same token, if you’re Pixar, you can afford to make backups, move them offsite, and give them decent security.

3. If you need to restore from your last offsite backup, treat it extra carefully. If you can’t restore remotely, copy it at the offsite location and restore from the copy.

4. NEVER unplug a running computer to interrupt processing! (Sorry, that one really gets to me.)

Thanks to Mary Ellen Wessels for helping to research the video.

The challenge of too much digital stuff

1 Comment

Yes, you want to save all those important family photographs. There’s just one problem: They’re mixed in with thousands of pictures. Which ones do you really want to keep? Should you pick out the important stuff and save it in a collection that gets special attention? That can be a lot of work. Should you toss everything onto a terabyte drive? That saves effort, but will your grandchildren bother to go through it for the pictures that are worth remembering? Are there pictures in that big pile that you’d much rather they didn’t see?

The Library of Congress offers some advice which sounds useful:

Identify where you have digital photos

  • Identify all your digital photos on cameras, computers and removable media such as memory cards.
  • Include your photos on the Web.

Decide which photos are most important

  • Pick the images you feel are especially important.
  • You can pick a few photos or many.
  • If there are multiple versions of an important photo, save the one with highest quality.

That’s a reasonable agenda for a full-time librarian. For those of us who have other things to do, it’s a daunting challenge. It’s not unusual to have a few thousand digital photographs lying around and very little organization about them. The only clues you may have about their content and context are the file date (which can be wrong) whatever you can gather by looking at the picture. Some of my oldest digital photographs, from 2002 or earlier, have no metadata beyond the digital characteristics of the picture; they don’t say when they were taken or even on what kind of camera. The files have names like DSCN0128.JPG. The file with that name, incidentally, is dated “Jan 1, 2001 12:00 AM,” and it’s not from a New Year’s party. I remember that party. We toasted the New Millennium to Also Sprach Zarathustra. The picture isn’t from there.

But I digress. The point is, you have lots of pictures and don’t necessarily know a lot about them. Storage is cheap, and time isn’t. The best strategy may be a culling strategy; not “pick the images you feel are especially important,” but “spot the ones that are plain junk and get rid of them.”

While you’re doing that, try to give the pictures some sort of organization. This is best done on an ongoing basis rather than in one desperate plunge. My approach is to have a bunch of folders with descriptive titles, by geographic area or event or whatever. A lot of the folders have subfolders; I have a “Cons” folder with subfolders by convention name, most of those with subfolders by year. I drag pictures from the camera import folder to an appropriate folder. The ones that don’t get dragged out of the import folder eventually get deleted. Sometimes I rename the files to something descriptive and add metadata; sometimes I don’t. The result is a semi-organized collection of pictures with some stuff which other people might find interesting in years to come. Since I’m the kind of person who writes about file preservation, I have occasional bursts of fanaticism that let me improve the organization a bit.

To one degree or another, that’s the approach which makes sense for most people. Try not to lose anything important. Keep it as organized as you can on an ongoing basis. Don’t make an unnecessary effort to live up to the standards of people who work for libraries (like me). A good management tool (e.g., Adobe Bridge but not iPhoto) is a big help. It’s much easier to maintain good preservation habits than to tackle a huge organization project.

Recovering encrypted files

Comments Off on Recovering encrypted files

Few things in digital preservation are as frustrating as finding out you can’t open an encrypted archive. It must have been something important, and now you can’t get at it at all! You might not even have a clue what the file is.

The number one cause of this situation is stupidity. Back when I was doing consulting work, I’d sometimes send my project on a disk. (This was before the Internet and high-bandwidth data connections.) As a safety measure I encrypted it and sent my client the password separately, with a strong reminder to decrypt the disk immediately on receipt.

In one of those cases, I got back a reply months later saying, “We got this disk from you a few months ago and we can’t figure out what’s on it.” I hadn’t kept the password around, so I couldn’t help them. All I could do was send them another disk. They didn’t get around to decrypting that one either.

If you’ve received an encrypted archive and a password for it, do one of two things right away: Either decrypt it and store the extracted data in a safe place, or store the password where you’re sure you won’t lose it.

Another way to lose encrypted data is to find that you have the archive and the decryption key, but no working software to do the decryption. Perhaps software using some obscure homemade scheme created the archive. The encryption is doubtless second-rate and has serious theoretical weaknesses, but that’s not much help unless you’re a topnotch cryptanalyst. Or you may just not be able to tell what encryption scheme was used; one collection of random-seeming bits looks a lot like another.

Finally, encrypted files are fragile. Accidentally changing one bit will usually make the whole file or a large chunk of it undecipherable.

Sometimes the first challenge is to find out what kind of software to use. FI Tools from Forensic Innovations claims to be able to identify encrypted file types. The file extension may give a clue; lists over 300 of these.

Why so many? For one thing, in the nineties the US government put severe restrictions on the strength of encryption that published software, especially for export, could use. This did little to keep terrorists from using strong encryption, but it encouraged people to roll their own encryption methods. Finding software for some of these could be very tough today.

On the positive side, you may be able to break old archives created with those feeble algorithms just by throwing computational power at them. The once popular DES encryption used 56-bit keys; it’s possible to crack a DES archive on a modern computer in a matter of hours.

You have to be careful when looking for encryption-breaking software. A large part of the market is for espionage and data theft, and the people who sell to this segment aren’t the most trustworthy.

As always, preventing the problem is far easier than curing it. Keep good track of encrypted archives, store the decryption keys securely, don’t let the only person who knows the password quit, and make sure decryption software is still available.

Saving Internet information from the Memory Hole

Comments Off on Saving Internet information from the Memory Hole

Before releasing the name of Sergeant Robert Bales, who’s accused of a murderous rampage in Afghanistan, the US military tried to wipe information about him from the Internet. Since this is a tech blog, I won’t be talking here about why they did it or whether it was a good idea. The questions I’m addressing here are: (1) If you want to wipe some information from the Internet, can you do it? (2) If someone tries to wipe information which you suddenly realize you want, how much can you recover?

We’re talking here about the government’s deleting only information which it directly controls. Parts of Bales’ wife’s blog disappeared, but probably this happened with her cooperation. If a government can control all websites in the country, including search engines, and restrict access to those outside, it’s a very different game. Think of China and the Tienanmen Square events of 1989.

If the government hadn’t been so rushed for time, it might have done a much more effective job. Keeping Bales’ name out of the media for a week was probably pushing their limits. If they could have had another week, many search engine caches could have lapsed, making it harder but still far from impossible to find old pages.

Let’s suppose information on someone or something has been sent down the Internet Memory Hole, and you’re an investigative reporter who wants it back. How would you do it? If you do a search on Google, many of the hits will have “cached” links. This lets you look at Google’s latest cached version of the page, which may be the only available version or may have information that was recently taken out. That technique is good for information that’s not more than a few days old.
Screen shot from Google showing "cached" link
For older information, you can look at the Internet Archive’s Wayback Machine. This site has a vast collection of old Web pages, but it’s still necessarily spotty. Usually it has only pages more than six months old, and anyone can ask not to have their pages archived.

If you looked at a page a few days ago and it’s no longer there, you may have a copy cached by your browser. Going into offline mode may improve your chances of seeing the cached page rather than a 404.

There may be copies of the vanished material elsewhere on the Internet. Some people fish out cached pages that have disappeared and post them, especially if they think the deletion was an attempt to hide something. I did this myself a few years ago; in 2004 John Kerry proposed mandatory service for high school students, making it illegal for them to graduate if they didn’t satisfy a federal service requirement. This stirred up a lot of anger and the page proposing it disappeared from his website. I grabbed a cached copy from Google and posted it. That copy greatly increased my site’s hit counts for a while. If you can remember key phrases from the delete page, using them in a search string may turn up copies.

There’s a Firefox add-on called “Resurrect Pages.” It offers to search several caches and mirrors if you get a 404 error. Another one is “ErrorZilla Plus.” I don’t have any experience with them.

Finding vanished information on the Internet is an art, and doubtless there are experts who know a lot more tricks than I’ve mentioned here.

iPhoto vs. preservation


How does iPhoto fit into digital preservation? Sort of like Rick Santorum in an ACLU meeting or a Yankees fan in Fenway Park. There’s at least one thing you have to use it for, and that’s importing pictures from an iOS device. But using it for anything you want to keep is a seriously bad idea.

Take a look at this article on Apple’s forums. A user asks a perfectly good question: How do you back up your iPhoto albums? The answer: “There is no album directory/folder. All the album info is stored in a data file that only has info of the album names and pointers to the actual photo files.” Look under “Pictures” in your user directory and you’ll find a folder called “iPhoto.” This may contain one or more library packages. A “package” is an invention of Apple’s intended to hide clutter from the user, as with an application that encompasses hundreds of support files the user shouldn’t have to mess with. In this case, though, it’s hiding essential information from the user. Fortunately, you can right-click it (that’s control-click for both of the people who don’t have a two-button mouse) and select “Show Package Contents.” This will bring up a window showing the contents of the package (which is just a folder in disguise); it’s rather bewildering. You can also right-click on a thumbnail in iPhoto and select “Show File” to see that file directly in the Finder.

Screen shot of an iPhoto library window

Screen shot of an iPhoto library window

Note: A question has been raised about the screenshot, with a warning that relying on it may “lead to massive data loss.” See discussion here.

The package has a folder called “Data” which is an alias to another folder within the package; this contains your actual JPEG files, carefully hidden from you. It may also contain other packages; these represent other iPhoto albums, which aren’t even visible in the Finder. You might say they’re sub-albums, but iPhoto doesn’t show any hierarchical relationship.

As far as Adobe Bridge is concerned, the library package is a binary document which it doesn’t know how to open. This means you can’t so much as see a list of your iPhoto pictures with Bridge.

That may be just as well. According to advice Apple support forums, if you try to do anything with those files, you’re apt to confuse iPhoto hopelessly. It’s like a micromanaging boss; the more you assert yourself, the deeper the hole you’re digging yourself into.

iPhoto horror stories aren’t hard to find. Here are a few I located quickly by searching for “evil iPhoto” and “hate iPhoto”:

Interchange formats


Some file formats are good for long-term storage of files, because they’re likely to be usable for a long time. (“A long time” in computer terms means ten or twenty years; if you want files that really last, get a rock, a hammer, and a chisel.) These are preservation formats. There are also file formats which are good for moving files from one application to another. These are interchange formats. (See my last post, “Tied to an Application”, on why these are important.) The two have a lot of overlap but aren’t the same.

The two have things in common. Specifications should be publicly available. The format should represent the information without losing any. There shouldn’t be legal barriers to implementation.

The big difference is that interchange formats have to work right now. A format which is otherwise great doesn’t help most users if they can’t import it into a new application with available software. Interchange formats have to keep editing-related information. PDF is a great format for preservation, but try turning a PDF into an editable file. The results are usually disastrous if the file’s at all complex.

Is Microsoft Word a usable interchange format? Much as it makes me gag, I have to say yes in many cases. You can open Word files with quite a number of different applications. Someone got paid a lot to reverse-engineer the Word format, but the job has been done. A safer bet, though, might be to export from Word to ODF. The current version can do this natively, and the ODF Add-In on SourceForge claims to do it better. That way, whatever application is importing the file is following a published spec, leaving less room for bugs and other surprises.

RTF (Rich Text Format) is nominally an interchange format, but it’s actually a poor one. Its handling of character encoding is miserable and can result in garbled files when an application guesses wrong about a file’s encoding. It isn’t standardized.

Don’t count on any interchange format to give you exactly the same content with a new application. There will almost always be subtle difference in formatting from one application to another. Color profiles may be treated differently. Metadata might not be 100% preserved.

Don’t use JPEG for image interchange. Its lossy compression means there will be spillage along the way. TIFF is good for getting images from one application to another.

When you export a file, keep it in the original format as well, at least till you’re sure you’ve exported it to your satisfaction. If anything goes wrong, that leaves you a chance of exporting again with better tools or settings, or if all else fails of manually moving information over.

Tied to an application


There’s nothing like a task you do every three years to remind you how transitory software can be, and how easy it is to lose files because you can no longer run the software to open and edit the files. I was reminded of this twice over as I started on the creation of the songbook for Concertino (blatant plug), a filk music convention which is held every three years in Massachusetts. I’ve been using Finale Allegro in the past, with my last upgrade being to the 2005 edition. Allegro is no longer available, and Allegro 2005 doesn’t export to any format that other software can open for editing. I have a lot of music in Allegro, so this is a dangerous problem.

The makers of Finale list an application called PrintMusic, a name which sounds really minimal, on their website. It turns out to be pretty much a renamed version of Allegro; if any features are missing I haven’t noticed so far, and it can open Allegro files though it uses a different native format. At this point I’m using it to enter songs and don’t seem to have lost anything.

This is fortunate, since after running it, Allegro will no longer run. It says it’s missing a required font. So I’m pretty much forced into buying PrintMusic at this point, and I’ll have to convert my existing files before getting stuck. The good thing is that PrintMusic can export to MusicXML, which other notation applications understand, so I can avoid being trapped again as long as I remember to export all my files.

After plain old data loss, scenarios like this are the commonest way to lose files. You use an application that works nicely for creating some important files, ignore them for a while, and then find you can’t open them with it any more. An “upgrade” in the operating system or hardware may have broken the application. Or you may have gotten an “upgrade” to the application itself, making it incompatible with the old files. (This shouldn’t happen but does.) Or in a more circuitous route, you may have switched from Application A to Application B, which opened A’s files just fine, only to discover that the latest version of B dropped that feature.

Sometimes you’re careful when switching to a new application or version, not deleting the old one till you’re sure you don’t need it, only to discover that the installation blew away some part of your computing environment that you needed. Even restoring the old application from a backup may not help if you can’t reinstall it from scratch. (Still got that serial number from four years ago?)

The best way to avoid this problem is to export important files regularly to a format that other applications can use. Often there’s an interchange format used by many applications that do similar jobs. This means you should check before committing to an application whether it has a decent export capability. Ideally, this should be an interchange format which other applications can read and edit. The exported file may be missing some fine points in the native format, and the importing application might lose more information or not format the file in quite the same way, but it’s a lot better than losing everything.

Next best is to save the visible rendering to a safe format. PDF is often a good choice, and these days most applications that can print files can “print” to PDF. If possible, export to PDF/A. Sometimes it makes more sense to export to an image file, such as TIFF. Don’t export anything but continous-tone images to JPEG; other kinds of images just look bad with JPEG compression.

Picking a “format that isn’t prone to breaking” can be tricky. I have an application called “Checkbook”, which is a nice checking-account managing application, and it lets you export your data to QIF. This would be more valuable if Quicken hadn’t dropped QIF support back in 2005 in favor of OFX, which Checkbook can only import. There are converters from QIF to OFX, but it’s not the ideal situation.

Application reviewers don’t usually say much about exit strategies. With any application, it’s possible you’ll have to give it up someday and go to a different one to carry on the job, and you’ll want to keep using your old data. Reviewers should pay attention to applications’ export capabilities. We don’t know how useful any export format will be in the future, but an application that has one improves your chances of avoiding a cul-de-sac.

Mirror, mirror on the web

Comments Off on Mirror, mirror on the web

Sometimes it’s helpful to have the same Web content at more than one location. Doing this means that it continues to be available if one site goes down for any reason. This can be useful with unpopular material that’s prone to denial-of-service attacks, or with material of lasting importance that shouldn’t go away if its primary maintainer drops the ball. For example, I’m the main force behind the Filk Book Index, a list of the contents amateur songbooks produced by science fiction fans. It’s mirrored, with weekly updates, at If goes away, the index doesn’t, and people can download and save a version which is up to date or nearly so.

A widely used tool for mirroring a site is GNU wget. This article on FOSSwire discusses how to use wget to create a site mirror. Be aware, though, that wget doesn’t do anything but grab files. If your site has dynamic content or if it depends on files that aren’t downloadable, wget won’t help you.

Another tool is HTTrack. Unlike wget, it has a GUI. It’s currently available only for Windows, Linux, and Unix. Like wget, it can only grab publicly available files.

Search engines don’t always deal well with mirrors. If they detect a mirror site, they’ll often list just one version, and they may guess wrong about which one is the primary. This actually happened with the Filk Book Index; for a while, Google and other search sites were listing the index on but not the one on The solution for this is for the mirror site to create a file called robots.txt at the top level of the site directory, with the following content:

User-agent: *
Disallow: /

Be careful not to put that on your primary site, though, or search engines won’t list you at all! wget works best if your primary site doesn’t have a robots.txt at all, since by default it respects its restrictions.

(In case you aren’t familiar with robots.txt: it’s a file syntax which search engines use by convention to determine which files on a site they shouldn’t index. It doesn’t actually prevent any access, so it’s not a security measure, but it’s respected by legitimate web crawlers. Learn more about it here.

What about the increasingly common sites with dynamic content? You can mirror them, but it’s harder. You’ll have to send your collaborator a copy of all your files and make sure that any needed software is on the mirror site. If it depends on a database that’s regularly updated, you may be able to give the mirror site access to it. Of course, if the database goes down all the mirrors go down with it.

A mirror actually doesn’t have to be publicly visible, as long as it can be made visible on short notice. You could, for example, put the mirror in a directory which isn’t available to browsers, and run a periodic script that makes the mirror available if the primary stops being available for an extended period of time. Strictly private mirrors can be useful too, if making them available quickly isn’t an issue; they can prevent content from being lost.

Video preservation

Comments Off on Video preservation

Planning so that your files will survive for a long time is tricky in general, and video is one of its trickiest areas. When even the designers of HTML5 can’t agree on a video format, what are the odds that your family’s or club’s movies will still be viewable in ten or twenty years? Even at the Library of Congress, there’s considerable uncertainty about digital video preservation strategies, and even big movie studios are at risk of not preserving their now all-digital movies.

Just figuring out what format you have is confusing. There are two things you have to know: the format of the file as a whole, called the “container,” and the way the bits represent the video, called the “encoding.” These are largely independent of each other, and the specifications for each can have multiple options. The same format may be referred to by different names, and different formats may be called by the same name.

Usually you create a video from a camera, and it probably doesn’t give you a lot of format options. If you process it with a video editor, you have more choices about the final format. The file suffix tells you what the container format is supposed to be but not what encoding was used. If it’s .MOV, you have a QuickTime container. If it’s .MP4, you have an MP4 container — which is not synonymous with MPEG-4, but rather with MPEG-4 Part 14. Both are MPEG-4 compliant but not at all compatible with each other.

It’s common to refer incorrectly to other MPEG-4 container files, including audio-only files, as MP4. If it’s not a Part 14 container, it shouldn’t be called MP4. On the other hand, its being a legitimate MP4 file tells you nothing about what encoding it uses, so not all “MP4” files are compatible with each other; likewise for QuickTime files.

Videos produced by current cameras and software usually will use the H.264 encoding, aka MPEG-4 Part 10. You may also run into MPEG-4 Part 2, which is based on H.263. If you have a strong preference for open-source, you may want to go with the Theora codec. The win is available source code and (hopefully) a lack of patent encumbrances, but the risk is that less software supports it. Preservation is always a matter of placing bets. If you use Theora, it should be in an Ogg container, not an MP4 container; the latter combination is technically MPEG-4 compliant, as a “private stream,” but may not be supported in the long term.

An older container format, Audio Video Interleave or AVI, still has strong support. It dates all the way back to Windows 3.1. Its Full Frame encoding option lets you store uncompressed video.

Microsoft’s current entry is Advanced Systems Format (ASF), often in combination with Windows Media Video (WMV) encoding. It’s widely supported but tends to be Windows-specific, so it may not be the best choice for long-term preservation.

Most video encodings are compressed, since they take a lot of space even by modern standards, and usually the compression is lossy (i.e., it isn’t possible to recover the original data without some loss of accuracy). There are ways to get uncompressed or lossless compressed encoding, but here we’re getting into esoteric areas which I’d best not touch.

The video encoding isn’t the whole story. An encoding such as H.264 is only a video encoding, and even if you’re a silent movie fan like me, you probably like sound in a lot of your movies. The audio encoding that goes with H.264 is usually MPEG-4 Part 3 Advanced Audio Encoding, known for short as AAC, but this isn’t required. If it’s something else you could have preservation issues.

As I said, it’s a mess. I’m far from an expert in this area, but this article should give you an idea of the issues to look for.

Suggestions: Current advice varies a lot. Popular options today include a QuickTime (.MOV) or MPEG-4 Part 14 (.MP4) container with H.264 video and AAC audio if you want to go with software popularity, or Ogg with Theora and Vorbis if you value openness more. The older AVI is hardly dead. Pay attention to the encoding, not just the container format. Stay tuned for future developments and be prepared to migrate to new formats.


Older Entries