[Manny Kivowitz]

That spike in xfer rate could be super significant, considering that I’ve heard quite often that real world captures on 8gb cards runs in the 15-16min range. 1 for 1 xfer rates would be far less than ideal, especially if you need to recycle those cards in the field.

Thanks!

Good heads up on the USB2 issue, I’ve not had any experience with them yet but I would not have imagined it to be such an issue. Was it just one drive?

[Manny Kivowitz]

Thanks guys, I agree firewire is agreat great solution (except when the drives die and I’ve experienced that several times now) but I’m afraid the amount of material would be daunting. I guestimated that each 1 hour episode will be cut from nearly 60 hours of material (lot’s of 2 & 3 camera interviews) and if captured at 720p30 would yield roughly 1.62tb of data per episode. As it is we’d have to greatly increase our xsan storage just to handle daily workflow.

That’s why I was considering the tape solution and while trying to educate/convince a network that they need to reconsider their deliverable requirements, the battle would no doubt be uphill.

Keep ’em coming…. all ideas welcome. Any info on P2 & Firestore ingest times would be very welcome.

[Manny Kivowitz]

We switched nearly two years ago because of some pending projects which, combined with Media 100’s waffling business seemed to make good sense. We’ve not looked back and now have 4 full up FCP 5.0 systems, 2 assistant stations, 1 loading station and 1 gfx/edit station (up from 2 media 100 systems).

While I personally loved cutting on M100 I almost never am the person doing the cutting….. you get the picture. I could hardly ever find editors who knew media 100 and was constantly strapped making the decision to either train or go with the best possible option out what sometimes proved to be a range of not so great options. We took a giant leap at the beginning of ’05 and installed the first X-san system in a boutique post environment and that’s proven to have been a great decision as well.

I remember having learned Avid and then making the switch to M100 in ’97 and being incredibly frustrated by the learning curve then as well, everything seemed counter intuitive… I’m sure the same is true making the switch to FCP. Avid editors however have little problem jumping to FCP which is a great boon when you’re looking for talent.

Good luck with the decision, I’m finally getting around to selling my two Media 100 systems including 1 with a p6000 card with analog BOB which comes with an sdi daughter card and sdi BOB. I’m also getting rid of my 601 card which comes with an analog BOB. All software and registration for both systems through version 8.01 available. I’m sure m100 is offering upgrades but you’ll have to contact them to find out.

[Manny Kivowitz]

I agree, but appreciate the suggestion. We’re using Sony’s DVR-1500a’s which should process the signal better than any intermediary device. In re-working our post work flow we were hoping to eliminate issues that come up from the 6 pixel variance between dv25 and our 10 bit uncompressed gfx and finishing process. Ideally the deck or the kona card would offer an on the fly solution other than canvassing the 720×480 image onto the larger 720×486 canvas leaving 3 lines of black at the top and bottom of the image.

This of course wouldn’t be a problem if we weren’t concerned about what the progams will look like on full scan plasma screens and the possibilty that the content will end up on dvd eventually. On standard home tube monitors it’s not a problem at all. Push slides, which we use variants of quite often, are a particular problem area where the jump between 720×480 content and 720×486 is quite obvious.

Our solution has been to put black masks on the top and bottom of the frame prior to mastering but we’d love to avoid this if we could.

[Manny Kivowitz]

I appreciate the HD pov but I should point out that we are in fact seasoned pros, if somewhat new to producing multiple episodes of a national cable series. It’s pretty clear though that we’re not alone as television producers in acquiring our content on dv25, but what’s surprising are the lack of solutions for dealing with workflow problems that one encounters in an effort to put out a quality product. Yes, it’s understood that quality is a relative term when capturing in DV25 especially considering that even the best cameras of the “mini” class have small, relatively inexpensive chip sets and equally inexpensive glass. We’re using the dvx-100’s (7 of them plus 2 backups) and overall we’re quite happy with them. Would we like a better imaging device with prime lenses and less or no compression? Sure, but it’s just not in the cards for now.

Certainly no one would argue that HD is the future for all broadcast content producers but I would bet that most of us thought that some flavor of HD would have been the present by now. The problems we face in making the move to HD are many, starting in our case with the fact that non-subscribtion cable networks are simply not willing to ante up the budgets that would allow the majority, if any of their content, to be produced in HD. Also for our show we would need decent cameras with a small footprint (a requirement for the specialty multi-camera rigs that we’re using), reasonable pricepoints on those cameras (perhaps the pending panasonic hvx-200 will fit the bill)and quite a bit more storage for post than our existing 18tb of san storage supplies since we work on up to 10 1/2 hour episodes at a clip. Sadly, HD’s feasibility still looms in the future for many of todays content producers such as ourselves but I certainly look forward to a time when we can leave SD behind.

[Manny Kivowitz]

Thanks Gary, it’s good to know we’re not alone.. but it’s a shame that a vendor hasn’t stepped up to the plate to effectively deal with the issue. Pinnacle’s cinewave was a step in the right direction that sadly led to a dead end. Relying on the system processors to handle mixed codecs seems to remain a distant pipe dream.

[Manny Kivowitz]

Shooting DV, we’re stuck with 720×480 as our originating source. The problem is workflow and issues that arise from having 3 odd lines of black at the top and bottom of the frame (or white depeding on how you handle the move from dv to 720×486).

The workflow issues stem from the fact that all of our footage is created in 720×480 but our graphics are created uncompressed 720×486 and make up as much as 15% of the content of any one program. Our final sequences for color correct & mastering are 720×486 10 bit uncompressed. If you dumb the graphics down to 720×480 dv codec they of course look “soft” which is unacceptable for delivery but fine for offline. It is however an extra step and often the resizing of the gfx can cause issues later, especially if the editor has moved.

So we have the option of either working in a dv sequence till picture lock (with downcoded gfx), then upres the footage either through a software export, recapture from the sources or output back to dv/dvcam and re-import via sdi.

Or we can bring the footage in via sdi from the get go using motion jpeg for offline (we have enough storage to work either in full res dv through the rough cuts but not enough for uncompressed) and redigitize from the masters. The problem here is that all of our renders, working in a 10bit uncompressed sequence, will a)take a long time compared to dv renders b) take up a ton of space c) be required quite frequently

It’s hard to believe that with the proliferation of dv as an acquisition medium and the ever expandig prescense of graphical elements across all programming that we’re alone in struggling with these issues.. any insight would be appreciated.