Ren Hinks
Forum Replies Created
-
[Scott Witthaus] “I have been with Avid products since they came to the market and I think you have a bit of rose colored glasses look going. Yes, avid is a great product and led the way, it took more than a few tweaks and adjustments for upgrades.”
[Scott Witthaus] “I was a beta site for many versions of Avid DS and I can tell you, not all the bugs get washed out in beta testing. Hell, pop over to the XpressPro bulletin board and check on the Domain Copy bug or the runaway playback bug that has haunted that software for several versions. Avid editors are putting up with that!”
Yeah, it’s possible that I’m a bit nostalgic :>) but I only worked with MC, not Xpress and never took the system to Adrenaline. In the first couple of years after I migrated away from tape based editing and tried several other brands before settling on AVID, it seems now in hindsight that AVID was then (93-94) competing with hardware based systems and couldn’t tolerate too many software based problems in order to get editors sold on the AVID NLE.
My discussions with editors were primarily at the annual International Users Group meetings that AVID hosted for several years – mid-90s. Perhaps one remembers best what was at hand – Beta testers are LOOKing for bugs, editors are not.
AVID said at one of these Users Group meetings that one needed to allocate $10,000 a year to keep a MC up-to-date – they were right up front about it. And the tech help, which at that time was bundled with the software maintenance program, really saved my butt one night at 1:53 AM so I can’t agree about it being worthless. But to keep my post on-thread, I’ll just convey this: as annoying as it was that AVID didn’t “qualify” it’s app for a MAC OS upgrade for at least a year and sometimes longer, their policy seems to mirror what folks are saying here – wait for the dust to settle. Their board sets were cutting edge but the OS it ran on was not bleeding edge. Apple’s policy throws a monkey wrench at that mindset by tying the app upgrade directly to an immediate OS upgrade.
ren
-
[Jerry Hofmann] “Marco’s suggestion to use the second SATA bay for an “ease into it” solution running Tiger and FCP 5 is exactly what I’ve done. I still have a 10.3.8 system running 4.5… But I’m finding bugs in 5 and sending them to apple for their perusal. Yeah it sounds like beta testing and from a point of view it is. But the grass isn’t greener anywhere guys. I’ve been running NLE’s since there was NLE’s and it’s never been different.”
Well, I gotta differ here on the opinion that “upgrading an NLE has never been different.” I used an single AVID MC system from 1994 – 2003 and through all the upgrades, there was never a need for a separate HD or huge concerns about the upgrade process – little adjustments, yes and an occasional phone call (AVID tech assistance never made me feel like I was getting the run-around but it did cost $2500 a year) but the software/hardware in all of its incarnations always felt in general like a professional tool, even when one upgrade required reformatting all existing MediaFiles using a utility AVID provided. Upgrading FCP however seems to have far less hand-holding – but consider the price difference!
I now have an FCP station running 4.5/10.3.9 and although FCP 5 (actually Final Cut Studio) and Tiger are sitting here next to me still in the packing box, it never really occurred to me to think about installing them until my current projects are complete – who has the time for the learning curve if you have imminent deadlines, let alone major de-bug issues? And because of the price differential, I have never expected FCP to be more stable than an AVID MC, so one better have more patience than would be expected using an AVID product. It’s great that the FCP feature set induces comparisons to its bigger cousins but to me there is a limit on what one could expect from Apple.
At the risk of being unfair or even just flat wrong; Apple is a generic Software/Hardware company, not a Video Production equipment company and its upgrades seem more like what you’d expect of a computer company rather than a video equipment company – end user beta testing. Imagine buying a Grass Valley switcher (10-15 years ago anyway) and experiencing anything but flawless operation straight out of the box (you did do a LOT of studio-wide analog aligning on a weekly basis though.) :>)
Finally, although I’m glad I checked into this COW forum to see if the dust is starting to settle on the upgrades, I don’t know how I would be able to use the 2-boot drive scenario. Both of my d2 G5 drive bays are populated per the advice I gleaned from this forum when I first bought the system – I bought a second SATA drive right away just for FCP direct use media while the original 160 is for apps and non-FCP media. But the 2-boot drive concept certainly seems sound even if no AVID editor I know of would put up with a Media Composer upgrade that caused this much grief.
ren
-
[Todd Beabout] “What kind of problems do you guys get using Compressor from FCP?
I only ask because after burning 100+ DVD’s in that manner, we have had no sync issues at all to deal with.”
I’m new to FCP (AVID editor) and I’ve spent the last day trying all three options listed in this thread with a :45 minute piece and I have had no sync issues with any outputs.
Exporting as a Non-Self Contained “Quicktime Movie” (using the Current Sequence settings) versus exporting “Using Quicktime Conversion” made more sense – no need to re-encode anything before it hits the Compressor encode to MPEG-2 as far as I can tell; just create a QT reference file.
There was no hiccup in the Export using Compressor either (I also HAD to try it when someone says it doesn’t work :>) because I was exporting Interview SELECTS on DVD to the writer and was using the TimeCode Reader filter on top of all the clips which caused FCP to Render a Self-Contained QT even when using exporting “Using QuickTime Movie” and not checking “Self-Contained”. I’m assuming FCP does this because the added filter had to be “rendered” for export even though the timeline was still “grey” – I definitely couldn’t trim clips in RT before the Export with this filter on – dropped frames like crazy.
The resulting QT “Reference” file was 7 GB so I thought it would be great if I could avoid that step and go directly to Compressor – it worked OK. But it’s clear that it ties up both FCP and Compressor so it made me wonder; are there problems if there is not enough memory on-board to run both apps in this manner. I’ve got 2GB ram in my box.
ren
-
[Will Kruger] “does compressor encode CBR? I haven’t found a setting.”
In Compressor, the CBR setting for video is the first choice, “One Pass”, (without any mention of VBR) which sounds however like the setting you first chose.
[charles simonson] “Or did you encode the video with Compressor at CBR, and the audio with BitVice Helper, which encoded the audio at VBR? If you must have CBR audio, then I suggest taking your AIFF and encoding it to MP2 with ffmpegX.”
If I read Charles’ post correctly, it sounds like BitVice Helper encodes the AIFF audio generated by BitViceHelper into MP2 with VBR while another free app, ffmpegX, can encode the MP2 audio with CBR. There seems to be no controls in BitViceHelper to alter the BitRate method and the doc makes no mention of it. BitViceHelper can be set to just do the multiplexing if the MP2 audio is previously encoded with another app.
My 2c is that there might be an issue with the timecode embedded in the Compressor encode, but I’m only guessing – I used to use PCMCIA flash memory card MPEG-2 players for controlable looped exhibit playback of video and it required multiplexed MPEG2 files, and since ir could be programmed to play just sections of video files, it kept track of timecode and was pretty picky about it. There is an option in Compressor to “Choose start timecode” and a “drop frame” checkbox – perhaps there is something there.
ren
-
After encoding with Compressor, I’ve successfully used BitVice Helper Multiplexor from Innobits. In the process of combining the video and audio files from Compressor, it also converts the .AIFF audio to .MP2 in the multiplex.
It is available at https://www.innobits.se/pubdown/BitViceHelper.sit as a demo (free) download (~900 kB) – the app also comes with a small Read_me.
ren
-
I just recently captured 10 hours of footage shot on a rented Panasonic DVX-100A and had the same FCP error message (VFR/Pulldown Cadence Error) show up on just about every single tape, usually just one instance every tape but one tape had several spots on it. I say spots because in every case, the problem was exactly at the same point on the tape every try. The only way I found around it was to skip over that small portion of tape.
This really changed my workflow which was geared toward digitizing all the tapes in a short amount of time (the rental was due back). My initial method was to attempt to digitize the entire tape using the “Create New Clip” option to work around the Panasonic generated timecode breaks (there were a TON of those – not anything like working with a SONY 600 BetaCam but I really wanted 24 PA for this project). I ended up taking the time to log and capture to make sure there there was at least a record of offline clips saved to the browser and that when I did run into the error, it didn’t take out a huge clip that I would have to take the time to re-do again, in smaller chunks. I learned the hard way because one of the first times this happened, it not only stopped the process after about 40 minutes of digitizing, it deleted all the new smaller clips that had been created due to the broken timecode AND the clip’s linked QT media as well. I had to start completely over on that tape – not a happy camper at 2 in the morning.
FCP was fine with automating its creation of smaller clips with continuous timecode from broken timecode tapes but was stopped cold with the cadence error. It asked to “continue” or “cancel” as you mentioned but I don’t believe that FCP would do anything more than a “retry” if you clicked “Continue”, not adding any extra processing in an attempt to increase the possibility that the clip would successfully digitize a second time around. Also aggravating was that most times when the error occurred, I also found that FCP had been corrupted and usually had to save my project, exit FCP and restart it to get normal operation back again. I asked the rental house about it when I returned the equipment but they had never personally experienced the problem nor had they heard any other users of the camera report a similar problem.
Your report of the very same problem has me thinking that there is a design weakness in how the Panasonic prints to tape (or a problem with the tape stock itself – I was using the rental house recommended Sony DVM60EXL) as none of my cadence errors occurred at start/stop points – always mid-stream on a shot and not even during unusual physical conditions such as sudden camera movements.
These errors did not show up when I first copied the entire tapes straight into a DVD recorder to show rushes to the producer, so it seems like it has to do with a mis-print to tape that causes the FCP 2:3:3:2 advance pulldown removal algorithm to hit a snag for which there is no “on-error” code to work around the missing frame count or even exit gracefully.
ren
-
[Sean ONeil] “SOME older Decklink models have some sort of effects handling built in, but everyone now knows to turn those off because FCP’s software RT Extreme is 10 times better.”
Great explanation.
[Sean ONeil] “When I said export as Uncompressed, I meant export FROM the Avid TO a Quicktime file using Apples “None” for the codec. That just means uncompressed.”
Uncompresseed=none. The light bulb goes off (or on).
[Sean ONeil] “Going from Avid 2:1 to Apple Uncompressed is fine. You don’t need to redigitize using Avid 1:1 – if that’s what you’re asking. “
I re-digitized last night to 1:1 as it was only a :30 ad on a BetaCam SP Edit Master. I’m just replacing head and tail graphics and adding animated LiveType over some of the body. I actually thought I saw a difference on the AVID between 2:1 and 1:1. Expectations are a bi*#h…it was late…
[Sean ONeil] “And again, if you don’t have the hard disk speed to handle Uncompressed on the Final Cut box, you need to go with DV (even thought that’s not a great idea for onlining).”
As far as I know I have enough horsepower now that I know that people don’t usally have to use outboard processors for Uncompressed. I have: G5 D2, 2GB ram, 165 and 300 SATA internal drives. Even a 10-bit encode/sequence ran last night without a warning of dropped frames from FCP. Please say this is OK! – there’s no more income until at least one of these puppies is out the door. :>)
[Sean ONeil] “If you do need to use the DV codec, then you may as well just dub a DVCam- the end result is the same plus you save a lot of time and hassel. “
I don’t know that I could show up at the agency with a DVCam after I was handed a BetaCam for source. ;>)
Cool. Fantastic help – much appreciated.
ren
-
[Sean ONeil] “The reason you aren’t seeing a difference between DV and 8-bit because you’re using the Firewire as your output to the broadcast monitor. Firewire outputs DV, DV50, and DV100 only. Nothing else. So the 8-bit is essentially being converted to DV as you play it back- hence you don’t get RT playback, only 1 frame when paused (BTW, hit option-P for close-to RT preview).”
[Walter Biscardi] “recorder is always running the footage through an MPEG-2 compression cycle before it gets to the monitor “
First of all let me thank you for the feedback – its extremely helpful – I’ve got three DV 24 PA projects mid-stream that have to get finished pronto and a re-edit of an ad walked in the door yesterday, all with April something deadlines. 480 versus 486 output is something this AVID editor never had to think about before – everything was 486 mindset except for export to DVD.
The reason I thought there was little difference between 2:1 Meridian compressed footage transcoded to DV or to 8-bit was that even though I could only look at stills of the 8-bit sequence, it seemed to look no different than stills of the DV sequence. However, there could be BIG differences in running playback seen through a card or IO hooked to a broadcast monitor – I thought looking at things through the DVD recorder to act as a Firewire bridge was a kludge but I didn’t even think about the MPEG-2 conversion it would apply to its output – thanks Walter.
Perhaps the two sequences looked identical because of the MPEG-2 compression being applied to the image but my initial reasoning had more to do with data rate comparisons of the original Meridian 2:1 Compressed file, the DV and the 8-Bit file – since one can’t improve on an image when transcoding, I reasoned that since the datarate of the Compressed Meridian was very close to the datarate of the DV transcode, that the original file’s resolution was the limiting factor. There is some proprietary encoding of AVID’s native codecs so that may not be a completely accurate assessment.
[Sean ONeil] “If you stick with the Apple 8-bit codec (or Blackmagic), and you have YUV rendering on, you won’t have to worry. As long as you don’t convert the colorspace, it’s 100% lossless.”
So to cut to the chase, now that I know I have the re-edit job of a :30 originating from a BetaCamSP edit master, I encoded it to the AVID here using 1:1 Uncompressed instead of 2:1 as I did the night before and then dumped that out to the G5 as a Meridian Uncompressed QT.
I have to go through the interim stage of using one of the Meridian codecs for export because the AVID is running on OS 9.0.4 and Quicktime 4.1.2 (the owner refuses to put any money into upgrading it, hense my migration to FCP) and has no 8-bit export option, only M-JPEG. I tried to D/L the Blackmagic 8-bit codec but the web site only has codecs for Windows systems and Mac OS 10.x; nothing for OS 9.x (even though there is a OS 9 logo in the codec D/L sidebar – I emailed Blackmagic about this).
On the G5, I transcoded the Meridian Uncompressed QT to an 8-bit and file size and datarates were almost equal. Using the 8-bit encode derived in this manner makes more sense to me and although I’m still not able to monitor the sequence on a broadcast monitor, the picture looks much better on the computer screen in FCP. FWIW, FCP is not happy trying to play a sequence based on the Meridian Uncompressed codec, hence the transcode to 8-bit for FCP use.
Someone in this thread earlier mentioned using MJPEGA for transport but I think I read that it is lossy, even at 100% – is there any reason to use that versus 8-bit?
[Walter Biscardi] “The G5 is the engine that drives most of the realtime functionality of FCP. You can work in full uncompressed video space without the need for any PCI cards by using the AJA Io which is an external I/O device.”
From the Blackmagic Web site:
DeckLink cards feature:Realtime effects in Final Cut Pro. Cross Dissolve, Dip to Color, Sepia, Desaturate, Brightness Contrast, Proc Amp, Tint, Gamma Correction and 3-Way color Corrector. RT Extreme support in Final Cut Pro
-
My rules (after 29 years of this):
(1) Please yourself.
Make the program something you yourself would want to watch. When responding with a re-edit to comments that matter, re-please yourself again as well. (If possible – I despise wannabe Producers.)
(2) Satisfy your ego with good storytelling, not technicals.
Something technically difficult might be nifty for you, but have no effect on anyone else. Watching video and audio tracks separately is a great idea – people tend to respond most strongly to one of three things; visual, auditory or feelings. If all three channels tell a good story, you’ll hit a wider audience. On the other hand, if you’re creating station promos, knock yourself out.
(3) When there is repetition in the various critiques, pay attention.
People WILL give you a critical opinion if you ask them, otherwise they might like the piece just fine. I usually start with, “did you like it”, not, “what do you think”. And, if a positive comment is repeated, try not to remove that element on any subsequent edits. If possible, ignore random negative comments that are not repeated by others unless they echo your own sentiments. However, the Boss is still the Boss. (Did I mention that I despise wannabe Producers?)
(4) Know that you won’t REALLY know how well you like the piece until 6 months after you’ve finished it.
While in edit, the flashlight beam of your focused consciousness is very narrow and moves quickly, making it hard to imagine the whole room you’re rearranging. Molehills that become mountains in edit, usually become molehills again in time. In 6 months, the quality of the story will become apparent as you finally become a viewer.
(5) This is a highly subjective business – get used to it.
Try not to take it too personally.
ren
-
Thanks all. I’ll give the Blackmagic codec a try. The Meridian is nice because the G4 based AVID takes forever to export any other codec, but if it causes problems with the rest of the process…
After more experimenting and reading, it seems possible that what I may be seeing on my computer screen is an artifact of RT FCP playback of non-DV clips due to the lack of hardware support and not anything that will end up in the edited file for export. I’m getting the impression (I REALLY need to take a crash course) that FCP is dependent on PCI cards and other hardware to provide extra horsepower for RT playback of anything more challanging than 720×480 DV.
I hooked up my stand-alone DVD recorder to act as a Firewire to S-Video output for my broadcast monitor and quickly learned that when the FCP Output Video says “NTSC DV (720×480)”, it doesn’t mean “FCP will RT playback 720×486 sized video through a 720×480 Firewire converter.” I need hardware
. When I cropped my Meridian QT file to 480 while encoding it to either DV or DVCPRO 50 codec and imported it, FCP acted like everything was fine, AND, I couldn’t see any difference on the broadcast monitor between the 8-bit sequence (I could only view stills of this sequence on the broadcast monitor) and the DV sequence. So I’m assuming that the limiting factor in this project is the quality of the original Meridian QT export from the AVID, originally encoded at 2:1 compression.
ren