[Mel Matsuoka]

I use Sorenson Squeeze for doing my mp3 conmversions. I haven’t found anything else that lets you do batch conversions and FTP uploads automatically.

Technically, the LAME mp3 codec is the best one for high-quality, high bitrate mp3s. I seem to remember that someone had figured out how to hack iTunes to use the LAME encoder instead of the built-in Fraunhofer codec in iTunes (which sounds absolutely horrible at nearly any bitrate, IMO)

Oddly enough, Squeeze is the only application on the Mac that can make decent sonuding low-bitrate mp3s (for audiobooks, podcasts, etc). It’s annoying that it isn’t Universal binary yet, but it still works fine.

[Mel Matsuoka]

Hi Luke,

Thanks for your response.

I guess I should have mentioned in my original post that I’ve trashed prefs and loaded the project under different users until the cows came home. Those are among the first things I do whenever I’m troubleshooting an issue with FCP.

Unfortunately, none of those procedures worked to fix the problem. In fact, a few weeks ago, I reinstalled the entire OS from scratch, thinking it was a system level issue. But this did not fix anything, either.

The problem seems to appear like clockwork now…print/edit once to tape, then try it again, and it barfs out the green (or no signal at all).

We are really at our wits end over this issue…please help.

[Mel Matsuoka]

I second the recommendation for the Extigy.

If you have simple monitoring needs, it’s the perfect, most inexpensive solution I could find. I bought 3 of them on eBay for around $150 total.

[Mel Matsuoka]

It’s funny you mention this, Jon, because after about 4 hours of troubleshooting, the only way I could get my system to output to BetaSP dubs without the wierd dropouts was to to unplug the reference signal to my Decklink’s Genlock connection. Of course, this caused rolling sync-bars on the Beta deck on E-to-E, but when playing back the tape after recording, it looks fine.

[Mel Matsuoka]

I too am getting the same “No Video Input” flashing issues (Decklink Pro card on a Dual 2.0Ghz G5, being fed an SDI signal from the Workgroup Videohub). In our case, it happens only when the FCP Log & Capture window is open. It just started happening all of a sudden for no apparant reason, and after exhausting all troubleshooting measures that I could think of, I broke down and re-installed the whole G.D. operating system from scratch, reinstalled FCP 5.1.1 and the newest BMD drivers…

…but alas, the flashing STILL continues 🙁

So what gives, good folks at BMD???

[Mel Matsuoka]

Wow…I thought I was the only one who has experienced the enigmatic “channel condition” problem!

We had the same problem with our A500 (channel condition light & tinny, distorted audio on output to tape), although in our case, the only thing that fixed the problem was to simply physically restart the Blackmagic Workgroup Videohub (an SDI router) which was feeding the deck. Restarting our burst generator didn’t do diddley-squat though…go figure.

It seems to be a completely random problem. I haven’t seen it occur for months now, and the only thing that has changed with our facility’s FCP configuration is software/driver related.

[Mel Matsuoka]

There is some serious wonkiness going on with either FCP -or- Quicktime when it comes to luma and chroma shifting. We had this problem back when we were running the AJA IO, and it has caused me nothing but headaches and embarrasment when doing finishing work with a client looking over my shoulder.

At least with FCP 4.5 & QT 6.5.x, I get shifts in my footage (noticeably visible on scopes, as well as in a difference-matte) even if I simply export a completely untreated clip (digitized as UC 10-bit) as a reference movie out of FCP, and then re-import the reference movie BACK into FCP!

I’m perfectly aware of YUV-RGB colorspace conversion issues, but it seems to me that an uncompressed 10-bit clip, exported out of a “high-precision YUV” sequence (either to the exact same codec, or ESPECIALLY as a simple Quicktime reference movie) should NOT exhibit any color/luma shifting when re-imported back into FCP.

I did extensive tests with this, and found that the only way I could get acceptable results was to *completely* bypass using FCP to export clips, and bring the original clip (from the Finder level) into AE, and–this is VERY important–setting the project to 16bpc before rendering back out. With 10-bit footage, there is still a very slight shift that is visible on the scopes (as is to be expected, since AE only works internally in RGB colorspace), but for the most part, it’s not noticeable to the naked eye, unless you strain your eyes real hard.

While this method works, it’s really a huge pain in the ass to have to eyematch shots and edits from the originally digitized clips!

After all the tests I’ve done, I can only come to the conclusion that there is something *seriously* broken with FCP’s Quicktime export functionality. I don’t think it’s a Blackmagic issue, because as I mentioned before, I had these same issues with the AJA Io.

I haven’t yet tested any of this on FCP 5/QT7/Tiger, and was hoping that it was fixed. But obviously it hasn’t 🙁

Aloha,
mel

[Mel Matsuoka]

I forgot to mention that I’m running Final Cut pro on a Macintosh G5. With a Radeon gfx card, PCI SATA adapter and the Blackmagic Card, there’s basically no room for another card.

[Mel Matsuoka]

[Igor] “I presume that you will have sinc problems with soundblaster on long ( over 6 or over 12 minutes ) clips.”

Why would I get sync problems with long clips? All the D/A conversion from the SPDIF input happens on the external Extigy box (I presume) and doesn’t even get sent to the computer (again, I assume).

Aloha,mel

[Mel Matsuoka]

[MATT LEMOS] “I need a shower after this news. Betrayal doesn’t even begin to describe this and it’s for Hollywood no less. Don’t those people get it that no matter how many times the try to come up with the latest Copy Guard someone is always going to find a crack for it. Get over it already, the rest of us producing stuff have a long time ago.

Also I am not convinced that Intel can handle the Graphics required for the Mac Platform. They never have been able to before.”

“Betrayal”??? That’s completely ridiculous, and something only a completely deluded Macintosh “fanboy” might say.

First of all, Apple did not do this to appease Hollywood. Intel’s foray into DRM enabled processors may be a fortunate (or unfortunate, depending on your viewpoint) bonus for them, in that it opens up iTunes for digital video content distribution. However, this change is all about staying competitive, simple as that. If Apple had stayed with it’s lackluster G5 architecture for much longer, it would surely have spelled the death of the platform as a viable alternative to the Wintel hegemony.

As far as not being convinced that Intel “can handle the Graphics required for the Mac platform. They have never been able to before”, all I can say is, what have you been smoking, and can I have some of it? 🙂

Graphics processing has been superior on the PC side of things for many years now. The bevy of high-performance, low-cost graphics cards available on the PC puts the Mac to shame. And as far as raw processing power is concerned, I am a heavy user of both After Effects and Photoshop on both our Dual G5’s and PC’s (I’m completely platform agnostic…computers are just tools to me), and the performance on our Windows machines are noticeably better than our G5’s. I wish that wasn’t the case, because as a FCP editor, I’d prefer NOT to have to switch platforms as part of my workflow, but I can’t deny that AE works better on Windows, and so I use it.

Aloha,
mel