Month: October 2004

OK – not a real discovery as such – probably well documented elsewhere, but we were chuffed to have found it!

The problem was two-fold. First, capturing footage from a camera needed a pre-set to match the camera. More often than not the sound would be out of sync by the time we got it onto the timeline. Secondly, putting the footage onto the timeline often meant we had to render it before we could edit it. Sigh.

First one was easy-ish. We simply had to understand that the camera was set to capture sound at 32Khz instead of the expected 48Khz. Making a capture preset based on 32Khz sound cured that one (of course, the camera is capable of 48Khz sound, and that will be the first thing I look into on Monday).

The second was a little more tricky. Looking at the footage, some of it went onto the timeline without the need to render, and some didn’t. There was obviously something different between the formats – and yet they all came from DV cams.

Looking more closely, we found that some of the footage was in DV PAL format, and some in DVCPRO PAL format. What on earth is the difference? Doing a little digging around (isn’t the Internet a brilliant thing?) I found this table to explain it. So how did we solve it…?

In the end it was simple – we figured out that the timeline really showed a graphical view of the sequence that we created… so we had to check the sequence pre-sets. What we found was that FCP creates sequences with different formats of DV, and where we imported footage that needed rendering, the sequence we put it into was a different format to the captured file. Easy, innit?

We just changed the sequence to match the file, lo and behold, the red render bars disappeared and off we went!

In fact we could save ourselves a lot of trouble by looking in the asset bin – the formats of the clips are all listed! We should have read the manual, shouldn’t we?

Anyway, Matt has been doing the editing, I’ve been concentrating on the encoding – we are both learning and that’s no bad thing!

Well… here we are at the beginning of a new DVD for Ultralab and Matt and I were trying to find a way to present the footage from all of the summer schools. What we found was that there was a lot of interlacing showing on the films when viewed on a computer.

What the heck is interlacing? It is a good question – and I don’t have a good answer except to say that TV pictures are made up of two ‘fields’ which appear on alternate lines. The TV set shows the first field and then the second, fast enough so that our eyes can’t see the change (although on some older TVs the change is noticeable as a ‘flicker’). On a computer screen, there is no such thing – it shows you the complete picture, but what happens when you show interlaced footage from a camera onto a computer? For the most part it looks OK, but where there is sudden movement the computer shows the first field and then the second field out of sync. Typically this looks like there is a row of ‘mouse teeth’ along the edges of the image and in really bad cases (such as in fast motion) the computer can display a striped ‘ghost’ of a person or object in two places at once. On a TV those ghosts simply look like subtle blurs and the interlacing never shows up.

So how do we deal with this – the DVD will be projected from a computer at the main ‘launch party’ in December, and it is quite likely that it will be viewed more on a computer than a TV, but of course not exclusively. We therefore had to find a way to get the best out of both situations.

We decided that one way around it was to de-interlace the footage. This is risky in some ways, depending on how it is done. If you remove a field, then a TV loses a massive amount of the picture resolution, which is no good. If you remove a field and then duplicate the other, overlaying it on top of the first then it is slightly better, but the very best way would be to use an adaptive de-interlacing method which keeps the vertical resolution by subtly blurring the two fields and joining them to be a single picture… this is similar to the way I understand progressive scan pictures are made (but then, what do I know…?)

So we tried it, and it looked pretty good on the computer screens – razor sharp, in fact, rather than with loads of mouse teeth. So we then built a test DVD and tried it on a range of TVs. In all cases the footage was pin sharp and it looked as if we had cracked it.

But this wasn’t the end – being a total perfectionist I needed to understand the interlacing issue even better, and looked to the Los Angeles Final Cut Pro User Group forum, where I asked the question – how does deinterlaced footage look when shown on a TV. The answer I needed came from a very respected Graeme Nattress (Many thanks Graeme).

Graeme explained to me the processes of deinterlacing, the tools available to do it and what to expect – it is akin to going somewhere towards re-creating a film look on video (which in my mind is no bad thing). I promptly went to nattress.com and bought the film look filter set that Graeme has developed and will now be using that with all of the Summer School clips.

The major down side of all this comes when we go to encode the footage to MPEG2. We are fortunate to have a decent enough hardware encoder (Mediapress Pro from Wired Inc) which works in real time from an output on the camera. However, deinterlacing the footage in Final Cut and then printing it back to a tape on a DV camera re-interlaces it.. D’oh! We can’t then use real time hardware encoding unless I can find a way to go to a camera or deck without the interlace. Instead, we have to go for a QuickTime transcode from DV to MPEG2 – the quality is outstanding, but the time… about 5:1 (which is better than the approximate 10:1 we would get through software alone).

More news about encoding as it arrives…