<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Why Apple should drop Log and Capture from FCP</title>
	<atom:link href="http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/</link>
	<description>Philip Hodgetts</description>
	<lastBuildDate>Fri, 10 Feb 2012 17:23:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Dylan Reeve</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82446</link>
		<dc:creator>Dylan Reeve</dc:creator>
		<pubDate>Fri, 02 Jul 2010 02:45:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82446</guid>
		<description>Terry, 

I have a huge amount of consideration for the fact Steve Jobs is known to be something of a control freak in many ways. And I personally doubt he has any idea what professional post production requires, nor do I think he really cares that much... But I also suspect that a lot of the core team behind FCP do know, and I suspect that Jobs probably doesn&#039;t care enough about FCP to want to force it in any specific direction.

If the decision makers in Apple Pro Apps care about their &#039;pro&#039; users then I can&#039;t imagine tape I/O will go away...</description>
		<content:encoded><![CDATA[<p>Terry, </p>
<p>I have a huge amount of consideration for the fact Steve Jobs is known to be something of a control freak in many ways. And I personally doubt he has any idea what professional post production requires, nor do I think he really cares that much&#8230; But I also suspect that a lot of the core team behind FCP do know, and I suspect that Jobs probably doesn&#8217;t care enough about FCP to want to force it in any specific direction.</p>
<p>If the decision makers in Apple Pro Apps care about their &#8216;pro&#8217; users then I can&#8217;t imagine tape I/O will go away&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dylan Reeve</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82443</link>
		<dc:creator>Dylan Reeve</dc:creator>
		<pubDate>Fri, 02 Jul 2010 02:29:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82443</guid>
		<description>Hey Philip, 

I absolutely understand the potential of enhanced metadata, faces and places and all that (and I will read your linked posts when I get a little more time to take it all in) - but my argument is that retaining tape support doesn&#039;t limit the application&#039;s ability to support all that, it jsut means that media capture from tape will not have any of those metadata fields available.

EDLs, for all their failings, are still the most widely supported way to move essential edit information from one system to another. I can&#039;t track (at least not directly) a lot of the metadata, but I can take a unique source identifier (tape number, or file name) and timecode - enough to get the most important parts of the edit through.

I&#039;m not suggesting that FCP should abandon all hope of wide metadata support in favour of retaining a strictly tape-based system, but I firmly believe that tape-based media can live within that metadata-rich system. It just has (by default anyway) a very narrow subset of metadata (although other tools could expand that metadata).

Again - I can see the benefit in making FCP more independant of a core reliance on tape concepts, but I can&#039;t see any benefit of ridding it of native tape support in the process. In reality even if tape I/O is eliminated entirely FCP will still have to be able to support media with to meagre amount of metadata available from a tape, as it will continue to be captured with outside tools and used. All that would be gained from eliminating it from within the app is the earlier-mention development savings in not porting the capture or output tools.</description>
		<content:encoded><![CDATA[<p>Hey Philip, </p>
<p>I absolutely understand the potential of enhanced metadata, faces and places and all that (and I will read your linked posts when I get a little more time to take it all in) &#8211; but my argument is that retaining tape support doesn&#8217;t limit the application&#8217;s ability to support all that, it jsut means that media capture from tape will not have any of those metadata fields available.</p>
<p>EDLs, for all their failings, are still the most widely supported way to move essential edit information from one system to another. I can&#8217;t track (at least not directly) a lot of the metadata, but I can take a unique source identifier (tape number, or file name) and timecode &#8211; enough to get the most important parts of the edit through.</p>
<p>I&#8217;m not suggesting that FCP should abandon all hope of wide metadata support in favour of retaining a strictly tape-based system, but I firmly believe that tape-based media can live within that metadata-rich system. It just has (by default anyway) a very narrow subset of metadata (although other tools could expand that metadata).</p>
<p>Again &#8211; I can see the benefit in making FCP more independant of a core reliance on tape concepts, but I can&#8217;t see any benefit of ridding it of native tape support in the process. In reality even if tape I/O is eliminated entirely FCP will still have to be able to support media with to meagre amount of metadata available from a tape, as it will continue to be captured with outside tools and used. All that would be gained from eliminating it from within the app is the earlier-mention development savings in not porting the capture or output tools.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Hodgetts</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82421</link>
		<dc:creator>Philip Hodgetts</dc:creator>
		<pubDate>Thu, 01 Jul 2010 23:08:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82421</guid>
		<description>Thanks for the apology Gary. I thought a lot of the commentors went a little personal and I verged close at least once. 

Of course this is my opinion blog. That&#039;s why I started it. That&#039;s what it&#039;s here for. That&#039;s why people read my blog, mostly, because they want the opinion of a 20+ year video vet with nearly 16 years in digital video alone. The opinion of someone who the CIS determined was in the top 3% of their profession (for my green card). The opinion of someone who is actually thinking &quot;big picture&quot; about the industry, rather than looking &quot;around the corner&quot;.

Of course, my curation of articles is subjective. Although I do post contrary positions, such as yesterday&#039;s post about HTML5 not being good enough for YouTube right now. Whereas I hate Flash with a passion (on OS X). There&#039;s no point promoting ideas that I&#039;ve already rejected after deep discussion and consideration. :)

My long term accuracy on predictions is about 80%. I&#039;d say Apple won&#039;t take out L&amp;C from the next version so I guess that would count as a &quot;wrong&quot;. But overall, I expect to be about 80% right about what I write about, long term.

I don&#039;t agree with Terry that Apple are turning FCP into a Prosumer application, and have detailed the reasons in two recent posts: 

http://www.philiphodgetts.com/2010/03/08/what-are-apple-doing-with-final-cut-pro/

http://www.philiphodgetts.com/2010/05/18/why-apple-insider-couldnt-be-more-wrong/

I like to put out thought bombs although ironically this one was not designed to be that. They generally get no comments but when I comment on today&#039;s (for me relatively boring) stuff, and comment about FCP, I get huge numbers of comments.

The production and post production industry is changing. It could be changing dramatically with short notice and I&#039;d like to know what the &quot;new answers&quot; might be. And it seems there is a lot of interest in what I have to say: June 17 I presented to 260 TV Academy members in a professional development session about &quot;Surviving the changing business of Television&quot; and they seemed to find it useful. Up against the Laker&#039;s final.

Two days later I presented in SF on &quot;Grow your production and post production business in any kind of economic circumstances&#039; and &quot;How to Grow and Monetize an audience for your independent project&quot;. They were also well received,nearly a sellout.

So, if you find what you read makes you think, that&#039;s perfect. If you don&#039;t want to, there are lots of blogs that tackle the working week stuff (Shane Ross, Scott Simmons, Oliver Peters, Steve Cohen come to mind immediately) that you might enjoy.

Here you&#039;ll find interesting stuff and sometimes leading edge thinking from one of the few genuine intellectuals thinking about post production.

Cheers

Philip</description>
		<content:encoded><![CDATA[<p>Thanks for the apology Gary. I thought a lot of the commentors went a little personal and I verged close at least once. </p>
<p>Of course this is my opinion blog. That&#8217;s why I started it. That&#8217;s what it&#8217;s here for. That&#8217;s why people read my blog, mostly, because they want the opinion of a 20+ year video vet with nearly 16 years in digital video alone. The opinion of someone who the CIS determined was in the top 3% of their profession (for my green card). The opinion of someone who is actually thinking &#8220;big picture&#8221; about the industry, rather than looking &#8220;around the corner&#8221;.</p>
<p>Of course, my curation of articles is subjective. Although I do post contrary positions, such as yesterday&#8217;s post about HTML5 not being good enough for YouTube right now. Whereas I hate Flash with a passion (on OS X). There&#8217;s no point promoting ideas that I&#8217;ve already rejected after deep discussion and consideration. <img src='http://www.philiphodgetts.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>My long term accuracy on predictions is about 80%. I&#8217;d say Apple won&#8217;t take out L&amp;C from the next version so I guess that would count as a &#8220;wrong&#8221;. But overall, I expect to be about 80% right about what I write about, long term.</p>
<p>I don&#8217;t agree with Terry that Apple are turning FCP into a Prosumer application, and have detailed the reasons in two recent posts: </p>
<p><a href="http://www.philiphodgetts.com/2010/03/08/what-are-apple-doing-with-final-cut-pro/" rel="nofollow">http://www.philiphodgetts.com/2010/03/08/what-are-apple-doing-with-final-cut-pro/</a></p>
<p><a href="http://www.philiphodgetts.com/2010/05/18/why-apple-insider-couldnt-be-more-wrong/" rel="nofollow">http://www.philiphodgetts.com/2010/05/18/why-apple-insider-couldnt-be-more-wrong/</a></p>
<p>I like to put out thought bombs although ironically this one was not designed to be that. They generally get no comments but when I comment on today&#8217;s (for me relatively boring) stuff, and comment about FCP, I get huge numbers of comments.</p>
<p>The production and post production industry is changing. It could be changing dramatically with short notice and I&#8217;d like to know what the &#8220;new answers&#8221; might be. And it seems there is a lot of interest in what I have to say: June 17 I presented to 260 TV Academy members in a professional development session about &#8220;Surviving the changing business of Television&#8221; and they seemed to find it useful. Up against the Laker&#8217;s final.</p>
<p>Two days later I presented in SF on &#8220;Grow your production and post production business in any kind of economic circumstances&#8217; and &#8220;How to Grow and Monetize an audience for your independent project&#8221;. They were also well received,nearly a sellout.</p>
<p>So, if you find what you read makes you think, that&#8217;s perfect. If you don&#8217;t want to, there are lots of blogs that tackle the working week stuff (Shane Ross, Scott Simmons, Oliver Peters, Steve Cohen come to mind immediately) that you might enjoy.</p>
<p>Here you&#8217;ll find interesting stuff and sometimes leading edge thinking from one of the few genuine intellectuals thinking about post production.</p>
<p>Cheers</p>
<p>Philip</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gary</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82388</link>
		<dc:creator>Gary</dc:creator>
		<pubDate>Thu, 01 Jul 2010 18:03:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82388</guid>
		<description>Phillip,

First of all, let me apologize for going over the top with my criticism. You certainly got me riled up, very riled up. And I reacted much more harshly than I should have. It was unprofessional and I feel bad about it.

So again, my apologies to you.

I will offer some constructive, I hope, more professional criticism sans the attitude.

You post opinions on your blog, on a variety of topics, that are based basically on opinion. You will use quotes from other people to back up those opinions, but they are always in support of your position, unbalanced with any information that might differ. That&#039;s cherry picking.

But it&#039;s your blog and you are entitled to say whatever you want.

You used HDV tape as your example of why tape is dead. But that is a bad example to base an argument on. HDV was never anything but an interim format.
HDV was dead the day it arrived. It was a problematic format to fill a temporary gap.

You used HDV and ignored the other more commonly used tape formats for broadcast level work. The life spans of HDCam, HDCam SR, DVCProHD tape and the still ongoing use of standard def formats should have figured in your position.

Terry is right that Apple and Steve Jobs are unpredictable in the Pro Apps department and can&#039;t really be counted on to do the right thing by it&#039;s Pro customers.

But I don&#039;t think a &quot;Post to iTunes&quot; button is coming. At this point Apple won&#039;t even acknowledge 1080i (or 1080 p) as delivery format within the universe of Apple plans. To him 720p with a lot of compression is where the future is at. Job&#039;s latest blog comments about Apple&#039;s position on Blueray cements that. And I think he is out of touch with content providers many of which want even higher resolutions and picture quality, and possibly 3D. It remains to be seen if people will pay Hulu $10 plus whatever other subscription services they would have to pay if they dropped cable tv. Hulu Pro is still only 720p and highly compressed at that.

I respect Terry&#039;s opinion as a facility owner. A fair amount of cynicism towards Apple is to be expected from someone in his position.

For production companies with their own in-house post, feelings run a little different.


Jobs is only one person, albeit an important one, in the world of content creation and delivery. His position is that the only thing consumers care about in media delivery is small mobile platforms and that there is no room in the future for the big screen tv&#039;s customers have been buying these last few years. Plus appropriate content to view on them. Other positions differing from his may find better traction in the marketplace over the long run.


OK, I have to go back to digitizing my next project... from DigiBeta.

Again, apologies.</description>
		<content:encoded><![CDATA[<p>Phillip,</p>
<p>First of all, let me apologize for going over the top with my criticism. You certainly got me riled up, very riled up. And I reacted much more harshly than I should have. It was unprofessional and I feel bad about it.</p>
<p>So again, my apologies to you.</p>
<p>I will offer some constructive, I hope, more professional criticism sans the attitude.</p>
<p>You post opinions on your blog, on a variety of topics, that are based basically on opinion. You will use quotes from other people to back up those opinions, but they are always in support of your position, unbalanced with any information that might differ. That&#8217;s cherry picking.</p>
<p>But it&#8217;s your blog and you are entitled to say whatever you want.</p>
<p>You used HDV tape as your example of why tape is dead. But that is a bad example to base an argument on. HDV was never anything but an interim format.<br />
HDV was dead the day it arrived. It was a problematic format to fill a temporary gap.</p>
<p>You used HDV and ignored the other more commonly used tape formats for broadcast level work. The life spans of HDCam, HDCam SR, DVCProHD tape and the still ongoing use of standard def formats should have figured in your position.</p>
<p>Terry is right that Apple and Steve Jobs are unpredictable in the Pro Apps department and can&#8217;t really be counted on to do the right thing by it&#8217;s Pro customers.</p>
<p>But I don&#8217;t think a &#8220;Post to iTunes&#8221; button is coming. At this point Apple won&#8217;t even acknowledge 1080i (or 1080 p) as delivery format within the universe of Apple plans. To him 720p with a lot of compression is where the future is at. Job&#8217;s latest blog comments about Apple&#8217;s position on Blueray cements that. And I think he is out of touch with content providers many of which want even higher resolutions and picture quality, and possibly 3D. It remains to be seen if people will pay Hulu $10 plus whatever other subscription services they would have to pay if they dropped cable tv. Hulu Pro is still only 720p and highly compressed at that.</p>
<p>I respect Terry&#8217;s opinion as a facility owner. A fair amount of cynicism towards Apple is to be expected from someone in his position.</p>
<p>For production companies with their own in-house post, feelings run a little different.</p>
<p>Jobs is only one person, albeit an important one, in the world of content creation and delivery. His position is that the only thing consumers care about in media delivery is small mobile platforms and that there is no room in the future for the big screen tv&#8217;s customers have been buying these last few years. Plus appropriate content to view on them. Other positions differing from his may find better traction in the marketplace over the long run.</p>
<p>OK, I have to go back to digitizing my next project&#8230; from DigiBeta.</p>
<p>Again, apologies.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Terence Curren</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82322</link>
		<dc:creator>Terence Curren</dc:creator>
		<pubDate>Thu, 01 Jul 2010 05:18:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82322</guid>
		<description>You folks are cracking me up. I had a conversation with Philip about where I see the Apple road map going, and it runs into a passionate debate about trying to hang on to the past. 

Okay, you think Steve Jobs gives a crap about what you think about your old media formats. Check this out:
http://www.macrumors.com/2010/06/30/steve-jobs-suggests-blu-ray-not-coming-to-mac-anytime-soon/

That&#039;s Steve Jobs. He is 6 steps into the future and running a huge company that is working towards being the ultimate media engine for the planet. And you honestly believe he cares about you being able to capture from a beta SP tape into FCP?

Get ready for iCut Pro boys and girls. With one huge &quot;Post to iTunes&quot; button prominently displayed in the center of the screen. And yes, that will replace any tape I/O. 

( I know nothing of Apple&#039;s plans, this is conjecture, please don&#039;t firebomb my house or send the Apple police after me)

Terence (knows nothing of Apple&#039;s future, only conjecture) Curren

PS: Did I mention that I personally know nothing of Apple&#039;s future and am just guessing based on outside indicators. If I&#039;m correct, please don&#039;t send the Apple police after me....</description>
		<content:encoded><![CDATA[<p>You folks are cracking me up. I had a conversation with Philip about where I see the Apple road map going, and it runs into a passionate debate about trying to hang on to the past. </p>
<p>Okay, you think Steve Jobs gives a crap about what you think about your old media formats. Check this out:<br />
<a href="http://www.macrumors.com/2010/06/30/steve-jobs-suggests-blu-ray-not-coming-to-mac-anytime-soon/" rel="nofollow">http://www.macrumors.com/2010/06/30/steve-jobs-suggests-blu-ray-not-coming-to-mac-anytime-soon/</a></p>
<p>That&#8217;s Steve Jobs. He is 6 steps into the future and running a huge company that is working towards being the ultimate media engine for the planet. And you honestly believe he cares about you being able to capture from a beta SP tape into FCP?</p>
<p>Get ready for iCut Pro boys and girls. With one huge &#8220;Post to iTunes&#8221; button prominently displayed in the center of the screen. And yes, that will replace any tape I/O. </p>
<p>( I know nothing of Apple&#8217;s plans, this is conjecture, please don&#8217;t firebomb my house or send the Apple police after me)</p>
<p>Terence (knows nothing of Apple&#8217;s future, only conjecture) Curren</p>
<p>PS: Did I mention that I personally know nothing of Apple&#8217;s future and am just guessing based on outside indicators. If I&#8217;m correct, please don&#8217;t send the Apple police after me&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ripvanmarlowe</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82312</link>
		<dc:creator>Ripvanmarlowe</dc:creator>
		<pubDate>Thu, 01 Jul 2010 01:49:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82312</guid>
		<description>I agree with Dylan, multiple vendors for I/O just screams compatibility issues, that&#039;s why Avid&#039;s capture tool is so awesome - only Avid make their I/O boxes.  

Every single one of the broadcasters we deliver to in the UK INSIST on tape-based deliverables.  This is the BBC, ITV, Channel 4, MTV, amongst others.  The BBC requires all high def programming to be mastered on to HDCAM SR.  We certainly deal with file-based productions but ALL of them must be output to tape if they are to be broadcast.  90% of everything we do (and we are a large post production house encompassing offline, online, grading, audio post which deals with primetime, mainstream national and international programming) comes in on tape, and a lot of that is still digibeta, it&#039;s still very much in use, to suggest it&#039;s dying seems incredibly premature when we are seeing absolutely no decline in tape-originated productions (if our 15 digibeta machines, 2 HDCAM machines and 2 HDCAM SR machines are dead by 2012 - not to mention all our beta SPs, D2s, D5s etc - then we are in serious trouble!).  The thought that i couldn&#039;t just open up my avid or FCP and go to capture seems ridiculously backwards.  Why on earth wouldn&#039;t you want that level of intergration in your editing product?  

However, if the rumours are true and the next version of FCP will be &quot;dumbed down&quot; as it were to target the prosumer market then getting rid of log and capture would make sense.  Just don&#039;t expect it to win any fans from the professional market and start waving goodbye to that supposed 51%+ market share (i&#039;d like to know how that figure was arrived at as most broadcast post houses i know of tend to favour Avid, especially when it comes to large scale productions requiring multiple editors and shared storage - but that&#039;s a whole other FCP ball ache).  

And what&#039;s all this about tapes not having metadata?  They have timecode and a little barcoded sticker with their tape number on it! (if you take your tapes seriously and seeing as we are talking about professional editing applications i&#039;m sure we all do!)  That&#039;s all you need to identify media.  I have a timecode and when i capture my clips i add roll number and designate a workspace to capture onto - any important metadata that i need is created by me at the capture stage.  Now i have a clip with timecode, tape number, storage location, along with various other details (media type, resolution, clip length, number of audio tracks etc) and this is more than enough information for me to effectively find the media or track it back through online to offline and relink if i need to.

Without a tape based master i start to get nervous.  What if a filename gets changed?  What if someone accidentally deletes a file? what if you have more than one shift working on it and someone stores the media in a directory and doesn&#039;t tell the next shift where they put it?  Being able to capture from tape provides a comforting visual reminder that if you blow away media by accident then all is not lost.  I don&#039;t need 3 hard drives to feel safe all i need is a little red tab pushed to its &quot;In&quot; position to know i won&#039;t blow a hole in my master.  This may sound like &quot;old thinking&quot; but until hard drives can last for decades without failing then there will always be a place for tape (just type &quot;tape is alive and kicking&quot; into google and open the sony PDF).  I don&#039;t know anyone seriously archiving onto a Lacie drive and thinking it will be ok.  FCP is the least streamlined and most clunky of the two big players (IMHO - not their fault, Avid have been around for yonks) and the last thing they should be doing is removing basic functionality that, i would dare to say, all editors expect to come as standard.  Adding another layer of complexity with third party capture just seems whimsical.</description>
		<content:encoded><![CDATA[<p>I agree with Dylan, multiple vendors for I/O just screams compatibility issues, that&#8217;s why Avid&#8217;s capture tool is so awesome &#8211; only Avid make their I/O boxes.  </p>
<p>Every single one of the broadcasters we deliver to in the UK INSIST on tape-based deliverables.  This is the BBC, ITV, Channel 4, MTV, amongst others.  The BBC requires all high def programming to be mastered on to HDCAM SR.  We certainly deal with file-based productions but ALL of them must be output to tape if they are to be broadcast.  90% of everything we do (and we are a large post production house encompassing offline, online, grading, audio post which deals with primetime, mainstream national and international programming) comes in on tape, and a lot of that is still digibeta, it&#8217;s still very much in use, to suggest it&#8217;s dying seems incredibly premature when we are seeing absolutely no decline in tape-originated productions (if our 15 digibeta machines, 2 HDCAM machines and 2 HDCAM SR machines are dead by 2012 &#8211; not to mention all our beta SPs, D2s, D5s etc &#8211; then we are in serious trouble!).  The thought that i couldn&#8217;t just open up my avid or FCP and go to capture seems ridiculously backwards.  Why on earth wouldn&#8217;t you want that level of intergration in your editing product?  </p>
<p>However, if the rumours are true and the next version of FCP will be &#8220;dumbed down&#8221; as it were to target the prosumer market then getting rid of log and capture would make sense.  Just don&#8217;t expect it to win any fans from the professional market and start waving goodbye to that supposed 51%+ market share (i&#8217;d like to know how that figure was arrived at as most broadcast post houses i know of tend to favour Avid, especially when it comes to large scale productions requiring multiple editors and shared storage &#8211; but that&#8217;s a whole other FCP ball ache).  </p>
<p>And what&#8217;s all this about tapes not having metadata?  They have timecode and a little barcoded sticker with their tape number on it! (if you take your tapes seriously and seeing as we are talking about professional editing applications i&#8217;m sure we all do!)  That&#8217;s all you need to identify media.  I have a timecode and when i capture my clips i add roll number and designate a workspace to capture onto &#8211; any important metadata that i need is created by me at the capture stage.  Now i have a clip with timecode, tape number, storage location, along with various other details (media type, resolution, clip length, number of audio tracks etc) and this is more than enough information for me to effectively find the media or track it back through online to offline and relink if i need to.</p>
<p>Without a tape based master i start to get nervous.  What if a filename gets changed?  What if someone accidentally deletes a file? what if you have more than one shift working on it and someone stores the media in a directory and doesn&#8217;t tell the next shift where they put it?  Being able to capture from tape provides a comforting visual reminder that if you blow away media by accident then all is not lost.  I don&#8217;t need 3 hard drives to feel safe all i need is a little red tab pushed to its &#8220;In&#8221; position to know i won&#8217;t blow a hole in my master.  This may sound like &#8220;old thinking&#8221; but until hard drives can last for decades without failing then there will always be a place for tape (just type &#8220;tape is alive and kicking&#8221; into google and open the sony PDF).  I don&#8217;t know anyone seriously archiving onto a Lacie drive and thinking it will be ok.  FCP is the least streamlined and most clunky of the two big players (IMHO &#8211; not their fault, Avid have been around for yonks) and the last thing they should be doing is removing basic functionality that, i would dare to say, all editors expect to come as standard.  Adding another layer of complexity with third party capture just seems whimsical.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Hodgetts</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82309</link>
		<dc:creator>Philip Hodgetts</dc:creator>
		<pubDate>Thu, 01 Jul 2010 00:20:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82309</guid>
		<description>Actually Media Composer had huge problems with non-tape workflows until they re-achitected and added in AMA. Architecture matters.

As I design metadata-based tools I can see clear distinctions in the way I&#039;d design an app for tape (reel and TC) to one that&#039;s designed to take advantage of &quot;real&quot; metadata, and do things with it.

That you reference ELDs and other interchange formats, does make me wonder about how deeply you understand metadata, sorry.

As for your last paragraph, as a programmer and (somewhat former) editor, I can see how retaining tape support compromises a truly metadata-driven application simply because, by comparison with what the app would be doing with metadata, any tape source would be crippled.

And that&#039;s not an elegant, S. Jobs approved approach. See http://gizmodo.com/5575412/apple-design-vs-apple-engineering for what I mean by elegance :)

If media that comes in from non-tape sources is automatically having faces and places identified, voice transcribed and summarized into keywords ahead of the creative work of the editor; and another source (tape) has none of that, it&#039;s not an elegant design or engineering solution.

If you are interested in metadata (in a real sense, not to just say you &quot;understand on a broad level&quot; then can I refer you to:
http://www.philiphodgetts.com/2009/06/05/i-think-theres-a-sixth-type-of-metadata/
http://www.philiphodgetts.com/2009/06/01/what-is-the-fifth-type-of-metadata/ which references the original four I identified early 2009.

Plus, if you want to understand my vision for where it&#039;s going in the future, then the Mundane and Magic Future of Metadata article in the free Supermeet Magazine http://supermeet.com/supermag/index.html will help.

thanks all for the Conversation it would seem that Apple would need to be &quot;very brave&quot; or at least careful in how they handle the (eventual, if not next release) drop of tape. This is my last post on this thread.

Interestingly, the same topic generated well over 100 emails at the Final Cut Pro yahoo group. By the time we got close to 100, some of the comments started to realize that a) tape capture is hardly integrated in any NLE - it always sits off to the side; and b) as long as we could capture tape in an elegant way (batch capture projects) then a changed approach might be good.

Thanks again for the conversation. I conceed! It&#039;s too early to drop tape support but then I never said tape support should go away. Just not be written by Apple.

Cheers all

Philip</description>
		<content:encoded><![CDATA[<p>Actually Media Composer had huge problems with non-tape workflows until they re-achitected and added in AMA. Architecture matters.</p>
<p>As I design metadata-based tools I can see clear distinctions in the way I&#8217;d design an app for tape (reel and TC) to one that&#8217;s designed to take advantage of &#8220;real&#8221; metadata, and do things with it.</p>
<p>That you reference ELDs and other interchange formats, does make me wonder about how deeply you understand metadata, sorry.</p>
<p>As for your last paragraph, as a programmer and (somewhat former) editor, I can see how retaining tape support compromises a truly metadata-driven application simply because, by comparison with what the app would be doing with metadata, any tape source would be crippled.</p>
<p>And that&#8217;s not an elegant, S. Jobs approved approach. See <a href="http://gizmodo.com/5575412/apple-design-vs-apple-engineering" rel="nofollow">http://gizmodo.com/5575412/apple-design-vs-apple-engineering</a> for what I mean by elegance <img src='http://www.philiphodgetts.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>If media that comes in from non-tape sources is automatically having faces and places identified, voice transcribed and summarized into keywords ahead of the creative work of the editor; and another source (tape) has none of that, it&#8217;s not an elegant design or engineering solution.</p>
<p>If you are interested in metadata (in a real sense, not to just say you &#8220;understand on a broad level&#8221; then can I refer you to:<br />
<a href="http://www.philiphodgetts.com/2009/06/05/i-think-theres-a-sixth-type-of-metadata/" rel="nofollow">http://www.philiphodgetts.com/2009/06/05/i-think-theres-a-sixth-type-of-metadata/</a><br />
<a href="http://www.philiphodgetts.com/2009/06/01/what-is-the-fifth-type-of-metadata/" rel="nofollow">http://www.philiphodgetts.com/2009/06/01/what-is-the-fifth-type-of-metadata/</a> which references the original four I identified early 2009.</p>
<p>Plus, if you want to understand my vision for where it&#8217;s going in the future, then the Mundane and Magic Future of Metadata article in the free Supermeet Magazine <a href="http://supermeet.com/supermag/index.html" rel="nofollow">http://supermeet.com/supermag/index.html</a> will help.</p>
<p>thanks all for the Conversation it would seem that Apple would need to be &#8220;very brave&#8221; or at least careful in how they handle the (eventual, if not next release) drop of tape. This is my last post on this thread.</p>
<p>Interestingly, the same topic generated well over 100 emails at the Final Cut Pro yahoo group. By the time we got close to 100, some of the comments started to realize that a) tape capture is hardly integrated in any NLE &#8211; it always sits off to the side; and b) as long as we could capture tape in an elegant way (batch capture projects) then a changed approach might be good.</p>
<p>Thanks again for the conversation. I conceed! It&#8217;s too early to drop tape support but then I never said tape support should go away. Just not be written by Apple.</p>
<p>Cheers all</p>
<p>Philip</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dylan Reeve</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82303</link>
		<dc:creator>Dylan Reeve</dc:creator>
		<pubDate>Wed, 30 Jun 2010 23:41:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82303</guid>
		<description>I think I have a pretty solid understanding of metadata on a broad level. What specific implementations might be with various formats, well I&#039;m not too concerned at the moment. Metadata can express many things - that every clip may not have all available metadata doesn&#039;t limit other clips from having more, or the application from tracking more.

As I said Avid Media Composer already offers strong metadata support (although much of it can&#039;t yet be used in ways it might later) without having to limit support for tape in anyway. And it&#039;s support for tape doesn&#039;t seem to limit it&#039;s ability to track metadata at all.

Even in the system you propose FCP will still have to be able to deal with tape-originated media, even if it&#039;s been captured with an outside tool. And presumably it should still maintain the ability to create EDLs and other standard interchange formats from selected metadata when necessary.

Supporting tape and being based upon tape-based workflows are not the same. The fact that FCP is reliant on various tape-based conventions at the moment is not due to it&#039;s support for tape, but due to design. It can continue to retain strong tape support while becoming a more versatile application for other workflows.

I still can&#039;t understand, as a programmer or an editor, how retaining native tape support will in any way limit versatility in regard to other applications.</description>
		<content:encoded><![CDATA[<p>I think I have a pretty solid understanding of metadata on a broad level. What specific implementations might be with various formats, well I&#8217;m not too concerned at the moment. Metadata can express many things &#8211; that every clip may not have all available metadata doesn&#8217;t limit other clips from having more, or the application from tracking more.</p>
<p>As I said Avid Media Composer already offers strong metadata support (although much of it can&#8217;t yet be used in ways it might later) without having to limit support for tape in anyway. And it&#8217;s support for tape doesn&#8217;t seem to limit it&#8217;s ability to track metadata at all.</p>
<p>Even in the system you propose FCP will still have to be able to deal with tape-originated media, even if it&#8217;s been captured with an outside tool. And presumably it should still maintain the ability to create EDLs and other standard interchange formats from selected metadata when necessary.</p>
<p>Supporting tape and being based upon tape-based workflows are not the same. The fact that FCP is reliant on various tape-based conventions at the moment is not due to it&#8217;s support for tape, but due to design. It can continue to retain strong tape support while becoming a more versatile application for other workflows.</p>
<p>I still can&#8217;t understand, as a programmer or an editor, how retaining native tape support will in any way limit versatility in regard to other applications.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82301</link>
		<dc:creator>Philip</dc:creator>
		<pubDate>Wed, 30 Jun 2010 22:53:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82301</guid>
		<description>Thank you for your well thought-out polite comment.

Philip</description>
		<content:encoded><![CDATA[<p>Thank you for your well thought-out polite comment.</p>
<p>Philip</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mitch Ives</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82283</link>
		<dc:creator>Mitch Ives</dc:creator>
		<pubDate>Wed, 30 Jun 2010 17:20:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82283</guid>
		<description>Okay, I&#039;m going to go with the old Charlie Chan line...  &quot;ahhh son&#039;s question is ahh like TV set on honeymoon... ahh not ah necessary&quot;.

First off, tape is not dead. Second there a millions of hours of footage on tape that will need to be accessed. They said the same thing about betaSP until somebody pointed out that 2 million hours of historically significant footage is still on betaSP tape.

As to the notion that we can use a third party app, sorry but no again. I have a ton of FCP project files with the footage painstakingly logged in FCP. I want to be able to re-digitize it whenever I want to.

Third, I don&#039;t buy the Apple is smart argument. Apple blew when they eliminated any Mac with more than 3 slots and chased everybody to the PC for video editing for many years. Removing the DVD drive in the Macbook Air has rendered it a highly unsuccessful product in terms of sales numbers. Now we have a new iPhone that has reception problems when you hold it. Great, at least they are posting to hire some antenna engineers.

The bottom line, this would be unwise and has NO upside and considerable downside. I.E. it&#039;s a bad investment...</description>
		<content:encoded><![CDATA[<p>Okay, I&#8217;m going to go with the old Charlie Chan line&#8230;  &#8220;ahhh son&#8217;s question is ahh like TV set on honeymoon&#8230; ahh not ah necessary&#8221;.</p>
<p>First off, tape is not dead. Second there a millions of hours of footage on tape that will need to be accessed. They said the same thing about betaSP until somebody pointed out that 2 million hours of historically significant footage is still on betaSP tape.</p>
<p>As to the notion that we can use a third party app, sorry but no again. I have a ton of FCP project files with the footage painstakingly logged in FCP. I want to be able to re-digitize it whenever I want to.</p>
<p>Third, I don&#8217;t buy the Apple is smart argument. Apple blew when they eliminated any Mac with more than 3 slots and chased everybody to the PC for video editing for many years. Removing the DVD drive in the Macbook Air has rendered it a highly unsuccessful product in terms of sales numbers. Now we have a new iPhone that has reception problems when you hold it. Great, at least they are posting to hire some antenna engineers.</p>
<p>The bottom line, this would be unwise and has NO upside and considerable downside. I.E. it&#8217;s a bad investment&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip Hodgetts</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82281</link>
		<dc:creator>Philip Hodgetts</dc:creator>
		<pubDate>Wed, 30 Jun 2010 16:47:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82281</guid>
		<description>If the architecture remains based on reel and TC then it can&#039;t be based on modern metadata. This has been one of the biggest problems all NLEs have had moving away from tape. Tape metadata is limiting (and limited to Timecode). Any metadata that has to be entered is less valuable than metadata we don&#039;t enter.

And metadata is going to be doing things you probably can&#039;t imagine (although I tried in my SuperMag 4 article The Mundane and Magic Future of Metadata).

If we must continue with an architecture int he application that focuses on reel name and TC, when there are more complex metadata structures required, I think we&#039;lll fail to realize the potential of modern metadata.

i guess it could be included as a sort of second class metadata. You can&#039;t automatically synchronize audio and video like we do with Sync-N-Link with tape-only metadata. If we could get the date stamp out of the BWF it would be even better. Sync-N-Lnk saves a lot of production time for quite a number of shows (some are mentioned on the product page)

If it wasn&#039;t for time stamped words in media files then our next product wouldn&#039;t work. 

Apple have been working on robust metadata for FCP since 5.1.2 as you can read in my previous writings on the subject.

Without disrespect, your response does suggest some gaps in your knowledge about metadata and what Apple have already been doing. I expect that the next release of FCP will make Matchback Magic obsolete. (It&#039;s based on QT metadata and makes FCP media bulletproof through offline or proxy workflows).

Philip</description>
		<content:encoded><![CDATA[<p>If the architecture remains based on reel and TC then it can&#8217;t be based on modern metadata. This has been one of the biggest problems all NLEs have had moving away from tape. Tape metadata is limiting (and limited to Timecode). Any metadata that has to be entered is less valuable than metadata we don&#8217;t enter.</p>
<p>And metadata is going to be doing things you probably can&#8217;t imagine (although I tried in my SuperMag 4 article The Mundane and Magic Future of Metadata).</p>
<p>If we must continue with an architecture int he application that focuses on reel name and TC, when there are more complex metadata structures required, I think we&#8217;lll fail to realize the potential of modern metadata.</p>
<p>i guess it could be included as a sort of second class metadata. You can&#8217;t automatically synchronize audio and video like we do with Sync-N-Link with tape-only metadata. If we could get the date stamp out of the BWF it would be even better. Sync-N-Lnk saves a lot of production time for quite a number of shows (some are mentioned on the product page)</p>
<p>If it wasn&#8217;t for time stamped words in media files then our next product wouldn&#8217;t work. </p>
<p>Apple have been working on robust metadata for FCP since 5.1.2 as you can read in my previous writings on the subject.</p>
<p>Without disrespect, your response does suggest some gaps in your knowledge about metadata and what Apple have already been doing. I expect that the next release of FCP will make Matchback Magic obsolete. (It&#8217;s based on QT metadata and makes FCP media bulletproof through offline or proxy workflows).</p>
<p>Philip</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dylan Reeve</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82240</link>
		<dc:creator>Dylan Reeve</dc:creator>
		<pubDate>Wed, 30 Jun 2010 10:46:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82240</guid>
		<description>It&#039;s taken me a while to get back to you - I&#039;ve been very busy at work capturing from- and outputting to- tape... :)

There&#039;s nothing mutually exclusive about file-based and tape-based metadata support. The nature of metadata as it exists is barely more than key/value pairs. For tape the metadata keys tracked are likely to be &#039;timecode&#039; (maybe a few of them) and &#039;reel&#039; or &#039;tape&#039;. Of course there are more than that - and even some more that are available directly from the tape.

Take Avid Media Composer for example - as far as I can tell it has the best metadata support currently available for professional formats. It can track and display most, if not all, metadata from supported formats. Nothing about it&#039;s ability to support tape (very well) inhibits that.

FCP has a lot of problems and issues that hold it back in terms of strong metadata support for all formats - and I beleive all of those problems arise from it&#039;s core reliance on Quicktime, a toolset that was never designed to do the things a professional NLE requires.

The current Log and Capture tool is very poorly implemented and barely seems to have changed since I first used it 10 years ago, so if Apple are to take a good look at the whole of the application then I hope that better tape I/O is the end result.

The only benefit I can see from dropping log and capture, and the only one you seem to have put forward, is a saving in development cost for not having to write the code.

Whereas the costs to FCP in losing the Log and Capture (and presumably Edit to Tape) functionality seem very significant, even if only for a smaller part of their market. It&#039;s a substantial lose of functionality making it much harder to incorporate into many post-production environments. In fact I suspect the lack of these features and reliance on unspecified third-party tools would eliminate it entirely in many people&#039;s purchasing decisions.

Simple things I do EVERY DAY would be much more difficult if tape I/O were not directly incorporated into my NLE. Insert edits into a master would be much more difficult, as just one example.

So Philip, here&#039;s my question: Aside from cost savings for development time, what could Apple possibly have to gain from the elimination of these core features? Commercially or in functionality.</description>
		<content:encoded><![CDATA[<p>It&#8217;s taken me a while to get back to you &#8211; I&#8217;ve been very busy at work capturing from- and outputting to- tape&#8230; <img src='http://www.philiphodgetts.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p>There&#8217;s nothing mutually exclusive about file-based and tape-based metadata support. The nature of metadata as it exists is barely more than key/value pairs. For tape the metadata keys tracked are likely to be &#8216;timecode&#8217; (maybe a few of them) and &#8216;reel&#8217; or &#8216;tape&#8217;. Of course there are more than that &#8211; and even some more that are available directly from the tape.</p>
<p>Take Avid Media Composer for example &#8211; as far as I can tell it has the best metadata support currently available for professional formats. It can track and display most, if not all, metadata from supported formats. Nothing about it&#8217;s ability to support tape (very well) inhibits that.</p>
<p>FCP has a lot of problems and issues that hold it back in terms of strong metadata support for all formats &#8211; and I beleive all of those problems arise from it&#8217;s core reliance on Quicktime, a toolset that was never designed to do the things a professional NLE requires.</p>
<p>The current Log and Capture tool is very poorly implemented and barely seems to have changed since I first used it 10 years ago, so if Apple are to take a good look at the whole of the application then I hope that better tape I/O is the end result.</p>
<p>The only benefit I can see from dropping log and capture, and the only one you seem to have put forward, is a saving in development cost for not having to write the code.</p>
<p>Whereas the costs to FCP in losing the Log and Capture (and presumably Edit to Tape) functionality seem very significant, even if only for a smaller part of their market. It&#8217;s a substantial lose of functionality making it much harder to incorporate into many post-production environments. In fact I suspect the lack of these features and reliance on unspecified third-party tools would eliminate it entirely in many people&#8217;s purchasing decisions.</p>
<p>Simple things I do EVERY DAY would be much more difficult if tape I/O were not directly incorporated into my NLE. Insert edits into a master would be much more difficult, as just one example.</p>
<p>So Philip, here&#8217;s my question: Aside from cost savings for development time, what could Apple possibly have to gain from the elimination of these core features? Commercially or in functionality.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Wolfmeyer</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82203</link>
		<dc:creator>Dan Wolfmeyer</dc:creator>
		<pubDate>Wed, 30 Jun 2010 04:33:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82203</guid>
		<description>My more thought out and lengthy response to all of this: http://bit.ly/9MqnyG</description>
		<content:encoded><![CDATA[<p>My more thought out and lengthy response to all of this: <a href="http://bit.ly/9MqnyG" rel="nofollow">http://bit.ly/9MqnyG</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gary</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82196</link>
		<dc:creator>Gary</dc:creator>
		<pubDate>Wed, 30 Jun 2010 03:47:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82196</guid>
		<description>Phillip,
You keep trying to defend an indefensible position.

What all these people are saying is that being an experienced professional editor as you say you are is mutually exclusive with your premise. 

You are either an experienced professional that knows tape will be around for a long time, or an inexperienced individual trying to pass their own &quot;niche&quot; off as representing the entire field of editorial.

Personally, I am still delivering a lot of tape masters. HDCam and Digibeta. Lots of standard def digitizing. Lots of DVCPro HD tape. DVCam tape.

You are grossly exaggerating the difficulty for Apple to keep Log and Capture. It&#039;s minor in the overall scheme of things. It&#039;s a no-brainer.

I have read through you blogs before. Generally there are no responses to them at all. They are generally so far removed from the real world as to be useless to respond to. Just noise.

But this one goes right to the real world of post production.

And it&#039;s a stinker.

And you finally got some traffic in your responses
but for all the wrong reasons.</description>
		<content:encoded><![CDATA[<p>Phillip,<br />
You keep trying to defend an indefensible position.</p>
<p>What all these people are saying is that being an experienced professional editor as you say you are is mutually exclusive with your premise. </p>
<p>You are either an experienced professional that knows tape will be around for a long time, or an inexperienced individual trying to pass their own &#8220;niche&#8221; off as representing the entire field of editorial.</p>
<p>Personally, I am still delivering a lot of tape masters. HDCam and Digibeta. Lots of standard def digitizing. Lots of DVCPro HD tape. DVCam tape.</p>
<p>You are grossly exaggerating the difficulty for Apple to keep Log and Capture. It&#8217;s minor in the overall scheme of things. It&#8217;s a no-brainer.</p>
<p>I have read through you blogs before. Generally there are no responses to them at all. They are generally so far removed from the real world as to be useless to respond to. Just noise.</p>
<p>But this one goes right to the real world of post production.</p>
<p>And it&#8217;s a stinker.</p>
<p>And you finally got some traffic in your responses<br />
but for all the wrong reasons.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maarten Butter</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82166</link>
		<dc:creator>Maarten Butter</dc:creator>
		<pubDate>Tue, 29 Jun 2010 22:55:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82166</guid>
		<description>In The Netherlands, as of 10-10-2010 all the major networks (PNO, RTL, SBS) stimulate the post industry to deliver all content digitally. For commercials, you are required to deliver them as a MXF file already. I see tape dying very quickly.

For archive / retrieval I would love to be able to do that from within FCP for the next 5 - 10 years. Tools from BlackMagic / AJA will do, if we have to.</description>
		<content:encoded><![CDATA[<p>In The Netherlands, as of 10-10-2010 all the major networks (PNO, RTL, SBS) stimulate the post industry to deliver all content digitally. For commercials, you are required to deliver them as a MXF file already. I see tape dying very quickly.</p>
<p>For archive / retrieval I would love to be able to do that from within FCP for the next 5 &#8211; 10 years. Tools from BlackMagic / AJA will do, if we have to.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Sanders</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82155</link>
		<dc:creator>Michael Sanders</dc:creator>
		<pubDate>Tue, 29 Jun 2010 21:24:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82155</guid>
		<description>Philip,  

Broadcast/Movies may be a smaller market for FCP than Corporate, education etc but...

A) As editors (and cameramen) we work on all the above and more.  This week alone (and its only Tuesday) I&#039;ve cut 2 segements for a network news show (captured to and from DVcam) and 3 corporates (all in one day) shot on EX3&#039;s.  No one has a edit facility that will only cut broadcast, or one that cuts just corporate - we all just need a programme that can handle what we throw at it.  

B) Broadcast may be smaller, but overall its worth a lot more!  Top end post facilities update their software and hardware as it comes out - we need it, the faster a render the more clients thru the door.  Plus in marketing terms saying &quot;The oscar nominated movie XX was cut on an Apple Running Final Cut Pro&quot; is going to sell a shed more apple products than &quot;by the way the training video we you just saw was editing on an Apple&quot;

To say broadcast is a niche market and to say its needs are less than any other market proves you really don&#039;t understand the post production business or the selling of computers.</description>
		<content:encoded><![CDATA[<p>Philip,  </p>
<p>Broadcast/Movies may be a smaller market for FCP than Corporate, education etc but&#8230;</p>
<p>A) As editors (and cameramen) we work on all the above and more.  This week alone (and its only Tuesday) I&#8217;ve cut 2 segements for a network news show (captured to and from DVcam) and 3 corporates (all in one day) shot on EX3&#8242;s.  No one has a edit facility that will only cut broadcast, or one that cuts just corporate &#8211; we all just need a programme that can handle what we throw at it.  </p>
<p>B) Broadcast may be smaller, but overall its worth a lot more!  Top end post facilities update their software and hardware as it comes out &#8211; we need it, the faster a render the more clients thru the door.  Plus in marketing terms saying &#8220;The oscar nominated movie XX was cut on an Apple Running Final Cut Pro&#8221; is going to sell a shed more apple products than &#8220;by the way the training video we you just saw was editing on an Apple&#8221;</p>
<p>To say broadcast is a niche market and to say its needs are less than any other market proves you really don&#8217;t understand the post production business or the selling of computers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Andrew Richards</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82119</link>
		<dc:creator>Andrew Richards</dc:creator>
		<pubDate>Tue, 29 Jun 2010 15:57:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82119</guid>
		<description>&quot;Film is dead too. How about getting rid of Cinema Tools?&quot;

Maybe Cinema Tools is the model for the future of L&amp;C support in Final Cut Studio; a standalone helper app that only gets used or even installed for certain specific workflows.  Just because something might be dropped from Final Cut Pro doesn&#039;t mean it can&#039;t or won&#039;t be there as part of Final Cut Studio.  The Apple Loops Utility as well as Logic&#039;s WaveBurner and MainStage are further examples of this kind of architecture among Apple&#039;s Pro Apps.</description>
		<content:encoded><![CDATA[<p>&#8220;Film is dead too. How about getting rid of Cinema Tools?&#8221;</p>
<p>Maybe Cinema Tools is the model for the future of L&amp;C support in Final Cut Studio; a standalone helper app that only gets used or even installed for certain specific workflows.  Just because something might be dropped from Final Cut Pro doesn&#8217;t mean it can&#8217;t or won&#8217;t be there as part of Final Cut Studio.  The Apple Loops Utility as well as Logic&#8217;s WaveBurner and MainStage are further examples of this kind of architecture among Apple&#8217;s Pro Apps.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gerard</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82090</link>
		<dc:creator>Gerard</dc:creator>
		<pubDate>Tue, 29 Jun 2010 03:55:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82090</guid>
		<description>Film is dead too. How about getting rid of Cinema Tools?</description>
		<content:encoded><![CDATA[<p>Film is dead too. How about getting rid of Cinema Tools?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82086</link>
		<dc:creator>Philip</dc:creator>
		<pubDate>Tue, 29 Jun 2010 02:11:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82086</guid>
		<description>If it&#039;s there in the next release it will be there forever. This is the time for rewriting or not rewriting the whole darn App. Major changes (like things we&#039;ve all been asking for) could happen if they re-architected now, while converting the code to Cocoa. Once done, it&#039;s done. If it could have been delayed another 2-3 years it would be a much easier decision.

FCP has been forced into rewriting code that was not expected to be rewritten (see my earlier &quot;What is Apple doing with FCP&quot; article). This means rewriting most of the original FCP. They could do a basic rewrite converting to Cocoa and integrating 64 bit support, Grand Central Dispatch and OpenCL (plus other good stuff) which would leave Media Management the way it currently is (not bad these days, but not perfect); media locations are a preference not project setting; there&#039;ll be no display of non-tape or not-entered metadata, etc. 

Or they can take this opportunity, take extra time and rethink and re-architect the application, saving media locations with projects; database based media management with in-file metadata support (for robustness); bypassing L&amp;T etc.

I&#039;m hoping for the latter, but if they do that, I think L&amp;C is more likely to not get remade in the new architecture, which would be optimized for metadata/non-tape rathr than tape.

Just thoughts.

Philip</description>
		<content:encoded><![CDATA[<p>If it&#8217;s there in the next release it will be there forever. This is the time for rewriting or not rewriting the whole darn App. Major changes (like things we&#8217;ve all been asking for) could happen if they re-architected now, while converting the code to Cocoa. Once done, it&#8217;s done. If it could have been delayed another 2-3 years it would be a much easier decision.</p>
<p>FCP has been forced into rewriting code that was not expected to be rewritten (see my earlier &#8220;What is Apple doing with FCP&#8221; article). This means rewriting most of the original FCP. They could do a basic rewrite converting to Cocoa and integrating 64 bit support, Grand Central Dispatch and OpenCL (plus other good stuff) which would leave Media Management the way it currently is (not bad these days, but not perfect); media locations are a preference not project setting; there&#8217;ll be no display of non-tape or not-entered metadata, etc. </p>
<p>Or they can take this opportunity, take extra time and rethink and re-architect the application, saving media locations with projects; database based media management with in-file metadata support (for robustness); bypassing L&#038;T etc.</p>
<p>I&#8217;m hoping for the latter, but if they do that, I think L&#038;C is more likely to not get remade in the new architecture, which would be optimized for metadata/non-tape rathr than tape.</p>
<p>Just thoughts.</p>
<p>Philip</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Philip</title>
		<link>http://www.philiphodgetts.com/2010/06/why-apple-should-drop-log-and-capture-from-fcp/#comment-82087</link>
		<dc:creator>Philip</dc:creator>
		<pubDate>Tue, 29 Jun 2010 02:11:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.philiphodgetts.com/?p=1594#comment-82087</guid>
		<description>If it&#039;s there in the next release it will be there forever. This is the time for rewriting or not rewriting the whole darn App. Major changes (like things we&#039;ve all been asking for) could happen if they re-architected now, while converting the code to Cocoa. Once done, it&#039;s done. If it could have been delayed another 2-3 years it would be a much easier decision.

FCP has been forced into rewriting code that was not expected to be rewritten (see my earlier &quot;What is Apple doing with FCP&quot; article). This means rewriting most of the original FCP. They could do a basic rewrite converting to Cocoa and integrating 64 bit support, Grand Central Dispatch and OpenCL (plus other good stuff) which would leave Media Management the way it currently is (not bad these days, but not perfect); media locations are a preference not project setting; there&#039;ll be no display of non-tape or not-entered metadata, etc. 

Or they can take this opportunity, take extra time and rethink and re-architect the application, saving media locations with projects; database based media management with in-file metadata support (for robustness); bypassing L&amp;T etc.

I&#039;m hoping for the latter, but if they do that, I think L&amp;C is more likely to not get remade in the new architecture, which would be optimized for metadata/non-tape rathr than tape.

Just thoughts.

Philip</description>
		<content:encoded><![CDATA[<p>If it&#8217;s there in the next release it will be there forever. This is the time for rewriting or not rewriting the whole darn App. Major changes (like things we&#8217;ve all been asking for) could happen if they re-architected now, while converting the code to Cocoa. Once done, it&#8217;s done. If it could have been delayed another 2-3 years it would be a much easier decision.</p>
<p>FCP has been forced into rewriting code that was not expected to be rewritten (see my earlier &#8220;What is Apple doing with FCP&#8221; article). This means rewriting most of the original FCP. They could do a basic rewrite converting to Cocoa and integrating 64 bit support, Grand Central Dispatch and OpenCL (plus other good stuff) which would leave Media Management the way it currently is (not bad these days, but not perfect); media locations are a preference not project setting; there&#8217;ll be no display of non-tape or not-entered metadata, etc. </p>
<p>Or they can take this opportunity, take extra time and rethink and re-architect the application, saving media locations with projects; database based media management with in-file metadata support (for robustness); bypassing L&#038;T etc.</p>
<p>I&#8217;m hoping for the latter, but if they do that, I think L&#038;C is more likely to not get remade in the new architecture, which would be optimized for metadata/non-tape rathr than tape.</p>
<p>Just thoughts.</p>
<p>Philip</p>
]]></content:encoded>
	</item>
</channel>
</rss>

