Carsten Orlt
Forum Replies Created
-
Carsten Orlt
January 24, 2008 at 11:52 pm in reply to: Compressor 3.0.2 gone mad || Transcoding NTSC to PALwell even a cow can be wrong sometimes :-))
(specially if she has never tasted the goodness of succulent pal pastures)Carsten
-
Carsten Orlt
January 24, 2008 at 11:43 pm in reply to: Compressor 3.0.2 gone mad || Transcoding NTSC to PALwhy don’t you try to transcode the original seq (NOT the m2v) instead.
would be much better quality too!!!
beside this I don’t know why compressor doesn’t show the duration correctly 🙂
but maybe it is because the m2v format is mpeg2 which is GOP based so not every frame is complete. Maybe compressor is not made to convert m2v files…and unfortunately Dave is incorrect: there are plenty of pal dvd players who can’t play ntsc, and even if they would they either have to convert the signal themselves to pal or the tv needs to be able to accept ntsc signals. more chances to play russian roulette…
-
I’m working in Leopard on a MacBook Pro 15′ 2.33.
I’m not sure I understand your question because if you monitor video AND audio out of your ioHD everything should be in sync regardless of your playback offset in FCP. All the playback offset does is to synchronize the canvas to the external monitor. Mine is 5.
Are you looking at your canvas and listen to your ioHD audio outs or are you only looking at your external monitor for video and audio. If your doing the later and the footage is out of sync then it has nothing to do with the latency of the firewire device.
I did get caught thinking the ioHD has a problem with sync when I first time worked with Varicam footage shot at 25p over 60p. Everything was out by 2 frames. Jeremy here told me then this is normal too for 24p over 60p footage. So nothing to do with playback offset or any internal ioHD processing.not sure this helps but hope it may give you a lead 🙂
-
Carsten Orlt
January 20, 2008 at 8:05 pm in reply to: Problem with audio sync transcoding from NTSC to PALSorry Robert, no idea why this happens…
-
Carsten Orlt
January 19, 2008 at 9:59 pm in reply to: Problem with audio sync transcoding from NTSC to PALyou don’t have to transcode the audio!
the same ac3 file works in NTSC and in PAL.
Reason: when transcoding between NTSC and Pal you not changing the length of your film just how frames per second. So the audio is not affected here.
Also not sure why you have DV PAL in your workflow. I come from Pal and go to NTSC but the principle the same. I create one Pal m2v video only, one NTSC m2v video only and one ac3 for the audio.Carsten
-
Just a little warning 🙂
always copy the new clips to your project and not your sequences to his!!
because otherwise you loose your master-affiliate links which means there is no link between your clips in the browser and your seq.
e.g. you wouldn’t be able to use ‘show clip in browser’ from your seq
or
changing the name of a clip wouldn’t change the name in your seq
etc…Carsten
-
Gary
I didn’t say that it is not working, but it is a bit on the slow side 🙂Do you have worked in 1080sf24 on an 8 core MacPro?
If yes I would be interested how you would rate the speed gains for general RT work.
Ah yes and I have a Sata raid which Aja system test rates at about 90-100 MB. Is yours faster? And if so, do you reckon that makes a bigger difference then a faster CPU?
Thanks for your time!
Cheers
Carsten -
I have the minimum MacBook Pro (15”, 2.33, 3GB) and I work in ProRes (not HQ) 1080i25.
(I have Sata Raids via a express card)
I’m now seriously considering getting a MacPro 8 core. And when I tried ProRes HQ I almost had to render everything.
I don’t know if the the old MacBookPro would work at all, but from my experience I doubt it. My MacBookPro just barely makes it.
I guess the only way to find out is to source a ioHD and try before you buy!Carsten
-
I have garbage frames (in lack of better term to describe) when i open a clip in the viewer and sometimes when opening seq in the canvas. I know that it is fcp because it still happens when I disconnect the ioHD 🙂
-
its really quite simple.
interlace means that that first the odd lines are written 1,3,5,7,9…..
and after that the even lines in a second run 2,4,6,8,10…..
In Pal this happens 50 times a second producing 25 complete frames per second.
Now imagine a camera chip that takes an exposure on each of those 50 cycles only writing either odd or even lines at a time, and you would look at one complete frame you would see a temporal difference between the odd and even lines (think of a ball flying left to right. the even lines would show the ball a bit more to the right then the odd lines on one frame)
But you can also expose all lines of the camera chip at the same time store the information in a temporary buffer and then write first the odd lines and then the even lines to tape. If you do this 25 times per second you effectively have a progressive frame. That it was is called Progressive segmented frame.