Here I consider the whole iPhone ecosystem as the sum of the “Touch” user interface and the AppStore and its 140,000 existing applications. For developers, it’s indeed the same platform.

The iPad re-purposes the iPhone ecosystem into the future mainstream utility to get things done. The magic is in simplifying things to make them iPhone-like, and the genius is in artificially restraining some technical capabilities.

Your mythical grand-ma cannot buy or use a computer alone, but she downloads and uses apps on her iPhone, alone. That’s the whole differentiating point of the iPad, and because it’s not a computer, Apple has met its goal to give whole new demographics their Internet-age appliance.

Now, let’s go back to SimpleMovieX. I have no doubt that the iPad will be a successful platform, that eventually will displace current platforms. That is definitively a place I will be unless I want my business to address only niche technical markets ten years from now.

SimpleMovieX is a lightweight video editor. From the scope point-of-view, it can be a good fit for the iPad, that is primarily a consumption and lightweight creative device. SimpleMovieX uncluttered user interface could easily be transposed to iPad screens.

The first problem is how you get your data into your iPad. Movies syncing through iTunes works well, but it is not the channel that people will use to import content that they want to modify. According to published information, the iPad doesn’t have a built-in camera, nor does it connect directly to video cameras.
The iPad seems too disconnected from video production workflows and from video devices to be a place for SimpleMovieX to live. At least today.

From the technical stand point, it looks really bad too: All indicates that the QuickTime framework that powers SimpleMovieX is not available on the iPad. Instead, the modern and efficient QuickTime X, used in the iPhone and iPad for audio and video playback, supports very few codecs and formats, and have near-zero editing capabilities.
This will improve over time, for sure, but Apple is like a car with no reverse gear: QuickTime X will grow towards the future, not towards ensuring full backwards compability with legacy QuickTime.

In other words, if SimpleMovieX someday exists on the iPad platform, it will have nothing in common with today’s SimpleMovieX. Except maybe the skin and purpose. Time will tell.

Similarly, every two or three months, I receive a movie repair that is at the edge of impossible. It has this rare quality of being too damaged to be repaired with known techniques, but at the same time I foresee that there is a small chance that a new technique may fix it.

Officialy, I don’t call it Everest-class, but rather Investigative Repair, to convey to the customer three important ideas:
- I have to develop something radically new. A unique solution for a unique case.
- it’s gonna be expensive (I charge usually one order of magnitude more for those repairs)
- at the end, I can come to the conclusion that the repair is impossible. Results are not guaranteed.

I do such repairs primarly to challenge my repair ability and to push the enveloppe of the discipline. As boring as repairing movies may seem, an Everest-class repair is when there’s adventure, struggle and achievement.

The last Everest-class repair came last month: Canon EOS 5D Mark II files with some bitstream corruption. Mr Szot, the polish director, did not notice the problem until the production was finished. The clips, needed for a 15 minutes short movie called “An Exclusive”, could not be shot again.

I observed around fifty defects in a dozen of files. The footage is encoded in H264, where one wrong bit can propagate nefarious effects over a dozen of frames. Even with “creative editing”, it would be impossible to tell the story: For some important takes, the footage was unusable.

In 99% of the repairs, the problem consists in re-indexing the clip: Audio and Video media is fine but the “table of contents” that tells where the data for each frame, is missing.
But here, it’s the opposite. The table of contents is fine, but the media is corrupt.

Not that corrupt, according to real world standards, since the amount of bad data is only 1 for 100 millions. Like a rare disease that would affect just 70 people in the world population. The typical needle-in-a-hay-stack problem. Change needle for bits and haystack for a file with one billion bits and you get the idea.

Bits Flipping Party

The repair technique lies on a simple idea: when decoding the frame, the wrong bit will cause errors and exceptions that eventually stop the decoding process. That is what we observe in a defective frame: the top is ok, then something occurs, then the rest of the frame is not decoded.
The location where it stops should be close to the wrong bit. Never before, at a short distance after.
From here, we will go backward and flip the bits one by one, until we get something that decodes without error.

I made a bold assumption here: that wrong bits are extremely rare. So rare that we can consider that there is only one wrong bit involved in every decoding error.
I had nothing to really back this assumption: If it’s true, we would be able to repair. If it’s wrong, it would be impossible. Checking the assumption thus became a priority before engaging into time consuming developments.

There’s a second assumption: The distance between the wrong bit and the error is small.
One iteration will be needed for every bit, and iterations are slow since they decode several video frames each. Not just one frame, but the whole group from the I keyframe to the damaged frame. That can take several seconds, so if we have thousands of iterations, it would become impracticable.

Prototype and Automation

I assembled a prototype from various pieces, an open-source H264 decoder, a couple of small programs to flip bits and to detect errors and generate pictures from potentially successful iterations.
I tried it on a first defect, a slow process since almost everything had to be done by hand, and results have to be carefully interpreted.
When I finally managed to get a good picture out of the prototype, it was unbelievable. I had found the needle.

Since I had almost fifty defects to fix, I spent some time automating the process. At the end, I would only have to send a few command-line commands, choose manually the starting point of the search, and launch it.
The computer would run for minutes, sometimes hours, until it starts spitting pictures.
I had to review the pictures one by one, until I could find one that was perfect.
Then, I would modify by the wrong bit in the movie and verify that it fixed the frame and also the rest of frames in the “Group of Pictures”.

In some cases, fixing a frame would just unveil a defective one a few frames later. Just as one train may hide another…

Finally, I managed to clean completely all but one defect. This was quite a surprise. I would never have anticipated such a desperate repair attempt to work with a 98% success rate.

My customer, Mr Szot, is happy. His film “An Exclusive” will be presented this week to the polish public.

Today, by doing casual research on “back side touch” keywords, I found a very interesting 2007 patent filing by Apple:
Back-Side Interface for Hand-Held Devices

The patent is credited to Apple engineer John Elias. This guy is the founder of Fingerworks.com, a company dedicated to develop devices than can be controlled by gestures. Apple hired him 5 years ago, and surprise! the website has been shut down this week…

Timing is perfect for a 27 January presentation.
I don’t intend to convert this blog into a rumors place, but God! speculation is exciting!

Either it’s on resting on a flat surface, and you have unacceptable ergonomics, with your hands hiding the screen and your neck bent at an angle that your EHS department won’t permit.
Or you’re holding it in your hands on front of you. But how do you use the touch screen if your fingers are behind the tablet?

Apple will for sure come with the solution, that will feel so natural and simple that all speculations like mine will look a bit stupid two week from now.

My take on the Tablet:
Why not make the back side of the tablet a touch sensitive surface and show the fingers as an overlay of the user interface?

Fingers that are merely resting on the surface would show a small, transparent “finger print” while the active finger would be more visible, for example with a black circle representing the pressure applied.
This would enable multi finger gestures, and give natural feedback, both visual and tactile.

Such a device with a screen on the front side and a tactile surface on the back side would work well in the two natural positions:
- Held with both hands, mid-air
- Held with both hands, but with hands resting on a table. This one provides a nice 45 degrees angle, and it’s comfortable for long sessions (like watching a movie).

I am not excluding that the screen would also be tactile.

What about the keyboard?
It’s hard to imagine interacting with a software keyboard operated from behind the screen, but why not? With the appropriate visual feedback, it seems plausible.

Such a device layout has another advantage: the touch surface doesn’t need to be exactly as big as the screen, it can be dimensioned to work well with standard hands size.

If ever it comes true, remember that you’ve read it here first!

Customers that have purchased the program in the last 6 months (June 1st onwards) are entitled to get a refund. Just email to supportcw@mac.com asking for it.

As the father of the creature, let me do the obituary:
CubeMovie is my first relevant program. With over 400 copies sold and $5000 in sales, I cannot call it a success but it still in the median of what a piece of shareware sells. (Fortunately, my more recent products were designed with more ambition and experience, and are doing better…)

CubeMovie is the first program I ever sold. This encouraged me to continue and write more programs. SimpleMovieX was born six months after CubeMovie, and showed enough potential to grow a business upon: I remember paying a fairly expensive PowerBook G4 in 2004 with CubeMovie and SimpleMovieX sales.

Finally, what sets CubeMovie apart is a little known fact: Under the hood, CubeMovie is a ClockWorks application. The whole program is made of around 400 interconnected “vignettes”, that define the flow of events. CubeMovie was first and foremost written as a “demo” of ClockWorks, a programming environment. But ClockWorks was a failure and CubeMovie was the unexpected debris of the shipwreck.

The picture below is the code that manages the texturing of the 6 faces of the cube: from top to bottom, the 6 picture views of the User Interface that link to 6 parameters objects that link to 6 OpenGL display lists.

The whole source of CubeMovie can be seen here (it’s a pre 1.0 version, the final 4.0.2 version graph was far more complex with over 400 vignettes, but I don’t have a picture in my archives, sorry).

For Windows users, I have recently found a good technique to create a disk image from the damaged disk or card, which is the first step towards recovery of footage.
Note that this can also be useful to Mac users if the disk is not visible in the Finder, but is visible on a Windows PC.

In a nutshell, we use a small utility called dd for Windows that is able to read the raw data of a disk. (From now on, I will just use the word disk, and it can refer to a hard disk, a memory card or a USB drive)

Under the premise that the disk is readable, ie Windows detects it when you plug the disk or insert the card in the reader, “dd for Windows” should be able to create a file with about the size of the disk.

Here is the process, step by step:

http://www.chrysocome.net/downloads/dd-0.5.zip

This program is free and distributed under GPL license. For more information, refer to the product page.

dd --list

And you will get a list of the devices connected to your computer.
Here is what I get for example:

rawwrite dd for windows version 0.5.
Written by John Newbigin
This program is covered by the GPL. See copying.txt for details
Win32 Available Volume Information
\\.\Volume{aef46cf9-3e3d-11de-b8c6-806d6172696f}\
link to \\?\Device\HarddiskVolume3
fixed media
Mounted on \\.\c:

\\.\Volume{aef46cf8-3e3d-11de-b8c6-806d6172696f}\
link to \\?\Device\CdRom0
CD-ROM
Mounted on \\.\d:

\\.\Volume{6f41f4b2-d11a-11de-b318-001d4f88486c}\
link to \\?\Device\Harddisk1\DP(1)0-0+5
removeable media
Mounted on \\.\f:

Don’t be afraid, it’s just a list of the devices connected to your computer.
Here the interesting device is the F:\ volume described as removeable media: this is the card that I want to recover. Take note of the corresponding volume name:
\\.\Volume{6f41f4b2-d11a-11de-b318-001d4f88486c}

This volume name starting with \\.\Volume{ and ending with } will be used in step #6.

dd if=\\.\Volume{6f41f4b2-d11a-11de-b318-001d4f88486c} of=c:\usb.img bs=1M

This command creates a file called c:\usb.img that is a carbon-copy of the damaged disk.
The operation can take a long time. For 1GB, it can take one minute or more. For 120GB, it will take several hours.

Note that you can monitor the size of the c:\usb.img file as it grows from 0 to the size of the disk: It will give you an idea of the progress.

What do I do with the .img file?
Now if everything went fine, you should have a .img with a size similar to the disk capacity.
If the disk still contains footage, the footage must now be inside this file also, and we can do a diagnostic of the file and hopefully, repair it.

For Mac users, Diagnostic and Repair have already been covered in a previous post.
For Windows users, the .img file can now be used to create an extract that will be uploaded to Aero Quartet. This is explained in the Movie Repair Guide in the Windows page.

Version 3.9.2 that runs on Snow Leopard is just a few hours away!

I will have missed the end-of-month deadline by a couple of days, because I had underestimated the changes that Snow Leopard is bringing. Let’s review the main points:

64 bit:
SimpleMovieX cannot compile in 64 bit because legacy QuickTime APIs are not available (only Cocoa QTKit).
For 64-bit apps using legacy QuickTime, a 32-bit process is automatically generated by the OS. Could be what happens in the next major release of SimpleMovieX.
The bottom line is that SimpleMovieX 3.9.2 will ship as a 32-bit Universal binary. Not a big deal.

Intel versus PowerPC:
Snow Leopard only runs on Intel Macs. Older PowerPC models can still run SimpleMovieX from Mac OSX 10.4 (Tiger) or 10.5 (Leopard).
A small problem arises for Snow Leopard users: Some components of SimpleMovieX are still PowerPC binaries, and they will probably not migrate to Intel anytime soon. In Leopard, Rosetta, the PowerPC emulation tool, would transparently take care of this. But Rosetta is not installed by default in Snow Leopard.
Therefore, Snow Leopard users that haven’t installed Rosetta will be invited by SimpleMovieX to do so, otherwise MPEG functionality will not work. I’m referring to MPEG-1 and MPEG-2 here. MPEG4 WILL work.

Supported Operating Systems:
SimpleMovieX 3.9.2 will continue supporting Mac OS X 10.4.11 and higher. There is no intention to drop 10.4 support soon, at least until new major version 4.0 comes out.

Grand Central Dispatch, OpenCL:
SimpleMovieX will take advantage of those technologies passively: GCD and OpenCL will not make SimpleMovieX perform better per se, but the OS and QuickTime can be faster and SimpleMovieX will benefit.
SimpleMovieX will require a major rewrite before it can use them directly. I believe that version 4, a paid upgrade due next year, should really take advantage of the new “state of art”.

QuickTime X:
Here Apple has done a good job confusing everybody. QuickTime X refers to a new player/editor application and also to a new framework.
The application is very limited in editing functionality. If you need anything beyond basic trimming, you will need to install QuickTime 7 application or better, use SimpleMovieX.
Framework-wise, Snow Leopard comes by default with both QuickTime X and QuickTime 7.
SimpleMovieX does not take advantage of the new framework, because of very strong limitations as of 10.6 release. QuickTime X is a work in progress that will need, I predict, 5 years or more to supplant good’ol QuickTime 7.
The bottom line for SimpleMovieX users: It is not necessary to install QuickTime 7 app in Snow Leopard (or to have a QTPro key) to make SimpleMovieX work.

Conclusion: SimpleMovieX 3.9.2 will be equivalent to earlier versions in features and performance. Snow Leopard lays the foundation for the next ten years on the Mac platform, but profound changes are needed in SimpleMovieX to take advantage of it. Version 4.0, a major release due next year, will bring the promise of those amazing new technologies.

Current version 3.9.1 of SimpleMovieX is not prepared to work with Snow Leopard.

Version 3.9.2, a free upgrade for 3.x users, will surface sometime during September, bringing back compatibility with the latest and greatest, ie Snow Leopard.

Tiger and Leopard will continue being supported, whereas Mac OSX 10.3 Panther is no longer supported, version 3.8.1 being the last release working with Panther.

Snow Leopard brings amazing new technologies that can make SimpleMovieX shine. I can think of Grand Central, Open CL, H264 hardware decoding, and QuickTime X.
But to digest all this, SimpleMovieX will require a major rewrite. I believe that version 4, a paid upgrade due next year, should really take advantage of the new “state of art”.

Stay tuned for more info about the future of SimpleMovieX.