Treasured is finally out!

October 31st, 2008

That’s a breakthrough in movie repair technology. For the first time, you can preview your damaged files and decide what deserves to be repaired.

It’s early to tell if all the goals of Treasured have been met, but for sure the landscape has changed for me:
Ten to twenty times more people contact me for a movie repair now. Treasured is definitively the hook that my Movie Repair Service needed.
But two thirds of them are not actual customers, they are just playing with the app and uploading a trashed DivX or WMV file.

The remaining third is a mix of my traditional customer base of video professionals, and a new category of customers. By lowering the barrier to request a repair, I’m attracting new types of repairs, new types of files, for which Treasured was not initially designed or optimized.

Bottom line: My claim of 90% accurate diagnostic, 80% with preview, that I religiously checked before Treasured was released, is wrong due to the diversity of movies I’m seeing now.

Google Chrome: Apple’s “Sputnik moment” ?

September 19th, 2008

Remember that Sputnik scene of “The Right Stuff”?

I can imagine some Apple execs running frantically in the hallways and meeting in an underground war room in Cupertino headquarters. In the dim light, they start analyzing Google Chrome features (of lack thereof) and suddenly Steve slams the table with his fist and yells: “Safari is dead if we don’t change the direction now.”

Google Chrome must have been a shock for Apple’s Safari team. Apple developers were probably quietly completing alpha stage for Safari 4.0, and suddenly, bam!

Now Safari must redefine itself, and go in a different direction, and do it fast. SquirrelFish Extreme, announced today, only a few weeks after the original SquirrelFish Javascript engine, is maybe a sign of things starting to move. If SquirrelFish was a leap forward, why announce another leap forward before even releasing it? Because of Chrome, imho.

Every day, I spend a few hours on a Windows machine, and this week I’ve noticed that I’ve stopped using Safari completely. Chrome is my browser of choice in Windows now. A threat for Safari on the Mac, for sure.

Apple will probably not conform with playing catch up, and I’m looking forward to see what exciting stuff there are preparing for January. Or maybe Safari 4.0 has to be delayed, but for good.

Frankenstein’s creature is alive

September 14th, 2008

For the last few days, I’ve been busy writing a new program, code named “Ventilo”, but that could also be called Frankenstein as it’s made out of a dozen of pieces of other programs that I’ve been writing over the last year and half.
Today I’ve made big progress and the creature is finally alive.

it's alive

Where I had twenty programs capable of repairing one type of damaged movies each, now I have one Frankenstein creature capable of previewing them all.

Note that I’m not saying repairing, just previewing. Because what I’ve grown in scope, has come at the cost of feature depth.

I’m happy with that, because it’s exactly what I wanted to do:
Being able to view what is inside a damaged movie file is indeed very important. It’s telling you two things:

  • First, that your beloved footage is still here, latent, waiting for a repair. You can almost touch it.
  • Second, that there’s someone that cares about video professionals. It’s not always a fairy tale, shit happens. And it’s good to know that someone is here to help.

The reason why Ventilo does not repair the movie is a technical one: If getting a computer to analyze the contents of a file and preview a cherry-picked frame is a hard task, it’s an easy one compared to extract all the frames, video and audio, and present them perfectly synchronized, without artefact, in a broadcast quality movie.

Preview is a feature that luckily falls at the tiny intersection of what people wish could be done, and what technically I’m able to do. And it’s also the missing piece of the Movie Repair puzzle because it’s what creates the emotion, the engagement.

Ventilo was born from an intuition:

Every day, a few hundred (unlucky) people discover that an important movie file, because it’s urgent or because it’s a piece of their memories, has been damaged and cannot be open. They seek help in friends, colleagues, Internet forums, and end up searching for a “tool to fix damaged movies” or a “software to repair corrupt film”.

What they find is a dozen of crappy products that will lead them nowhere. The problem is that quality movie repair is delivered as a service, not as a software. But people doesn’t look for a service, it looks like a strange idea.

So how can I let them know, and help them recover their movie?

Enter Ventilo. A free tool that they will easily find and use, and that will tell them the truth about their file:

“No, it can’t be repaired because the file contains only alien data”

— or —

“Yes, it can be fixed, look at the preview… but the repair is a complex task, it can only be done by a video hacker and this service can cost you between x and y.”

Ventilo also facilitates some hardeous tasks, like data extraction and transfer, and saves time both to the customer and to the repair technician.

it's alive

In summary, Ventilo lowers several barriers:
Barrier to discovery (Google will find it), to use (it’s software), to gratification (free preview!), and to engagement (big hope, small time footprint).
Thus enabling many more people to get their file repaired.

As I’m working alone, instead of a specification, I prefer a small set of guidelines that let me decide quickly whether something must, can, or cannot be added to Ventilo.

My guidelines:

  • Tell something interesting about all the files in my “collection” of corrupt movies, and preview 90% of them.
  • Release 1.0 within one month, stable enough.
  • Provide a simple user interface that makes Ventilo feel like a Mac application.
  • Give an emotional touch to the Preview.

Ventilo is far from finished, the user interface work has just started. I’ll share with you in the next days the first screenshots and discuss a couple of interaction design items.

it's alive
click to enlarge

Contact me if you would like to beta-test Ventilo. bjoossen at aeroquartet.com

Teach a man to fish…

September 1st, 2008

(Third installment of my “Movie Repair Guide”, where you’ll learn how a movie can be extracted from a larger file)

repairing movies often gives surprises

When you repair movies, you never know what you can find.
Yesterday I had an old shoe moment while looking for some mountain footage in a corrupt file.
Some obscure AVI Windows file containing this infamous “Download” animation surfaced when I least expected it:


Error text.

Today I’ll teach you to fish, in other words I’ll explain how to rescue movies from inside larger files. It will only work if certain conditions are met, but it’s an exciting experience… that can end with an old shoe. You’ve been warned.

-=-=-

Container Structure Correction is a repair technique that acts upon the container structure data, leaving the media data and the index and tables untouched.
Unlike reindexing or other techniques that need to act on hundreds of audio or video frames, a structure correction is usually a question of few bytes to correct or a misplaced block of data. For this reason, it can be done manually.

If the same correction has to be applied on a collection of files, then maybe it’s worth spending time automating the structure correction.

Most common structure damages and how to fix them:

  • Embedded movie
  • Full movie data, including container, is embedded in a larger file, for example after a data recovery.
    In this case, the data can be extracted and saved with the container suffix and it usually works.

    In this example, we have examined the file with an Hex editor and have found an intact RIFF structure in the middle of a file. Note that the length of the structure 0×49e4 is encoded just after RIFF in 32 bits, big-endian.
    A quick check shows that after 0×49e4+8 bytes, there is suddenly no data, thus confirming that we are into something.

    02a3970: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    02a3980: 0000 0000 0000 0000 0000 0000 0000 0000 ................
    02a3990: 5249 4646 e449 0000 4156 4920 4c49 5354 RIFF.I..AVI LIST
    02a39a0: 2004 0000 6864 726c 6176 6968 3800 0000 ...hdrlavih8...
    02a39b0: 8545 0100 f816 0000 0000 0000 1008 0000 .E..............
    02a39c0: 0500 0000 0000 0000 0100 0000 7c0b 0000 ............|...
    02a39d0: 3c00 0000 3100 0000 0000 0000 0000 0000 <...1...........
    02a39e0: 0000 0000 0000 0000 4c49 5354 d403 0000 ........LIST....
    ..........
    02a8310: b9b9 b9b9 b9b9 b9b9 b9b9 b9b9 b9b9 b9b9 ................
    02a8320: b9b9 b9b9 6964 7831 5000 0000 3030 6462 ....idx1P...00db
    02a8330: 1000 0000 0400 0000 7c0b 0000 3030 6462 ........|...00db
    02a8340: 1000 0000 880b 0000 7c0b 0000 3030 6462 ........|...00db
    02a8350: 1000 0000 0c17 0000 7c0b 0000 3030 6462 ........|...00db
    02a8360: 1000 0000 9022 0000 7c0b 0000 3030 6462 ....."..|...00db
    02a8370: 1000 0000 142e 0000 7c0b 0000 0000 0000 ........|.......
    02a8380: 0000 0000 0000 0000 0000 0000 0000 0000 ................

    By copying this data to a new file and saving with an AVI suffix, we now have a valid movie.
    Make sure you copy exactly the required bytes, starting from the R in RIFF, ending after idx structure, otherwise it won’t work.

  • Multiple moov atoms found, but last one is corrupt
  • When you edit a movie in-place (ie without writing again all the file), some edition softwares just add a new moov container at the end of the file, without bothering to remove older ones. If the file has become corrupt, those old containers can still work.
    The trick consists in finding the moov structures and redirect towards an older one.
    You’ll need an Hex editor and good knowledge of QuickTime file format to do that.

  • Mispositioned blocks of data
  • Files from a data recovery can present defects: contents not matching the file name, truncated files, mashed contents coming from several files, moved or missing blocks.
    As data recovery acts at the lower filesystem level, the data is always presented in blocks, for example exactly 2048 bytes.
    A movie can fail to open because some blocks have been moved, duplicated or missing. The fact have blocks always have a length of 2048 bytes helps to detect and correct those problems. It’s like solving a puzzle and is usually complex.