René Rebe

So Lena Meyer-Landrut indeed won the Eurovision Song Contest 2010 in Oslo as predicted by Google. She actually is from Hanover, which just happens to be the capital of the region where I grew up, too!

ExactCODE just released another major ExactScan product family update: the new version 2.10 brings the teased major surpise Most notably is the new and novel TWAIN Bridge. It allows to utilize the many built-in drivers built into ExactScan from other, third-party TWAIN applications.

Another magical feature is the new flatbed de-skew. While previous versions of ExactScan already came with, what I would call, industry leading auto-crop and de-skew for scan with the built-in drivers from the ADF (Automatic Document Feeder), recent advancements in our in-house R&D (Research & Development) allowed us to add truely revolutionary de-skew even for flatbed scans! It allows to intelligently track objects on the flatbed glass and auto-crop and de-skew sufficient rectangular objects, such as: letters, receipts, post-cards, CD covers, coaster, etc.

Of course we also continue work as usual on the next maintenance update.

Read more: ExactScan homepage

So, you are just hacking on your boot loader, BIOS? Need to verify the executable binary you get out of GCC, LLVM? Or need poke into it otherwise, because some commercial, binary-only does not want to behave?

objdump -D -b binary -mi386 -Maddr16,data16 thy-binary

After the amazing success of the last, and very focused ExactScan release we continued the same with OCRKit. Version 1.2 shipped with hundreds of new internal test cases and all bugs closed that our valued customers brought to our attention, not to mention the always improved recognition accuracy. Oh, and last but not least we engineered a new de-screen filter that we also put into this OCRKit release, it can drastically help recognizing text on dotted background, like 25% or 50% dot background as used so often in popular spreadsheet applications.

Simply dag’n drop your files on the OCRKit application icon.

Today (yes, a Saturday, don’t ask I have to work any day, …) I had to hunt an ugly bug for a custom. Actually that gdchart, an aging PHP charing extension, does not work with PHP 5.3. Actually an issue that is all over the web and zillion of people want to see work and a patch for.

I wonder why there are no patches for this apparently kind of prominent issue. Anyway, after too much time diving thru all the mess that is PHP (yeah, I’d prefer nearly any language, such as Lua, but that is a different topic), I found the culprit the all so often “private, modified, and statically linked copy of a library” problem. Point in case: libgd, an albeit aging and ugly graphic library by itself.

So PHP 5.3 changed the symbol visibility and no long exports the libgd symbols the gdchart extension needs to perform it’s work. So after finding all this out the fix (or workaround, whatever you wanna name it) was trivial. I wonder why noone else came up with a fix, yet. Though, maybe PHP website constructors are just not up to digging thru such details.

Point being: Don’t ever, never ever, copy a library into your project and link it in statically. You’ll doing anyone a favor. Not yourself, not the distributors, nor the users. Yes, I understand it’s tempting, and worst historic coding practice. But don’t! It will just duplicate workload and headache. Not only will it age, be subject to security issues, bugs and lagging features long after the upstream library was improved. You’re unlikely doing a better job on it than the original authors. And from my T2 experience I know it! Maintaining all the thousand packages I have seen it all: from zlib, to libjpeg, libtiff, libpng, libgd, or lua, you name it.

And for the higher educated readers: You will also waste storage space by having the same executable code bundled multiple times, as well as also consume more virtual memory as those multiple executable chunks have to be mapped into memory multiple times as well, …

Subject says all! It is great to see modern, efficient, and supposedly not patent encumbered codec pushed by a major vendor.

It got a new name, too: Now called WebM = VP8 + Vorbis in an Matroska container.

Update: Apparently does not really live up to expectations, … :-( Though at least more open video codec code, and traction in the X.264 patent debate against Theora, et al.

Update 2: And in T2.

So Android 2.2 adds JIT, Just-In-Time compilation of the Dalvik Java VM. This must be a joke. They tried to compete on the mobile space with that slow apps? Against other, native, frameworks. No wonder Android was that lagging. And it took them over 5 years to get to JIT? I’m feeling lucky I didn’t got an Android phone :-)

Now Adobe continues to get crazy about one set of devices not supporting Flash. Just like a yearold taken the lolly from. However, this is pure bullshit^10.

In the beginning (about 10 years ago) Flash was mostly about animated advertising. And no-one wanted it. Heck it wasn’t even available for a vast majority of U*ix a-like systems and Macromedia gave a shit. Then came it time where Flash was used for more useful things, and whole web-sites where implemented in it (though still mostly advertise driven micro-sites for product placement, anyway). Open source folks actually wanted to start to view them, but the Flash player was then still only available for i386, 32bit. Still leaving the vast majority of other architectures and U*ix a-like systems out of luck. Heck, Macromedia, now Adobe even hindered attempts re-implemtngin Flash in an open source way. Open source implementation, such as Gnash are still not complete(ly usable).

And now, just because Apple decided not to support Flash on the iPhone they go nuts? Hello founders of Adobe: Do you actually noticed how much we went nuts that there was no Flash for Linux/Alpha, Linux/PPC, BeOS whatever? No Photoshop for Linux? Do you care about that?

Of course Apple position is likewise awkward: Not supporting Flash in their Mobile Safari is one (reasonable) thing. But forbidding other developers to use certain programming languages (like Lua, Python, Ruby, or this crappy Flash if one absolutely wants, to) in the Apps they then can only sell via the iTunes App marketplace is another, not very nice, move at all.

Certainly Adobe is just all nuts, because they see their cash cow going under. But truth told: The web is about web, is about the web, is about the web (www, got it?). That is by it’s initial definition HTML+CSS+Javascript, in modern words: AJAX. What unportable plugins try to add there (read Flash and other crappy, Active-X plugins, et al.) is not “the Web”. That are proprietary and unportable platforms tried to establish by companies to generate a cash flow. Nothing else. And in times of HTML5, Canvas and Video certainly not needed anymore, anyway.

The least thing you want on your mobile phone is pure software video decoder, that’s not using SoC accelerators, rendering everything in RGB spaces, and burning CPU and battery like nothing else. That’s certainly no help for the all so important mobile device’s battery life and smooth interactivity. Actually even on my multi-core notebook the fans start to spin up when I just read an article on an Flash advert laden news-site and those Flash ads are playing their game, even in non-visible parts of the site!

That the iPhoneOS (and thus the iPod Touch and iPad) finally contribute to the downfall of the Flash legacy is certainly the only positive thing the FSF and open source folks can find in Steve Jobs recent actings.

However, the use of patent encumbered H.264, in either Flash or HTML5 is certainly another non-open issue on the modern web.

I did not miss Flash 10 years ago under Linux, still do not have it on my Linux machines, and will miss it even less once Apple decided to ship the IPad in the non-US world, that is Europe and I can hold an iPad in my hands.

The world does not ned a proprietary web, does not need Flash. Then again the wold needs nothing from us, but humankind needs peace, freedom, and more so drinking water and food for all in any area of this world.

A long long time ago, 2+ years or so, I got the Apple Bluetooth Headset to accompany my iPhone. The Apple Bluetooth headset is pretty, astonishing, and awesome(!) tiny, slim and sexy. One could say of superb design –a design icon– that could live in a museum (like near the G4 Cube at the Museum Of Modern Art).

However: It features the worst audio quality I experienced, ever. Even worse than an IBM PC XT/AT PC speaker. Noisy, damped, and other block artifacts that sound like skipped, dropped Bluetooth packets. Absolutely uncomfortable to talk over. Some is certainly due to the monophonic and low bandwidth Bluetooth Headset Profile (HSP). However, other headsets sound at least somewhat better, and usually do not have that many gaps, due poor Bluetooth signal, dropped packets, whatever.

Battery life is also not that stellar, some some hours of talk time, and a day standby (or so). Which is certainly no surprise given the tiny nature of the device, and the therefore absolutely miniature battery somehow squeezed into it.

The biggest selling point certainly is the smooth iPhone integration, including the automatic pairing when connected to the dock connector, and battery level indication in the status bar, and recharge lock screen.

In retrospect, the Apple Bluetooth Headset is actually the gadget I least used, ever. Given the poor Bluetooth connection and battery life it is certainly no wonder even Apple stopped sales and took it off the market just months after it went on sale.

I wanted to try out Bluetooth stereo audio for some time, now, and just got myself my first bluetooth headset, ever (more on that in another post). As audiophile my first impressions where a little mixed, but eventually I figured out why they where worse under Apple’s Mac OS X, even compared to Apple’s iPhone 3G. Some excessive research turned out why (beside the crappy SBC codec mandatory in A2DP): OS X’s “BluetoothAudioAgent” may use forbidable low bit-rates for the forbidable bad audio codec by default! The straight-forward, cut’n past-able tweak is as simply as running this in your terminal:

defaults write com.apple.BluetoothAudioAgent “Apple Bitpool Min (editable)” 52

The max may be 64, however, 56 did resulted in the agent to connect to my headset, 52 worked. Please post a comment if a higher rate works for you, or you need an ever lower value (btw. the default appears to be as low as 2! …). Now with the tweaked setting a lot of the noise, hissing, and other compression artifacts experienced with A2DP under Mac OS X are gone! :-)

On the way I found out something likewise interesting: The menu extra’s (the little widgets in the top-right area of the menu) show alternate versions when clicked with the Option key hold down (unlike other, regular, option-click context menus for this easter egg a possibly enabled, real right click is not enough, you have to Option-click).

For example the WiFi one shows some internals: BSSID, PHY mode, channel, encryption, … the Audio one lets you switch your audio sources (!!!), the Battery one shows the condition, and the Bluetooth one display the version, and entries for the Bluetooth Explorer, Diagnostics Utility, and PacketLogger. Neat!

Which finally brings me to the UI way to do this tweak: Option-click the Bluetooth Menu Extra : Open Bluetooth Explorer : Utilities : Special Options… : Audio Options : For A2DP connections use these bitpool values: Minimum : 52

Personally I find the “Special Options…” particularly amusing.

By-the-way: performance metric on the side, on an underperforming Atom Z530 iTunes consumes 11% CPU (3% on a 2.2GHz MacBookPro) decoding an average MP3, and the BluetoothAudioAgent a little more than 16% (5% on a 2.2GHz MacBookPro) to encode the audio stream into the sub-standard SBC (Sub-Band-Codec). Not only would MP3 codec over A2DP support in more headsets and Bluetooth stacks save at least those 16% of the re-encoding, it would also save some of the 11% initial decoding, and improve audio quality by magnitudes!

Hardware vendors, please? Guess it’s time to bring my own advanced-codec Bluetooth headsets to the market :-)