TubeSock 3.0 has advanced to beta 19 (download TubeSock 3.0 beta 19 here!) and it fixes the crash on PowerPC / Tiger Macs in beta 18. Yes, we finally got our dead PowerBook G4 up and running, and after a seriously large amount of tediousness, we found the bug. It was in the new code that displays the FPS counter. Apparently the conversion can be slow enough on PowerPC that it exposed a condition where the buffer containing the FPS could be empty. The code has been re-written in a much more defensive manner, so a null this or a nil that won’t crash anything.

A few other fixes made their way in: fixes to a site that made a recent change, a rare condition where the output name could match the input name and overwrite the input file, and some more general interface tweaking.

Please download the new beta, and let us know if you find any problems with it.

My apologies for taking so long to get this release out. We made the decision to move our Windows codebase to cocotron, so that our Mac and Windows versions would come from the same code, so we’d have less code to maintain and thus could concentrate on features. (I see this is an increasingly popular thing with other Mac developers, too.)

However, the cross-platform TubeSock is not ready yet. So, last week’s chaos forced us to go back to the old TubeSock for Windows codebase and update it. Which we have finally done.

So behold, beta 18. Download TubeSock 3.0 beta 18 here! Please post problems in the comments (don’t forget to include the URL that failed, your OS version, and your CPU type). Our PowerPC Mac is still dead, so we’re especially interested to hear from PowerPC users.

A number of other minor bugs were fixed in this release, including: a bug where Dailymotion videos were improperly titled, a bug in the selection of high-quality videos (if the destination format is FLV, we don’t pull the MP4), and a bug in the creation of MP3 files. Also, for fun and edification and bragging rights, the conversion rate (frames per second) is now shown.

And by the way, all you folks who like to save MP3 files: if you’ve got an iPod, use AAC instead. Much better.

More info on the problem with Tiger here.

Me too, so I decided to figure out what the hell was going on, and it turns out that it’s all Adobe’s fault. Imagine that! Apparently, in the new Flash 10 release, somebody left a call to Debugger() in the code. This is in the final, non-beta Flash 10. I’d expect calls to Debugger() in a beta, but to leave that in a final release does not inspire confidence in the rest of the code.

So yeah, if your app uses WebKit, and you’re running your app in XCode, and some page your WebKit is loading has Flash content, bam. Instant stop.

Until Adobe gets their act together, the only solution is turn off “Stop on Debugger() /DebugStr()” in the XCode “Run” menu. Which means, if your own code uses Debugger or DebugStr(), sorry, you can’t use it until Adobe fixes their screwup.

Also, a few leftover NSLog()s were left in the code from troubleshooting the YouTube problem, which were removed. TubeSock should no longer fill your system log files with pointless junk.

Please report any problems you encounter in our support system. Please be sure to mention that you’re using the TubeSock 3.0 beta.

Also, we’re making plans for TubeSock 4.0. If there’s a feature you want to see added, let us know! And if there is a video site you’d like to see us support, please let us know by voting in this poll.

We’re working hard on Sumo! improvements. In fact, we do have a Sumo! 1.0.2 release waiting to go, once the 1.0.1 update is accepted.

Please accept our apologies. But we are totally and completely at the mercy of the App Store. Thanks for your patience!

However, we have gotten two reports of iPhone videos conversions showing up as all black (a bug we fixed in 2.0.3) for videos that we ourselves have successfully watched on the iPhone. So either (a) something weird happened in the universe and computer programs are no longer deterministic, or (b) there’s a deeper issue. Both videos converted in the 690kbit/sec range, so it’s possible the problem is that the bitrate cutoff is not 700kbit/sec but a hair lower. We’re looking into it!

• Improved compression profiles for iPhone, iPod, Mac, and AppleTV — this solves the “this file can’t be played on this iPhone” message that many users had been seeing
• Support for Unicode filenames with “Add to iTunes”
• Finally fixed that lingering barber pole/progress bar issue
• Detects formats it can’t decode (i.e. On2) and displays an appropriate message (so far, we’ve seen no On2 files in the wild, but we’re ready)
• Fixed an issue caused by YouTube using the Google video cache
• Added support for 2-pass encoding. Yes! Awesome! And then, after seeing it made no difference, we removed it.

You can download the latest beta release right here.