Database Info

Reader feedback welcome: Multimedia Streaming Bible, VPN Bible, map image downloader

I'm currently working on two new Bibles concurrently & I’ve written a map downloader. I’d certainly welcome any reader feedback BEFORE publishing the first version(s) of these Bibles - what you would like to read, what apps / services I shouldn't forget to elaborate on etc. I also seek info on whether there is any need for an enhanced version of the map downloader introduced in the last section.
The two Bibles are as follows:
a full roundup & tutorial on all kinds of multimedia streaming, including
listening to Internet radio stations & watching TV shows - the basics
accessing non-streamed network resources - file system-based, pre-created files over both local networks and the Internet
ORB, CorePlayer, TCPMP, PacketVideo’s PVPlayer etc. - all streaming-capable Windows Mobile clients
specific radio / TV listing apps like Resco Radio, Mundu Radio etc.
streaming (and/or transcoding) from a desktop computer using SHOUTcast servers, WME etc.
Problems with limited connections and RTSP (RealOne, HTC's Streaming Media etc.)
RTSP -> HTTP converter proxies
using a VPN connection to play back otherwise (using the given restricted connections) unplayable RTSP (non-HTTP)-based streams
etc.
A VPN Bible:
when may you need a VPN, even if you don’t need remote access to any other private network – for example, if and when you want to listen to /watch RealOne or 3GP (for example, Mobile YouTube or YLE Mobile) streams only streamed via RTSP (because of the client’s inability to switch to HTTP streaming)
configuring VPN servers under WinTel (and, probably, Linux) operating systems
how you can access already-existing VPN’s from Windows Mobile (not just the ones you configure yourself, but any of them)
a review & comparison of VPN-related literature (books), should you want to know more of this technology
Finally, upon a reader request (many people know I’m especially well versed in Internet protocols, including HTTP – the protocol behind the Web), I’ve thoroughly analyzed the HTTP communication used by http://map.meta.ua/, a well-known mapping service in Ukraine. My reader asked me to let for saving the individual maps in a file so that they can be browsed even without an active Internet connection and/or on a Pocket PC (where the original interface may prove pretty hard to use).
Needless to say, I've managed to write an early demo (it doesn’t support all functionalities of the original Flash client) of an app that does this. You can find the Java source of the app HERE. It’s just a demo showing it’s possible - it puts 20 images of Kiev (but you can easily modify it to save the fully zoomed-in map of any other city), continuously scrolling to the left, in ResponseX.png files (I've, in case you don’t want to fiddle with Java sources, the images HERE).
My question is as follows: does anyone need anything similar to download the maps of other online map sources? As, to tell the truth, I can’t follow the (desktop-based) advances in this area, I’m not sure whether it’s worth enhancing this app. As most Flash / ActiveX-based solutions seems to use pretty much the same protocol, I can enhance and further develop this application to download any map (of any town, not just in Ukraine) into PNG files for offline browsing or importing for GPS applications. Feel free to tell me if you need such functionality and whether there are other, better, downloadable maps that would result in my enhancing the application absolutely unnecessary.

The UPnP Bible

Introduction
What is Universal Plug and Play (UPnP) and why you might want to make use of it? To get a nice overview what it’s all about, spend some time on reading the Digital Living Network Alliance (DLNA) tutorial’s first three pages HERE, HERE and, finally, HERE. These pages are also interlinked so you can just safely follow the “Learn how DLNA works” link at the bottom of the first page. I especially recommend the interactive “What can you do with DLNA products?” section at the bottom of the third page. Try selecting all the possible pairs to see what a particular device pair can be used for - this demo is really instructive. An example screenshot showing what for example the NAS & networked TV pairing can be used for:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Pretty instructive, isn't it? Again, I really recommend playing with the different pairings so that you get a clear picture of what UPnP can really be used for. In addition, please PLEASE do read the above DLNA intro (the three pages) so that you understand what UPnP is about and the terms used in this UPnP Bible. I’ve refrained from reproducing (almost) the same info in here so that I could concentrate on the more important and never-before-published subject: how this all works on the two most widely used mobile platforms: Windows Mobile and Symbian.
You might also want to take a look at the Wiki page (most importantly, the “UPnP AV (Audio and Video) standards” section) but it’s highly technical and, for a non-pro, in no way as comprehensible as the DLNA tutorial. Note that the DLNA tutorial doesn’t explain what “Controllers” are. It’s, as has also been explained in the Wiki (officially referred to by “MediaServer ControlPoint”), is like a remote controller between the source (the “MediaServer”), that is, typically a file store, and the target (the “MediaRenderer”); that is, typically, a TV set, a monitor or a home Hi-Fi.
On both Windows Mobile and Symbian (more precisely, the latest-generation, N-series Nokia handsets) all these three functionalities are supported:
a phone can act as the source (“MediaServer”) of multimedia content (for example, the pictures you’ve taken with the built-in camera; the MP3’s you have on your storage card etc.)
it can also act as the mediator (“MediaServer ControlPoint”) between the server and the renderer. That is, it can select the files on the server you’d like to, say, see on your TV / listen to on your home Hi-Fi etc. It also allows for basic playback control functionality like pausing/ resuming, previous / next etc.
finally, it can also function as the target of the stream: the device that actually plays back the video / audio / images on its own screen / audio unit. That is, it’s also a “MediaRenderer”.
As far as the two operating systems are concerned, all these functionalities are implemented. First, a birds-eye view on what’s available and supported.
For Windows Mobile (WM), currently, there are three apps with UPnP capabilities: Nero Mobile Pro, Conduits’ Pocket Player and Rudeo Play & Control (at the time of writing - December, 2007 - no preview of CorePlayer 1.2 was available. It will also have UPnP support.)
For the newer Nokia N-series Symbian devices (N95 (8 GB ), N81, N82), the OS already has built-in, pretty impressive (no third-party, commercial apps are needed) UPnP support.
[*]: with the N95, only starting with firmware version v20, not with previous OS’es; also see THIS. Note that the manual printed with the original N95 still reflects this (old) state.
[**]: limited presentation capabilities (while it has no problems with the much more important streaming): no library, not even file system folder-separated view
Now, let’s take a look at what functionalities the MediaRenderer-capable applications offer.
I'll later explain what the difference between pre-fetching and streaming is.
Incidentally, the second column ("Accessible for external controllers") is also clearly visible in the following Windows Vista screenshot:
It shows the following UPnP servers / renderers in order: Nero MediaHome (server), N95 (server), (the notebook itself, where the screenshot has been taken), the built-in UPnP server of the Vista on the notebook, the Conduits Pocket Player (PP) renderer (!) on the “wr-x51v” PDA; the same PP on the same PDA as a server; PP as a server on the “wr-univ” and, finally, PP as a renderer on the same “wr-univ”.
1.1 Differences between traditional Remote Media Controllers (RMC’s) and full UPnP applications
Back in February, I’ve already published an extensive Bible on all non-UPnP applications. Now, let’s see what the real difference between a fully-fledged UPnP app and the, back then, reviewed remote controllers is!
First, as you may already have guessed (without even reading my previous Bible), RMC’s can only remotely control media player applications – they don’t offer built-in, local rendering (MediaRenderer) or file serving (server) capabilities. The best, UPnP-capable titles in this respect (currently, as of late December, 2007, Pocket Player 3.51 on Windows Mobile and the built-in UPnP client on the latest Nokia N-series models) offer both of these.
Second, their configuration can be much more complicated than those of UPnP clients, particularly when you need to manually (!) enter the local network address of the server (also containing the media player) you’d like to remotely control. This is true with almost all RMC’s not capable of discovery protocols to automatically discover controllable servers in the LAN. UPnP’s automatic discovery also greatly helps in this respect: you don’t need to do any manual work; just let the controller discover the servers / renderers and you’re all set.
Third, you can only remote control a Windows PC (in cases, other desktop OS’es are also supported) with those “old-fashioned” RMC’s because all the tested applications need server&renderer-side custom software to be installed. This also means it’s impossible to remote control for example Network Attached Storage (NAS) devices (file servers) or plain renderers like a flat TV. With UPnP, all these can be remote controlled.

1.2 Available UPnP-capable software
Now, let’s take a look at what’s available on mobile platforms. Note that as far as Palm OS is concerned, not even Pocket Tunes, by far the best music player support UPnP (and CorePlayer won’t support it either) – you need to go the manual route explained in my RMC Bible for being able to stream stuff from your local UPnP network. There’s a nice thread on this all HERE.
Please, Windows Mobile users, don’t be disgruntled because of including Symbian. Some of the, especially, multimedia / entertainment-centric smartphones like the Nokia N95, N81 and N82 have excellent capabilities well worth incorporating into Windows Mobile handhelds. For example, these devices support UPnP “out of the box”, which is only available (if at all – see for example the complete lack of, say, UPnP printer support in current WinMo apps) with (expensive) third-party applications on WinMo. A direct inter-OS (operating system) comparison like this will certainly help both Microsoft decide to, finally, include UPnP in Windows Mobile (not only on non-WM WinCE 6 devices) and also shows WinMo hardware manufacturers what they should concentrate their forces on – for example, at really (!!!) lowering Wi-Fi power usage when not actively used.
The same also states for Symbian users. I know you’d rather not see Windows Mobile contents in here, but, again, such a comparison is instructive for you too because, then, you’ll know what Nokia should be told in order to improve the facilities of its client. And, as I seriously doubt anyone (except me) would write a thorough feature comparison / buglist of these two operating systems, Symbian developers can make great use of this report.
1.2.1 Windows Mobile
1.2.1.1 Conduits Pocket Player 3.51
Currently (before the release of CorePlayer 1.2 and its UPnP support) this is definitely the best and most versatile UPnP client for Windows Mobile. It has definite advantages over the alternatives: first, as opposed to the two other WM solutions, it can act as a server. Second, as opposed to Nero’s app, it can act as a pure controller (without locally rendering anything), in which it can be pretty handy at just controlling the data flow between your home entertainment devices. After all, if you do have a UPnP-enabled flat TV (with an excellent H.264 decoder), why would you want to watch the same video on the small screen of your smart phone? On the other hand, your phone is one of the best tools to actually remote control the data flow in the network - you, for example, won't need to purchase additional, UPnP-only remote controllers if you already have a UPnP remote control-capable phone in your pocket.
The UPnP interface, accessible under Browse / Network, is pretty easy to master. In addition, moving between the pages (with the left/right D-pad arrows) is very easy too – not so with, say, the much more awkward (and VERY slow!) Nero Mobile Pro, where it's very easy not to be able to click the "Back" arrow at the top of every list.
It’s only at remote controlling that I’ve found it a bit lacking: the pure remote control user interface (UI) it uses isn’t as intuitive as that of Nokia or Rudeo: you need to use a separate, list-based UI. That is, not the native, well-known and familiar playback interface, but a completely different one depicted here:
In this regard, Nokia’s and the Rudeo apps are definitely better. Again, on these, you can use the well-known controls to control the multimedia stream flow between the media server and the renderer as if you played back a local stream as can be seen in the following screenshot:
As can also be seen, Nokia's (and Rudeo's too) not only displays the controls to control the rendering of a multimedia stream, but also displays its metadata, the progress etc. No such features are available with Pocket Player.
1.2.1.1.1 Additional screenshots & usage tips
An example of browsing my (Vista) notebook: the main category list. All these contain the usual categorization: the music list shows the traditional (example of the album view and, inside of it, the list of the individual songs) library view.
The list of videos is also shown; they, however, can’t be played back, not even WMV files (which are, by default, supported by PP with local playback) – only the sound will be heard. If playback starts at all, that is - it doesn’t seem to work on WM6 (only the list is shown, play controls don’t work) ; it does on WM5 as can also be seen in HERE (notice that the movie is being played back). Unfortunately, this also applies to viewing pictures – while their list is correctly displayed, “Play” doesn’t result in their being actually displayed.
PP is also able to use another renderer (screenshot of stepping into the menu); for example, in THIS screenshot, you can see the GUI for remote controlling a device.
1.2.1.1.2 Problems (as of version 3.51)
1. Even Western (äö, for example) accents in the title of the MP3 tags (the one needed to be displayed in the given situation) result in the clients not being able to connect. The Symbian client displays the server’s refusing the connection (“Selected device rejected the operation”):
The Nero Mobile client, when run from another PPC, just crashes and immediately exits when stepping into a view that would contain an accent anywhere. From the same PPC, it “only” refuses to display anything including and after the accent. For example, if you have the album “Hilapiäles” from the artist “Pömpeli”, then, only a single “P” will be displayed as an artist name (the second letter, ö, is already accented) and only “Hilapi” as the album name.
2. When (this is a very rare case but you may still run into it, particularly if you try to remote control a Windows Mobile PDA from, say, a Symbian phone, which defaults to remote rendering) it’s controlled from an external controller and its renderer module is instructed to connect to its MediaServer module, the connection will fail. During this, it just displays a local (192.168.0.1:51524) connection message for about 30 seconds; nothing happens after this, no playback / anything.
3. When operated in direct mode (NOT remote controlled! In the latter case, it has no problems accessing MediaServers!), it can’t connect to other Windows Mobile / Symbian servers (tested with both serving-capable UPnP apps: Pocket Player itself, running on another Pocket PC, and Nokia’s UPnP app). Then, it displays a “Server Error or Access Denied” error message.

1.2.1.2 Rudeo Play & Control 2.9.15
In my RMC Bible, I’ve already discussed the non-UPnP-capable version of this program, Rudeo Control for Windows Media Player. Rudeo Play & Control is entirely different as it’s specifically written for controlling UPnP-compliant servers and renderers – and to play back from the latter.
(playing back a song remotely; also showing the target renderer; note that the song title is only shown at the bottom)
(playing back a song locally, also showing the target renderer)
(server list)
During install time, you can also install a server-side component, which lets for some goodies well-explained in the user guide. It, however, didn’t work with my setup (XP SP2 + WMP 11).
Other screenshots: filelist of the, in the previous screenshot, listed two servers. As can be seen, it correctly lists the categories / files. Quickly playing a title is pretty easy (if you don’t want to fuss with playlists): just tick the given song, tap and hold it and select “Checked – Add and Play” as can be seen in HERE.
It seems it has severe problems with the CPU usage even in pure remote control mode (the same on the Wizard, in pure remote control mode; the red chart is the charted Rudeo executable). The situation is even worse when it locally plays back music (Wizard example screenshot HERE); then, the CPU usage can be so high that the player really quickly chews through the battery. Note that this seems to be a generic problem with all Rudeo products: Rudeo Control for Widows Media Player also had unpredictable, sometimes very high CPU usage (see my previous RMC Bible).
Incidentally, as has already been mentioned, like Nokia’s player and as opposed to Pocket Player and Nero and, it pre-fetches the songs before playing them. This can be a bit time-consuming, largely depending on the speed / optimization of the storage card. Unlike with the Nokia, where you can set where the fetched file should be temporarily stored (either the card or the, at times, much faster built-in storage), you can’t do the same on Rudeo’s controller.
1.2.1.3 Nero Mobile Pro 1.4.0.9
I’ve already reviewed the individual audio file playback and MPEG-4 ASP/AVC playback support of Nero Mobile Pro. Unfortunately, compared to the best (and, at times, even free like TCPMP!) titles, it didn’t really excel at them.
The case is pretty much the same with UPnP. First, it only has pretty basic UPnP support. It has absolutely no MediaServer and (purely remote) MediaController capabilties, unlike all of the alternatives (note that Rudeo can’t act as a MediaServer either; Pocket Player and Nokia can). That is, it can “only” connect to other UPnP MediaServers and play back (locally render) their contents on the PDA itself. That is, you can’t use it at all to, say, remote control the communication between your UPnP-capable flat panel TV and network storage – again, unlike with all the other alternatives.
1.2.2 Symbian (Nokia N-series)
The latest Nokia N-series (that is, multimedia-centric) phones have UPnP support built-in. Before the latest (2007 Autumn / Winter) batch of multimedia Nokia phones, they - in addition to being MediaServers and the ability to send files directly to, say, UPnP printers - were only able to remote control other UPnP devices. That is, they didn’t have local, on-phone rendering (playback) capabilities. Now, with the latest models (N81, N82, N95 8GB ) and firmware upgrades of older models (N95-1 with the v20 firmware), a (pre-fetching) renderer component has also been added.
(main mediaserver list; as can be seen in there, it saw Conduits Pocket Player’s server on my Dell Axim x51v; Orb, Nero Mediahome and the built-in UPnP server in Vista on my notebook called “WR-NOTEBOOK”; the Conduits Pocket Player’s server on my HTC Universal and, finally, the TVersity UPnP server on my notebook.)
A quick tip: by default, when you select a (single) song on an external MediaServer to be played back on the (local) Nokia, when you click on the song, the pop-up window displayed only lists the external renderers.

In order to play back the title on the local Symbian device itself, you must select Play / On device instead:
Note that the other menu item in this submenu, “Via home network”, results in displaying the available renderers on the network – that is, the same dialog as above. Also note that, if you select more than one song to play back with either Mark/Unmark / Mark all viewed or with the traditional multiple selection shortcut on your particular model (for example, on the N95, holding down the pen button while navigating down with the D-pad), you will only be able to use this menu for initiating playback. Simply pressing Action on a title to be played back on another, external renderer won’t work when more than one title are selected.
Note that, in order for the other devices to see your Symbian device (that is, it can act as a MediaServer), you must manually enable “Show phone” in “Visibility in network” in the settings as can be seen in HERE. This needs to be done every time you start Tools / Connectivity / Home media – this setting, unlike with Conduits Pocket Player’s similar setting (Browse / Setting/ Enable sharing), doesn’t stick.
Still speaking of PP, it’s also worth pointing out that, in Pocket Player, sharing your own contents is, by default, disabled; therefore, you may want to click all the three list elements in Browse / Network / Settings so that they become the following:
(the second list item makes Pocket Player controllable from another MediaController. If you don't need it, just don't click it).
Finally, in addition to multimedia playback / remote control, the Symbian UPnP client excels at something the Windows Mobile clients don’t support: handling non-multimedia UPnP devices like wireless UPnP printers. To make use of them, you can just copy any document to them with “Copy to home network”:
1.2.2.1 Problems with the Symbian client
Unlike with all (!) MediaServers (Windows Mobile and desktop alike), it doesn’t support media library or even file system-based file / media separation. That is, while it does have three main categories (Music, Images&Videos, Uploaded) (the latter for direct file transfer – the N95 supports it both as a client and a server – note that few other MediaController clients support this). (The same category screenshot is HERE, taken on the desktop running Cidero, which I’ll elaborate on later.)
Inside these categories, however, ALL the available files are shown without any separation (screenshots: Music; Images&Videos) – neither library-, nor file system-based. Hope the Nokia folks fix this VERY annoying issue some time and at least adds file system-based separation, if not the full Music Player library support.

1.3 Minimizing power usage – with benchmarks
1.3.1 Rendering: Pre-fetching vs. streaming
As has already been explained, a media renderer may opt for pre-fetching a file before / during playback so that it doesn’t have to stream the content all the time from the MediaServer. Two renderers follow this approach: Nokia’s and Rudeo.
Pre-fetching, while it’s certainly has its drawbacks (for example, pre-fetching huge media files may just fail because of the lack of storage space and/or can be lengthy at first), has some definite advantages; most importantly, the Wi-Fi power usage can be minimized – if it automatically powers down itself after a given inactivity time threshold. The following screenshot certainly shows this all:
I’ve played back several songs during the test; the power usage peaks definitely show the boundaries of these songs. (It was slightly before the end of each song that the Wi-Fi unit was activated and the next song was quickly pre-fetched.) As can clearly be seen, the average power usage was 0.57W, which is about only 0.18W more than playing back local MP3’s (see THIS for more info & never before published benchmarks on the latter). Pretty impressive, isn’t it?
Interestingly, keeping the N95 visible (again, it defaults to being invisible) in the Wi-Fi UPnP network (as a server device) was also really battery-friendly – only consuming some 0.11W’s (that is, almost the same as without Wi-Fi).
As far as Rudeo on Windows Mobile is concerned, it also does pre-fetching, which also allows for the Wi-Fi unit’s powering down. However, as the CPU usage of Rudeo is pretty high, the overall power usage will also remain high, particularly with non-battery-friendly CPU’s like the Intel XScale PXA-2XX series (their latest, PXA-3XX series, now, Marvel-branded CPU’s are stated to be better in this respect; I've elaborated on the huge power usage increase with increasing CPU usage when compared to, in this respect, much better architectures like the newer TI OMAP platform for example HERE, in section "1.1.1.1 Battery life considerations" - worth a read!). The following acbTaskMan screenshot (measured on a Dell Axim x51v with minimal backlight and moderate sound volume) clearly shows this:
This chart shows an about 2-3-minute-long initial pre-fetch session, when all the three demo songs were pre-fetched for playback on the local PPC (about 450 mA current, with 600 mA peaks). After the fetching has completed, the player switched to regular playback and the Wi-Fi unit was powered down to idle state, but the CPU usage remained very high (20% at 624 MHz, with much higher peaks) – hence the overall ~280 mA current.
It can clearly be stated that, battery usage-wise, prefetching is WAY better than streaming solutions. The following screenshot shows Nero Mobile Pro (in minimized state – let’s not forget that its graphics takes a LOT of CPU cycles, resulting in even worse figures) streaming (MP3’s from Orb) on the Dell Axim x51v (run without a charger). As can clearly be seen, the average Amperage was around 450 mA’s, while the CPU usage at around 60% - that is, not much higher than with Rudeo (let alone the N95, which has by far the best power management). Yes, prefetching surely has definite advantages.

The situation is similarly bad with Pocket Player, which also uses streaming:
As can clearly be seen, the Amperage has always been around 380 mA (with the lowest backlight level and default Wi-Fi sensitivity setting) – which is still about 100 mA’s more than with Rundo and its Wi-Fi power saving by pre-fetching contents. The somewhat lower CPU usage of Pocket Player doesn’t really help in this respect.
Note that the previous screenshot has been made on the 520 MHz HTC Universal because, on the x51v, for some reason, PP has produced far worse results, where the CPU usage is way more as can also be seen in HERE. Frankly, I don’t know what this is caused by.
Note that both Nokia’s engineers and Rudeo’s developers allow for continuous playback: Nokia pre-fetches the next song while still playing the last one and Rudeo fetches all the songs (and writes to the storage card) while playing the first (few) song(s). This results in no pauses between songs (if there are more than one of them) – only the starting of the playback of the first song will be delayed.
1.3.2 Remote controlling
The situation with pure remote controlling is pretty much the same as with above. The power saving feature of the Nokia kicks in quite fast and results in about 0.15-0.17W generic power usage (that is, about 0.07 Watts more than without Wi-Fi remote control activated). Windows Mobile-based devices, in this mode, fare far better than in the previous case as can clearly be seen in the following screenshot:
As can clearly be seen, the average current is 130-150 mA (just slightly more than without doing anything and a LOT less than the ~400 mA average of active Wi-Fi streaming), which clearly shows the Wi-Fi unit is idling and the CPU usage, which is very low, doesn’t contribute much to the overall power usage.
1.3.2.1 Try disconnecting / powering down your handset when not actively remote controlling!
Finally, a quick tip. As has also been explained in the RMC Bible, you can safely disconnect / power down your handset after initiating a (fully) remote playback – that is, between, for example, a NAS and a flat TV. Then, when you need remote control again, you just power on your device, let the Wi-Fi unit reconnect and you'll almost promptly be able to regain remote control on both the server and the renderer. This is pretty much the same as with traditional, non-UPnP RMC applications and, again, is thoroughly explained in the RMC Bible.
1.4 Networking
If you plan to use your handset in a “real” home environment (to, for example, control the multimedia data flow between a flat TV and a Network Attached Storage), you’ll end up having to use Wi-Fi.
You may (depending on whether your clients are Bluetooth PAN – see below – capable) also want to use Wi-Fi if you “only” have computers on your network. Then, you’ll have somewhat more choices: you can use both infrastructure and peer-to-peer (p2p) mode between the devices. The latter doesn’t require an access point and is supported by both Windows Mobile and Symbian.
However, if you strive for better battery life, you can also use Bluetooth (BT) Personal Area Network (PAN) if and only if all your UPnP components support it. Unfortunately, there’s no widespread support for BT PAN. Symbian devices don’t support it at all; neither do Windows Mobile ones with the MS BT stack in client mode (and, unrestricted, in server mode only with an additional hack). That is, it’s only with Windows Mobile devices with the (in cases, “hacked”, post-installed) Widcomm (Broadcom) BT stack that you can use this form of very battery-friendly form of multimedia sharing / control.
Please also see the related section in the old RMC Bible for more info on all these networking-related questions. Also, let me know if you don’t know how to set up these kinds of networks - but, of course, before asking, first, read the linked article (and all the backlinked ones - I've publsihed several, extensive tutorials on creating for example peer-to-peer Wi-Fi networks).
2. Desktop UPnP apps
Should you want to play with desktop (Windows, Linux, Mac etc.) servers / controllers / renderers, you’ll want to check out the following section. Note that you will in no way need these applications for your mobile UPnP clients to operate in an already-deployed UPnP home network; I’ve only presented it to you so that you know where to look for, say, a pure, but decent and free (!) controller running on any desktop or server OS (for that, I recommend Cidero’s app). These can help a lot with quickly seeing whether a given server is accessible / visible on the network, what content it offers etc.
Another great use for these apps (in this case, Nero MediaHome) is seeing what’s happening in the UPnP network, how many users / clients have connected to your server from which local IP’s. These apps greatly help in tracking down possible networking problems. For this kind of problem fixing, I recommend Nero MediaHome the most.
In the next three subsections, I elaborate on the three main components of the UPnP architecture: (Media)Server, (Media)Controller and (Media)Renderer. In general, there’re no software products implementing all these three functionalities (unlike, say, Conduits Pocket Player on Windows Mobile). There’s On2Share Pro - UPnP AV Suite that promises to implement all of this (it has a 14-day trial and is pretty cheap: only 19.95 euros), but I’ve never managed to make it really work – neither under Windows XP nor under Vista. (I’ve tried to do this on two different desktop PC’s, using two different networking topologies – both peer-to-peer Wi-Fi and using a standard access point. A no-go. While it did list the other UPnP-capable, visible (either a server (upper listbox) or a renderer (lower listbox)) participants:
(another screenshot of the lower part of the server list)
it wasn’t able to communicate with them in any way. (Note that the screenshot has been taken under Vista, using large fonts (a must on a 15" UXGA screen); this is why the lower left buttons are messed up; on XP, with normal fonts, it's correctly rendered. Also note that it displays 127.0.0.1 as the local IP, that is, localhost. This shows the computer had no active Internet connection when the app was started (I've, later, set up an Internet-less p2p Wi-Fi connection manually). Don’t let this make you think I’ve messed up the setup – in other tests, I’ve restarted it so that it received a real LAN IP address. Then, it didn’t work either.)
2.1 (Pure) Servers (MediaServers)
2.1.1 TVersity
Along with Sling (which I haven’t been able to test because it’s still not available in Europe, except for the U.K.) and Orb, TVersity is the most popular remote (WAN; that is, non-local (LAN) UPnP) streaming server, allowing for a lot of niceties; for example, dynamic radio / media transcoding. If you already know this app (because, for example, you’ve used its streaming capabilities over remote mobile networks), you’ll certainly welcome its UPnP capabilities.
(the share config screen; the second tab, with the list of the contents on the server, looks like this – as can clearly be seen, it’s pretty complicated to navigate between the server multimedia contents as there’s no scrollbar. A screenshot of browsing TVersity on a Symbian device is HERE)
TVersity, of course, has its own discussion forum; of it, I recommend THIS thread.

2.1.2 Orb
This is probably the most widely known, free (!!!) home streaming server also compatible with Windows Mobile. It also supports UPnP. It comes with UPnP enabled by default:
Unfortunately, it doesn’t have as nice debug / client configuration capabilities as Nero MobileHome either. But, at least, it’s free and, when it comes to transcoding, definitely more capable than the latter. All in all, highly recommended.
2.1.3 Nero MobileHome
It’s part of the, if you’re into AVC (H.264 / MPEG-4 Part 10) video encoding, pretty much recommended Nero 8 Ultra Edition.
Compared to the first two servers listed above, it has some goodies. For example, with the two servers, it’s impossible to see what clients have been connected, what they’re listening to / watching, what client they use etc. For example, HERE is a list of the renderers found.
The following screenshot:
shows a case in where it’s even more useful: it shows what clients have connected, what they’re streaming / downloading, what they really are etc. In the shot, the first client is Conduits Pocket Player running on my x51v and streaming “02 Track 2.wma” (at 35%); the second is Nero Mobile Pro running on another Pocket PC in the network and streaming “06 Track 6.wma” (at 14%). Also, it lets you define what network interface to use for streaming.
Otherwise, it has pretty much the same capabilities as the former two servers:
- manual addition of shared media directories (note that it also supports automatic refreshing via Nero Scout)
- streams TV
- supports a remote UI
- supports transcoding
(Note that in my forthcoming Multimedia Bible I will continue elaborating on these three products: they have excellent, remote (non-UPnP), smart phone-compliant transcoding and TV/radio streaming capabilities well worth exploiting.)
2.1.4 Other servers
MediaTomb: free, open source, non-Windows
TwonkyVision Media Server (the forum is worth checking out for generic UPnP-related discussions too)
DLink Media Server
Philips Media Manager
JRiver Media Center
Note that Windows Media Connect (still recommended on the Rudeo page) 2.0 is no longer available because the same functionality is built into Windows Media Player 11 for Windows XP or Windows Vista
2.2 (Pure) controllers (MediaControllers)
Cidero - Java-language, multiplatform controller. Don’t be afraid of it being written in Java – it’s very easy to install: just download the installer EXE, run it and you’re set.
It’s a very nice and free app. As it has no built-in renderer, you must use an external one to play back multimedia content.
2.3 (Pure) Renderers
Probably the most important is the Un*x-based GMediaRender; unfortunately, it has no desktop Windows version.
Hardware-wise, Sony PlayStation 3 (PS3) is generally considered one of the best media clients / AV (for example MP4 HD) renderers.

Whoa, AMAZING!
thank you!
this is very much to digest all at once, but i'll get into it and start trying it for myself

UPDATE (12/23/2007): There’s a nice quick summary of how a mobile device can be used for in a home environment HERE, in the first post of the thread. It’s worth a read if you still don't really understand what UPnP can be used for in everyday life. (Note that it discusses the Nokia N95 in this scenario. Of course, any other, UPnP- & remote control-capable mobile device can be utilized in exactly the same way. Also note that it still discusses the old, pre-v20 firmware of the Nokia N95. As has also been mentioned in the (currently) last post of the thread, the N95 has received real renderer capabilities in the meantime.)

Omnia
The Samsung Omnia now comes with uPnP control point software.

yannick said:
The Samsung Omnia now comes with uPnP control point software.
Click to expand...
Click to collapse
cool, thanks, in a subsequent update, I'll post this piece of info.

By wikipedia, a list of hardware and software UPNP media server/player/renderer/...
http://en.wikipedia.org/wiki/UPnP_AV_MediaServers
It hasn't a seccion for windows mobile, anyone for add our seccion for PDA?

great write up!

The Radio Stream Transcoding Bible

With the advent of cheap and/or unlimited data plans, good coverage and the increasing presence of Internet radio stations, the importance of listening to streaming radio stations have become much bigger than ever. In this Bible, I mostly elaborate on practices that
may make the sound quality much better using the same bandwidth, and/or
may save you tens or hundreds of bucks a month by heavily reducing data usage, while providing the same (or even better!) sound quality should you not be able to access any unlimited data plan (Canada with its ridiculous data rates comes into mind), and/or
may heavily increase your battery life by letting you “falling back” to the much more battery-friendly 2.(7)5G Internet access technologies instead of the power-hungry 3(.5)G ones, and/or
in cases, may even let you listen to some radio stations you would never have thought of because of the network / operating system restrictions, and/or
makes the central administration of your radio station favorites much easier – no need to switch between different radio programs if there’s a difference between the protocols / formats they use.
This article is part of my “Multimedia Bible” series and will, eventually, be incorporated in some way in the final version of Multimedia Bible, which, hopefully, will be published this month. Note that I'll also elaborate on TV (video) streaming and transcoding in a later Bible. We’ll use many of the tools / technologies introduced in this Bible in there; most importantly, Orb and VLC.
This Bible, as with my last multimedia-related articles, multiplatform. Don’t get offended by this if you're a fanboy of either of the platforms and just hate everything related to the other: both Windows Mobile and Symbian software developers need to know what the other operating system offers so that they can improve on their products. In addition, should you have devices of both operating systems, you'll be able to optimize the usage of these devices. Just an example: I mostly use the Nokia N95 as my main entertainment and light Web browser / mailer / communicator device because of its, compared to any Windows Mobile device, superior A2DP quality, built-in, stereo speakers, acceptable battery life and lightweight (120g), small body. Therefore, when I know I won't need a Pocket PC (and its high-resolution VGA screen), I know I can safely leave my comparatively heavy and "brick" HTC Universal at home, and go to, say, a quick walk with my N95 only. And, of course, when I do know I will need a Pocket PC and/or a high-resolution screen (for example, to do some serious (!) Web browsing or remote desktop access/control), I take my Universal with me too. (For phoning purposes, I still use my HTC Oxygen (s310) WM5 MS Smartphone because it's cheap - no problem if I'm robbed / it's stolen -, very sturdy and is one of the very few Windows Mobile devices that support flawless, two-party call recording capabilities. I always keep it in my trousers' pocket.)
Note that I planned to review the Palm OS as well. As, currently, I don’t have a Wi-Fi card for my Tungsten T3 and I just couldn’t make it use an external IrDA / Bluetooth modem (unlike with my old Zire 71), I couldn’t test streaming on it. By the time I publish the final Multimedia Bible, I’ll try to get hold of a Wi-Fi card and update this Bible so that Palm OS is also covered. (Sorry, I can't affort a 750p just to be even more multiplatform. If you have one lying around unused, of course, you can send it to me, particularly if you're inside the EU to avoid customs issues ;-) ). After all, on Palm OS, Pocket Tunes is a freaking good audio player well worth comparing other mobile operating systems to.
Introduction
While trying to listen to a radio stream, you surely have run into not being able to play back an Internet radio station either entirely or without severe quality and/or battery life degradation. After you read this Bible – and digest all its contents –, you’ll know how to fix problems like these.
1.1 When it’s completely impossible to listen to a stream...
First, let’s take a quick look at what can cause your handset to not be able to play back a particular Internet radio station.
Your connection speed simply doesn’t suffice for correctly playing back the stream. For example, you’re trying to listen to a 64 kbps (kilobit per second; that is, the so-called ‘bitrate’) stream over a standard GPRS connection. That is, your Internet connection speed is no more than 43 kbps. In these cases, you simply won’t be able to listen to the stream without severe pauses / stuttering, no matter how large buffers you use.
The situation is the same when you try to stay away from using a 3G (either a UMTS or a HSDPA) connection. Even if your handset supports 3G and you also have the necessary signal, you may still want to opt for disabling 3G entirely and going back to using GPRS. The most important reason for this is the vastly increased power usage of current 3G modules used in recent, even high-end handsets like the Windows Mobile HTC Kaiser or the Symbian Nokia N95 or N82. I’ve elaborated on this problem (with several tools that help in switching) in THIS (Windows Mobile) and THIS (Symbian) article.
In these cases, you will want something to (in cases, radically) decrease the bitrate of these streams. Fortunately, it’s in no way impossible. With current technology, you can transfer FM-quality, stereo music even at 24 kbps. I’m not kidding!
(Note that, in this Bible, I assume you only have GPRS access. Unfortunately, many GSM operators still stick with the GPRS + 3(.5)G schema, leaving out the 2.75G technology, EDGE altogether. One example of them is Vodafone, which, with their unlimited data plans, only support GPRS, UMTS and HSDPA / HSUPA. That is, no support for EDGE at all - at least here.
EDGE has both (for radio streaming at least) good speed (236 kbps at most) and low power usage - according to my benchmarks, it doesn't use more power than GPRS.)
You’re trying to listen to a so-called ‘RTSP’ stream but your mobile phone operator doesn’t support direct Internet connections. They use firewalls and NAT’ing (Network Address Translation – see THIS article for more info on the consequences), making it for the radio server to completely impossible to connect back to your handset. Unfortunately, about 60% of the world’s GSM operators do so.
Unfortunately, several radio stations or applications use RTSP. Most importantly, all (except for Mplayer on Windows Mobile – more on this later) mobile RealAudio players use RTSP on both Windows Mobile and Symbian. This means you simply can’t listen to radio stations utilizing RealAudio unless you’re lucky enough to have a data subscription at a mobile operator not using NAT’ing.
(Speaking of the Windows Mobile port of Mplayer, it uses the firewall / NAT-friendly HTTP protocol instead of RTSP. However, it’s a real CPU hog: in the current version, RealOne streaming only works on 624 MHz Xscale CPU’s because it’s really-really CPU-intensive and, on these CPU’s, it chews through the battery really-really fast. It can’t be played back on current, TI OMAP-based Windows Mobile models at all. All in all, it’s pretty much useless.)
RTSP is also very extensively used by Orb, one of the best tools to transcode Internet radio stations. More on this in the Orb-related section.
There are simply no players to play back a given stream type. Then, even if you have a quick connection and/or a non-NAT’ing network operator, you still won’t be able to play back the stream.
The most important case of this are Windows Media Audio (WMA) streams on Symbian. While the built-in Music Player supports playing back local WMA files, it can’t do the same to WMA streams. The situation is particularly bad because the well-known, excellent Orb service, currently, only uses WMA as the only non-RTSP stream format. As WMA streams aren’t compliant with Symbian, you simply can’t use the otherwise excellent Orb if your connection is NAT’ed.
OGG stream support isn’t particularly good on Symbian either. Oggplayer is pretty much a joke and additional radio stations are pretty complicated to set up in the commercial LCG Jukebox, the only other, SHOUTcast OGG-compliant player on Symbian. (Note that CorePlayer is able to play back WMA and OGG streams but, currently, as of the current beta version, its networking module is so bad that it’s unable to play back anything without severe problems surfacing after some minutes at most. This applies to not only WMA, but also other streams. Hope future versions - hopefully the forthcoming 1.2 - fix these issues. In the meantime, stay away from it.)

1.2 When you prefer optimizing an, otherwise, working stream...
Now that we’ve seen what can make it completely impossible to listen to a particular stream, let me also take a look at when you may still want to go for an optimized version of a radio station.
While, at your current connection speed, you already have a compatible stream, it isn’t of the best quality and you would prefer something much better.
The most important examples of this case are GPRS connections, meaning less than 43 kbps total download (downlink) speed, which means about 32 kbps effective radio stream bit rate. With traditional (non-HE-AAC v2) radio stations, you can only have streams of bad quality using GPRS.
For example, Orb only offers a 32 kbps, mono, 44 kHz stream when you switch to the GPRS mode (by using the “40 kbps” mode) if you can’t use RTSP because of the NAT restrictions of your operator. In no way can you instruct the Orb client to transfer stereo WMA audio in so low bitrates.
The (pretty few – most radio stations only have 60+ kbps OGG / WMA and 90+ kbps MP3 streams) radio stations that natively support 32-kbps-max bitrates suffer from the same problem: these streams are almost all mono and still of low sound quality.
You may want to prefer a single interface to quickly switch between your favourite radio stations, independent of their type / source. For example, you don’t want to fire up Internet Explorer Mobile (or, on Symbian, (Nokia) Web) to log into your Sirius account to listen to your Sirius stream only to find out you would still prefer a non-Sirius stream. In these cases, you’ll want to do this using an interface letting for quickly switching between your streams in order to avoid having firing up completely different interfaces to access them all.
And, I’ve already mentioned the vastly increased battery life when you fall back to 2.(7)5G technologies like GPRS (or EDGE – if you’re lucky enough to be a subscriber of a mobile operator with EDGE support). In general, you can count with about 50% (!) increased battery life if you do so.
Again and again, now, with the latest achievements in the radio streaming / encoding technology, you can get perfect sound quality even at GPRS speeds. That is, now, pre-3G technologies (and, particularly, GPRS – as has already been explained, EDGE, which offers far higher transfer speeds without any severe power usage increase, is able to stream most, if not all, current radio streams) have become much more important than ever before. You wouldn’t have thought you would force your shiny, HSDPA-capable, expensive handset to use GPRS only, have you? It certainly pays off if you need acceptably battery life while listening to your radio stations without any external charger for more than a few minutes.
If you don’t believe you can save a LOT of battery life by sticking to GPRS (or EDGE), just take a look at the following acbTaskMan screenshot showing the TCPMP playback of an MP3 stream on an HTC Universal. The first section shows playing back the stream over UMTS; the second over GPRS. The current difference is 200 mA / 330 mA = 60% (see the upper chart; the lower one shows the CPU usage which, in this test, is exactly the same because I played back the same stream with the same player). (Disregard the temporary power "bump" of the second part.) Yes, you can get 60% better battery life if you force your handset to operate in GPRS mode, instead of streaming over UMTS. Quite a difference, isn’t it?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
As can clearly be seen, the difference is almost the same as with the Nokia N95 – or, for that matter, with any other, current handset. As a rule of thumb, you will have at least 50% better battery life with any handset if you don’t use 3G for streaming.
To have a picture of what playback times you can expect of current handsets while playing back HE-AACv2 (and, on Symbian, MP3) streams over GPRS, I’ve made some serious long-time tests. On the TI OMAP-based HTC Vox / s710 MS Smartphone, HE-AACv2 (TCPMP) consumed 27% power an hour. Incidentally, as the TI OMAP platform exhibits far less CPU usage-dependent power usage than at least the older (but still most widely deployed) pre-PXA-3x0-series Intel Xscale’s, I’ve got almost the same figure with A2DP enabled. A2DP causes about an additional 20% CPU usage on the Vox; still, the difference in battery life is negligible when streaming (streaming itself is a very battery-consuming activity, even if you only use GPRS/EDGE, and stay away from 3G).
On the Nokia N95 v20, without A2DP, the power consumption is about 0.93W (see THIS) ; with A2DP, about 1.15W. Therefore, you can expect slightly less than 4 hours of playback time without A2DP on the handset – just like with the HTC Vox.
Note that, currently, on Windows Mobile, you’ll want to use TCPMP to play back your streams. See THIS article for more info on HE-AACv2 compliance. It’s only later that CorePlayer and, probably, Conduits Pocket Player / PocketMind Pocket Music (the developers of these apps promised they'd look into implementing support for them) get HE-AACv2 support.
Keep in mind the following: if you install TCPMP on a MS Smartphone (WM6 Standard), as opposed to “regular” Pocket PC’s, just extract 00000aac.001 from the AAC CAB file, rename it to aac.plg and copy it to the home directory of TCPMP on your Smartphone.
On Symbian, currently, Nokia Internet Radio (see remarks & quick review HERE) is the best way to play back SHOUTcast MP3 streams.
Now, let’s take a quick look at what tools we have at our disposal.
1.3 Our tools: transcoders, stream formats
1.3.1 You must run a transcoder on your desktop PC!
First and foremost, for ALL the alternate technologies, you’ll need to have a desktop computer attached to the Internet and switched on when listening to music. The sole reason for this is that it’s on this machine that the so-called ‘transcoding’ (converting between two stream formats; Wiki page HERE) takes place. Your handset will connect to this desktop PC instead of the original radio station URL.
Why no purely desktop PC-less setup, you might ask. Why can’t you just connect to a third-party server to do the trick for you? The reason for this is pretty simple: transcoding is a pretty much CPU-intensive task. A typical transcoding process, in VLC, takes about 10% CPU cycles on a contemporary 3.2 GHz P4. You can’t expect for example the Orb folks to install a supercomputer or some hundred PC’s to offer transcoding to their clients – for free. Of course, in the future, companies / services specialized in providing server-side, commercial transcoding services may turn up.
This is why you MUST have a desktop PC running your transcoder, independent of their particular type.
1.3.2 Stream formats
In my quick review of streaming audio formats, I’ve already elaborated on the different playback capabilities of the available media players.
You may already also know that you should go for the currently best, most effective audio format, HE-AAC v2 if you have a Windows Mobile device. If you have a Symbian one, then, either MP3 or, if you have a non-NAT’ed network connection, even Orb's RealAudio or RTSP/AAC will work for you.
Quality differences (in which, HE-AAC v2 is certainly the winner) and generic operating system compliance (again, streamed HE-AAC v2 is, currently, only compatible with Windows Mobile but not with Symbian) aside, there are some other factors you should consider when going for a given streaming format; for example, the CPU usage, which, at least on some architectures, may have a huge effect on the power usage and battery life of the handset.
The following screenshot shows playing back MP3 (which is a less CPU-hungry operation) and HE-AAC v2.
Note that this, mostly, affects Intel Xscale PXA-2xx users only – that is, users with HTC Universals, Athenas / X7500’s and several earlier PDA’s and handsets. Users of for example TI OMAP-based handsets won’t really notice any increase in battery life if they go for MP3 instead of HE-AAC v2. The reason for this has already been explained in my H.264 Bible: the TI OMAP platform is much more battery-friendly than the Intel PXA-2xx one. I can only hope Marvel, the new owner / developer of the old PXA architecture, have indeed improved on power usage in the brand new, 3x0-series PXA’s. (I still haven't had the chance to verify this as these new CPU's are used in very few and, in Europe, still not available, disconnected, traditional PDA models.)

1.4 Transcoders
Now, let’s elaborate on all the transcoder alternatives.
1.4.1 Orb
Currently, the most widely known and popular transcoder (and generic radio streaming) service is that of Orb. It is hugely popular with both the Windows Mobile, Symbian and iPhone folks. It certainly deserves this: while, in some cases, it’s definitely lacking, the web access module it provides is by far the best of all. And, it not only allows for transcoding radio stations, but also accessing the files on your desktop computer and streaming multimedia files from there – as if they were located on your handset.
After installing, if you want to add your own radio stations to Orb, right-click the Orb icon in the Windows tray in the lower right corner, select Configuration and go to the Media tab. There, click the Add button in the “Music” group to add the directory of your playlist files.
They’ll, then, be shown under Audio / Playlists:
Of course, under Audio / Internet Radio, you’ll still see the radio stations shipping with Orb – you might also want to take a look at them.
I REALLY recommend giving Orb a try. Even if you don’t start to actively use it (because of the severe Orb restrictions and the vast superiority of the HE-AAC v2 format (Orb only uses the “dumbest” AAC-LC)), it’s still worth paying a try.
1.4.1.1 Restrictions of Orb
If you take a look at the online Settings / Stream page of Orb, you see it offers several output stream types:
(Incidentally, it’s this page that allows for selecting the streaming format. All this when accessed from a mobile browser like Internet Explorer on Windows Mobile, Nokia Web on Symbian or Opera Mobile on both operating systems.)
As can clearly be seen, WMA, RealAudio, some 3G formats (ALL in RTSP!), Winamp PLS and Flash are supported. Unfortunately, many of them (the 3G formats and RealAudio) are RTSP-only, which means they are completely useless if your mobile operator uses NAT’ing – that is, doesn’t expose your handset directly to the Internet.
As far as the Flash support of Orb is concerned, on Windows Mobile, the Flash player (screenshot running under Opera Mobile), while it starts with the official, latest MM7 Flash player plug-in, crashes after about 10 seconds when used from the built-in Internet Explorer (tested on two devices). On Opera Mobile 8.65, it keeps playing; however, it utilizes the CPU at 100% as can clearly be seen in HERE. And, in addition to the huge CPU usage, it also has a major problem: it uses a temporary file in the built-in storage of the device, which will, sooner or later, result in the storage’s entirely filling up and stopping / crashing the machine. A screenshot of these temporary files is HERE. Flash Lite 2.1 is totally incompatible with Orb’s Flash streams as can also be seen in HERE.
Under Symbian, it doesn’t even start under the “old” but still official Flash Lite 2 support of Nokia Web as can also be seen in HERE.
All in all, under the two mobile operating systems, using the Flash mode is in no way recommended.
Also note that the Winamp .pls format it offers internally just uses WMA streams – don’t think it’s a SHOUTcast-compatible stream meaning compatibility with Nokia Internet Radio / LCG Jukebox on Symbian or with many SHOUTcast clients (GSPlayer etc.) on Windows Mobile.
Two compatibility charts follow, which show the two major mobile operating systems in both NAT’ed and non-NAT’ed (direct) cases:
Windows Mobile:

Symbian:
As can clearly be seen, if your connection is NAT’ed, your only choice is WMA (which, incidentally, uses 32 kbps 44 kHz mono (!) sound in the 40 kbps, that is, GPRS setting). This will work on Windows Mobile but, currently, not on Symbian.
All in all, Orb is a decent choice if you have a faster (for example, EDGE or the even faster 3G, assuming you aren’t afraid of the huge battery usage of the latter) connection and/or a non-NAT’ed environment. In these cases, its technical inferiority (the lack of SHOUTcast stream support and, most importantly, the lack of HE-AAC v2 – that is, the only high-quality streaming format for GPRS connections) won’t cause you problems. Finally, it has pretty nice Sirius and XM support. See THIS for more info on the latter.
Let me, however, reiterate its disadvantages again:
if you try to listen to radio stations at GPRS speeds (meaning streams with 32 kbps bitrates max), it’s, audio quality-wise definitely a suboptimal solution and should only be used when you absolutely need to use it – for example, because you prefer its GUI to those of the other players. Why would you want to prefer mono WMA streaming with a lot of compression artifacts when, with other transcoders, you can have excellent, stereo HE-AAC v2 streams without compression artifacts - at the same bitrate? and/or
if you have Symbian (not WM) and a NAT’ed connection (ruling out everything – remember, in a NAT’ed environment, with Orb, you could only rely on WMA, but it’s not supported by the system and CorePlayer’s current version has very buggy streaming support),
you will definitely want to take a look at the SHOUTcast / Icecast2-based alternatives; most importantly, Oddsock.org’s excellent apps.
Note that I’m pushing the Orb folks to add Icecast2-based HE-AAC v2 and MP3 stream support. See THIS thread for more info.
1.4.1.2 Other Orb-related discussion threads of interest
Mobile Phone Streaming Issues
XM and Sirius
SKY.FM, DI.FM
Note that, while the old "High quality" option under 3GP, had a separate checkbox to switch to AAC(-LC); the new, 2beta version has a separate, top-level radio button for this mode. That is, don't let you be mislead by THIS, THIS, THIS and THIS threads, which still refer to the old approach.
Streaming, additional aac codec

1.4.2 Icecast2-based streaming
The following alternatives all require the usage of an Icecast2 server. (Note that, as an exception, VideoLAN VLC doesn’t necessarily need it unless you stream to a Symbian handset from it. The same stands for WME as well - it's a server on its own.)
1.4.2.1 Icecast2
Icecast2 (Wiki page HERE) is an open source equivalent of Nullsoft’s SHOUTcast server, which does exactly the same. There, effectively, there isn’t much difference between SHOUTcast and Icecast2; geeks and other pros tend to prefer the latter; therefore, I also elaborate on it in here, instead of the closed-source, proprietary SHOUTcast.
You can get it HERE. The download links are on the top of the page; if you have Windows, you’ll want to download the icecast2_win32_v2.X.X_setup.exe file. After installation, start it. Go to Configuration / Edit Configuration and edit the file in the following way:
Change the three passwords from “hackme” to anything under icecast / authentication. For example, in THIS screenshot, I’ve changed all the three to mennpwd. You don’t need to use the same word for all the three passwords.
The number of concurrent streams under icecast / limits / sources. If you plan to transcode more than two streams with a multiple stream-capable source client at the same time, you must modify this parameter too. For example, in THIS screenshot, I’ve set it to 30 so that I can have 30 concurrent, different streams (we’ll see in which cases you’ll find this useful).
After editing, just close the Notepad window and answer Yes to saving it.
Now, when you click the Start Server button, it starts listening to incoming streams as can be seen in HERE. You won’t need to do anything else to Icecast2, other than starting / stopping the server if you need it or don’t need it any more.
Note that, by itself, Icecast2 doesn’t stream anything; it needs other clients (“source clients”), whose streams it just relays to the Net. That is, effectively, it uses the famous three-tiered Web application server model already known to many IT gurus, where the listening client equals to the Web browser, the middle tier (the application / Web server) is Icecast2 and the database back-end is, in this case, the transcoding source clients. It’s the stream of the latter that Icecast2, in the middle tier, “just” relays further to the client listener(s).
The streaming clients introduced in the next subsections are all geared towards using Icecast2 as the real streaming server. The only exceptions are:
VideoLAN VLC, which can also operate in a standalone mode (but, then, produce a stream not compatible with some media player clients, including Nokia Internet Radio);
Orb and, finally,
WME, which are also completely independent of Icecast2.
1.4.2.1.1 Mount points
You must be aware of the so-called ‘mount points’. Particularly when you stream more than one radio stations at the same time (in cases, you’ll want to prefer this solution to the others because it frees you from having to remote control the sound source), you will want to know what a mount point is.
When you configure an Icecast2 source client (VideoLAN VLC, Oddsock.org’s apps etc) to stream their contents to an Icecast2 server, you not only pass these clients the Internet address of the Icecast2 server they’ll need to connect to, but also an additional parameter that, later, uniquely identifies the stream: the mount point.
For example, let’s assume you stream two streams to your Icecast2 server from your VideoLAN VLC client. To quickly fire up the streams, you create a batch file with the following contents:
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
start vlc.exe --sout-shout-name="Radio Vaasa" --sout-shout-description=" Radio Vaasa (Finnish)" http://webcast.vlp.fi:8000/radioVaasa :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/radioVaasa}}
Here, look for the iskelma and radioVaasa parameters. It’s there that you tell Icecast2 where to “map” these streams to. If you use these two mount points, you can access (listen to) these streams from a SHOUTcast/Icecast-compliant mobile client (TCPMP, CorePlayer, GSPlayer, Nokia Internet Radio, LCG Jukebox etc.) by simply supplying the mount point after the address and IP of your server like in the following direct URL you can directly enter in any of these players:
http://111.222.333.444:8000/iskelma
and
http://111.222.333.444:8000/radioVaasa
(111.222.333.444 is my desktop computer's imaginary IP address. You'll, of course, will need to provide yours. Use What Is My IP if not sure.)
Of course, prefer defining a playlist .pls file instead of entering URL’s like these into a player to make your life even easier because of the direct file access in most of these apps. The contents should be as follows:
[playlist]
numberofentries=2
File1= http://111.222.333.444:8000/iskelma
Title1=Radio Iskelmä
Length1=-1
File2=http://111.222.333.444:8000/radioVaasa
Title2=Radio Vaasa
Length2=-1
Version=2
(Note that you can leave out the Title and Length attributes. However, if you do so, the current beta of Nokia Internet Radio will crash and will be needed to reinstalled for it to work again.)
You can use any mount point name and you don’t need to explicitly configure the Icecast2 server to know anything about them. That is, you don’t need to tell Icecast2 “hey, I want to use the mount point “mystation”; let me configure you” at all. This is certainly very good news: only the original clients (transcoding the original Internet radios and streaming the transcoded contents to Icecast2) and the mobile players need to be aware of (that is, use) the same mount points.
An Icecast2 screenshot of showing several mount points being in use at the same time, with VLC acting as a streaming client:

1.4.2.1.2 Connecting to your Icecast2 server
In this section, I elaborate on how streaming clients and mobile multimedia players can connect to your Icecast2 server.
1.4.2.1.2.1 Streaming clients
As has already been mentioned, for a streaming client to connect to Icecast2, it must know the streaming source password (set in the icecast / authentication / source-password), the address: port (127.0.0.1:8000 if it’s running on the same desktop PC) and, finally, the arbitrary mounting point.
For example, in the above-shown VLC batch file,
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
the bold text, source:[email protected]:8000/iskelma, contains all this information.
Here, “source” is the username by default for streaming clients like VLC or the Oddsock.org apps. “mennpwd” is the password I use; “127.0.0.1:8000” is the IP address and port number of the Icecast2 server. In this example, it’s running on the local PC; hence the localhost address. Finally, “iskelma”, as we’ve already seen, is the mount point name.
1.4.2.1.2.2 (Mobile) receiver clients
As has already been mentioned in section “1.4.2.1.1 Mount points”, you can either directly enter the URL (of the form http://your desktop computer IP : port (8000 by default)/mount point) into the player or, alternatively, can create a .PLS and/or (preferably extended, so that it also contains the station name) .M3U file with the URL and a description. Note that these playlist files can have several URLs with separate descriptions. (Also note that I only use PLS files as examples in this tutorial because Nokia Internet Radio doesn’t support M3U files.)
An example PLS file having seven entries:
[playlist]
numberofentries=7
File1=http://111.222.333.444:1234/
Title1=Radio Peili
Length1=-1
File2=http://111.222.333.444:8000/iskelma
Title2=Radio Iskelma
Length2=-1
File3=http://111.222.333.444:1236/
Title3=Arkisto
Length3=-1
File4=http://111.222.333.444:8000/radioVaasa
Title4=Radio Vaasa
Length4=-1
File5=http://111.222.333.444:8000/rspo
Title5=RSPO
Length5=-1
File6=http://111.222.333.444:8000/klf
Title6=KLF
Length6=-1
File7=http://111.222.333.444:8000/rhesa
Title7=Radio Helsinki
Length7=-1
Version=2
Note that it has two non-8000, that is, two non-Icecast2 ports: 1234 and 1236 in the first and third records. I’ll elaborate on this a bit later, in the VLC section. All the other URL’s point to the same Icecast2 server with, of course, different mount points.
Colleting your favorite stations into one PLS file is pretty much useful because, then, it’ll become far easier for you to switch between the radio stations after opening the playlist file. For example, the above PLS file is rendered by Nokia Internet Radio the following way:
By TCPMP, this way:
and, by CorePlayer, this way:
Note that the two latter apps automatically start playing the first station in the playlist (Nokia Internet Radio doesn’t); if it’s a problem, you will want to separate your stations in separate PLS (or M3U) files. Also note that you can transfer these streams to your built-in "favorite" playlists in all these radio clients. Then, you won't need to click / import PLS files more than once.

1.4.2.2 Oddsock.org apps
Oddsock.org is the most important source of both MP3- (for Symbian users, the best solution) and HE-AAC v2- (for WM users) compliant encoding / transcoding server with direct output to Icecast.
Note that for some of them (except for the most recommended WinAMP plug-in version) to work with HE-AAC v2, you’ll need to copy two DLL’s to the home of the app (and NOT to the WinAMP home directory, no matter what the installer states): enc_aacplus.dll and nscrt.dll from the WinAMP plugins directory and home, respectively, if you’ve already installed WinAMP (you don’t need to install it for these apps to work). You’ll find all the two DLL’s (along with libfaac.dll – see next paragraph) in THIS RAR file. After decompressing, just copy the DLL’s to the home (c:\Program Files\StreamTranscoderV3\ or C :\Program Files\OddcastV3 if installed on the c: drive in an English-language Windows).
For simple AAC(-LC), you’ll only need libfaac.dll if you plan to use it at all. I wouldn’t – it doesn’t seem to work with mobile clients. TCPMP announces it’s plain incompatible with the stream; CorePlayer and Nokia Internet Radio just endlessly buffer it – without playing anything. With desktop clients (for example, WinAMP) that do play it back, the sound is seriously distorted and is MUCH worse than with even MP3, let alone Ogg. I, however, have included it in the RAR file, should you still want to play with it. (Again, it’s not recommended.)
For MP3 streaming under OddcastV3, you’ll need to acquire the Lame MP3. I haven't included it in the RAR file.
1.4.2.2.1 StreamTranscoderV3
One of the most useful, albeit in no way flawless Icecast2 source clients is StreamTranscoderV3, which, as the name implies, transcodes an input radio stream to another format. Note that the input stream must be either an MP3 or an OGG one. That is, it can’t transcode RealAudio and WMA streams at all. For the latter two, you must use other alternatives: Orb (if the problems – lack of HE-AAC v2 and MP3 etc. – aren’t an issue), OddcastV3 or WME (the latter if RealAudio is the source).
1.4.2.2.1.1 Installation, configuration
After installing the app, go to c:\Program Files\StreamTranscoderV3\ and, after you’ve copied the AAC DLL’s in there (if you want to transcode into HE-AAC v2), start streamTranscoderUIv3.exe. (Note that you can also do the same by clicking the streamTranscoderUIv3 icon on the desktop. It isn’t put in the Start menu.)
Using the ST3 is pretty straightforward. All you need to do is giving it the (source) stream URL (for example, http://81.175.250.3:8000/) in the uppermost text input field, pressing the upper arrow in “Num encoders” so that it becomes at least 1 and double-clicking the resulting, just-displayed “Disconnected” row in the main text area. An instance of Notepad pops up with an XML configuration file. In there, first, you must set the source password in the fifth row (ServerPassword=sourcepwd in the screenshot below) and the mount point to your choice (in the example, /iskelma) in the (sixth) row just under it.
Then, set the “Encode” attribute in the “# Output codec selection” section to “AAC Plus” and set BitrateNominal to, say, 32 (corresponding to 32 kbps). Note that you don’t need to alter the BitrateMin and BitrateMax parameters at all – the HE-AAC v2 encoder doesn’t take their value into account. Also note that you don’t need to touch the parameters in the “# AAC (FAAC) specific settings” section either. It’s only with streaming in AAC-LC (that is, using the old faac.dll) that these values have any meaning. For ~32 kbps streams, then, you’ll need to use AACQuality about 10 instead of 100. Again, streaming plain AAC-LC with ST3 is in no way recommended – even MP3 produces far better results at these low, GPRS-friendly bit speeds.
The above configuration assumes you want to stream HE-AAC v2 contents. If you’d prefer MP3 (because, for example, you’d like to stream to Nokia Internet Radio, which, currently, doesn’t support HE-AAC v2 – or, for that matter, would like to use a non-HE-AAC v2-compliant Windows Mobile radio app), of course, you’ll need to use the string “MP3” in the Encode attribute. Then, in addition, you will want to reduce the sampling frequency as well. You shouldn’t do the same with HE-AAC v2: there, you must use the default 44.1kHz; otherwise, the encoder will fail right at connecting.
Note that you may also want to change at least the “ServerName=This is my server name” attribute so that meaningful values are displayed as the server name in your clients, instead of “This is my server name”.
After this, you can press the Start button and the streaming to Icecast2 will start:
You can easily check this with the Icecast2 console:
As can clearly be seen, Icecast2 is already broadcasting the stream coming from the stream source; in this case, StreamTranscoderV3.
1.4.2.2.1.2 Problems with ST3
Most importantly, it doesn’t seem to have a (working) dynamic volume limiter. This means some sources will be far too loud, which results in very annoying distortion in the transcoded stream. Some affected radio streams are as follows: Basso, Iskelmä, and, to a lesser degree, Radio Voima. You will NOT want to transcode these (and similar) radio stations with ST3 but go for an alternative solution; for example, OddcastV3 or, if low-bitrate MP3 is sufficient / preferable (instead of HE-AAC v2), VLC.
Second, the transcoded version of original OGG streams (as opposed to MP3 ones), like Radio Suomipop or Radio Classic will have heavy skips, while their MP3 stream (HERE and HERE, respectively) of the same stations work OK. It seems ST3 has similar problems with other OGG sources as well. If you encounter cases like these, go for an alternative solution - fortunately, there’re several of them.
1.4.2.2.2 OddcastV3
It’s the WinAMP plug-in version of OddcastV3 that I recommend the most of all these transcoders, particularly when you are a Windows Mobile user and only have GPRS access and, therefore, would like to prefer HE-AAC v2 all the way. It has unmatched capabilities, which, paired with the excellent remote controllability features of WinAMP, make OddcastV3 without doubt the best solution for transcoding.
First, I explain the usage of the WinAMP plug-in; after this, the standalone one. You can download both HERE. Select either the WinAMP or the Standalone version. I heavily recommend the former; only go for the standalone version if you know, for some strange reason, you hate WinAMP and would never touch it because it can be used with any sound source, not only WinAMP.

1.4.2.2.2.1 WinAMP plug-in version
This version is integrated into WinAMP and should be accessed / controlled from in there (not as a separate entity, unlike with the standalone version). After installation, start playing a stream (the one you’d like to transcode) in WinAMP (this is VERY important – something must be played back in order the plug-in to be able to connect to Icecast2), go to Options / Preferences / Plug-ins / DSP/Effect and click oddcast DSP v3 (dsp_oddcast_v3.dll):
Click Add Encoder and, inside it, configure everything like with the standalone version of the same OddcastV3. That is, click “Add encoder” first. After adding one, double-click it (just like in ST3) to configure the outgoing stream.
It can be configured in a much easier way than ST3: instead of having to edit an XML file, you can edit the stream encoding parameters in a dialog box. For example, the following dialog box shows a 32 kbps HE-AAC v2 stream going to the Icecast2 server installed on the localhost, using the source password “menneisyyspwd” and using the mount point /iskelma:
After this, just click “Connect” in the main OddcastV3 GUI and the streaming will start right away.
Note that, as, by default, it uses the output of WinAMP, you don’t need to click the crossed-out mike icon,
, in order to set up the mixer to act as the source. Instead, it’ll directly get use the output of WinAMP as the source. This has the huge advantage of it not “picking up” other noises / sounds of the desktop PC. Also, it lets for setting WinAMP’s output volume to zero (as opposed to the generic, non-WinAMP-plugin version). Finally, you don’t end up having to play with the system (Windows)-level recording volume controls in order to make it work and/or fine-tune the sound volume so that it’s neither too quiet nor too loud and, consequently, distorted – see the distortion problems explained with StreamTranscoderV3. Incidentally, I’ve tested the same radio stations causing severe volume overload-related distortion. I haven’t run into the same problems with this title. Also, it has no problems with OGG sources either.
One of the best features of the plug-in version is the ability to directly transfer song-specific metadata. Several Internet radio stations (for example, 977music.com) stream title-specific metadata along with the streamed audio. An example of this is shown HERE, showing both the stream source (WinAMP in the background) and the mobile client running in SOTI's excellent Pocket Controller). Very few alternative technologies are capable of this feat – for example, anything based on the system audio mixer (and not direct stream transcoding) isn’t, including the standalone version of the plug-in.
A screenshot of the WinAMP plug-in version of OddcastV3 streaming the direct output of WinAMP:
The problem with this plug-in is the lack of support for original streams not played back by WinAMP; most importantly, RealAudio. However, you can stream them too (if you plan to stick with this stream source) if you quickly change the audio source from the WinAMP (internal) DSP to the system-level mixer of the PC in exactly the same way as with the standalone OddcastV3 client. This will also be elaborated on in the next section.
Note that, as with all the other Oddsock.org apps, the WinAMP plug-in OddcastV3 supports several output streams of the same input. The following screenshot shows it producing both a HE-AAC v2 and a plain MP3 stream, both at 32 kbps:

There are many cases you’ll want to make use of this feature. Just an example. I, generally, keep several Windows Mobile and Symbian handsets with me. Without having to remote control my desktop computer with a fully-fledged, bandwidth-hungry desktop controller (see their Bible HERE), I can quickly select from between the Windows Mobile-compliant, high-quality HE-AAC v2 and the Symbian-compliant, low-quality MP3 stream. That is, I don’t need to use the “lowest common denominator” approach to streaming (that is, streaming using the low-quality MP3) when I don’t know beforehand what operating system I will want to listen to radio stations – I can select the right one at runtime.
1.4.2.2.2.2 Standalone OddcastV3 client
This utility is vastly different from both ST3 and the WinAMP plug-in version of the same OddcastV3 introduced in the previous section in that it gets its source from the sound card mixer and not an external stream (as with ST3) or directly WinAMP (as with the WinAMP plug-in version of OddcastV3). That is, only stick to this if you in no way want to use WinAMP as the stream source.
This also means, compared to the WinAMP plug-in version, it has an extra configuration step (in addition to the initial AAC / MP3 encoder DLL copying to the home, C :\Program Files\OddcastV3, of course, which is also necessary with ST3). After installation, start it and set it up in exactly the same way as the WinAMP version. In addition, however, you’ll also need to set the default audio mixer of your desktop PC in the “Live recording” group. On my desktop PC, it’s “Realtek HD rear audio input”; on yours, it will be something else.
If you’re a newcomer to utilizing the built-in audio mixer of Windows, do the following in order to be absolutely sure you’re using the right input (and not, say, the default mike): click the loudspeaker / volume icon in the system tray (if you can’t find it, go to Start / Programs / Accessories / Entertainment / Volume Control), select Options / Properties and select the input mixer device you’ve defined (see the “Mixer device” drop-down list):
Now, click OK and make sure the “Stereo Mix” checkbox is ticked in:
In the above screenshot, the mouse cursor is just hovering over the checkbox so that you can easily find it.
1.4.2.3 VideoLAN VLC
There may be cases when you will want to prefer VLC to the other solutions, particularly when you have several streams you’d like to broadcast at the same time without relying on remote switching between them from a Web browser running on your handset. In this regard, VLC is probably the best solution.
Also, it’s heavily scriptable, which means, in general, you only need to create a batch file to quickly start transcoding. You just click on a batch file and a whole slew of transcoding processes start.
It, while is able to act as an Icecast2 / SHOUTcast source client, can also be directly connected by clients (it has server functionality too). Then, the stream it sends out won’t be SHOUTcast/Icecast2-compliant, which means for example no compatibility with Nokia Internet Radio. However, for other (for example, Windows Mobile) clients, it will still be usable and connectable. This is the mode you’ll need to use when transcoding WMA.
Finally, opposed to Orb (exactly like the other clients in here), it is completely SHOUTcast-compliant when used with an external Icecast2 client, which means it’s able to broadcast (some – unfortunately, not all!) SHOUTcast streams. This also means it’s fully compatible with Nokia Internet Radio (currently, the only really usable SHOUTcast client) on Symbian – and, of course, all the SHOUTcast-compliant clients on Windows Mobile.
However, it has problems as well; most importantly, it in no way supports HE-AAC v2 output (transcoded) streams. In addition, it’s not possible to remote control it, unlike with WinAMP-based solutions (most importantly, the most recommended OddcastV3) or Orb. Finally, VLC only supports (also see THIS) one codec type (of the many), Cook, of RealAudio. This means it’s unable to play back for example Sipro Lab Telecom ACELP-NET (sipr) streams used by, for example, YLE (example stream at rtsp://ra.yle.fi/live/radiopeili.rm).
As there are a lot of tutorials explaining how the GUI should be used for streaming, I don’t elaborate on these issues. Instead, I provide you with something that you’ll find much more interesting, particularly if you need a way to mass-invoke the encoding process. Here, I show you how you can invoke VLC from the command line to quickly start transcoding (as opposed to the GUI-centric tutorials written by others).
I’ve already shown you a batch file (excerpt) in section “1.4.2.1.1 Mount points”. Let’s go over it again; this time, I explain what the parameters mean. First, these two commands (preferably when put in a batch file) invoke the main executable, vlc.exe, and pass several parameters to it, telling it which source stream to transcode and what Icecast2 server to send the transcoded stream to. In addition, it has additional parameters (static station names).
Let’s start with the first command,
start vlc.exe --sout-shout-name="Iskelmä Radio" --sout-shout-description="Iskelmä Radio (Finnish)" http://217.30.180.250:8050/ :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
Here, I used the Windows batch command “start” to start vlc.exe in the background. Should I have left this out, the batch file wouldn’t go on after invoking the first vlc.exe – that is, only the first stream would be transcoded.
--sout-shout-name="Iskelmä Radio" instructs vlc to use a user-defined string, “Iskelmä Radio”, to identify the station. The next parameter, --sout-shout-description="Iskelmä Radio (Finnish)" provides a somewhat more elaborate description of the station. These are in no way mandatory parameters. (Note that there're other SHOUTcast parameters usable with VLC; they, however, didn't work with me.)
The next parameter, http://217.30.180.250:8050/, is the source stream’s URL and, therefore, much-much more important than the first two.
Finally, the last parameter:
:sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma}}
is pretty much intimidating at first. Don’t be afraid, however, I explain it all.
The first section between the {} marks, acodec=mp3,ab=32,channels=2, tells the system to 1, use the MP3 encoding; 2, use 32 kbps and, 3, use two channels (stereo) in the transcoded stream. This section is very easy to modify; for example, if you want a mono MP3 stream, just change 2 to 1 after channels=. This will give you somewhat better audio quality and is preferable when you wouldn’t, otherwise, benefit from the source being stereo – for example, with mono talk programs. However, if you listen to streamed music via headphones, you’ll want to stick with the stereo mode, even at the expense of the (slight) sound quality degradation.
Similarly, if you need a 16 kbps MP3 stream instead of the 32 kbps one, just change 32 to 16 after ab=. (Then, you’ll also want to switch to mono mode, of course.)

The contents (access=shout,mux=ogg,dst=source:[email protected]:8000/iskelma) of the inner parentheses after “duplicate” defines some other parameters; namely, the target of the stream, which, in this case, is an Icecast2 server. “source” is the standard name for Icecast2 (‘back-end’) stream sources; mennpwd is the password I use. 127.0.0.1:8000 is the address of the Icecast2 server I (and, most probably, you also will) use (that is, as can clearly be seen, it’s running on the same PC) and /iskelma is an old friend of us: the mount point.
Based on the information above, you’ll recognize everything in the following direct invocation batch file snippet:
start vlc.exe --sout-shout-name="Radio Vaasa" --sout-shout-description=" Radio Vaasa (Finnish)" http://webcast.vlp.fi:8000/radioVaasa :sout=#transcode{acodec=mp3,ab=32,channels=2}:duplicate{dst=std{access=shout,mux=ogg,dst=source:[email protected]:8000/radioVaasa}}
Now, let’s take a look at a somewhat different batch file snippet: two VLC invocations that don’t use an external Icecast server as the middle tier in the transcoding process, but opens two ports in itself and waits for incoming client connections. (In this way, it implements the classic two-tier, client-server architecture.)
start vlc.exe mms://mediau.yle.fi/liveradiopeili :sout=#transcode{acodec=mp3,ab=32,channels=1}:duplicate{dst=std{access=http,mux=mpeg1,dst=:1234}}
start vlc.exe http://194.252.88.103/eanettiradio :sout=#transcode{acodec=mp3,ab=32,channels=1}:duplicate{dst=std{access=http,mux=mpeg1,dst=:1236}}
These commands are pretty much similar to the previous ones, except for:
1, they completely lack the --sout-shout-name and --sout-shout-description parameters (they can only be used together with an external Icecast2 server)
2, here, the dst (destination) parameter only has one port number (1234 with the first and 1236 with the second commnd) – and nothing else. This instructs VLC to open up server ports in itself, waiting for listening clients (for example, your handset) to connect. Instead of making an external Icecast2 server do this task.
Why would you want to use the second case? It’s pretty easy: there are streams that VLC is just unable to correctly transcode into an Icecast2-compliant format. WMA streams (just like the two in this example; that is, THIS and the WMA stream at mms://mediau.yle.fi/liveradiopeili) too belong to this category. In these cases, you can still directly access VLC.
Incidentally, if you encounter Icecast2 vs. VLC compatibility problems with some source stream types (like the above), you can easily determine if a given stream type can’t be streamed to VLC by checking out the total_bytes_read (highlighted HERE) of the particular stream. If it’s 0 (as in the just-linked screenshot), then, the stream is just not compatible with Icecast2. WMA streams are exactly like these.
Note that I haven’t managed to test the RealAudio transcoding capabilities of VLC because of the limited compatibility. In this regard, Orb fares without doubt the best – that is, use Orb to transcode an initially RealAudio-only stream into a more handset / NAT-compliant one.
1.4.2.4 Windows Media Encoder (WME)
This free, system audio mixer-based (meaning it also needs a system-level audio source like WinAMP) and easy-to-use tool doesn’t require an outgoing Icecast2 server. That is, you can directly connect to it from your handset. However, its usability is pretty much hampered, particularly if you are stuck with GPRS because HE-AAC v2 delivers MUCH better sound quality at the same (low, GPRS-compliant) bitrates. Therefore, you’ll always want to prefer HE-AAC v2-capable transcoding solutions (for example, WinAMP with the OddcastV3 plug-in and an external Icecast2 server) to WME.
I don’t elaborate on configuring it in server mode because
there are several tutorials on it – use Google
as has already been pointed out, I do NOT recommend using it. In general, other formats are much more efficient at (24…32) low bitrates
The only reason I include it in this Bible (and in the final Comparison Chart) is that you can compare its capabilities with the competing technologies.
1.5 Remote controlling WinAMP
As has already been seen, currently (before Orb finally introduces Icecast2-based HE-AAC v2 streaming) WinAMP, together with the OddcastV3 plug-in, is probably the best way to transcode your streams. And, if you use a transcoder getting its audio input from the operating system mixer, you may still want to prefer WinAMP because of its high compatibility ratio (of the major radio streaming formats, it’s only RealAudio that it doesn’t support; Windows Media Player is far worse in this respect, unless you manually install additional codecs for it) and excellent remote controllability.
As using WinAMP (both with the OddcastV3 plug-in and a third-party, mixer-based encoder like WME or the standalone version of OddcastV3) it’s strictly a one-stream-at-a-time solution (as opposed to VLC or StreamTranscoderV3), you MUST know how it can be remotely controlled from your handset when you want to switch to another station.
Fortunately, there’re several remote media controller tools compatible with WinAMP. I’ve elaborated on all of them in the Remote Media Controllers Bible. Please make sure you VERY thoroughly read it and go for a solution that supports both WinAMP and remote, TCP/IP-based access.
1.6 Other goodies
All of the reviewed tools allow for not only transcoding radio stations, but also saving the stream to your desktop computer, into a file.
Note that, however, none of them has the same functionality as that of Streamripper. That is, even if they support music metadata, they don’t create separate files based on them. As has already been mentioned in my previous, radio streaming-related “sneak peek”, Resco’s excellent SHOUTcast client, Pocket Radio also supports this on Windows Mobile.
2. Feature & comparison chart
In the following chart, I compare the reviewed applications. The three main groups are as follows: Input compares the input formats they’re able to transcode; Output compares the streaming formats they are able to produce and, finally, Misc elaborates on issues already touched on in this Bible.

3. Verdict
As usual, there’s no winner because several factors may influence your decision. Let’s walk over some of them.
If reducing the bitrate to 32 kbps or less is very important because you only have a GPRS connectivity or want to save bandwidth usage: your best choice is HE-AAC v2 (preferably, the WinAMP plug-in version of OddcastV3) if you have a Windows Mobile device. If you have a Symbian one, either a SHOUTcast MP3 stream-capable one or, if you’re lucky enough to have direct connection to the Net (non-NAT’ing mobile operator), you can (also) use Orb’s 3G AAC or RealAudio formats. Given that Orb has the best remote controller / stream selection interface, the latter choice is the best, particularly if you plan to listen to / switch between more than one stream.
You may also want to decide how many radio stations do you plan to transcode. First, let’s assume you don’t want to use Orb either because of the inferior transcoded sound quality at low bitrates (no HE-AAC v2 support – any sane person striving for using really low data usage will want to use HE-AAC v2 and nothing else) or the full incompatibility with your client (Symbian player in a NAT’ed environment).
If only one, then, you can use any of these technologies – even VLC and StreamTranscoderV3 (the two direct transcoders that can’t really be remote controlled without a fully-fledged and, as opposed to remote media controllers, heavily bandwidth-wasting remote desktop controller tool) will do.
If you’d like to easily switch between, say, 2...20 transcoded radio stations without any kind of remote sound source control (WinAMP remote control – again, see the related Remote Media Controllers Bible), you might want to take a look at VLC (started from a batch file so that you don’t need to set up each transcoding session manually each time) or, again, StreamTranscoderV3. These are the best tools for parallel transcoding of some tens of radio stations (depending on your CPU speed and maximal usage you’d like to let). Note that, however, both of these solutions are a bit suboptimal. First, you may also run into the volume overdriving problems I’ve explained with StreamTranscoderV3 – and its limited source compatibility. And, with VLC, you can’t output HE-AAC v2 in any way.
If you need to transcode more than 20…30 stations (so that you can arbitrarily select from them on your handset), you can forget about parallel transcoding at once because of its CPU needs. Then, you WILL need to install a remote media controller to directly control (switch source stations) the sound source on your desktop computer. While there’re remote controllers for all major desktop players, you may still want to prefer WinAMP – particularly because of the excellent integration of the plug-in version of OddcastV3.
If using Orb isn’t a problem with you because
- the lack of HE-AAC v2 isn’t a problem because, for example, you (also) have an EDGE connection and, therefore, aren’t forced to using GPRS speeds and/or
- you have a direct, non-NAT’ed connection and/or
- you have a Windows Mobile device (remember: on Symbian, you MUST have a direct, non-NAT’ed connection for Orb to work! That is, orb is completely ruled out if you’re NAT’ed),
it might be the best choice for you because it’s really easy to set up and use: no need to set up and configure any transcoders and/or remote media controllers at all. Its Web interface is really intuitive, powerful and consumes very little bandwidth – as opposed to some other web interfaces (most importantly, that of VLC, which is really bad in these respects).

UPDATE (01/03/2008): as an addition to bullet 3 of section “1.2 When you prefer optimizing an, otherwise, working stream...”, I’ve made some 3G vs 2G power consumption tests on the HTC Trinity / P3600 running the official February 2007 ROM version so that I can prove that the “streaming over 3G consumes way more power than streaming over pre-3G connections, even at the same bitrate” rule-of-thumb is right with every single chipset used in contemporary handsets. The results speak for themselves:
The first section shows playing back a stream over HSDPA, the second shows playing over exactly the same HE-AACv2 stream over GPRS, in TCPMP.
Let’s do some math: ~500 mA / ~280 mA = 78%! That is, if you stick with 3G on the Trinity for streaming, your battery life will be about 80% worse!
CPU usage vs power usage
Still looking at the above screenshots, the third (and all section after that) shows switching from the more CPU-intensive HE-AACv2 stream to an MP3 stream (still using GPRS – as in the next benchmarks) to find out whether the decreased CPU usage results in any change in the power usage. As can clearly be seen, there’s not much difference – they’re unmeasurable.
In the following screenshot:
I’ve enabled A2DP audio transfer to stereo Bluetooth headphones. A2DP, for some (for me, unknown) reason, is very CPU-intensive on all Samsung-based Windows Mobile devices. As I’ve already stated in some of my articles (see for example THIS), it raises the CPU usage by about 50 (fifty) percents. (For comparison, at 400 MHz, the same Microsoft A2DP implementation “only” results between 10...20% of CPU usage increase on Intel Xscale (pre-PXA-3xx, where I still haven’t tested this) and on TI OMAP CPU’s.) Therefore, switching on A2DP is a great way to quickly “bump up” the CPU usage. In the first (short) test, I’ve continued playing the same MP3 stream (for quite a short time; therefore, the (relative) results aren't very dependable); in the second (much longer) test, I switched back to the original, more CPU-intensive HE-AACv2 stream. Then, the CPU usage was constantly at 100% (again, "thanks" to the huge CPU usage of A2DP on all Samsung-based Windows Mobile handsets) and the audio started to stutter. As can be seen, there was no measurable increase in power usage, compared to the case of only about 30% CPU usage.
This certainly shows the Samsung CPU’s do have some strengths; albeit, in many other ways, they’re definitely behind the current crop of CPU’s. For example, they still use the ancient ARMv4T architecture (approximately the same as that of the 9-year-old Intel StrongARM - yes, the CPU used in the first, h31xx/h36xx-series iPAQ's released in May 2000), while
even the oldest (much older than those of Samsung!) Intel PXA-series CPU’s are already ARMv5TE,
let alone the latest Texas Instruments OMAP2420 generation (used in, for example, the Nokia N95 or, as far as Windows Mobile devices are concerned, (only) the Samsung SGH-i616, BlackJack II and the Moto Q9h Global – note that the Texas Instruments OMAP 850 Windows Mobile phones almost exclusively used in HTC’s “lower-end”, and the OMAP 1710 in some MS Smartphones are still ARMv5TEJ only)
and the Qualcomm MSM7200 (used in many contemporary, higher-end HTC devices - HTC Kaiser etc.), which are ARMv6. That is, two generations more advanced than those of Samsung.

REVIEW: just-released VirtualCE 4 – another great PDA controller alternative!

Last Summer, upon the release of the brand-new, 6-series of SOTi Pocket Controller Pro and the free My Mobiler (click the links for a review!), I’ve already pointed out the “let’s control your Windows Mobile device from your desktop!” scene is really thriving.
Since the above reviews, here have been major upgrades. First, My Mobiler has been greatly enhanced (for example, TCP/IP connections have been added) and the bugs I’ve elaborated on in the review have all been fixed – while still maintaining its free status. In this article (and the accompanying chart), I also thoroughly elaborate on these changes.
Even more importantly, the, for long-time Windows Mobile users, known VirtualCE has been greatly upgraded and enhanced.
As VirtualCE has been written by the same developer as the well-known and very fast PQV and SmartGear – one of the best titles in their respective categories (picture viewers and pre-SNES home and handheld console emulators). I wasn’t disappointed: while there is indeed some missing functionality in the new version, its price, CPU usage and, at times, speed, speak for themselves. It’s evident it has been written by a Windows Mobile & C / assembly language guru that knows how to optimize code and, therefore, reduce the CPU (and memory) usage.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(The main interface screen and an example of remote controlling a HTC Vox / s710. The latter displays the VirtualCE client on the handset.)
VirtualCE is, feature-wise, somewhere between the free My Mobiler and the pretty expensive, albeit VERY capable and highly recommended SOTi Pocket Controller. In some respects, it’s definitely more capable than SOTi’s app (for example, see the parallel multicontrol feature, which is only present in the even more expensive Enterprise version of SOTi’s app; also, the much lower CPU usage should be mentioned); in other respects, it’s inferior to even My Mobiler (see for example the complete lack of handheld / handset -> desktop PC clipboard synchronization).
Installation, usage
Installation-wise, there isn’t much to do. Just download the trial version HERE (note that there is a different one for Pocket PC’s and MS Smartphones), start the installer on the desktop computer and make sure your handset is connected via ActiveSync so that the (handset-side) server can be installed.
Should you want to activate the connection, then, you’ll need to start Start / (on Pocket PC’s) Programs / Virtual CE on your handset and. Then, just start the VirtualCE client on your desktop computer.
Should you want to remote control your device via ActiveSync, just cradle / connect it to your desktop and double-click the default “ActiveSync” entry in the list. If you establish the ActiveSync connection between the desktop and your handset before starting the desktop VirtualCE client, it'll automatically connect.
Should you want to create a non-ActiveSync connection, go to Connection / New… and, after naming the next entry (you don’t need to do this, but is still recommended), select the connection type in the Connection Type drop-down menu:
Should you want a remote TCP/IP connection, select WAN / Internet; then, you’ll also need to enter the IP of the handset as can be seen in THIS screenshot. Should you “only” want to control a, say, Wi-Fi-connected device on the LAN, you can also select LAN (Auto Discovery). Note that the latter will make initiating the connection a bit slower, as, as will also be explained in the “SOTi vs. VirtualCE” section, you’ll always need to select the device from a list whenever you try to initiate a connection to it.
Functionality
VirtualCE supports most functionalities one can expect of a non-high-end controller: taking screenshots, rotating the screen to be able to take screenshots / control games using GAPI to switch to Landscape mode and/or Web browsers like Thunderhawk that also use the landscape orientation. Also, just like all the other, most recommended alternatives, it allows for TCP/IP connections, which means you can remotely access a (connectable; that is, non-NAT’ed / firewalled) Windows Mobile device anywhere in the world. This is of extreme importance particularly for Customer Service and/or enterprise folks, who may need to access the handsets of their customers / workers somewhere else in the world (that is, not connected to the local desktop, where ActiveSync would (also) work.)
It also supports connecting to several clients at the same time. This is pretty unique. An example is shown in the following screenshot (click for the original size!)
In here, I’ve shown an example of controlling no less than five (VGA WM5 x51v, VGA WM6 HTC Universal; QVGA WM2003 HP iPAQ 2210; QVGA WM6 Vox/s710 Smartphone; QVGA WM6 HTC Wizard) devices at the same time. Note that I’ve left the main server screen of VirtualCE on all the handsets to reduce the size of the screenshot (PNG’s don’t really like colorful, “natural” pictures, and I didn’t want to use the, for making technical screenshots, inferior JPG); I could have controlled these devices freely. Also note the different IP’s visible on the phones.
However, it lacks some basic functionalities; most importantly, the ability to copy some text from the handheld to the desktop. While I agree the opposite direction is far more widely used (think of, say, quickly pasting loooooooooong registration numbers to your just-purchased app!), in cases, the opposite may also be desirable, particularly with folks that publish a lot of articles on Windows Mobile devices. (For example, I need to copy text from, say, Web browser User-Agent strings like in THIS thread.)
CPU usage
Traditionally, PDA controller apps have had high CPU usage. The two other, highly recommended controller apps (SOTi, My Mobiler) too have high CPU usage – particularly when controlling a VGA device.
Not so with VirtualCE. It has the least CPU usage of all; in this regard, it’s way the best. If you have problems because another remote controller app (either SOTi’s or My Mobiler – but are way worse in this respect) takes too much CPU time (which, for example, results in a very bad slowdown), make sure you give VirtualCE a try.
Speed
The screen refresh rate has always been causing the most problems with most remote controllers. (Actually, this is why I don’t recommend any of the alternative controllers at all: they’re plain slow, even with low-resolution (QVGA) devices, let alone high-resolution ((W)VGA) ones.)
In this regard, VirtualCE fares pretty well. Compared to (the free) My Mobiler, it’s faster in every respect; this is particularly visible in the full-screen animation video (see later). On QVGA devices, the difference isn’t that big, though – My Mobiler is perfectly usable on the latter.
Compared to SOTI’s much more expensive, but, apart from the CPU usage and the inability to control several devices at the same time and LAN discovery, vastly superior remote controller, there are two remarks.
1. If you need to control an application with frequent full screen upgrades (a game or even wildly scrolling the, say, Programs screen), SOTi’s app is much better and faster on high-resolution ((W)VGA) devices.
2. If, on the other hand, the changes are only restricted to a comparatively small area of the screen, VirtualCE updates the desktop-side screen somewhat faster than SOTi.
Again, the speed difference between these three apps are only really visible on high-resolution devices like WVGA or even VGA ones. On low-resolution (QVGA or 176*220 Smartphones) ones, there won’t really be (at least annoying) differences. There, My Mobiler will be the slowest but still really well usable.
I’ve made several, easily comparable test videos of all these results so that you can see I’m not lying. Two of them (the one based on my self-written test counter suite; the other on the new, excellent game Nanobotz) show changes restricted to a small area on the screen; the other shows a small portion of a full-screen animation. (Note that I’ve run the counter test twice on the VGA Dell Axim x51v: underclocked to 208 MHz and at the default 624 MHz to emulate slower and/or underclocked VGA devices).
Use the built-in Windows Media Player to play back the sample benchmark videos (all of them are linked from the chart). Unfortunately, the otherwise free and highly recommended (VideoLAN) VLC client isn't able to play them back.

How does it compare to Pocket Controller Pro?
Pros
First, it’s way less expensive, particularly if you have more than one Windows Mobile devices. In the latter case, you would need to purchase a license to each of these devices from SOTi.
It has way less CPU usage, resulting in a far snappier client. This is especially useful on (W)VGA Pocket PC’s, where the CPU usage of SOTi can easily become an issue.
It allows for controlling more than one Windows Mobile client at a time. This is only available in the significantly more expensive version of SOTi’s app.
It not only supports (remote) TCP/IP connections, but also LAN discovery (for example, Wi-Fi connected handsets on the same local area network). An example of this:
This frees you from having to enter the client IP. However, this also makes initiating the connection a bit slower as you’ll always end up having to select the LAN-connected device you’d like to control from a list whenever you try to connect a LAN-autodiscovered device.
It doesn’t display a connection message when you start the connection. In SOTi’s app, this can’t be suppressed, which means you can’t start the control session in several games / other, mostly full-screen programs without, say, the top taskbar being imposed over the image displayed by the controlled application. (BTW, in this regard, My Mobiler is also better than SOTi’s app.)
Cons
While, particularly on (W)VGA devices, VirtualCE clearly beats SOTi’s app in capturing and transferring changes restricted to a very small screen area, the latter is much faster when there are (nearly) full screen changes. This means you may want to prefer SOTi’s app when, say, you want to take screenshots of a game.
There are no built-in video recording features. While with an external, desktop-side application capable of recording any screen area into a video (like SnagIt or Fraps), you can easily record what the controller shows, built-in video recording capabilities would be even better. This regard, SOTi’s app is way better / more convenient.
Note that, as far as other controller apps are concerned, the non-recommended dotPocket and the free and, now (as of version 0.91b), WM5-compliant VH PocketPC Capture are both capable of video recording. They, however, are significantly inferior to the most recommended “Holy Trinity” of handheld controllers (SOTi Pocket Controller Pro, VirtualCE and MyMobiler). Should you still want to give the latter two apps a try (I wouldn’t bother with dotPocket; VH PocketPC Capture is a tad better), see THIS for more info. (Note that the article still discusses the previous, 0.9b version of VH PocketPC Capture; it wasn’t, back then, WM5-compliant. Now, it is.)
How does it compare to My Mobiler?
Pros
Lower CPU usage
Ability to control several devices at the same time in wildly different networking topologies (again, in these two respects, it’s better than even SOTi’s Pocket Controller Pro).
Definitely faster in every scenario
Ability to custom rotate the screen
Doesn’t display an icon on the Today screen on Pocket PC’s / on the taskbar on Smartphones
Cons
It isn’t free (albeit $10 is REALLY cheap if you take into account its capabilities)
No PDA -> PPC clipboard synchronization
Impossible to reduce the zoom factor to 0.5 (when, for example, you’d like to take a QVGA-sized, low-res screenshot of a VGA devices without manual resizing in another program like ImageMagick.)
Comparison / feature chart
As usual, I’ve created a comparison / feature chart. Because of the size and the useful links inside, I can’t include it in here. IT IS HERE – CLICK THE LINK!.
Verdict
Now that there is another, highly recommended remote controller application, it’s even harder to choose from the “Holy Trinity”: SOTi Pocket Controller Pro, VirtualCE and MyMobiler. There are tasks one of them is best and there are tasks when the others.
Just some cases / examples showing you which of the three controllers you choose, depending on your particular needs:
for example, if you need to take a video / animation of a screen, particularly if it’s a VGA; then, your best choice will be SOTi’s app (or, probably, VirtualCE, if there aren’t frequent full-screen changes or animations and you can put up with using an external, generic video recorder like SnagIt).
(Note that, in this case, absolutely the best and fastest solution is using a PDA with a VGA (an example: Dell Axim x50v/ x51v (see THIS); you’ll also need an external VGA-to-analogue converter) or an analogue (non-VGA) output like that of the HTC x7500 / Advantage / Athena. If you plan to make a video of, say, a fast-paced action game where the quality degradation introduced by the double digital -> analogue -> digital conversion isn’t a problem, this might be the best solution. If, on the other hand, you can’t introduce analogue artifacts (blurred screen), you will still need to stick with a PDA controller app to take your videos. Unless, of course, you use so high a video compression rate in the final output file that effectively hides the artifacts introduced by the dual D/A and A/D conversion.
Note that some of the PDA’s with a built-in VGA output are pretty slow; an example of them is the (old) e800/e830. Also note that the old(ish) CF / SD-based video output cards or Bluetooth-based video output solutions like the Mobility Electronics Pitch Duo Presentation Device, Colorgraphics Voyager CF, Video Output SDIO Card From Spectec, Pretec VGA CF, or the discontinued Margi Presenter-to-Go and Presenter-to-Go SD for Select (see THIS for more info & links on all these) are, in general, pretty slow too and can’t match the speed of the video output speed of the Dell Axim x50v/ x51v or the HTC x7500.)
if you need absolutely the least CPU usage (because you don’t want the app / game you control / take screenshots of to be executed with a snail’s speed), your best choice might be VirtualCE
if you need to paste a LOT of text from the handset’s screen to your desktop (and you don’t want to use a file-based, very awkward transfer method), go for anything else than VirtualCE
should you need an easy way of editing / accessing the Registry, running keyboard macros etc. on your handset, get SOTi’s app
if you have more than one handset you’d like to control, but don’t have much money, you won’t want to go for SOTi because of the increased price (need a license for each and every client)
if you need to make screenshots of a WM game well into the game, but running it under a remote controller would really slow it down to a crawl, you will want to go for a controller that doesn’t mess up the game screen when activated – well into the game. SOTi’s app, in this respect, might turn out to be the worst solution because the dialog it displays on the handset may fully mess up the screen of the currently running application – or, at least, alter it to some degree. In this case, you may want to go for either VirtualCE or My Mobiler.
should you need PNG or JPG output with selectable (!) quality, either go for anything non- VirtualCE or, if you stick with the latter, make sure you install a third-party app to convert the output images (I recommend BMP) to PNG’s or JPG’s; now, with the needed quality.
Albeit I’ve already elaborated on this issue in some of my articles, let me quickly recite what you’ll need. First, get and install ImageMagick. Then, copy all the files you’d like to convert to a directory and put one of the following commands in a batch file (change http://www.winmobiletech.com/012008Controllers/Program Files\ImageMagick-6.3.1-Q16\convert.exe to the path of your version):
FOR /R %%X IN (*.bmp) DO "C:\Program Files\ImageMagick-6.3.1-Q16\convert.exe" "%%X" "%%X.png"
(this converts from BMP to PNG)
FOR /R %%X IN (*.bmp) DO "C:\Program Files\ImageMagick-6.3.1-Q16\convert.exe" -quality 50 "%%X" "%%X.jpg"
(this converts from BMP to JPG, with settable output quality – here, it’s 50%).
By just running the batch file(s) in the directory you’ve collected your VirtualCE screenshots to, you can easily fix the complete lack of PNG / settable-quality JPG files.
Finally, note that VirtualCE excels in that it allows for one-click screenshots with auto-numbering. This can prove to be extremely useful in some cases.
etc. – the list continues

This also shows there simply isn’t an all-the-best application. Everything depends on your needs. What I recommend is the following: if you have the money, get both SOTi Pocket Controller Pro and VirtualCE. Then, you’ll have the best of both worlds – all your future needs will be satisfied. If you can’t afford SOTi’s app but can still afford VirtualCE, don’t’ hesitate to purchase it – it’s still better and faster than the free My Mobiler and is really cheap. Then, however, just in case you’d need (frequent) handset -> PC text copy/paste, also make sure you download and install My Mobiler. (You won’t need the latter if you go the first, that is, the SOTi + VirtualCE route as SOTi’s app also supports this direction.)
Finally, if you have absolutely no money, My Mobiler is still way better than any other, free alternative like Microsoft’s remote controller or the various VNC-based tools. That is, go get it and forget all the other, free alternatives, no matter what some other people say – believe me, it’s vastly superior to them.
(Note that the current, tested, 4.0.2 version occasionally crashes, mostly upon saving into BMP24 screenshots, rotating the view and when, after having connected to a Portrait device, connect to a Landscape one in multiple device control mode. I haven’t encountered similar problems with connecting devices using strictly the Portrait orientation. Hope these bugs will be very quickly fixed by the developer.)

UPDATE (01/31/2008): MoDaCo frontpage
UPDATE (01/31/2008): Thanks to beemer on my blog, the just-released My Mobiler 1.0.70821.010 has the following enhancements compared to the version reviewed above:
-It now rotates the screen manually
-It uses 50% CPU on a G900 against 90% CPU of SOTI pocket controller.
-It allows to hide the icon on the PDA Today screen tray bar from the desktop tray bar icon menu.

UPDATE (02/01/2008):
Pocket Controller 6 IS able to (auto-)discover other clients in a (for example, Wi-Fi) LAN.
Unlike with ActiveSync, when connecting thru Wi-Fi (which may mean other kinds of TCP/IP connections - I haven't tested this), in PC6, the connection dialog isn't displayed.
(thanks to 3pears on my blog for the info!)

The Multiplatform Podcasting / Podcatching Bible (updated!)

Listening to or watching podcasts is great fun. If you think they are boring, meaningless or can’t entertain you during, say, a long fight, you’re wrong. For example, watching all the clips of X-Play, played back on my VGA HP iPAQ 214 (thanks to Smartphone & PPCMag / iPhone Life’s Hal Goldstein for the gift!) could entertain me for long-long hours. (Sure, I’m not of a big 3D FPS gamer on desktop PC’s – I only play text adventures like those of Legend Entertainment and RTS games like Starcraft –; still, I did enjoy witty episodes like Cheating Unleashed: Darth Vader Tryst or Final Fantasy Date).
And, if you’re more of a traditional news viewer / consumer, you’ll definitely prefer automated podcast downloading to hunting for the same video / audio clips on the web. Just a real-world example: Before finding out the Tagesschau (the German news program we usually watch at home in addition to the Finnish YLE programs) podcast feeds, I always had to navigate to HERE (preferably after 9PM and before midnight each day so that I can catch the main evening news program at 8PM) and click the 20:00 link to initiate playback. Then, still two clicks: to start the streaming and to maximize the player screen after the video playback has started. All in all, a lot of clicks and waiting in between – not to take into account you can’t access the programs of the previous day(s).
Diametrically opposed to the awkwardness of all the above, just subscribing to the Tagesschau podcast feed (with downloading the video podcasts (files), the so-called “enclosures“, to the local PC or Windows Mobile, Symbian or BlackBerry handset / smartphone) makes sure you’ll always have access to the main, longest (the one at 20:00) programs – and instantly. That is, you don’t have to (slowly) traverse Web pages, wait some seconds for the video streaming to start to be able to make the player fullscreen – if you are always in a podcaster program (on either a desktop PC or any of the smartphone operating systems), in general, (at least in a well-designed podcaster app like NewsBreak) a single screen tap starts the instant playback.
The same stands for, for example, the MoDaCo (Windows Mobile), All About Symbian (Symbian) or CrackBerry (BlackBerry) podcasts. If you don’t use automatized podcatcher apps to gather these podcasts and make them available offline on your handset (for mobile access; of course, you can also store it on your desktop PC, but the major focus in this article is on fully-mobile podcast/catching), then, you end up, on your desktop PC, having to do a lot of hunting, right-clicking, saving to your hard disk and manual transferring to the storage cards. There, you’ll still need to make sure your mobile media player is able to play these podcasts; this may also require a lot of additional work like starting a library refresh (see dedicated bible HERE) and waiting for it to complete. In cases, this may turn out to be just too slow and time-consuming.
Side note: Difference between podcasters and podcatchers
What’s the difference between podcaster and podcatcher applications, you may ask. The much simpler podcaster apps can only stream (play back) podcasts, but can’t save them to the file system and, consequently, don’t have any kind of scheduling, cleanup or storage usage restriction capabilities. They, nevertheless, allow for subscribing to feeds, which makes it possible to avoid having to enter their Internet address every time.
More advanced ones (in our case, Pocket Player, as opposed to the, as of the current, 1.2.5 version, simpler CorePlayer) even allow for marking podcasts that have already been listened to “read” so that the user won’t listen to them again by mistake as he or she already sees the given podcast has already been consumed. In this regard (too), they provide a far sleeker interface to podcast feeds than traditional Web browsers on mobile platforms, which are much harder to use. With the latter, it takes much more clicks to get to the next podcast; in most cases, Web browsers require podcasts to be saved to the file system first and only let them to be played by a multimedia player later, while podcatching-capable apps are capable of instant streaming etc. Nevertheless, on the BlackBerry platform, still a lot of people prefer downloading podcasts manually (linked to from HERE), via, say, Opera Mini .
The much more advanced podcatcher applications, on the other hand, in addition to being able to play back the podcasts (in several cases, with the help of an external player), are also able to store them in the local file system and can also work in scheduled mode, making it possible to run even lengthy download / synchronization processes when you surely won’t need the handset – for example, during the night.
If you, on the other hand, run a podcatcher application on your handset every night, connecting to the Internet via a Wi-Fi access point of an unlimited Internet connection to download the latest podcasts and to store them on/in your storage (card), you won’t have to waste time on anything explained above. When you wake up in the morning, the latest podcasts will already be available on your handset and you simply don’t have to be afraid of anything else.
Running direct podcatcher applications on your handset – if you do plan to listen to / watch these podcasts right on the phone – is definitely more preferable to doing the same on the desktop and manually synchronizing / copying the files to the handset:
- You don’t have to do any synchronization between your desktop and handset (or memory card swapping if you plan to make a non-high speed transfer faster)
- You don’t even need to switch on your desktop computer for the new podcasts to be downloaded (let alone having to sync it with your handset or, even worse, manually hunt for, select and transfer the new podcasts to it). This results in, among other things, a lot of saved electricity
- You don’t even need to have a desktop computer at all – all you need to get the latest podcasts is your handset itself with an unlimited Internet (or Wi-Fi) connection.
Still, if you do want to know what desktop podcatcher applications there are, you’ll want to read either Smartphone & Pocket PC Mag‘s or Engadget’s tutorials (the former being far more thorough). They both discuss Doppler (probably the best desktop client; another also very popular one is Juice) on the desktop – and synchronizing the clients to your handset. More advanced users / hackers may also want to take a look at the MortScript-based PC -> Windows Mobile syncing solution HERE.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(Doppler on the desktop; by default, it downloads to c: \Documents and Settings\<username>\My Documents\My Music\My Podcasts\<feed name>).
Note that not even popular desktop browsers like Opera support automatic podcast downloading (that is, podcatching). Three screenshots showing this:
(podcasts shown in Opera)
(another rendering example– as you can see, Opera doesn’t download content)
(There isn’t anything you can do in Feeds / Manager Feeds / Edit (Properties) either, except for setting the interval of the auto-retrieve)
There are even fewer write-ups on the handset-based podcaster applications. The most important of them is Podcasts on a PDA..., which discusses three mobile OS'es and only few podcaster apps: WM (Egress), Palm (Quick News), Symbian (Nokia Podcasting) - as you can see, BlackBerries are not discussed.

Note that this roundup is a separate entity from my forthcoming RSS / Syndication Bible (to be published early September). I found it necessary to separate the two roundups from each other as, while, basically, they’re all RSS readers, their aim is different. In addition, some of the podcaster apps are just not recommended as an RSS reader and vice versa: some well-known RSS reader titles like Spb Insight (as of the current, 1.5.1 version) aren’t enclosure-capable at all.
Also note that because there are several high-quality and recommended podcast/catcher apps, I don’t have a definite choice. (If you really want one, I recommend NewsBreak if you are ready to pay for your podcaster and BeyondPod or HubDog if you aren’t.) Therefore, I don’t provide you a full tutorial of any of these apps either. However, in the chart, I do give you a lot of tips and tricks and describe how / where a specific feature can be found. This is why I provide the full menu path of all the, say, feature en/disabling checkboxes in the chart. I also provide several screenshots showing all this.
That is, while I don’t provide a full, 100% tutorial to any of these apps, as with all my chart-based articles, bibles and full roundups, I do provide you with hundreds (!) of tips and tricks in the chart. If you really don’t understand how you can configure a given podcaster, feel free to post a public (no private messages please) note and I answer your questions. I don’t think, however, that you wouldn’t understand them. They’re all (except for FeederReader, which does require a LOT of learning) fairly easy to learn. Just keep playing with your choice for some hours and you’ll start to know it like the palm of your hand. Then, all the puzzles will also fall into their places.
Now, let’s take a quick look at the podcast/catcher applications available for the three mobile platforms. Note that this section is in no way a full discussion and introduction of all the apps. The sole reason for this is the main chart’s having all the information you’ll ever need. That is, don’t expect this humble section to contain as much information as available in the 60 kbyte-long (!) and tabular (which eliminates the need for repeating the same info again and again) chart. Also note that all the apps are podcatchers, unless otherwise noted (with the case of CorePlayer and Pocket Player).
Let’s start with Windows Mobile, with remarks to the BlackBerry version of AudioBay and, finally, the Symbian-based Nokia Podcasting.
BeetzStream SmartRss V4.3157 - RC1
This app requires .Net CF 3.5 SP1 (while the other Compact Framework-based titles don’t need more than CF2) and MS SQL Server Compact Edition 3.5 SP1. The trial version is pretty useless: it limits you to 5 items per channel and will not save any setting changes, as opposed to the, in general, fully functional, 30-day test version of the other apps.
In a nutshell, I don’t really recommend this title - there're far better alternatives.
Kinoma Play
As of version 5.0.60, this recently-released player has excellent (streamed) podcasting features (but not podcatching at all).
It allows for directly entering RSS URL's in the main menu. It’s quite a bit buried under the different menus: it’s available at Settings / Player / Open URL:
The latest update (see THIS) has also introduced auto-pasting features (manual pasting doesn't work as the app uses nonstandard text input fields / areas).
While it doesn't allow for direct OPML input (that is, you can’t explicitly browse the file system to find the given file), if you just put the OPML file in the file system somewhere, it'll find the contents and list it under "My Media Files / Playlists" as in the following screenshot:
Note that if the OPML file also contains subfolders, they’ll be correctly rendered and the OPML file’s original name will be used as the playlist name. An example of this is (the highlighted) “BeyondPodFeeds” item in the above list.
Note that while it streams stuff, it, of course, needs to download multimedia content that it can’t play back streamed. Examples of this are the Tagesschau videos
pRSSreader
As of version 1.4.2, this, because of it being free and open-source, pretty popular generic RSS client has some limited podcatching capabilities. In no way as sophisticated as those of some of the other clients as, unfortunately, it in no way can be forced to automatically download enclosures (again, unlike most other podcatcher clients). In the top-level "Channels" view, Menu / Offline / Cache Unread Items only downloads all the articles, along with their images, and not the enclosures themselves.
Unfortunately, there's no way to initiate anything like "play all" from inside the app either. Fortunately, as pRSSreader stores the individual podcasts using their original name in feed-specific subdirectories (the subdirs having been named after the URL of the

It also has a cache manager (accessible via Menu / Cache Manager); unfortunately, it doesn't allow mass playback either (only mass deletion):
Initiating the in-app download of an enclosure involves several taps: after entering the article (two subsequent taps in the article title list), Menu / Enclosure / Download:
If, on the other hand, you want Internet Explorer Mobile to open the file, you can just click the name of the enclosure at the bottom (which has the same effect as Menu / Enclosure / Open).
Viigo 3.0.18
This is a multiplatform application: has Windows Mobile, BlackBerry and generic (also Symbian-compliant) Java MIDlet ports.
Even the most advanced Windows Mobile version is way less powerful than any of the other podcatchers. In addition, the BlackBerry version, as of current (3.0.224, released on Sept. 12) version has absolutely no podcast support (also see THIS for more info) and neither does the generic Java MIDlet version. Podcatching support is only promised for later. However, as I seriously doubt the podcatching support of it will be any better than the current (very weak) podcatching support of the Windows Mobile version, I wouldn’t be holding my breath either – it’s just too weak, even if you take into account the currently only real podcatcher on the BlackBerry, AudioBay, isn’t top-notch either.
Some WM screenshots:
(main view)
(podcast list view with menu)

(Properties of a feed – as can be seen, except for providing a login/password, absolutely nothing can be set)
(the player. Note that it couldn’t play back m4a (AAC) files; this is just a demo of how it looks like)
(the only setting capabilities Viigo has – see why I don’t recommend it?)
BlackBerry screenshots:
(Main: the feed list. No upper-level menus!)

(the menu in the feed list)
(the above two screenshots (an individual article view and the menu in there) show there aren’t even links for download using the built-in BB browser, Web)
CorePlayer 1.2.5 (also applies to Symbian / Palm OS / iPhone & other, supported OS’es!)
This is a strictly podcasting-capable application you should already have if you’re seriously(!) into multimedia. While it’s no doubt the best all-in-one player for Windows Mobile, Symbian and Palm OS, its podcasting capabilities are pretty limited. Hope this changes with the imminent release of the 1.3 platform with its downloading capabilities.
Incidentally, speaking of the iPhone, the situation seems to be otherwise pretty dire. This will, on the other hand, surely change in the future.

Conduits Pocket Player 3.7
It’s another strictly podcasting-capable application with somewhat better podcasting capabilities & compliance than those of CorePlayer. That is, if you also need podcatching capabilities, you’ll still end up having to get a separate podcatcher app.
A quick intro to accessing feeds: you can add a feed in Browse / Podcasts / Add Podcast Feed:
Double-click the new podcast to see the available enclosures:
Note that this screenshot has been taken with the MoDaCo feed, which Pocket Player has severe problems with. As can be seen, they’re in no way descriptive – unlike with other podcast downloading-capable apps compatible with the MoDaCo feed (that is, not for example CorePlayer). It’s only when actually starting to stream them by, for example, a left-right swipe that more info becomes available on a given MoDaCo podcast:
Note that I haven’t encountered similar problems with the other, tested (and working) feeds.

Hubdog 2.0
This podcatcher client is very famous for its Web & community capabilities. They aside, it’s still a very capable an decent client, albeit, in my opinion, can’t really match the speed and the easiness and intuitiveness of NewsBreak.
BeyondPod 2.8.0
This free app is probably the most featureful catcher of all. Highly recommended unless the speed problem introduced by its slow rendering engine really annoys you.
FeederReader 1.10.0
This is another featureful podcatcher with some really unique capabilities.
Too bad using it is like rocket science. You’ll want to start with the manual and also make you read the tutorials: THIS, THIS and THIS, in this order.
AudioBay 4.0/e0 (Windows Mobile) and 3.4/e0 (BlackBerry 8800);
Note that it also used to have a Symbian S60 version but has been discontinued in the meantime because of Nokia’s Podcasting. The Windows Mobile and the BlackBerry versions, on the other hand, are still developed.
The former (the Windows Mobile) version is pretty much average: not among the best titles but not the worst ones either. The BlackBerry version, on the other hand, is THE way to go. Note that, however,
1. AudioBay has no trial version (this should be fixed by the developer!)
2. Some people have found it to be unreliable, particularly on Verizon
(WM)
(BB)

NewsBreak 2.1
While this certainly isn’t the most featureful application, it’s by far the easiest to use. It has large, nice download icons associated with each podcast easily pressable. As soon as the download is over (which is the fastest of the bunch), the icon (which, after queuing the podcast for download, changes to a “Cancel” icon) changes to a “Play” icon. All this makes it possible to really easily queue, possibly cancel and, then, play back a given podcast. In this regard, NewsBreak is clearly the best of the bunch.
Top-level feed view
Channel view
Article view
Egress 4.0.1
Egress is another very strong title. iPhone(-alike) fans may prefer it to the other apps because of its iPhone-like interface. In my opinion, NewsBreak is better mostly because it takes fewer taps to queue something and is generally faster / easier to use. However, Egress is still a recommended title.
NewsGator Go! for Mobiles (current version as of late August 2008; internal filedates: 03/28/2008)
NewsGator, which has recently made been free, has a very strong Web-based interface. If you look for something like Opera’s Opera Link but with a generic subscription & already-read-flag synchronization, this should be the podcatcher to check out. Otherwise, I would stay away from it: it’s certainly lacking in features and, what is worst, is very-very slow in everyday use – even for normal (podcast-less) RSS use.
Skookum 2.0.0.0
Skookum is an abdandoned, free podcaster app. It has nothing to write home about; albeit, it’s certainly not the worst one either.
The developer is no longer in business (see for example THIS and THIS for more info). Sites like PocketGear only seem to have the commercial, initial and, therefore, in no way recommended, 1.0 version
Note that you will need to use CF1SP3 (or, of course, CF2+) to run it; it crashed on me, along with throwing a FileNotFoundException, right at the beginning with an older version.
Note that, while some of the errors (see see THIS and THIS for additional info) may show you you need to manually install System_SR_enu.cab (linked from HERE) , you won’t need to do this.
Much as the developer’s long been out of business, I haven’t disqualified the app as it’s free.

Symbian
With AudioBay’s Symbian S60 version discontinued (because of Nokia’s app’s release), Nokia Podcasting has become THE podcasting app for all S60 v3 phones. It’s generally very well done, fast at downloading and only lacking in some advanced features like channel image view.
It offers pretty nice, pre-configured choices, parallel downloading (of course, it allows for multiple selection with the Key button + the up/down arrow):
, automatic scheduling. However, it isn’t capable of parsing generic URL’s like that of MoDaCo for feeds. In these cases, you must enter the URL directly in Podcasts / Options / Go to Podcasting / Podcasts / Options / New Podcast:
Don’t forget to set your storage card as the download target at Podcasts / Options / Go to Podcasting / Options / Settings / Download:
The chart
As with most of my generic bible / roundup articles, the focal point of this bible is the feature chart, which makes it possible to pack in as much information in an article as possible, also allowing for direct, easy comparison between the different solutions. As usual, you’ll want to maximize it and, on smaller-resolution screens, zoom out to avoid (excess) scrolling. Sorry for the size: as usual, I wanted to present a full roundup; hence the gigantic size. The chart is here.
Explanation
Today / home plug-in showing the number of new podcasts etc. (NOT just a start / stop / pause control, with the song title, of the currently playing track!): some podcatchers also display the number / title(s) of newly downloaded podcasts (or simple articles).
Does it allow for user-def’d podcast categories?: more advanced catchers allow for organizing podcast feeds into user-defined categories. If you have more than a handful of feeds, this capability can prove VERY useful.
Feed login/password?: there are some private feeds requiring a login/password pair to only allow authenticated users to access their content. Almost all podcast/catchers support this.
Terminology used: particularly if you test more than one app, you may run into terminology inconsistency problems. For example, feeds are referred to as “Channels” by many. Feed contents are generally referred to as “items”, “headlines” or “episodes”. In this row, I’ve collected the terminology used by all apps so that you can avoid any confusion.
Support for non-supported (in general, non-MM) stuff?: here, I’ve listed non-multimedia stuff. Some feeds (for example, the C&L feed) not only have multimedia audio / video content, but also other stuff like YouTube links, Flash (.swf) and Adobe Acrobat (PDF) files etc. In this group, I’ve tested whether these kinds of files can be (manually – automatic download, in general, won’t work, except for very few titles like FeederReader) downloaded.
Download benchmarks (~20M mixed content over 512 kbps ADSL): in this test, I’ve tested how fast the app downloads to a 8GB Class 4 Sandisk card over a lower-end (512 kbps) ADSL connection. High-speed connections, of course, may have resulted in a much more pronounced difference. Just an example: over a very fast connection, NewsBreak is flying, while Viigo remains abysmal, certainly showing its file buffering / flushing algorithm is very weak.
Auto download / fetching: Supported? Refresh intervals / timestamp to execute?: Automatic podcast download / fetching is very important. In this row, I elaborate on which (or both) of the two updating timing is used: interval-based or a given, pre-set time of the day. I’ve also elaborated on the freedom of settings these parameters – that is, the granularity of the timestamp / interval setting. (Can you configure it to refresh the contents every, say, 5 minutes? Or, are you only allowed to do an update, say, at most once an hour?)
Download restrictions settable separately for each feed, as opposed to one, global setting?: Especially with sizable podcasts, it may be very important to be able to set completely different for example auto-deletion / retention parameters for individual feeds.
The storage requirements of different feeds can vary a lot. For example, there can be a feed with podcasts only taking up some 2-3 Mbytes at most (an example of these is Heart of Space, which only offers 30-second-long podcasts taking up only some hundreds of kilobytes), while other podcast episodes can easily be 50-100 Mbyte long (an example is X-Play’s lengthier movies). This means if you have little storage space but would like to keep as many podcasts as possible on your handset, you may opt for only letting for the retention of, say, 1-2 episodes of feeds generally having huge files, while not having so strict restrictions on feeds with small podcasts. In these cases, feed-level configurability (as opposed to one, global setting) can really pay off.
Distinction between allowed / blocked connection types to avoid using (expensive) cellular data?: some podcatchers allow for restricting the type of connection for downloading to avoid high data bills. The majority offering this capability has the ActiveSync vs. cellular distinction.
Can you define whether to force to open a connection if it isn’t available: some (unfortunately, VERY few) apps allow for very advanced functionality like enabling Wi-Fi / BT / the cellular radio (if any) before starting the update (and, when needed, disabling them after the update). In this row, I explained this (and similar) capabilities.
Storage usage restrictable / automatic deletion of listened-to / expired enclosures?: in percentage of free / remaining storage?: this subgroup has detailed information on whether you can fine-tune the storage usage by not letting the podcatcher download stuff that would result in the storage fill up. This is a basic setting and should be supported by all podcatching applications.
Permanent storage in the file system: can the home directory be set?: better apps, in addition to storing the podcasts on a storage card (or a, size-wise, comparable entity), may also allow for setting their home directory to anything, not just a wired-in directory name like \Podcasts.
Settable maximal number of enclosures kept?: Better catchers striving for efficient storage usage may employ a deletion strategy stating the following: whenever the pre-set maximal number of enclosures becomes too small to download the newest podcast(s), the oldest one (or an already-consumed one) is deleted.
Auto-deletion of podcasts older than X days?: storage saving may also be enhanced by allowing for (unconditional – that is, not depending on whether it has been consumed or not; see on this the next row) automatic deletion of podcasts older than X days.
Flags: Already listened to? What functionalities (not listing, deletion etc.) are based on this flag?: A decent podcaster application should at least flag already-consumed media as “read”. Based on this flag (and the visual presentation), the user would have the chance of not listening to the same podcast twice.
Podcasters behave differently when it comes to the read flag. For example, NewsBreak makes sure articles already read are put at the of the headlines, should you still need them. That is, at the beginning of the headlines list, you will only see unread articles. Some other casters “only” unbold read articles. Also, some of them have the “Hide read articles” functionality.
Better podcaster applications also have even more advanced functionality based on the “read” flag. The most important of this is (mass) auto-deletion of such articles. Too bad this really basic functionality is missing from most of them.
Not listened to, but old enough to be deleted (expired)?: in addition to the pretty basic “read” flag, some casters also employ other flags like “expired”, which, in a decent caster, would allow for deleting old, but not (necessarily) listened-to podcasts.
Note that some apps do support this functionality by just offering the “Delete all podcasts older than X days” functionality.

Downloads: Multiple downloading threads at the same time to make performance better?:
This row shows whether enqueued podcasts can be downloaded in parallel. The point in parallel downloading is as follows:
- Some servers serve podcasts considerably slower than your local Internet connection. Say you have a 2 Mbps connection, while the server you’re currently downloading podcasts is only capable of serving a podcast at 500 kbps. This means 1.5 Mbps of your Internet connection remains unused.
- You may want to quickly download something while another download is in progress. For example, let’s assume you’re downloading a huge podcast when you notice there’s another, interesting one you’d like to listen to as soon as possible. In a single-threaded (simple) app, you would either need to cancel the current download(s) to quickly queue the new clip as the first one to download. In a more advanced multithreaded app, you just start the download and it downloads (albeit a bit slower because the bandwidth available may be divided up between the current downloads), without further ado.
Progress bar (or any way to see what has already been downloaded): better apps have some kind of a visual feedback showing how many bytes (and/or percent) of a given podcast (and, preferably, all the queued podcasts) have already been downloaded.
Streaming (playback without downloading the entire enclosure (first)) Supported? : better players allow for streaming – that is, playback without downloading the entire enclosure first. Note that the built-in WMP doesn’t support this; CorePlayer does.
If streamed, random positioning supported?: there are two approaches to streaming – one that allows for quickly fast forwarding into still not downloaded parts of the podcast (that is, allows for really free random access, independent of what has already been downloaded) and the simpler one that doesn’t. Naturally, the former is preferred.
Here, n/a, naturally, shows the given app isn’t at all able to stream.
Feed input (in addition to direct address entering, which is supported by all): OPML import / sync?: There are several ways of making podcast/catcher apps aware of the feeds you’d like to subscribe to. In addition to by directly entering their URL’s, one-by-one, the most important way of importing them is via OPML files.
Note that several of the apps also support exporting into OPML files of your current subscriptions, which makes it easier to transfer your current subscriptions to another (OPML import-capable) podcatcher/caster.
M3U / PLS support?: some apps also allow for mass-importing feed URL’s via the well-known M3U and/or PLS playlist files. (See for example THIS for more info on these formats.)
Pre-defined, built-in library?: many of these apps have some kind of access to predefined, online libraries already offering feeds you can subscribe to.
Online search?: there are several services allowing for feed lookup based on their names. Some of the handset apps have interfaces to directly access these services.
Generic HTML page parsing if unsure about the exact feed URL?: (very) few apps allow for parsing generic HTML pages to find feed URL’s in them. (This is how most desktop browsers and Opera Mini work when they display a “This page has RSS feeds in it” type of message.)
Online, web-based, synchronizable and/or readable account?: one of the best capabilities some of these apps offer is an online account allowing for either account management (importing / deleting etc. feeds, sharing them with your friends, the community etc.) or on-line article reading via any Web browser – or both.
The former greatly simplifies subscribing to feeds (and deploying the same set of feeds to other, OPML importing-capable podcasters later).
Built-in player (if any): AVRCP: while the majority of these apps rely on external players to play even the most basic and widely used podcasting file formats like MP3, some of them have a built-in player to play them back. It’s the limitations, capabilities, CPU (and, consequently, battery) usage of these built-in players that this group is all about.
The first test in this group, AVRCP, discusses whether Bluetooth remote control, AVRCP, is supported by the player (if any). Naturally, as with most of the entries in this group, n/a means there’s no built-in player in the app at all.
CPU usage?: The CPU usage of multimedia players is of extreme importance when it comes to maximizing battery life. This is why I’ve made some extensive tests to find out how these apps behave in this regard. Please also see THIS for more info on the well-established players.
Remembers last position (resume-capable)? And, even better, auto bookmark-capable?: with sometimes lengthy podcasts, it’s essential for a player to be able to resume playback after restarting (simple resume) or even switching to another and, then, returning to the same podcast (more advanced bookmarking capability; now, storing a “last playback position” associated with each podcast file, not just globally for the last played one).
Positioning (with already-local playback); + stands for external players with podcatcher apps without a built-in player: it’s also essential for a podcast playback application to be able to randomly position inside the already-local podcast. Note that this has nothing to do with the positioning capabilities of still-downloading and/or streamed apps, which was elaborated upon earlier.
If it does have a player, can you still use an external one?: almost all the built-in players are definitely inferior (buth CPU usage- and capabilities-wise) to those offered by other, third-party players. Therefore, particularly with podcaster applications having a low-quality player, it’s essential to be able to configure it to be able to invoke an external multimedia player to play back any multimedia content.
Channel / individual song image support: Generic channel image displayed?: This group elaborates on whether generic (non-podcast-specific) channel images and podcast-specific, inline images are supported.
The first test, “Generic channel image displayed?”, shows the podcaster app is able to display the generic image associated with a channel. This is in no way essential, just cool to have and makes it easier to easily spot a feed, particularly if there are more than a handful of them.
Album art / article display? :
Note that, with external players, this will only players that do support embedded artwork in individual podcasts; that is, NOT the built-in Windows Media Player Mobile in Windows Mobile. See the first chart HERE for more info on this question and the compatible apps.
Mass playback / delete operations: Mass playback in a given channel?: this mass operation-specific group elaborates on operations best done in one step instead of doing the same separately for each and every headline / podcast – that is, using mass operations.
The first of the tests, “Mass playback in a given channel?”, elaborates on whether the podcasts of a given channel (feed) can be played back in order without having to manually intervene (that is, start the next one when the previous is finished). This is of extreme importance with shorter clips you’d like to see. Just a real-world example: during my last 10-hour-long bus trip, I’ve watched almost all the episodes of X-Play. These podcasts are, in general, some 2…5 minutes long. As the client (the otherwise great NewsBreak) doesn’t support mass playback, it was quite a nuisance to always having to switch back to NewsBreak (from CorePlayer playing the video) and tap (with my finger) on the next feed’s “Play” icon.
With podcaster apps capable of mass playback (either in a given channel/feed or globally, with all available podcasts), you don’t need to constantly switch back to the podcaster app to start the playback of the next podcast.
Incidentally, behind the scenes, mass playback is accomplished by using playback (m3u / pls / asx files). This is how podcaster apps instruct external players to be aware of more than one playlist items. Also, this is why some of the podcaster apps (for example, Egress) explicitly refer to creating playlist files upon downloading.
Mass playback globally (not just in one channel, but all the new enclosures)?: while the previous row discussed in-feed mass playback (without human intervention), this one refers to playing back all the clips globally, originating from all feeds, not just one. Unfortunately, as with the feed-only playback, very few podcasters support this.

If (any kind of) mass playback is supported, audio / video distinction (unattended “Commute mode“ as referred to by FeederReader?): when you, for example, jog and, therefore, can’t watch the screen of your handset, in a mass playback mode, distinction between audio-only and video content can be highly useful. This way, you can be sure no video will be played back while in mass playback mode; only audio.
Mass deletion of all enclosures? If possible, can you do this on both globally and just in an individual channel?: in addition to mass playback, mass deletion can also be highly useful. Here, I elaborate on both global and in-one-feed mass deletion capabilities.
Filename naming conventions (for quick file system-level lookup, mass playback queuing from external players, deletion etc.): there are two approaches podcatcher applications use when downloading streams (one of them, BeyondPod, also supports both): either keep their original names (in some cases, adding a unique, machine-generated trailer/header to make sure no accidental overwriting will occur) or use a fully machine-generated name, mostly consisting of running indexes.
Both approaches have advantages. If you keep the original podcast filenames (particularly if you do this in separate, feed-specific subdirectories in the file system), you won’t need to do any lookup to find out what a given podcast really is. Also, queuing podcasts for mass playback (particularly if they’re in a separate subdirectory) becomes far easier. However, it’s prone to the overwriting problem, which may be particularly an issue with, in this regard, not very well written applications like
If you only have index-based and/generated random indexes, accidental overwriting won’t even occur. However, you may have a hard time identifying the podcasts in the file system, should you want to access them in an external media player without firing up the podcatch/caster application.
Of course, there are combined solutions as well; for example, Egress uses both a unique, random leading string to make sure no overwriting will take place and, after this, the original filename follows.
Compatibility with some real feeds: MoDaCo: in this pretty large group, I’ve presented some real-world test results on whether these podcast/catcher applications are compliant with some real-world, popular podcasts. The first of the test is MoDaCo’s, which causes some problems to, for example, Pocket Player (the fix is promised for the next version). It’s, otherwise, a pretty usual MP3 podcast. CorePlayer, which, as of version 1.2.5, has still pretty bad RSS feed parsing capabilities, is fully incompatible with this feed.
1Src Palm-powered Podcast (MP3): another usual MP3 podcast, no real catches here, except for Skookum, which can’t download more than one podcast a time, as it erroneously assumes the filename being “redirect.mp3”, which results in downloading subsequent episodes overwriting previous downloads.
Heart of Space (Mp3): another pretty usual feed. The only podcaster not compatible with it is NewsGator Go! for Mobiles: while it can download it, it can’t invoke an external app to play it back. This is a pretty common issue with NewsGator Go! for Mobiles, several other feeds are also suffering from this problem.
SpaceMusic Archive (MP3) and (Current) SpaceMusic : no problems at all with any of the apps.
Radio 538 (AAC-LC) : now, this is a problematic feed causing issues with many apps. For example, CorePlayer has problems with the 080804 issue, while the other episodes (for example, 080811) work just fine.
Also note that it isn’t an MP3 podcast but an AAC-LC one. Therefore, many podcasting/catching apps are simply unable to play it back – or, for that matter, even retrieve it.
Classic Animation (H.264 Baseline video): switching to videos, Classic Animation is a great source of old cartoons. They have their stuff in H.264 baseline format, which means great compatibility with a lot of multimedia players (as opposed to more advanced H.264 formats).
It worked with most podcasters, except for NewsGator Go! for Mobiles, which exhibited the same trailing bug as with a lot of other feeds.
X’Play’s Daily Video Podcast : these videos are high-res (VGA, 640*480) and use a more advanced, non-baseline H.264 format meaning very few players (most importantly, CorePlayer on all mobile platforms except BlackBerry) will be able to play them back.
Tagesschau Podcast (MP3): these MP3 files are the plain audio tracks of the Tagesschau video programs. They’re different from the previous titles (but not the original “video” versions) in that they have a much more complicated feed URL. Probably this is what makes these feeds inaccessible for several podcatcher/caster apps (CorePlayer, Hubdog and the BlackBerry version of AudioBay).
Tagesschau Video Podcast (MP4 / H.264 baseline): the situation is pretty similar with the original video versions of these programmes.
Other sources of information
A REALLY cool post on desktop podcasting
VoiceIndigo for BlackBerry
What are you using to “podcatch”?
A german list
Another quick news item on the PPCMag article
A 2006 thread: RSS reader with podcast support for TyTn, any suggestions?
Mostly a FeederReader-specific thread
Note that, while some feeds (for example, C&L) offers the capability of accessing two videos from one article, physically, they only hold one enclosure, not two (they only link to two videos). An example screenshot series:
No longer existing or plain weak applications
SmartFeed, an old, still widely known, popular app, has been incorporated into NewsGator in the meantime.
The Windows Mobile version (as of beta3) of the otherwise very nice and famous Doppler is pretty much useless and far inferior to any of the products in the chart. Still, a quick elaboration, should you still want to know why I don’t recommend it.
First, unless you have a lot of built-in storage, in Menu / Options / Settings, you’ll want to change the default podcast download path, \My Documents\My Podcasts. Finally, after a double-click on the feed, select Menu / Download podcast. Trying to update feeds / podcasts has always resulted in constant problems; then, also Aborting download… has stalled and required a manual, forced task kill. Therefore, it seems the only way to download the podcasts is via the built-in Internet Explorer (that is, fully manually – which is in no way recommended; after all, podcatchers exist just in order to avoid doing this), you can manually tap the link after double-tapping an article.
PiP (also see for example THIS) has been discontinued in the meantime.
Pocket Podcasts 1.0 is also pretty weak and requires a desktop-side server; this is why (on purpose) I’ve left it out.

Appendix: the Microsoft Zune
The desktop client of the Microsoft Zune allows for podcatching and synchronizing – just like Doppler, Juice and iTunes (and unlike WMP 11). I found it useful to include this section in this guide as
1. after all, the Zune is a portable device
2. Microsoft promises "Zune store integration", which is quite a bit similar to that of Nokia’s on-device music store solution. One can only hope Microsoft also makes the podcatching and synchronizing capabilities of the desktop Zune version 2+ available for Windows Mobile clients as well – even if "only" on the desktop side, and not natively on the Windows Mobile clients (unlike, say, the way Nokia implemented their Podcasting app).
The desktop podcatcher component of Zune has no timing capabilities (it starts downloading new episodes as soon as you connect or wirelessly sync your Zune, which also starts the Zune app on the desktop), which may be a bit disappointing, particularly if you have a lot to download (which may also greatly slow down the desktop) and/or have a slow connection and, therefore, need to wait a lot for all the new episodes to download. Nevertheless, it has a very simple and logical interface, which is really easy to use, while still offering advanced capabilities like feed-specific retention and synchronization settings (the ability to set the number of episodes to store on the desktop / on the Zune, from 1 to 10 and including all).
It also has a built-in search, should you want to avoid having to directly paste the feed URL's to Zune. All you need to do is just entering the name of the podcast feed (like "modaco") to the search input field. It found most the English and German test podcasts. It, however, didn't contain anything Finnish from THIS list, not even English-language ones like Radio Free Finland. I needed to add these feeds, then, one by one.
Unfortunately, it doesn't support OPML import – not even in the current, just-released, 3.0 milestone version. It didn't have problems with parsing any of the directly entered URL's, unlike some of the tested apps.
Some screenshots (of version 2.X; the latest, 3.0 version isn't at all different when it comes to podcatching):
http://www.winmobiletech.com/082008Podcasting/zune20podcast.jpg
(General settings)
http://www.winmobiletech.com/082008Podcasting/zune20podcastseriesstting.jpg
(Feed-specific settings)
http://www.winmobiletech.com/082008Podcasting/zune20podcastmain.jpg
(Main podcasts screen, showing all the subscribed feeds on the left and the episodes in the middle; the state of the current download etc.)
http://www.winmobiletech.com/082008Podcasting/zune20syncgroups.jpg
(sync group-view, also showing the total space)
http://www.winmobiletech.com/082008Podcasting/zune20justsyncing.jpg
(Just Syncing-view)
Unfortunately, the Zune client does have its share of problems. For example, it entirely lacks MP4 (m4a) chapter support (like the ones in the enhanced MoDaCo podcast feeds or the Tiesto feed). Not even the just-released 3.0 desktop/device software fixed this.
Also note that Zunes can't update traditional podcasts over the air (only the newly (in version 3) added channels, but these channels can't be manually created) without the need for syncing with the desktop Zune software. Yeah, I know podcatching (with everything involved: incompatible feeds, incompatible formats can't be natively played back on the Zune etc.) isn't at all trivial; still, I would really welcome full podcasting client support as opposed to the pre-made, no-user-channels-possible channel syncing currently supported. Microsoft could, for example, just port the podcatching code from the desktop software to the device firmware. It's pretty solid and dependable; again, it was able to sync to all the feeds I've thrown at it not necessarily present in Microsoft's library.
(Some other, Zune & podcatching-related articles:
How to manage podcasts in the Zune software: this is the current one; also applies to 3.0.
Some examples of old, outdated, pre-version 2 tutorials:
How to Manage Podcast Content With Your Zune and HOWTO: Podcasting with a Zune. These are, again, outdated; now, there is absolutely no need to use an additional podcatcher in addition to the desktop-side Zune app. (This is also reflected by ExtremeTech's initial article Zune: iPod Killer or Half-Baked Flop?). Note that it was with the release of Zune 2 a year ago that podcatching has been added to the desktop software.)