What ever happened to the Shake replacement?

Last we heard, Apple was planning to ship their replacement for Shake sometime in 2008. I was kind of expecting that we’d hear something at Siggraph, but Siggraph is underway and there’s not even a peep from apple. I wonder if we’ll still hear anything this year, or if Apple is going another direction with that project.

YouTube audio compression (volume, not bits) smashing up sound

Slashdot ran a story a few days ago, discussing the new audio compression filter YouTube seems to be using on content. Essentially, they’re trying to get everything into a single intensity range to, presumably, make jumping between videos on YouTube a bit more pleasant. However, like anyone who uses a compression plug in for the first time, they’ve over done it. Waaaay over done it.

There’s a thread on YouTube’s forums discussing the issue, and a fellow named ‘ccalam’ has posted a video demonstrating what happens with and without the compression.

The fix, until YouTube does something, is to mix in some constant volume high frequency noise, which will get stripped during the bit-compression phase, but which misdirects the audio compressor enough to keep your actual audio safe.

I can sort of understand what YouTube is up against, as this is an issue I struggle with on Media Mill as well. There are lots of things I can do to make really bad videos look and sound better, but those same things will make good videos look and sound worse. You always try to walk the line between both extremes, but you always wish you could do more.

XDcam EX + FileVault = Fail?

I was using an XDCam EX on a MacBookPro today and getting very strange results – copying the BPAV folder from the SXS card to the internal drive resulted in totally corrupted video in both the Clip Browser and XDCam Transfer. When I tried copying the BPAV to an external drive, there were no problems at all. The laptop had FileVault enabled. I’m beginning to wonder if FileVault interferes with the XDCam software in some way.

More testing is needed, but it’s very curious.

I can spraypaint over the Nvidia logo too…

This press release from Pixellexis/Ambric Silicon caught my attention today. Pixellexis are the folks who tried to raise a buzz at NAB this year with their RedBox external processing unit. Every time I went by their booth, it was a bit empty. As Mike said, “I’m not sure I’d start a company based on the idea that computers will never get faster.”

In any case, the press release talks about the new Ambric Silicon chips they’re using, which have 300+ cores in a single die. Which sounds suspiciously like a commodity GPU. With OpenCL in the near future (and far cooler than the public info would have you believe), it’s hard to imagine dropping serious cash on a proprietary secondary processing unit.

So, I’ve been reading the US Code

It’s funny, there’s an awful lot of stuff in the US code that would surprise most folks.

For example, in the world of video production, folks often talk about how there are certain buildings that are copyrighted, thus preventing their incorporation into videos. Or else folks say, “it’s a gray area” …

One gets the feeling that it’s in the best interests of the copyright holder to keep this a “gray area,” because confusion leads to capitulation.

Doesn’t seem very gray to me.

(a) Pictorial Representations Permitted.— The copyright in an architectural work that has been constructed does not include the right to prevent the making, distributing, or public display of pictures, paintings, photographs, or other pictorial representations of the work, if the building in which the work is embodied is located in or ordinarily visible from a public place.

Title 17, Section 120.

I’m working on a more extensive post dealing with some of these issues.

Sinful coder

The Adobe Flash plugin for Quicktime seems to only support movies with a duration of 2^24 milliseconds. That’s about 4 hours and 39 minutes. Funny enough, I had reason to compress a 4 hour and 41 minute movie today. The FLV format is supposed to support up to 2^32, using an extended timestamp attribute, but it sure doesn’t seem like the plugin makes use of it. After 16777216 milliseconds, we roll back to zero.

Interestingly though, the files are still valid and playable, they just can’t be indexed properly by the various FLV metadata injectors. And progressively downloading a four hour movie isn’t such a great choice.

The fix? When you’re injecting metadata, watch for the timestamp to roll and then just tack on an extra 2^24 to all the timestamps from there on out. It’s a bit dirty, but it’ll work, since the truth is you’re matching timestamps to byte offsets – once you’ve built your metadata array, the timestamps in video packets don’t matter.