In a previous post I learned the hard way that making compilation DVDs with Final Cut from source movies has the unwanted time/disk space baggage of reprocessing, and FC's highly finicky nature about the KHz of the clips. I also learned that QT Pro does a jim-dandy job of snipping out commercials and saving short reference movies for iDVD.
Which brings me to the next challenge. By default iDVD considers separate movie clips dropped into it as, well, separate. Click one and it plays, but at the end it returns to the main menu instead of continuing to the next, the way you'd expect chapters to play on a theatrical DVD. And there's no "play all" option.
In order for iDVD to consider clips as being linear chunks of a sequence, they have to be linear chunks in a sequence when dropped into iDVD. If iDVD doesn't see chapter markers in a file dropped into it, it considers them self-contained, unsubdividable sequences.
If you don't have Final Cut, you've got two options for making chapter markers. Prior to iMovie HD, you had to have QT Pro, a text editor, an understanding of QT's caption markup language, and the patience of a saint. And enough time and disk space to export a separate, self-contained movie of the original movies put together in order. It's time consuming and may crash at the 98% complete point. Oh, and there's a pretty good chance iDVD won't recognize the chapter titles if anything's amiss. Suddenly FC's razorblade icon starts suggesting its other popular connotation.
iMovie HD offers a simpler solution. As before, edit your source clips in QT Pro, save reference movies, and then open a new iMovie project. Drop the reference movies into iMovie's timeline in your preferred order, then click the iDVD button. A list window appears; click each movie clip then click "Add Chapter." Then click "Create iDVD Project" and iMovie does the dirty work for you, silently building a chaptered reference movie and dropping it into a new iDVD project. Main menu title screen with "Play All/Select Chapter" options, and a second page with the default chapter metaphor (e.g. freezeframes of the chapter beginning).
As a test I did this reusing the clips from the last DVD project I built. The first three movie clips came in lickety split... ...then the fourth sprung the dreaded "Importing Files" dropdown, with an import time longer than the clip. I cancelled it and tried the fifth clip. Same result. Why? Is there some "honeymoon" limit of roughly 60 minutes before imports go to hell? I doubt it.
As it so happens the first three clips were 20-minute reference movies saved from original 32-minute movies. The fourth and fifth were 20-minute reference movies saved from the same original 62-minute movie. I suspect iMovie's import speed is proportional to the number of edits from the source movie. Interestingly enough, after import the aspect ratio on the two clips is squashed with black TV-safe margins above and below.
We'll see how the final movies come out. If this technique works I have a vastly improved workflow for my MST3K conversion process.
Unusual note: I was testing how well the H.264 codec performs when I noticed shit-awful levels of flicker. At first I was inclined to blame the codec itself, but when getting info on the samples I saw they had fps rates of 11 and 14 instead of the 29.97 AlchemyTV was told to capture. The clearly visible frame overlap in freeze frames proves it.
So, the question of the day is what's changing the framerate?
Saturday, May 28, 2005
Monday, May 23, 2005
Gentrification
It's one thing to crow about the virtues of designing web sites using XHTML/CSS instead of HTML4 tables and JavaScript. It's another to go back to one of your own Frankenstein jobs and fix it.
The Bert Lauzon exhibit was one of two I inherited midstream from my predecessor, a talented graphic designer named Bob Lunday. Bob set the tone for what exhibits could look like. However, when he left NAU for W.L. Gore in late 1999, Dreamweaver 3 was teh hotness, and Web design was largely a matter of building tables.
The magnifier pane is an excellent example of a concept not ready for the real world. Invariably the demos are on pages which aren't long enough to scroll, so the issue of dynamically calculating the offset of the pane from the thumbnail never comes into play.
Typically when I find a JS widget from someone else, there's a honeymoon period followed by the stark truth of how easily it breaks when just a few basic assumptions in the original design are challenged with real world requirements. Recently a charming little script for automatically checking/unchecking all the boxes in a form met the real-world problem of what happens when half those boxes are divided visually from the other half, but share the same NAME value (e.g. separate fieldsets). The code had to be rewritten to take a container ID and use a different method for collecting the INPUT objects.
Back to the magnifier pane. With the thumbnail in an unknown position, I had to rewrite the code to account for the pane's location. At the time, the 4.0 browsers were dominant. It would be nostalgic to say the differences in the dialects were mostly semantic; the truth is the object models diverged unpleasantly, and the dialects reflected different paradigms. My "force relative position" script in the body onload discovered each thumbnail's coordinates, then repositioned the pane relative to the thumbnail. This was complicated by the limitation that IE 4 only returned the coordinates of an HTML element relative to its container element, not the page, so if the image was in a table (like all of them are in the exhibit), the script had to be modified to take the container ID as well. If IE was detected the table's coordinates were determined instead and then the thumbnail's offset from the table was fudged to create the image coordinates.
In its 2000 incarnation, the magnifier pane breaks in all modern browsers, whose script engines expect DOM models for event capture, object referencing and style property names. This is actually a good thing. The challenge was finding a modernized version of the magnifier pane, since the original author seems to have forsaken it. Thankfully someone at Princeton either wrote or found a fix which cooperates in IE/Moz/Opera/Safari (but not in Konqueror). Its only drawback is that in IE under W2K the pane blanks while you drag it—most likely due to its method of overloading all BODY drag behaviors (thinking like OOP rather than procedural code). Under XP it's fine.
The rest of the Lauzon exhibit still requires reworking. Completed so far:
The Bert Lauzon exhibit was one of two I inherited midstream from my predecessor, a talented graphic designer named Bob Lunday. Bob set the tone for what exhibits could look like. However, when he left NAU for W.L. Gore in late 1999, Dreamweaver 3 was teh hotness, and Web design was largely a matter of building tables.
- Websites were designed in Photoshop, chopped in ImageReady into tables and given over to DW for cleaning up the aftermath.
- JavaScript rollovers were everywhere, along with image preloaders. At a time when most people still had dialup connections I can't explain what we were
smokingthinking. - We were just beginning to figure out that using the LAYER tag wasn't such a good idea.
- CSS was used mainly for link text rollover effects in IE since Netscape wouldn't support it until 6.0 came out, and Netscape 4's CSS model was eight kinds of broken.
- We duplicated everything across every page — scripts, rudimentary CSS, BODY formatting, everything. Possible exception for long script modules.
- JavaScripts were written for Netscape 4 or IE 4, both of which used dialects soon to be obsolete, and browser sniffing and code forking was everywhere. DHTML authors were the only ones working on universal wrapper functions, which as they metastasized from functions into entire libraries, eventually became more of a problem than a solution.
- Most JavaScripts looked more like BASIC-Plus than object-oriented code because conceptually most script authors weren't coming from C++ or Java backgrounds and didn't recognize the potential or good programming practices.
The magnifier pane is an excellent example of a concept not ready for the real world. Invariably the demos are on pages which aren't long enough to scroll, so the issue of dynamically calculating the offset of the pane from the thumbnail never comes into play.
Typically when I find a JS widget from someone else, there's a honeymoon period followed by the stark truth of how easily it breaks when just a few basic assumptions in the original design are challenged with real world requirements. Recently a charming little script for automatically checking/unchecking all the boxes in a form met the real-world problem of what happens when half those boxes are divided visually from the other half, but share the same NAME value (e.g. separate fieldsets). The code had to be rewritten to take a container ID and use a different method for collecting the INPUT objects.
Back to the magnifier pane. With the thumbnail in an unknown position, I had to rewrite the code to account for the pane's location. At the time, the 4.0 browsers were dominant. It would be nostalgic to say the differences in the dialects were mostly semantic; the truth is the object models diverged unpleasantly, and the dialects reflected different paradigms. My "force relative position" script in the body onload discovered each thumbnail's coordinates, then repositioned the pane relative to the thumbnail. This was complicated by the limitation that IE 4 only returned the coordinates of an HTML element relative to its container element, not the page, so if the image was in a table (like all of them are in the exhibit), the script had to be modified to take the container ID as well. If IE was detected the table's coordinates were determined instead and then the thumbnail's offset from the table was fudged to create the image coordinates.
In its 2000 incarnation, the magnifier pane breaks in all modern browsers, whose script engines expect DOM models for event capture, object referencing and style property names. This is actually a good thing. The challenge was finding a modernized version of the magnifier pane, since the original author seems to have forsaken it. Thankfully someone at Princeton either wrote or found a fix which cooperates in IE/Moz/Opera/Safari (but not in Konqueror). Its only drawback is that in IE under W2K the pane blanks while you drag it—most likely due to its method of overloading all BODY drag behaviors (thinking like OOP rather than procedural code). Under XP it's fine.
The rest of the Lauzon exhibit still requires reworking. Completed so far:
- 2-row, 1-column image/caption tables have been changed to 1-cell tables with CAPTION elements (not a perfect solution, but until HTML has rendered caption metadata for image tags this is it).
- JavaScript rollover image buttons are now completely CSS, utilizing a transparent IMG trick I recently developed (and haven't seen duplicated elsewhere). The default button image is a transparent single-pixel GIF stretched to the background image's dimensions; a hover behavior on the link overrides the background image. Cross browser compatible without csshover.
- The remaining table formatting is mostly replaced with CSS and more syntactically meaningful code. Bert Lauzon's diary entries are BLOCKQUOTEs.
- The image of W.W. Bass' classified newspaper advertisement has been given a LONGDESC pointing to a separate web page containing a reasonable simulation in CSS. I haven't seen any formal declarations stating that LONGDESC pages are supposed to avoid any CSS markup, so for now it isn't cheating.
Saturday, May 21, 2005
How not to make DVDs of your favorite TV shows
What I've been doing for close to a year now is capturing shows with AlchemyTV DVR to .MOVs on my hard drive, then editing out commercials in Final Cut Express 1.0.1, exporting .MOV and dropping into iDVD.
For a while it seemed to work great. However, we began to notice that the audio sync was slightly off in a few places. Doing some tech searching it was strongly suggested that drift could be caused by capturing video to your startup HD.
So, we bought a second internal ATA Maxtor and changed all of AlchemyTV's and Final Cut's settings to do nothing with the startup disk and do everything in the second disk. For a while that worked, too, but soon we began to see the same problem in our DVDs.
So, I optimized the second HD before all DVD projects. No go. Out of curiosity I looked at the FC export .MOV (which QT 6 could not play, but QT 7 can) -- the drift was there. In the export. The original .MOVs were fine. So, I experimented with different recording codecs. No dice. Some movies came into FC fine, others came in with noticeable sync problems, even before export.
After bothering FC experts in a forum, they gave several suggestions:
If I needed professional video effects this would be a real problem. But for the home user who's just making DVDs of their favorite shows or dubbing from old VHS, QT Pro is all the tool you need, and you'll avoid an unnecessary extra transcoding before burning.
For a while it seemed to work great. However, we began to notice that the audio sync was slightly off in a few places. Doing some tech searching it was strongly suggested that drift could be caused by capturing video to your startup HD.
So, we bought a second internal ATA Maxtor and changed all of AlchemyTV's and Final Cut's settings to do nothing with the startup disk and do everything in the second disk. For a while that worked, too, but soon we began to see the same problem in our DVDs.
So, I optimized the second HD before all DVD projects. No go. Out of curiosity I looked at the FC export .MOV (which QT 6 could not play, but QT 7 can) -- the drift was there. In the export. The original .MOVs were fine. So, I experimented with different recording codecs. No dice. Some movies came into FC fine, others came in with noticeable sync problems, even before export.
After bothering FC experts in a forum, they gave several suggestions:
- FC isn't meant to work with anything other than pristine DV straight out of a DV-cam.
- QT movies not from DV-cams don't guarantee 48.000KHz recording rates and FC, unlike QT Player, isn't capable of dealing with less than perfection. The irony here is that Linux developers have known for years that consumer Canon DV-cams don't output perfect 48.000 and Apple's had to write code to compensate for it for years.
If I needed professional video effects this would be a real problem. But for the home user who's just making DVDs of their favorite shows or dubbing from old VHS, QT Pro is all the tool you need, and you'll avoid an unnecessary extra transcoding before burning.
Subscribe to:
Posts (Atom)
Posts
