Thursday, February 23, 2012

iMovie '11: deleting rejected clips reduces video quality

The great thing about my home video archive project [1] is that there are always more pitfalls. I suppose it's a bit like golf that way.

In the last few days, for example, I discovered that the 10 or so hours of analog video I'd painfully captured had only one audio channel [2]. Prior to that I figured out that the existence of an Event repository on an external firewire drive was preventing thumbnail generation with new event capture.

Yes, it reminds me of the joys DesqView/QEMM DOS memory management. Be glad you don't know what I mean.

Even better, last night I discovered that iMovie '11s "Move Rejected Clips to Trash" feature destructively degrades archival video quality. Without, I might add, any warning.

Like all video pitfalls, this surprised me. I remember QuickTime Pro was very good at excising bits of DV files [3]; select the region, delete, quickly get a smaller file. Alas, iMovie doesn't work this way.

Instead iMovie decompresses (decodes to lossless) the clip, which in the case of my Analog to Digital capture is the entire file. [4] Then it excises the unwanted segments and it re-compresses to back to DV-25, changing the packaging as well (from .DV to .MOV). Since DV-25 is a lossy form of compression [5] there's a significant quality degradation from removing unwanted clips, such as the trailing frames iMovie creates after my camera's DV stream ends.

Oh joy. Now I get to redo that tape [6].

So why does Apple do this [7]? Probably because nobody seems to have noticed. Even when I knew what to search on Google found only one reference from 2007 [8]...

harder & harder to remove unwanted...: Apple Support Communities

... I can still crop bits from my events and send those bits to the trash BUT doing so converts the underlying DV movies into .MOV files and DOES modify the quality of the video. I'm not sure if it's significantly worse quality, but I can do a side by side comparison of the original DV and the MOV file that iMovie 08 insists on making if I delete bits permanently from my events and there IS a difference...

... However, they get "squeezed" for some reason, as you pointed out, so that when played directly (i.e. from Finder in QuickTime) they get reduced from their real/original 853x480 to a smaller, squished 720x480...

Even in that thread the participants missed that DV (MPEG-2) is lossy compression; the reassurances were misplaced.

Someday I'll have to see what Final Cut Pro X does. iMovie's callous recompression doesn't give me warm and fuzzy feelings. (Admittedly, nothing about Apple gives me warm and fuzzy feelings any more.)

[1] For the rest of the current series over the past week or two, see:

[2] I'd swear one of the capture UIs I used appeared to show stereo. I think the problem was that the Canon STV-250N video cable only looks standard; I think it flips an audio and video input. So one audio was going to the video channel, but since I was using an S-video cable I didn't see this. I'd long ago mixed that cable with others, and it took some detective work and web image study to identify it.
[3] DV-25 technically, though I believe that label conceals a wide variety of messiness including variations in codec version, variations in metadata, variations in sound encoding, differences in 'pixel aspects', interlacing variations and so on. 
[4] Maybe it always does all clips in an Event. I don't know. In this case the Event was a single 10GB clip and it was entirely re-encoded. I also don't know if this continues to happen after the initial DV/MOV reencoding, perhaps iMovie can work with some forms of DV more directly.
[5] Quite lossy by still image standards. It feels comparable to 60% compressed JPEG, so a single re-encoding cycle causes noticeable damage. I have a theory that low compression MPEG-4 (30 Mbps+ data rates) is less lossy than DV, but saying this tends to enrage video "experts" in Apple's Discussion groups.
[6] It looks like I'm going to be running through each A to D conversion an average of 2.5 times. If I could travel back in time two weeks I'd send me to a commercial A to D conversion service.
[7] Aperture does something similar, albeit less obnoxious. Even if you don't edit a JPEG image, if you export it as JPEG Aperture always decompresses and recompresses. There's no intelligent export of the original.
[8] Not the point of this post, but this bit of the thread helps explain why video work is so nasty (more on formats some other day) ...

... QuickTime always reports two dimensions, the native format size — 720x480 — and the playback display size, shown in parenthesis, e.g. "(853x480)". The native size is measured in non-square pixels and the display size in square pixels. (Or is it the other way around?)

.. Throughout the history of QuickTime the playback of DV video has evolved from always displaying it as 720x480 — which confused viewers because the pixel shape of DV caused the video to appeared "stretched" — to adjusting the playback display to 640x480 for 4:3 video and 853x480 for 16:9 video. Sometimes QT doesn't choose the display size we expect, but that shouldn't affect the size or quality of the underlying video. (To force the video to use the aspect ratio we want so it looks right, QuickTime Pro lets us adjust the display size, just like we used to adjust all 720x480 DV to play as 640x480.) ..

at

1 comment:

  1. Unknown14/5/13 8:31 AM

    The same thing happens in iMovie08. I thought they'd have sorted this by now. It's a total pain. Unless someone knows different, the only solution is to avoid rejecting unwanted clips. Also, keep everything on tape (or whatever) and selectively import. It helps enormously if you keep notes on paper of which clips you want to include and avoid importing unwanted stuff..



    ReplyDelete