Brain Flush

January 24, 2008

Cowon iAudio D2 – PMP With Two Faces

Filed under: Hardware & Technology, Mobile Devices — Tags: , , , , , , , , — Matthias @ 10:23 am

I am currently in Tokyo for a couple of months and I commute five days a week between Soka-shi in the Saitama prefecture to Bunkyo-ku in Tokyo. In total, that’s a one hour trip two times per day, which may not seem that big of an issue to most people, but for my part, I am simply not used to it and it is really becoming a chore.

Obviously, it was time to upgrade my mobile gear and let go of my iPod Nano, which I learned to hate in its few months of use. Sound quality and headphones are almost ridiculously bad for a device with a 180€ price tag, I never got used to the navigation wheel, it operates very fuzzy and unprecise and the display is small, low-res and everything but rich in color. My biggest gripe however with the Nano — and iPods in general — is Apple’s inability (refusal maybe) to provide proper Linux support for their devices. Their iTunes software has still not been ported to Linux, and most probably never will. There are open-source solutions like GTKPod, Floola and various iPod plugins for popular Linux media players like Rhythmbox, Banshee or Exaile, but I have used them all, and most of them are buggy, difficult to use or do not support newer iPods. Being an open-source aficionado and full-time Linux user myself, I have to face the truth: iPods simply do not fit into my setup. I admit it though, the iPod Touch looks sexy and I thought about buying it. I would have loved to have Wi-Fi on my PMP. But, considering these points and the fact that almost everyone between 10 and 30 is running around with an iPod these days, my urge to buy one has somewhat declined — or, as some user on the head-fi.org forums put it: “It is my personal opinion that owning a soul and owning an apple product are incompatible concepts”. Although my attitude towards Apple products ain’t that radical, I can definitely see where he is coming from.

Long story short, I went with Cowon’s iAudio D2, the 4GB version, in white. South-Korea based Cowon has made itself a name for building portable audio players with excellent sound quality, and best of all, which can be used with Linux, because they do not use a database model that can only be updated by means of a proprietary software (such as iTunes or Sony’s equivalent for their Walkman players). Instead, the D2 is recognized by the system as a USB mass storage device and you can simply drag-and-drop your music and video files onto the respective folders. Easy and simple. For Windows users, Cowon also ships their JetShell and JetAudio software for transferring and converting media files.

The device is small and handy (though maybe a bit thick — check this site to see how its size compares to an iPod Touch) and sports a high resolution, color rich display which is operated by touch. In fact, the only buttons on the D2 are the power and hold button (which are incorporated into a single snap-slider, very cool), a menu or “M” button (which can be configured to do different things), and two buttons for volume control. Navigation using the touch screen is responsive and for most parts straight forward. The default user interface already looks really sleek, but if you do not like it: it’s skinnable. For those people whose fingers aren’t slim anough to hit the (sometimes really small) on-screen buttons, Cowon also packs a plastic pointer with the D2.

Sound quality is great, it’s lightyears ahead of an iPod. Moreover, the D2 has the most capable equalizer I have ever seen on a PMP, it lets you adjust an almost ridiculous amount of options. The earphones bundled with the D2 are decent, but maybe not great. Still, much better than the ones coming with a Nano. Video playback is fluent, and the 16 Million colors display is crisp, which — despite its small size (2.5 inch at 320×240 pixels) — lets you read smaller text as well.

Concerning audio formats, the player supports a much wider range of codecs than most other players I have seen to date, including OGG, which will make many Linux users happy (at the time of this writing, OGG support is buggy on the D2 as some OGG tags are not properly read by the player; playback support is there however). For the video support, the D2 unfortunately doesn’t shine as bright. In fact, this is one of my biggest gripes with the D2: It doesn’t play videos encoded with the AAC audio codec, the format employed by Apple which almost every website that syndicates podcasts uses. Instead, the D2 can only play videos with MP3 encoded audio. This is extremely annoying, as you have to fall back to a video transcoder in order to play back video podcasts downloaded from the internet. There is also some confusion about the actual video codec and container format (I am no expert on this, so please anyone correct me if I’m wrong): The player is often tagged as an MP3/MP4 player, which is supposed to indicate that it can play back MPEG-4 encoded video (it supports the XviD codec, I am not sure about other MPEG-4 codecs). Technically, this is wrong however, because MP4 does not refer to the video codec, but the multimedia container format, and the D2 does not use MP4 here, but AVI (the format introduced by Microsoft in the `90s). Although the specs are silent about the supported container formats, my D2 won`t even display video files ending in .mp4, but it does display all files ending in .avi.

Another extremely annoying issue I am having with my D2 is its seemingly buggy support for ID3v2 tags. Although my MP3s are properly tagged, they always show up in the Music Library in wrong order, that means, not sorted by track number. For albums where order matters, like DJ mixes or audio books, this is a show-stopper, as there is no support to manually sort tracks on the D2. As a fallback, one has to go through the D2’s file browser instead. I seriously hope this will be fixed with a future firmware update.

To draw a conclusion, I think the D2 is a somewhat two-faced PMP. It does so many things right, like providing OGG support for Linux users, but then again, the support is buggy or incomplete. Then it provides lots of audio codecs, which makes it very versatile in that department, but for video, it only supports a format that almost nobody on the WWW uses to distribute podcasts — the killer application for portable media players! Concerning the user interface and functionality, light and shadow continue to co-exist on the D2: There are two (!) different calculator programs (gimme a break), but I can’t even do simple things like sorting my tracks or create playlists.

While I can still recommend the D2, if even for the mere lack of decent competition in the deserted lands of Linux-compatible PMPs, these points just make me pull out my hair and scream: “It would have been so simple, why, Cowon, why?!”.


Find below some reference and software proposals on how to operate the D2 under Linux.

Podcast management: GPodder — a very decent podcatcher for Linux (GTK-based)

Video conversion: iRiverter* — get the D2 device profile here

* some Ubuntu Linux users (including me) had problems running iRiverter. If you get an exception about a missing SWT library, try following this proposed solution, which fixed the problem for me.

UPDATE 2008-01-26: Modified section about video and codec support

January 18, 2008

Integrating Direct Web Remoting (DWR) in Mozilla Thunderbird

Direct Web Remoting, or DWR for short, is a Web technology for exposing server-side Java interfaces via a dynamically generated JavaScript API. A specific Servlet will translate incoming JavaScript calls to their Java equivalents which makes integration of applications programmed in client-side JavaScript with Web applications written in server-side Java a no-brainer.

DWR calls are typically dispatched from a JavaScript/JScript program running in a Web browser such as Mozilla Firefox or Microsoft’s Internet Explorer, but since all Mozilla products are built upon the Gecko layout engine and XUL (which are programmed using JavaScript modules), you can leverage DWR to dispatch remote calls from e.g. a Mozilla Thunderbird extension just as easily. Integrating DWR into a XUL based extension is actually pretty straight forward, but there are couple of subtleties to be aware of.

I will hereafter assume that a Web application called ‘MyWebApp’ has been deployed on localhost port 8080, that it’s up and running, that it exposes an interface called ‘MyService’ via DWR. Refer to the DWR documentation if you are unsure how to do that. It is further assumed that the DWR servlet is reached at dwr/ relative to the base URL. All following code examples refer to DWR version 1.1, which unfortunately has already been superseded by version 2.x at the time of this writing. If required at all, changing the code to run with newer versions of DWR should be easy enough however.

In order for your XUL component to be able to access `MyService’, add the following lines to your XUL file (e.g. myOverlay.xul):

<script type="application/x-javascript"
    src="http://localhost:8080/MyWebApp/dwr/engine.js"/>

<script type="application/x-javascript"
    src="http://localhost:8080/MyWebApp/dwr/util.js"/>

<script type="application/x-javascript"
    src="http://localhost:8080/MyWebApp/dwr/interface/MyService.js"/>

Don’t go looking for MyService.js in your file system, it’s not there. DWR will take care of dynamically creating it once your client requests it from the server. You can find both engine.js and util.js in the dwr.jar file which should reside at WEB-INF/lib of your deployed Web application.

Now you’re already prepared to invoke your service. However, when run outside a Web browser, as is the case with e.g. a Thunderbird extension, there is a catch: DWR won’t correctly resolve the target URL for your server, because it operates on relative URLs by default. You can fix that problem by modifying the MyService._path variable, which was auto-generated by DWR. Ponder the example program below, which invokes MyService.service() from a JavaScript program running in a Thunderbird extension:

function callService() {

    MyService._path = "http://localhost:8080/MyWebApp/dwr";

    MyService.service({
        callback: function(returnData) {
            // perform logic
        },

        errorHandler: function(error) {
            // handle error
        }
    });
}

That’s it basically; of course you may want to add additional call variables or use another invocation style altogether, but you get the idea.

January 17, 2008

Mozilla Thunderbird Extension Development – Environment Setup

It took me a while to setup my Thunderbird installation in order to make it ready for convenient extension development, by which I mean having all the tools and configuration in place. So I thought I’d share the most useful steps you want to perform in order to make your life easier.

You should basically do two things: One, reconfigure Thunderbird to be more developer-friendly, and two, install some cool extensions.

First, I recommend installing the following plugins:

  1. ChromEdit Plus – allows for easy access to your configuration files. Works in Firefox, too.
  2. Venkman – A JavaScript debugger. Must have. For Firefox, I recommend Firebug instead.
  3. Console² – An advanced error console. Can interpret JavaScript commands on-the-fly.
  4. Chrome List – Lets you inspect chrome packages of all installed components. It’s somewhat buggy for me though, sometimes the contents of XUL files are not displayed in the viewer.

With these plugins installed, you already have a solid basis to built your hacking on.

Now to the configuration. You can do this with ChromEdit now, or if you haven’t installed it, fall back to your favorite text editor. Open the ChromEdit Plus menu, select ChromEdit and navigate to the ‘user.js’ tab. From here you can edit your ‘user.js’ file located in your profile folder (on Linux, it’s in your home directory, on Windows, it’s in ‘Documents and Settings/<username>/Application Data/Thunderbird/Profiles/<long_UUID>’ ). If it does not yet exist, and it doesn’t by default, go ahead and create it). Add the following lines (it’s a JavaScript file, so it’s simply JavaScript syntax):

user_pref(“javascript.options.showInConsole”, true);
user_pref(“nglayout.debug.disable_xul_cache”, true);
user_pref(“browser.dom.window.dump.enabled”, true);
user_pref(“javascript.options.strict”, true);

The following explanations are taken from the MDC:

  • javascript.options.showInConsole = true. Logs errors in chrome files to the Error Console.
  • nglayout.debug.disable_xul_cache = true. Disables the XUL cache so that changes to windows and dialogs do not require a restart. This assumes you’re using directories rather than JARs. Changes to XUL overlays will still require reloading of the document overlaid.
  • browser.dom.window.dump.enabled = true. Enables the use of the dump() statement to print to the standard console. See window.dump for more info. You can also use nsIConsoleService from privileged script.
  • javascript.options.strict = true. Enables strict JavaScript warnings in the Error Console. Note that since many people have this setting turned off when developing, you will see lots of warnings for problems with their code in addition to warnings for your own extension. You can filter those with Console2.

In order for the Thunderbird standard console to appear, run Thunderbird with the ‘-console’ command line argument. The dumped statements won’t appear in Console² though.

You may also want to refer to Setting up extension development environment on MDC as a primer, I particularly recommend the steps outlined for externalizing your development files into a separate folder, so you won`t have to reinstall the plugin each time you change a line of code.

Create a free website or blog at WordPress.com.