Forum Replies Created

Page 53 of 70
  • Bob Flood

    October 5, 2006 at 2:53 pm in reply to: IO la, Intel Mac Pro, firewire cards, and thou

    JG

    JG: Put your firewire drives on the PCI card (I re-read my last post and it does sound like I said put the io on the card, I didn’t mean it). The io should be the only firewire device attached to any internal fw port on your desktop.

    BF: ok

    J: The fw400 and fw800 bus on the desktop IS THE SAME BUS.

    B: I thought this was waht was going on. nice job apple!

    J: You need a separate card for your firewire drives.

    B: ok. looking into combo 400 800 cards or seperate 400 and 800 cards. any suggetsions?

    J: Zelin says to fire all firewire 400 drives cuz there’s much better/faster/more reliable and inexpensive drives out there.

    B: yeah i knew that, i thought he was having other issues with fw 400.

    J: FW400 is only good for dv25, and dv25 only. dv50 or above you really need FW800 or better.

    B: ok. we do a lot of pitches, promos, loops etc at dv25, so its just fine for us. we also already own them, so we are trying to get some ROI

    FWIW on a side note:
    i found out there really are no firewire drives, that they are IDE or SATA drives in an enclosure or on an adapter that connects to the computer w firewire
    I also know that early versions of fw 400 drive enclosure/adapters were flaky, and that the latest chipsets are actually quite stable, however they do limit to dv25 video use, but if thats all you need them for they seem to be ok

    thanx again for your help and patience

    now if we can just find PCIe FW cards, life will be good!

  • Bob Flood

    October 5, 2006 at 1:57 pm in reply to: IO la, Intel Mac Pro, firewire cards, and thou

    JG

    no I live in minnesota, but i work in denial 🙂

    you and zelin and aja are all saying different things: zelin sez all fw400 drives must die, you say put the io on a pci card, aja sez DONT put the io on a pci card. (all this video is giving me a headache, lets go to the mall 🙂

    how about this: i buy a 400 /800 card, or a 400 card and an 800 card and i put my drives and my vtr’s on that/those cards, leaving ONLY the IO on the apple firewire 400 bus and nothing on the apple fw 800 bus. has anyone tried this? will this work?

    thanx again for all the help

    bee eph

  • Bob Flood

    October 5, 2006 at 2:36 am in reply to: IO la, Intel Mac Pro, firewire cards, and thou

    Mr Zelin

    I sense your feeling somewhat adamant about fw 400 drives

    why? what are the issues with these devices?

    And is FW800 any better? (or maybe its twice the headache?)

    FWIW i just did a 4 camera shoot mutlicam edit, all dv25, all from a single, unstriped, 10,000 rpm fw400 drive(without the IO,)

    nary a dropped frame to be had

    My boss, who thinks he knows everything and refuses to listen to his staff, (which together have approx 1,000 years of experience)insists on doing a dv25 fw400 based workflow, at least for non broadcast. so i am kinda stuck here.

    BUT after some research we landed on dual sata drives in a FW800 enclosure so as to allow us to move DVCPRO50 jobs between 2 fcp systems in a cost effective manner.

    Oh By The way, i did some tests waiting for a response

    having the IO on the 400 bus greatly decreases the writing speed of the 800 bus ie when the IO is plugged in, my write speeds to the FW800 raid 0 is 25-30 mB/sec

    BUT when i unplug the IO the write speed jumps up to 60 mB/sec

    if i could find a PCIe FW800 card and connect my FW800 raid 0 to this card, will i see these kinda numbers?

    thanx again for your help

    bee eph

  • Bob Flood

    September 29, 2006 at 3:20 am in reply to: using Kona LH with a betacam SP deck

    hey Bob

    WE are using that configuration, and we actually did a couple of layoffs to Beta sp without a ref to the kona, ,and other than the error message and watching the video “float” on the output of the deck, the recordings seemed fine.

    We were also doing this with edit and media 100

    dont get me wrong, i think having a black generator and feeding stync to everything is the way to go, but i think hopalong can go to the bathrrom first! just order the thing between the bathroom and dinner.

    bee eph

    BTW we loop black from the generator to the composite video in of the UVW, then loop from there to the ref in on the uvw

  • Bob Flood

    September 28, 2006 at 3:16 am in reply to: adding firewire devices corrupts io la

    Thanx

    i started looking for a firewirecard before i even started my reply

    bee eph

  • Soooo

    I opened the same show back on the g5 as i left it, when i thought all was well, and lo and behold the same issues were there

    however its not as bad as i thought

    FWIW when i was working w edit, when i would post a question about “is this a bug?” I would get an answer, usually the beta testers who were done with that version (ie their NDA did not apply to released versions)

    I find the fact that apple never admits what are known bugs or “issues” to be a real pain. at least if i knew waht was wrong, i would have more confidence i was making a mistake

    and dont gimme this “our software has no bugs” bah loney

    bee eph

  • Hi

    I have some advice to help you all, but first i must rant:

    Unreal

    Here is a workflow that apple endorses “capture the whole tape and seperate the clips after the fact” and actually this makes a lot of sense, in the case of beta, dbeata and other real formats, you save wear and tear on the tape by not having to shuttle around to mark in and outs etc. in the case of firewire formats like dv, hdv, dvcam etc its faster cuz shuttling those formats takes forever.

    so yeah, this is a great idea! except for one thing: IT DOESNT WORK!!!

    I mean this isnt like “oh media manager ate my footage” or “oh the mark out isnt like the avid, where it does not include the outpoint” NOOOO this is: THE PROGRAM DOES NOT CAPTURE VIDEO CORRECTLY”

    now you know why you only pay 1500 for an edit program
    I guess its true: you get what you pay for

    on a more constructive note: SMPTE timecode was never great. it was always prone to errors. even the slightest dropout or dropped bit can trip off sensitive TC readers. the better timecode readers have very robust error correction.

    when ever we old timers had issues like this ie bad code, or what the editor percieves as bad code we usually did this:

    1. make sure all your machines are getting house sync ie feed video black from a stable sync generator to the reference ins and video ins of the vtr’s and to the ref ins of the capture cards/devices. also make sure said capture cards, devices, and vtr’s are locking to that black or ref in, they call it genlock

    2. restripe the videotape, or clone the videotape and nake sure you are regenerating timecode, not just copying, (the recording vtr should have provisions to regenerate code based on an external tc source) It would be nice if you could regenerate the timecode over the rs422 interface. An edit systme we once had used a video connector for timecode in. when we had flaky code on tapes, we would take a “jam sync” continuous updateing timecode generator, and put it inline between the vtr and the editor. this would take the timecode off the tape, regenerate it w the same numbers, and pass it to the edit system. (for those who care, it was a montage)

    3. log and digitize seperate clips like days of yore

    4. Complain to Apple. A Lot.

    Hope this helps

  • Bob Flood

    September 18, 2006 at 2:42 pm in reply to: LCD (lowest common denominator) for editing HDV sources

    hey bob

    we own the HDV camera and m10u. i edited one job in hdv native. I found it underwhelming at best.
    if you are going to be cutting only on a laptop or all by yourself, and you can finish yur show with enough time to render and export before fed ex then great, more power to you, go for it!

    however i work in the real world, where one or 2 producers have to see all the effects in real video on an NTSC monitor at any given time, and insist on making edits up to the very last second ie 5 minute to fedex.

    On my next job i digitized analog component through a Kona LH to dvcproHD and found it better. However i was not happy with the exporting of the footage for dvd as it got soft (my kona diod do an excellent job of downconverting in real time however)

    On the third job I digitized analog component through the kona LH to DVCPRO50 at 16×9. Best so far. accurate previews, quick export, efficient use of drive space. I have made this my workflow of choice.

    look at it this way, all the real time stuff is handled by the CPU. By capturing the stuff at the rez i want to output (I do not have a lot of call for HD masters etc) the card has done the “heavy lifting” and makes the RT previews a little faster.

    as for differences in the VTR’s? i think the extra mony is worth it for the M25, as it allows you to make HDV clones from a camera WITH MATCHING TIME CODE, something the m10u does not. And man the m10u is a lot slower than a real DVCAM Machine, like a dsr
    so if the M25u has a better transport, definitle go for it!

    hope this helps

    bee eph

  • Bob Flood

    September 18, 2006 at 1:59 pm in reply to: reveal a clip in timeline, from browser

    hey homer (duffbeer)

    frankly i drink bear whizz beer myself

    but seriously, If you make a color label for the clip in your bin, it will add a color label to the clip in your sequence. depending on the size of the sequence and how far out you have to zoom the timeline and still see the clips, you can then spot the clip with the color label pretty easy

    hth

    bee eph

  • Bob Flood

    September 14, 2006 at 4:52 pm in reply to: whats more better for FCP: Ram or CPU

    Our IT guy said it was out, and cheaper, but he did not say where

    I saw ads for ram at Anandtech.com, and they are pretty good mac heads anyway

    HTH

    Bee eph

Page 53 of 70

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy