UPDATED 9/15/10...I just tested it and FCP 7.0.3 does successfully retain ORIGINAL CAMERA TIMECODE when transcoding to ProRes! The clips do not reset to zero! This plus the LCPM patch is a welcome step in the right direction! (I have not tested the LCPM and recognition of SD clips...but I will probably leave that to other users for now...John

Here's a paraphrase of what's included in this update...(though there is no specific mention of whether original source timecode is retained or not, I will have to run a test)...LCPM patch seems to be in, recognition of SD files...see below...

Final Cut Pro 7.0.3

Adds real-time compatibility with Sony XDCAM HD422 720p24/p25/p30.
Adds Log and Transfer compatibility for Sony NXCAM MPEG2 SD formats.
Control-G now closes the correct gap in the Timeline under the playhead.
Fixes several issues with closed captioning .scc files and Print to Tape/Video including:
Outputting to AJA Io HD now preserves closed caption data.
When outputting the same sequence multiple times, users can choose different .scc files.
Print to Tape/Video no longer hangs with certain types of .scc data and Snow Leopard.
The speed of importing AVCHD with LPCM audio is now similar to other types of AVCHD imports.
AVCHD thumbnail images in SD are now the correct 4:3 aspect ratio.
XML export now retains the carriage return when working with text and third-party applications.
Several memory fragmentation issues have been resolved.
Localized versions of Final Cut Pro now recognize HDV devices that use the 1080i60/1080i50 FireWire Basic Easy Setups.
Log and Transfer supports ingesting more than one format recorded to the same SD card.
Final Cut Pro will no longer occasionally report tape trouble incorrectly when capturing from a tape source.

Other updates include Motion, Color, and Compressor.

Here's the link: Pro Applications Update 2010-02 (http://support.apple.com/kb/DL949)

YES!!!!!!!!!!!!!!!!!!!!!!!!!! and Thanks for posting!

wonder if they fixed the in/out marker crash issue or the supposed shuttle crash?

I checked out the new update and the AVCHD files come in through L&T retaining the time code. With multi camera it will be a big time saver.

As for the MPEG2 SD Format, You can now bring the MPEG2 files in through L&T. It convert the files to Apple ProRes 422 format. It does not keep the time code. Each clip is still reset to 00:00:00:00. What I used before was StreamClip to convert to a DV Stream then had to render the audio.

The clips now come in and are ready to edit. The only problem I have found so far other than the time code is when you put the spanned clips together, at the end of each clip about 3-5 frames of sound are missing. The video is complete (no missing frames) and matches up fine.

Maybe Apple will fix the time code for SD with the next patch.

so you are saying that when L&T the mpeg 2 SD footage, thats when the missing sound frames occur? I guess the Streamclip option then is solid and still the way for SD?

Steve,

A question for you on HD and SD timecode. If I recall from the manual for the NX5U, the timecode for simul records with HD and SD will be different and will not match with each other. Have you found that to the case?

And yes, I think it's important that the spanned SD clips should not lose frames of audio when joined by Log & Transfer. Hopefully another patch will be coming within the next month or two. I don't anticipate the next big version of Final Cut until closer to the NAB in April of next year (that's just my gut hunch).

For my immediate concerns, it's a big win to get timecode preserved for HD during the transcode to ProRes and to be able to record audio in LPCM on longer projects. And hopefully since Apple solved these, they can take care of the SD dropped audio frames given a bit more time.

Thanks for your reporting back on the SD side of things...as I was about to post a question on this thread asking that very thing.

John

I'm curious has anyone else had different results with the log and transfer of mpeg2 files?

Last night I did a comparison of the same clips in SD format, using MPEG StreamClip and FCP L&T. I put both of the converted clips on the time line and cropped them so I would have one version on the right and the other version on the left (Split Screen) I noticed that the L&T version was slightly reduced even though the size was 100% (Slight Black Boarder). It was also 2 pixels lower than the MPEG StreamClip version, not a big deal if you stay within the same conversion process.

The quality of the clips looked very close. The problem I had was the footage I used was shoot at a Greek reception for a baby shower with the guests dancing. I had the gain set to +12db and used available light, so the footage is a slightly grainy.

For the 7.0.3 update and SD MPEG2 import:

Cons: With the 3 - 5 frames of audio missing, when you are linking clips the drop out of audio is noticeable and with slight reduction in frame size was concerning, Apple almost got it right.

On the plus side, there are less steps to bring the footage into FCP. The format is ready to edit without rendering the audio. As longs as you are shooting short clips the missing frames of audio won't be an issue. For fast turn-around you gain speed.

I feel MPEG StreamClip is still a better solution even though you will need to render the audio before editing. There is no loss of audio and it can stitch the clips together into one large file as if it was recorded that way.

Both versions reset the time code of each clip to 00:00:00:00.

On the AVCHD side, retaining the time code is a winner!

When I get a chance I will shoot SD and HD at the same time and compare the time code on the clips to see if there is a difference or if they hold the same code within the camera playback of the files.

Steve

Have not used 7.03 for SD footage, but it's a real improvement in terms of transcoding AVCHD to ProRes -- faster, no issues with LCPM audio, original timecode carried through. Still a bit unstable tho if you preview footage in the Log & Transfer window while transcoding other clips.

Have updated my blog accordingly Adam Welz's NXCAM Blog (http://adamwelznxcam.wordpress.com)

Thanks John!

Adam