NATE: AIC and 24p questions
 

Nate posted, "FCP and iMovie will digitize even 24p using AIC, but will give you media files that are timed at 59.94."

When you say "timed" do you mean it's Item Property was 59.94?

I just captured using AIC in FCP 5. Checking the media it was labeled as 29.97. Which seems like a very wrong number!

The 720p60 carries the 24p using Repeat Flags. I've got to wonder if FCP can do what other NLE do with 24p -- rather than remove frames by reverse 2:3 pulldown -- they simply skip frames when playing. It saves conforming.

----------------------------------------

Just in case it helps anyone. Everyone assumed the HD1/HD10 recorded 72030 and then when it was played on the camercoder -- the analog output circuit doubled each frame to output 720p60.

I now think JVC has always used Repeat Flags. With 720p30 there is one encoded frame plus Repeat Flag. Thus, I think JVC has always used a 720p60 timebase.

All the playback devices were simply following standard MPEG-2 rules. The RF simply caused the last frame to be output again.

That means the HDV/AIC i.LINK capture software must be dropping the RF since we know we get only 30p. But, shouldn't that mean the multiple RFs in 24p should also automatically be dropped and we get 720p24?

Yet, this is not happening. I really can't figure out HOW Apple wrote their software.

Did you check if Apple's MPEG-2 decoder actually might actually play the media with the Media Flags ignored.

Yes. To Quicktime, it is a file with a 59.94 timebase.

Dunno what to tell you. Was it 720p24 you digitized?

QT will play at 24 if it has the right kind of file. If you give it a straight demuxed .m2v from MPEGSTREAMCLIP, it will play at 59.94. If you demux to a "headed" .m2v, the resulting file will play back at 23.98. You can bring that resulting file into a 23.98 HDV timeline, but it will need rendering before it'll play.

It seems to FCP 5, 24p AIC has a timebase of 29.97 which is what it reports after direct i.LINK capture. Thus, it plays perfectly in an AIC 29.97 Sequence, but not in 23.98 and59.94 AIC Sequences.

Cinema Tools is very happy to see the 29.97 number and will do a Batch Conform to 23.98. Now the conformed clips play perfectly in a 23.98 AIC Sequence.

Of course, as you or Tim reported, Cinema tools doesn't do what it should do. It should preserve the PCM audio from the AIC QT file and marry this saved audio to the new 23.98 video. Since it doesn't we get slow audio.

So I do a Batch Export of the AIC files to AIF audio-only files of the same name. Now I conform the AIC clips.

Then a CTRL+OPT drag of a conformed clip brings just the video into the timeline. Now I just drag the AIF clip underneath. Then LINK. Can then drag back to a BIN.

I don't know if I can load only video from an AV clip into the Source window and then ADD an audio-only clip to it. That would be very nice!

I think it is safe to say based on the tests Nate and I did that FCP always ignores the pulldown frames and only digitizes the flagged frames when transcoding into AIC. This is how it works with NTSC 24 Advanced pulldown too. Those pulldown frames are never ever written to disk.

I would say that is a safe assumption considering the 720p30 HDV capture setting works with the HD100. I don't have a HD1 or HD10 so the best way to confirm it is to look at the timecode base on those cameras. Is it 30fps TC or 60fps TC?


I think that it is happening, but it doesn't know how to handle it with sync sound. I imagine what happens is that the transcoder sees a m2t stream at 720P60 with flagged frames, it writes the flagged frames to disk, but the programming hasn't been put in place to determine the proper frame rate - thus the resultant quicktime file defaults to the 59.94 fps frame rate, but it only contains 40% of the frames it used to. The good thing is these are the exact frames we wanted. However, since the clip is now only 40% of the length it should be, the audio is truncated - not compressed. If we were able to find and hack the Capture preset to compress the audio to 120Khz during the capture stage, then we could maintain all the audio for the clip in sync. I had hoped that by turning on the option to digitize audio & video separately would help - but it doesn't function with the AIC digitizer. Nate thought ahead and exported the first 40% of the audio he had to AIF so that he could get a sync reference for the music video performance.

No it doesn't, but MPEG Streamclip does only play the flagged frames.

I'm not sure how you got the 29.97 fps. Nate and I performed the same tests with repeatable results on both FCP v5.0.2 and v5.0.3. My best guess is that you accidentally digitized 720P30 media instead of 720P24, so your resultant clips should have a 29.97 frame rate.

Just so we are on the same page, here is what Nate and I both did.

1. Select "HDV - Apple Intermediate Codec" as the default capture preset.
2. Open "Log & Capture" but now we don't get the usual log & capture window - instead it is just a simple prompt requesting a clip/file name. Enter the name, hit return, and it will automatically start playing the tape and capture separate clips to AIC, breaking them where the start/stop points are in the tape.
3. Hit ESC when you have captured what you want.
4. Confirm frame rate by doing any of the following:
   1. Checking the frame rate column in the bin.
   2. Open the quicktime file(s) from the capture scratch folder and then "get info"
   3. Open with Cinema Tools and click "Clip Analysis"
5. Open Cinema Tools
6. Batch Conform the digitized AIC clips in the capture scratch to 23.98fps.

By the way, Nate and I think that the AIC digitizer is actually just the coding from iMovieHD '05 that was thrown into FCP5 as a bonus. The results are repeatable by using iMovieHD. You can work with the digitized clips the same way in CT by clicking on the project file, open package contents, and then the files will be in the Media folder.
The benefit of using iMovieHD is that you can actually see your clips being written into the bin.

Actually it does EXACTLY what it should. The Batch Conform function is designed for conforming teleciné transferred footage (23.98) back to true 24fps and adjusts the sample rate of the audio at the same time to maintain perfect sync. Avid used to do this by flipping that 1.0/0.99 switch on the Digidesign box. This is a software solution that works well.
So we are just using it to do things like slow motion or this work-around - but it was never designed for this purpose. Since our clips have the flagged frames we want, but are incorrectly playing 250% faster than they should, conforming them to 23.98 works perfectly. The problem is that the audio is also slowed down to around 19.2Khz. Hence - this method only works for M.O.S. footage.

Like I mentioned before, we also did this, but we can only get the first 40% of the audio since the latter 60% is truncated during the digitizing stage.

>>> It was late and I didn't check the entire clip. So we are SOL for sync-sound.

Looks like it's up to my BlackMagic card.

I don't know whether that's a safe assumption to make. Keep in mind that 720/30p is a valid HDV mode, ensconced in the original HDV specification. 720/24p is not. 720/60p is. So to get 720/24p, they carried it within a 60p stream, to keep it HDV-compliant. There's no reason to do that with 30p, as 30p is a recognized, legitimate HDV format.

I'm sure someone could examine a .ts and tell for sure though...

Good point. The advatnge of Repeat Frames in the data stream is that every MPEG device knows what do to. So I can plug an HD1 into any HDTV with FireWire and it automatically repeats the last frame even though it has no idea about 720p30 HDV.

In other words, I think 720p30 is ATSC 720p30. Now maybe saying the timebase was 720p60 is wrong, but what I meant -- and what I think JVC means -- is that with ATSC 720p60 there are no RF. Going to ANY lower frame rate is done by RFs. And, ATSC devices upon seeing the RFs automatically create 720p60.

I think it is also a strong hint 720p60 is comming soon.