Steve Covello
Forum Replies Created
-
eom
-
Here are two options I have been using without incident: if you don’t want to blow the hundreds of dollars on Flying Cows or the new AJA product [which I haven’t looked into yet], you could use your DVCam, DBeta or HD deck as a D/A by hardwiring the AES K2 outputs to the AES inputs of the deck, then normalling the analog output of the deck to your mixer for your playback monitors [I use this method for monitoring 4-trk programming]. This is a less than ideal situation since you would have to be careful about creating a feedback loop, but it would work in a pinch.
If you don’t have a digital deck to use as a D/A, then you can use an Edirol UA1A USB input/output device. It connects to your USB port and provides a conversion from digital to analog audio with RCA stereo outputs and inputs. This has worked well for me for regular stereo programs and for recording scratch audio from a mic via mixer. My UA1A output is connected to a patch bay that allows normalling into the mixer for playback, then the subs of the mixer routed back to the patch bay for output to vhs or 3/4″. This prevents feedback too. I have experience no a/v sync problems at all this way, and no computer noise or crappy stereo mini plug noise. The FCP settings can be toggled from USB output to K2 digital output in a snap.
I admit I’m being a cheapskate, but if it works and there’s no one else that needs to deal with it but you, then it’s an option.
steve covello
double wide post -
If you are working on a Mac on OS X, then you have nothing to worry about. OS X utilizes “dynamic RAM”, which unlike OS 9, uses as much as it needs based on what is available. OS 9 required “assigning” a RAM amount which it was limited to. This means that it will use more if more is available if you close out unused applications. But it doesn’t guarantee that it will use every single ounce of RAM if 1.5 gb is available.
If you go into Activity Monitor [Applications/Utilities/Activity Monitor], you can see a running account of your RAM usage throughout your machine while you are rendering.
The speed of your computer’s performance will certainly improve with more RAM, but the processor speed will ultimately limit the highest level you can get.
steve covello
doubel wide post -
An alpha channel is a video term that means roughly the same thing as transparency in PS. It is the information that allows an image to be ‘cookie cut’ as a fg image over a bg image. Having just looked at the link, it’s hard to say why there would be a need for the white layer, though the layer above it is being used as an alpha channel [notice the black square with the white circle]. What the example does not show you are the track/transfer modes [the toggle opposite of the raster/anti alias/motion blur view shown in the screen shot.]. So the white layer is being ‘cut’ according to the tranparency [presumably] of the layer above it. So assume that you have to set your layer with a track mode “alpha”.
If I understand correctly, the tutorial is trying to say the following:
-
I had a similar problem with FCP 4.5 and the first driver for K2, outputting to DBeta 4-tracks. The timeline and audio channels were all set correctly, but the routing to the deck was completely off — ch. 1 going to ch. 4, etc. There were several questions about this early on here in this forum. One issue was that audio on tracks 3/4 that were NOT routed to CHANNEL 3/4 were getting patched incorrectly no matter what, and the workaround was to move them to tracks 5/6. The other troubleshoot on this was to use panther/tiger cache cleaner which solved the problem for a while. It’s been a while since I’ve output more than 4 tracks at a time, so I don’t know whether this was fixed completely for all deck drivers.
try also outputting from the Viewer rather than the Canvas. This was an old old workaround for an FCP “incompatible compression” conflict on edit to tape even though the sequence was fine.
steve covello
double wide post -
Sorry I can’t answer the more important questions to your post since I still running 4.5. But I can say that the reason for the FW versus SDI capture for pulldown removal is because of the proprietary nature of the panasonic data stream.
When the DV signal is recorded on tape with PDa, there is a flag that is included which can only be decoded via firewire, not SDI. Nor can the flag be read if you are using a DVCPro25 tape in a DVCam [Sony] deck, since Sony equipment can’t ‘see’ the PDa flags either, even if it’s a firewire hookup.
So you will need to stay in the FW connectivity setup if you plan on offlining and onlining in 24 from a PDa source. Also, I have always been under the impression that you could choose whatver compression you wanted to work in independently of the means of digitizing or the format you were digitizing from. So as long as you stay FW, you should be able to go in any way you want as long as the card and deck are capable of doing so [i.e. trying to capture a 720 signal into 1080 — can’t say tihs would work since they are different formats — never tried it]
steve covello
double wide post -
Had precisely the same problem, only with input via SDI from DBeta. Hadn’t touched the control panel in weeks, so even though it checked out ok, I figured it couldn’t be the problem.
What worked was trashing preferences, running Panther Cache Cleaner at Medium cleaning on all levels [Tiger Cache Cleaner if you are on 10.4.x], restart [automatic], then repairing permissions. I will also occassionally trash my FCP Rescue backups by trashing the backup files AND the pref files on the computer, startup FCP and configure it the way it is normally used, then quit FCP. This will create a new fresh set of prefs which I then backup into FCP Rescue for future use.
Seems like a lot of stuff to do unnecessarily, but in the long run it’s worth it.
steve covello
double wide post -
This is an excellent solution which I plan on testing for myself.
The only caveat I would add to this workflow is that if there were to be any additional need for the footage after it has been digitized i.e. vizcode dubs, SD DC clones, etc., then your only source for the footage are your camera masters. I tend to think of HD CM’s like negative and try not to touch them too much.
So if you forego making downconversions to DVCam, for offline convenience, or DB’s, to online in SD, then you must rely on the integrity of your HDCam deck to not mangle your CM’s. I guess if you have 200 hours of HDCam masters and the thought of coughing up for 200 DC’s, I could see your point. It’s a risk you have to take depending on the situation.
I still don’t feel comfortable post-jam syncing timecode only onto a TC DAT by hitting play/rec. Call me risk averse… Put it this way:
The ground can’t cause a fumble.
An editor should not cause a re-shoot.steve covello
double wide post -
[this note is based on my experience using only an F500 HDCam deck. Can’t say if the same holds true with other HDCam decks]
On HDCam, pulldown timecode does not actually exist on the HDCam tape. Even though you can get the deck to DISPLAY DC TC, it is only being generated in RT from the 23.98 TC that was literally recorded on tape.
When you downconvert to SD, the pulldown boards generate SD 29.97 TC in realtime and integrates it into the data stream that your SD record format receives via **SDI** in the VITC, not RS-422. FCP receives its TC information via **RS-422**, so the SD SDI downconvert spigot from your HDCam deck will not provide FCP with the DC TC information that matches your DVCam DC dubs.
In other words, if you downconvert to SD, thus creating pulldown timecode at 29.97, then try to capture your online from the **HDCam** deck at 29.97 (though your material is 23.98), there is no way for the HDCam deck can provide the 29.97 downconvert TC through the normal RS-422 connection from which FCP is able to read. So FCP will not know what to do.
I can’t say whether putting the HDCam deck into 29.97 Interlace mode will solve this problem — never tried it. This does not guarantee that the TC output via RS-422 will be correct.
What may have happened in your partial online capture was that some of your clips started with TC numbers that actually exist on the 23.98 fps tape, and some start with TC numbers that do not i.e. 1:00:01:28. Once FCP acquires a capture starting point, it might not care if the frame rates are different, though it may not know when to stop. [I was able to fake out our FCP onlining a 29.97 SD project in HDCam 23.98p using this method, though every scene was off]. HDCam deck will only playback at the frame rate it is set to, not what you want it to capture at. At least with the F500 in my case.
I concur with Walter about having done tests with your workflow before implementing it. Had it been me, I would recommended downconverting to DBeta and using the DB’s for offline and online, though it adds an extra expense of machine rental and tape stock. Maybe clone the DB’s to DVCam too if you are in a DV only type setup.
K2 dudes: if I am off on any of this, let me know.
steve covello
double wide post -
In your Capture Presets for FCP, do you have Speaker On? This is normally defaulted to Off.
AudioVideo Settings/Capture Presets/Edit/Quictime Audio Settings: Advanced/Speaker On
See if this is the issue.
With regard to the blank audio, I have seen [heard] this happen on timelines with more than 8 tracks, even though the tracks are rendered. Strangely, it happened only on exported QT files, not on straight playback. There was one clip that seemed to corrupt everything else and I ended up re-arranging the audio clips into different tracks and it worked out OK, though not perfectly. I am running off Kona2, so it’s hard to say for sure whether your isse is and FCP or an IO problem since our problems sound similar. Forgot to mention that all of the audio on my timeline was brought in from CD at 44k, and converted RT by FCP. That may have been a factor as well.
I am running 4.5 off of OS X 10.3.8 on G5 dual 2ghz via Xserve RAID
steve covello
double wide post