[Paul Dickin]

Hi
When converting web-delivery codec movies to an editing format with QT Player Pro or MPEG Streamclip it is essential to set the frame rate of the transcoded movie in the settings box.

Web movies can be any frame rate, including a not-quite-consistent rate ‘near to’ the correct editing frame rates. So make sure the output frame rate is set to correct this, as FCP doesn’t cope with inconsistent frame durations.

I’m not sure if this is the cause of your problem, but having badly prepared movie files from miscellaneous sources is a sure fire recipe for subsequent FCP project corruption or render fialure problems…

[Paul Dickin]

Hi
How are you initiating the ETT process?
I find that dragging the Sequence icon from the Browser first to the Viewer, then repeating the Browser icon drag to the ETT window’s Assemble (or Insert) overlay seems to be the only way to get everything to work.

[Paul Dickin]

Hi
Photo-JPEG @ 60% or so is a good choice – the MJPEG codecs were for hardware video cards.

720×480 is really a non-square pixel size for DV editing – for computer screen work square pixels would normally be used. But using 720×480 with square pixels would give a slight widescreen aspect ratio which you might prefer.

One option is to make your QuickTime movie at 360×240 pixels, then use QT’s scale to double size option, which would play out 720×480, but with a far smaller movie file size.
Save your movie after it has been enlarged and it will always play at the larger size.

[Paul Dickin]

Hi
The rule of thumb for creation of QuickTime movies has been that the pixel size should be divisible by 16.
As in 768/16=48.
Your 1024 dimension is fine, 1024/16=64, but your 682 dimension doesn’t comply, 682/16=42.625.

The reason for this is the way the file is made up of macroblock segments:
https://en.wikipedia.org/wiki/Macroblock

Some codecs can be sub-divided further, into 4×4 blocks, but even using one of these you will get a compression error with your choice of vertical pixel dimension, 682/4=170.5.

[Paul Dickin]

[Ben Holmes] “Glad my company needs a couple of family pack licences “
Hi
Just for information 😉
Quote:
“as long as those computers are located in the same household and used by persons who occupy that same household. By

[Paul Dickin]

[szumlins] “Now FCP on the other hand…. “
Hi
😉 Won’t we all have to stump up $69 for the Leopard-compatible FCS maintenance release DVDs?
Too big for download…

[Paul Dickin]

Hi
10 years ago I was called in to troubleshoot a new Targa 2000 card Mac OS 7.6.1 capture problem – trying to capture caused a crash every time.

I spent several days repeatedly reinstalling everything – doing an erase of the SCSI system drive each time. No joy, a crash every time.

Because I was only working during office hours on the system, I at first didn’t want to waste the best part of a day doing a low-level drive format, so I just did an erase, but after many days getting nowhere, I twiddled my thumbs for the hours it took to do the full SCSI format.

Problem solved, the software/hardware thenceforth worked absolutely fine.

Well nowadays low-level formatting has disappeared into history, but if I was confronted by a similar intractable problem I would do a full write-zeros scan of the system hard drive, because the problem then had to be caused by some persistent sector corruption on the hard drive.
And if that could happen then I’m sure it could now…

[Paul Dickin]

[David Roth Weiss] “[Arniepix] “Does this drifting audio stay in synch with the picture of that camera?”
Yeppers!!!”
[David Roth Weiss] “[Sean ONeil] “What about the picture? Does the video for both cameras stay in sync?”
Yep!!!”
Hi
Paradox time…
If each camera’s audio is in sync with its video, and
If both camera’s audio drifts sync with the other, then
Both cameras video should, in maintaining audio sync, not remain matched.

So a timecode reader filter on each cameras video should determine if there is the same frame count = duration on each camera shot from clapper board to something equally determinable at the end of the audio.

If it isn’t then the two cameras are running at different frames/sec rates – which is a mechanical head-rotation difference, and nothing to do with audio sample rate.

Different battery-charge levels or something, affecting each camera’s head-rotation ability to keep up with its internal crystal-sync…

On the other hand if there is the same frame duration for the two cameras over the hour+’s video duration, then something is indeed happening to the audio sampling rate.

Does Cinema Tools or some other software have a ‘Conform to Frame-rate’ facility?

[Paul Dickin]

Hi
Hey David and Shane, I’m not having an ‘issue’ here, all I was commenting on is that ‘General Error’ rendering bug others are experiencing, well I can conjure it up anytime, as described.

So anyone getting ‘General Error’ for appropriate-media FCP editing might be able to benefit from my analysis that its caused (in my case) by out-of-kilter media-asset parameters, and not by the FCP itself.

Since MPEG Streamclip did the transcode fine, I’m in a go situation untiI get the DigiBeta masters tomorrow…
Cheers

[Paul Dickin]

Hi
My normally stable DV-PAL FCP 5.1.4 edit system has just yesterday suffered repeatedly from the General Error rendering failure after a couple of minutes rendering a long timeline.
Its a repeatable failure, so I’ll add the info here:-

It happens when I try to transcode WMV low res files off a website into PAL DV, on the timeline. I only have the free WMV player component, and using QuickTime Player or MPEG Streamclip’s Export function puts a watermark on the transcode, which doesn’t happen using FCP’s timeline.

The reason I’m doing this is I have access to the DigiBeta master tapes, but not at the weekend, but as the archive is all online at low res, I tried a quick transcode to DV-PAL to allow cutting in the WMV clips as a temporary offline, to be replaced on Monday.

These WMV clips don’t have a stable frame-rate, and and are variable-rate compressed audio.
So:
Either the codec, or the unstable frame-rate, or the compressed audio, or all three, is flipping FCP 5.1.4’s render-engine stability.

I would guess that the same factors may well be causing the problem for the people who are experiencing this failure with ‘proper’ clips.