Forum Replies Created

Page 96 of 189
  • Sean Oneil

    October 8, 2007 at 1:58 am in reply to: RocketRaid & Raid 5

    [walter biscardi] “Wow, that’s strange. Our Write speeds are higher than the Read speeds. One test was 517MB/s Write / 388 Read and after we adjusted the unit, 420MB/s Write / 340 Read. This is running the Atto R380 SAS card.”

    I think your results are much stranger :). I have a lot of different RAID-5 solutions. Read speed is always at least twice as fast. When you write to a RAID-5, it has to write not only the data, but also the additional parity data (what’s used to rebuild it if you lose a disk). But when you read from it, it’s just like reading from a RAID-0.

    You could have filesystem caching turned on during your speed tests. That would explain the faster write speed.

  • Sean Oneil

    October 8, 2007 at 1:55 am in reply to: RocketRaid & Raid 5

    [Kevin Schumacher] “Both my HighPoint cards (2224 and the 2322) use the same connector, a mini-SAS, and are very secure, as is the cabling; the only difference is that one uses a latching style lock and the other uses screws.”

    Very true. Tons of SATA cards and enclosures use the same Infiniband and mini-SAS connections that SAS cards use.

    I just don’t see any advantage to using SAS. You can find “enterprise quality” SATA drives that are just as reliable. Yes, they make 15k RPM SAS drives (SATA only goes to 10k), but the capacity is very low. And at that point, why not just get Solid State Drives?

  • Sean Oneil

    October 7, 2007 at 8:00 pm in reply to: RocketRaid & Raid 5

    I used a 2224 with an 8 disk RAID 5 for a long time.

    At first I had the issue of a drive disappearing and the alarm going off. I updated the firmware and it never happened again.

    I got about 450 MB/s read, and about 200 MB/s write (RAID-5 always has much slower write speeds).

    I also want to make sure everyone knows that SAS does not provide any speed benefits over SATA. SAS is a faster bus, but that means nothing since the bottleneck is always the disk drive itself – not the bus. SATA is still many, many times faster than any hard drive ever invented.

  • Sean Oneil

    October 6, 2007 at 5:01 am in reply to: Interlace artifacts?

    I don’t know the steps to downgrading. But I know they can be found somewhere here on the Cow.

    I’ve never bought the Applecare Pro package. It may be worth for you. If you get an AJA product, their free tech support is fantastic.

  • Sean Oneil

    October 5, 2007 at 6:09 pm in reply to: Interlace artifacts?

    [AnotherProductionCompany] “I posted this problem on the Apple FCP forum…is there a specific “Feedback Forum” that is directed to Apple, versus users? In regards to the QT 7.2 bugs…should we uninstall QT and try installing a previous version?
    “

    Google “Final Cut” and “Feedback”.

    Downgrading QT might be a good idea. I’m going to as soon as I get a chance.

    I have an Intel Mac Pro. One of my co-workers, who’s using a PPC G5, has QT 7.2 and doesn’t seem to have this problem. I haven’t tested it on his machine myself, but he’s outputting web clips of film-based 29.97 footage using Compressor’s deinterlacer (he uses blur deinterlacing) and they look fine. I’m unable to do that on my machine. It’s combining the wrong fields no matter what options I choose.

  • Sean Oneil

    October 5, 2007 at 6:04 pm in reply to: 720p 24 HDV to Apple Pro Res

    [gary adcock] “Watch out because you will need to compensate for the incorrect aspect ratio of Media Manglers conversions to ProRes- MM maintains the original file’s aspect ratio on conversion rather than rendering the content as full raster.

    I use QT player – it always handles the conversion correctly (and it is fast when using automater) “

    Hold up now.

    First of all, I’ve never seen this problem. I just tested it myself going from 1080i HDV to 1080i ProRes. It correctly converted the pixel aspect.

    Secondly, Randy is working with 720p. 720p HDV is full-raster. 1280×720, square pixels. So even if this bug does exist, it doesn’t apply here.

  • Sean Oneil

    October 5, 2007 at 2:44 am in reply to: 720p 24 HDV to Apple Pro Res

    I’m not trying to start any arguments, but trust me, converting HDV to ProRes using Media Manager is absolutely fine. Especially considering your circumstances. You don’t have HD-SDI capture and you probably don’t have an HDV->SDI converter box. On top of that, you already spent time capturing it via Firewire.

    MM is the most convenient for you because it will automatically keep the timecode and reel names intact. And because ProRes is so good, there is no quality difference between that and HDV editing.

    Highlight the clips in your browser. Right-click and select MM. Choose the option “recompress”. Not sure why you don’t see it. It’s there. Choose the sequence setting you want: ProRes 720p24 (which is really 23.98). And to answer your question, no, you do NOT want to convert the frame rate. At least not w/ MM. That is a very complicated process. If you don’t see a 720p24 ProRes sequence setting, you’ll have to create one. Make sure “delete unused media” is not checked, and choose a folder for where the new files go. The other options are self-explanatory and they shouldn’t even matter here.

    Before I get lambasted, I’ll explain the reasoning as to why Walter and probably many others believe it to be better to capture ProRes on ingest rather than converting it with software. First of all, capturing ProRes on ingest uses the same exact Apple software encoder that Media Manager and every other QT app uses. It’s no different. The only hardware ProRes encoder I know of is in the AJA IO/HD. And it could be worse than the software encoder for all we know. Whatever the case it matters little because ProRes is so good. The issue isn’t the ProRes encoding, it’s the HDV decoding that is in question.

    When you capture HDV over firewire and export it in Media Manager, your Macintosh uses the Apple software HDV decoder in order to export it. But if you capture on ingest, then the HDV is instead being decoded by the source device using hardware. In this case let’s say it’s the HD-Connect SI Box by Convergent Design: https://www.convergent-design.com/CD_Products_HDConnectSI.htm

    This hardware decoder may be better than the Apple software decoder. It may also be worse. Or this model may be better than others (Miranda). Or the other way around. Who knows. I haven’t tested them to this kind of extent, nor do I know of anyone who has.

    In the past when working with standard-def DV, hardware decoders built into DV decks, like the Sony DSR-1800, were always better than the Apple DV decoder. Walter, among many others, may be taking that old and wise knowledge and applying it to HDV. And he may very well be right. Or he may not be.

    Anyway, the quality difference, if there even is one, should be very, very minor. Even if the quality is better on ingest, it won’t be dramatic by any means. If you are THAT picky about imperceptible quality differences, you should ask yourself why you are shooting on HDV to begin with.

    Now as far as native HDV editing goes – HDV editing uses the same Apple HDV decoder as Media Manager. So NONE of what I’ve just been saying applies here. Hence, my statement that you won’t be able to see any difference after using MM. There won’t be any difference because it’s the same HDV decoder, and the ProRes encoder is virtually lossless.

    One last thing. FCP 6 allows you to edit HDV natively while encoding only your render media to ProRes. You’ll find it in the sequence settings. This is probably your best option. This is what HDV is meant for. SDI capture vs. firewire/software conversion is very convinient for bigger places with machine rooms, SDI patch bays, and people who charge by the 1/2 hour. This obviously isn’t the case for you so don’t even worry about it.

  • Sean Oneil

    October 4, 2007 at 3:46 am in reply to: Interlace artifacts?

    This is a bug that seems to have started with the Quicktime 7.2 update. Please use Apple’s feedback forum to let them know.

  • Sean Oneil

    October 2, 2007 at 3:40 am in reply to: EDL issues for film-out in FCP

    Few things to try.

    1. Try the DVCProHD framerate converter tool. I know you’re missing flags, but maybe it could work (probably not).

    2. Throw the footage on a 23.98 timeline in Final Cut. You’ll have to re-render, so I suggest working in Uncompressed or ProRes. If Final Cut guesses the correct cadence, then you’re set. If not, you may have to play around with it. Perhaps try trimming the in-point by 1 frame and dropping it in – repeat until it gets it right. I don’t know how FCP determines cadence, so this may or may not work.

    3. Throw the footage on a 60i sequence (29.97 timebase in sequence settings), export a self-contained movie, and then use Cinema Tools to reverse telecine. I’m quite sure this method will work without a doubt, but it will take longer to do.

    You’ll probably lose embedded timecode using any of these methods. But you can manually re-create embedded TC using “Modify -> Timecode” in Final Cut. Maybe just write down what the TC of the first frame of each clip is. And know that you can still store 30fps timecode within 23.98 video and vice-versa.

  • Sean Oneil

    October 1, 2007 at 6:45 pm in reply to: OT: super long DVI run
Page 96 of 189

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