[Paul Dickin]

[Winston A. Cely] “Apple no longer cares about us! “
Hi
Don’t kid yourself. They never did care (about us).
But this week we were supposed to be in awe of the strikingly simple unibody design elegance – and a huge proportion of the core user-base are distinctly not, over the design-over-function no-FW issue…
That maybe is making a dent in the laser-tooled aluminium-smooth Apple corporate consciousness.

Next year we will no doubt be expected to be in awe of how Snow Leopard will make full use of the new MacBook Pro’s 9600M GT graphics processor for increased render power, whilst the native 9400M chipset will handle the GUI display.
…maybe we will. Maybe not.

Maybe we’ll be more concerned that the legacy codebase of FCS and QuickTime will still be creaking under the demands of providing the required functionality of a 21st century pro app editing suite.

Apple have everything to prove at this point in time. 😉

[Paul Dickin]

[Ben Holmes] “to remove a port… “
Hi
They haven’t ‘removed’ it from the new MacBook – there isn’t enough room to stuff one in.
Its that simple – Jony Ives’ new design was NEVER going to be compromised…
https://images.appleinsider.com/ifixitmbpalum13-2.jpg
From
https://www.appleinsider.com/articles/08/10/16/apples_new_macbook_and_macbook_pro_torn_down_photos.html

[Paul Dickin]

[Ben Holmes] “WHY DROP IT?”
Hi
Because the NVIDEA chipset doesn’t do
FireWire S800T (IEEE 1394c-2006) – FireWire … enhanced to share gigabit Category 5e cable…
automatic negotiation that allows the same port to connect to either IEEE Std 1394 or IEEE 802.3 (Ethernet) devices.”
https://en.wikipedia.org/wiki/FireWire

[Paul Dickin]

Hi
The FW-loss fuss from the video crowd ain’t nothing compared to the music/audio-tech crowd’s howls. 🙁
A lot of it directly to https://www.apple.com/feedback/macbook.html
The audio interface industry is just now by-passing PCIe in favour of FW….

However David Roth Weiss and others here have been saying for months (years) that buying into FW technology for video is investing in an EOL technology. Which I totally agree with.

Apple over the last decade has never been a company that listens to its customers. It is proud of its abilities to take its product range into unimagined territory – where no feedback process could conceivably take them, confident that users will welcome their new-found opportunities…

Apple chucks away technology as freely as it invents – the abandonment of the serial port and floppy disks 10 years ago was just as catastrophic for music hardware/software users. SCSI’s more or less gone gone gone.

Video production Mac users have spent the last 5 years bemoaning the lack of the 4th PCI slot that disappeared with the demise of the G4 tower range. Did Apple listen?

The trouble, this time, is that the dots just don’t join up for us to move on easily. 🙁
USB isn’t a viable alternative for (some) video or (most) audio professionals.
eSATA cable technology is as limiting as SCSI was before it – useable in fixed installations but impossibly inflexible for on-the-move use.
Cabled Gig-Ethernet is beset by old-fashioned/inappropriate protocols for high-bandwidth streaming workflows, and wi-fi is still too primitive.

But. Just as it was about floppies 10 years ago, so today its dead on the money to aim for simple uncluttered mainly-wireless technologies for the average, majority, user-base. I reckon.

We just need high-bandwidth/low latency network protocols to come along and it can all work out for the best for everybody. 🙂

[Paul Dickin]

Hi
As another PAL editor, I edit NTSC from time to time using exactly the same set-up as you, except I use FCP 5.1.4 and a Sony PVM monitor.
I don’t recognise the problem you are describing – everything is fine for me.

You must monitor on a proper NTSC video monitor to see the footage correctly – any sort of PAL60 or NTSC 4.43 monitoring can be compromised by all sorts of scaling artifacts.

[Paul Dickin]

[Bob Flood] “sounds somewhat selfish i know, but what the heck? “
Hi
Not at all… That’s what metadata should be all about.

QuickTime re-wrapped files brought into FCP via Log & Transfer can acquire all sorts of clip/project metadata that couldn’t get included by the older Log & Capture – Cocoa versus Carbon coding presumably?

All that Apple needs to do is get all the native camera-created MXF metadata to come across as well – which presumably requires a Cocoa rewrite of QuickTime.

AND for camera next-generation time/identity/properties stamping (= new SMPTE timecode) to be seen by Apple’s software for what is is, not incompatible with QuickTime’s way of doing it…

Hopefully this is all well in hand, as part of the Snow Leopard ‘optimisation’ scenario.
Otherwise we’re doomed (60s British TV series catch-phrase) 🙁

[Paul Dickin]

Hi
Whist I hear your cry, that is in effect a mere detail… 🙁

Regardless of the actual frame rate, there has been a lack of VITC-like identity-stamping of every frame since tape was eliminated from the editing/post-production workflow.
Frame-stamping is absolutely essential – so the NLE asset database (even more absolutely essential) can recognise footage after its been fragmented by the editing process.

Hitherto the blind-grunt power of computers to do incredibly (mindlessly) boring addition/subtraction processes which create innumerable frame-offset lists – to keep track of the overall edit-decision operation – and render it all into dumb XML project files, has kept the creaky-leaky good ship NLE afloat.

What’s needed going forward – into the sunlight 64-bit tundra of the snow leopard – is a QuickTime/FCS code-base that accommodates:
a) Fundamental, powerful, database structures – to replace inadequate XML project structures, and
b) Powerful frame-based metadata structures to identify all assets, at every stage of any process being applied to any fragment of the larger file.
__________________

[Paul Dickin]

Hi
I’ve had DiskWarrior jinx a project – and give me a load of media asset problems after running it (on an early version of Tiger and FCP 5).
BUT, it wasn’t my project from the outset – and I was already trouble-shooting the FCP red screen of death in this inherited project.

And I had identified some corrupt DV media files with QT Player, and replaced them with proper versions – but running DW at that stage caused me to have to spend another half-day of wheedling out corruption. 😉
Actually I don’t begrudge DW that – because maybe those inherited files were incipiently dodgy…

Since I’ve routinely run 22 or 23 individual eSata or FW800 drives on my G5 Mac since mid-2006 whilst editing (no RAID 0 – once bitten twice shy) I’m fairly highly sensitised to OS X’s start-up/shut-down delays – which can vary considerably depending on the daily disk usage. DW seems to be more necessary with the 6 or 7 FW800 drives.

[Paul Dickin]

Hi
With the clip selected, or double-clicked into the Viewer, Shift-F.

[Paul Dickin]

Hi
Specifically look for clips that have non-standard frame rates. FCP is very sensitive about this – at the render stage.
Cinema Tools can be used to Conform a suspect clip’s frame rate to be correct, or it can be Exported into a new file with the appropriate frame rate.