[Andy Mees]

Vedat , it’s all really just the same thing but getting there by different routes.

You’re taking your encoded 720 source and stretching it out to its true display aspect of 1024 … thats a stretch by a factor of 1.422. If you take my 45 pixel crop of the encoded original and stretch it out by the same factor and that comes to 64 … which is exactly the same as what you have there (1024-960 = 64).

So how you chose to arrive at your 15:9 Anamorphic result is entirely up to you. If to your eye, one method seems to produce visibly cleaner results, then it would seem logical that you go with that one. Either way you’re ending up 15:9 which hopefully means you’re happy 🙂

Best
Andy

[Andy Mees]

Matt

If there is a specific XDCAM related issue at play here then it is certainly also hardware/software conflict specific, as we work with XDCAM HD on dozens of MBP’s every day of the week, 52 weeks a year without any of these problems.

I know thats not the corroboration you were looking for, but its probably worth knowing.

Cheers
Andy

[Andy Mees]

Apologies Vedat, I was using a true 16:9 source hence the different results … with a 16:9 Anamorphic source I see what you’re seeing too.

So, for a 16:9 Anamorphic source the easiest way to figure out the necessary crop is by doing some quick sums. As 720 pixels is the encoded source width, and as that equates to 16 units as per the ratio, then 1 unit is 45 pixels (720/16=45). As you’re looking to create a 15:9 Anamorphic target then you need to reduce your 16:9 Anamorphic source by one of those units of width ie by 45 pixels. That being the case, set the Source Inset (Cropping) to Custom, and then manually enter a Left crop value of 22 and a Right crop value of 23 (or visa versa).

See if that works for you.
Best
Andy

[Andy Mees]

Robert,

Check to see if you have Perian installed … if you do, then you might want to try updating it to the latest version and/or uninstalling it. Then test and see if the issue you’re reporting is resolved.

Cheers
Andy

[Andy Mees]

Well Nick, I must say I’ve never tried it on a G4 specifically but it certainly does work on a G5 which is also a PPC based machine, so yes, I do think the PDZK-P1 software should install and run on your machine. Bottom line, try it and report back.

[Andy Mees]

[walter biscardi] “XDCAM is 1440×1080. We’re using the EX-3 right now for a series. It’s still XDCAM. “

Well, just to take a step back for a moment, XDCAM is a recoding format not a codec. XDCAM cameras and decks can record in many codecs from DVCAM through to MPEG HD 422 … and included amongst them there certainly are some 1440 x 1080 codecs, but there are also full raster 1920 x 1080 codecs (and both are possible with the EX1 and EX3 cameras depending on which setting you choose when you record).

My guess Walter, is that you’re both right. You may very well be using an XDCAM 1440×1080 codec, but the posters who are recommending the EX1 or EX3 as full raster 1080 HD cameras are actually right too.

[Andy Mees]

Thats odd , it works just fine here. I just did a quick test and got exactly what I expected … an anamorphically stretched 15:9 edge cropped 4:3 video (which when shown on a 4:3 TV in its correct aspect would display in its full raster glory with shallow letterbox bars at top and bottom)

What are you seeing there? What settings is your source video reporting in Compressor (look in the A/V Atrributes tab in the Inspector) … and exactly what settings are you using for the target?

[Andy Mees]

that camera shoots SD in an MXF wrapper which is not natively supported in Quicktime
the Sony XDCAM Transfer app will rewrap those MXF files as MOV’s which FCP can then handle natively … and despite what you may have read it DOES work on non intel Macs

if you are looking for a native MXF import solution then you can look at MXF4QT from MXF4Mac

[Andy Mees]

stay with PAL CCIR 601

[Andy Mees]

2. For the SONY XDCAM TRANSFER TOOL software, is there any advantage to using it as a plugin within FCP as opposed to using it stand alone

To posit an alternative theory …

Yes, absolutely there is, although it certainly revolves around ones personal workflow preferences.
The advantage of calling up the transfer tool from within FCP is that it allows direct background import of the media to any open project and it’s this background transfer that really powers the tapeless workflow. With linear based capture methods the NLE is tied up for the duration of the capture process, but with the tapeless ingest enabled through Sony’s XDCAM Transfer, you start editing with the media you have whilst the remaining media transfers in the background as you edit. And as the transferring media becomes available you can incorporate it into your edit without additional manual intervention.

To be fair much of this is still possible when you use XDCAM Transfer as a standalone app, true, but you do have to interact with the Finder to manually update your project with any newly acquired media … and if you wait until all the media is ingested first so that you can drop the folder of clips into your project (in a nice organized bin) then in some respects you have lost much of the advantage of that dynamic background tapeless import process.

I gotta say I do agree that having to sort the ingested media into bins after/during the fact can be an annoyance, but for the organizational fiends amongst us (myself included) an alternative workflow is available. One can make use of FCP’s ability to keep multiple projects open simultaneously, and create a separate project for each source reel. That way transfers can be targeted to their own specific source reel/disc project. Not for everybody, but perhaps a salve for those that can’t abide clips being imported in the first instance to the root level of the project.

As I said its all down to ones personal workflow preferences, but food for thought hopefully.

Cheers
Andy