Database Info

ROUNDUP: Bluetooth remote control (AVRCP) compatible media players

Audio/Video Remote Control Profile (AVRCP) is a very nice feature of Bluetooth. Accessible on Advanced Audio Distribution Profile (A2DP)-capable Bluetooth Hi-Fi stereo headphones, they allow for remote controlling your media player on the Pocket PC: going straight to the next or back to the previous song or pause/resume or stop/restart the current one.
Now that I’m working on a big roundup of Bluetooth Hi-Fi stereo headphones, I’ve also thoroughly scrutinized the AVRCP capabilities of current Pocket PC multimedia players. In this article (which will be followed a lot of similar articles discussing AVCRP (and, naturally, A2DP) compliance of different stereo BT headphones), I elaborate on what you need to know about remote controlling your Pocket PC-based media player from the Plantronics Pulsar 590A stereo headset.
Unfortunately, current headsets are far from being compatible with all multimedia players and Pocket PC's. There are several multimedia players and Pocket PC's (more precisely, specific Bluetooth stack / A2DP / AVCRP implementations) not compatible with the Pulsar while it's compatible with other models and vice versa (for example, the built-in A2DP of the WM5-upgraded 2.01 hx4700 works just great with the 590A while it's almost useless with the Moto HT820). Therefore, what you read here mostly applies to the Pulsar only. Still, if you have (or, plan to purchase) a different model, this article will be really worth reading because it discusses a lot of additional hacks and tips - not only related to the Pulsar headset. For example, in addition to a lot of "which is the best media player I should look for", I also provide some dependable CPU usage statistics (playing a 112 kbps MP3 (Värttinä – Oi Dai / Oi Dai)) so that you will be able to compare the battery usage of each application (with and without the equalizer enabled – it’s only with TCPMP that enabling the equalizer caused some visible CPU usage increase. The CPU usage data was measured on my Pocket Loox 720; with WMP10, on my WM5 hx4700).
The, currently, four remote controllable third-party applications (the built-in Windows Media Player (WMP) is AVRCP-compliant in both version 9 and 10) are as follows:
The free, excellent Mortplayer (current, tested version: 3.31RC6 released slightly over a month ago). Its only downside is the lack for WMA support (the other three alternate clients support WMA.) I also recommend this thread on the AVRCP support of MortPlayer.
The free, also excellent TCPMP (current, tested version: 0.72RC1 released about half a year ago)
Pocket Player 3.0 by Conduits (current, tested version: 3.0 released two weeks ago; no build data available)
The fourth Pocket PC multimedia application to support AVRCP is 40iPlay (current, tested version: 10/01/2006 released two weeks ago), which should be accessible here. If you get a screen with a simple link when you visit the page like this, then, you’re out of luck: your IP address is banned off the site as is the case with many people having tried to access the page. Unfortunately, the developer doesn’t seem to be wanting to remove the ban of, it seems, half of the world (I also recommend this thread on this problem). If you also encounter this problem, I recommend trying it via alternate means; for example, accessing the page via your dial-up / mobile account. It’s via my GPRS account that I access the page.
It’s worth noting that, while 40iPlay runs flawlessly on my considerably older, PXA255-based WM2003 iPAQ 2210, it refuses to work on my (newer, PXA272-based) WM2003SE Pocket Loox 720 complaining about it not having an XScale CPU. This is certainly a bug in the current version; the older versions I’ve tested didn’t have this problem. Unfortunately, the hack PM'ed by FirstLoox forum member androabo (thanks for that!), that is, depressing “?” during loading the program, didn't work either.
Note that I’ve scrutinized the recording capabilities of the application in the Sound Recorder Bible.
I really recommend this media player because
it has one of the lowest CPU usage of all the applications (even slightly lower than that of TCPMP!) and has even in-app CPU speed setting capabilities to further reduce CPU consumption (please read this article (and all the past articles linked from it) for more on this subject: there, I've shown some nice examples of this fact.)
I've played a lot with the latter and found it to be highly useful and reliable. While it doesn't offer automatic scaling (unlike XCPUScalar), it's good to have it built-in on devices that otherwise, "out of the box" don't offer CPU speed setting capabilities (iPAQ hx4700 and 2210, HTC Wizard, Universal etc). It's really easy to use: you just click the Turbo ON/OFF and, then, SET icon when you want to switch back and forth between a downclocked and the original mode.
I've found playing stuff worked pretty OK with the following parameters:
h2210: 100 MHz (via wired headset!)
x51v: 208 MHz (via Widcomm A2DP) - note that the x51v also has a system-level CPU speed setter capabilities, but they're well-buried under the Power applet and you need to click a lot to access it
hx4700: 208 MHz (via A2DP)
Unfortunately, it's unable to underclock the HTC Wizard as can also be seen in this screenshot showing the CPU controls shown on the Wizard (example screenshots of running it on other devices follow: x51v, hx4700 and 2210).
its "Reverb" effect (accessible here) is by far the best I've ever heard on Pocket PC and is indeed industry-strength. I really recommend it - you'll love it
The compatibility / CPU usage can be found here - CLICK THE LINK!
CONTINUED BELOW!

The hacks I've used / referred to:
Adding A2DP (and AVRCP) support to WM2003 devices
WM2003 devices should use the Widcomm 1.6 HP Bluetooth AV upgrade to gain A2DP / AVRCP support. The update is officially only meant for HP iPAQ 5550 devices but it works (to some degree) on other Widcomm-based WM2003 devices too (you can install it on any device – the installer isn’t locked to the particular PPC model). Note that you shouldn’t except miracles: for example, on my HP iPAQ 2210, the sound sometimes stops for 1-2 seconds and, what is worse, it gets a considerably lower, really annoying pitch for some 10-15 seconds before this. That is, it’s highly possible you’ll find it useless on your particular WM2003 model too - it's only certified to work on the 5550.
Adding A2DP (and AVRCP) support to WM2003SE devices
(Widcomm-based) WM2003SE devices should use the hack CAB available here. See this and this for a generic discussion. Note that you shouldn’t try updating your WM2003SE device with the Widcomm 1.6 HP Bluetooth AV upgrade (see the WM2003-related section above) meant for plain WM2003 devices (you can, however, give it a try - it may work - or not). At least on my Pocket Loox 720, it would never stop discovering the services of my Plantronics and, therefore, seems to be useless.
Unfortunately, this update has severe problems: no matter what model it’s installed on, the sound transfer will just stop after some dozens of minutes and can only be restarted by explicitly disabling Bluetooth on the PDA and, then, reconnecting to the headphone (fortunately, no soft reset is necessary). This makes listening to music wirelessly really painful on the long run.
Note that exactly the same applies to the (current) Widcomm version 0.50 “hack” for the WM5-upgraded Dell Axim x50(v) and the entire x51(v) series: from time to time, the sound transfer will just stop and, then, you'll need to reconnect to the headset. (This problem may be only related to the 590A only - I haven't really seen similar bug reports in the above-linked thread - neither have I seen here.) This won't be a problem with most x51(v) users as the built-in A2DP / AVRCP support in AKU2.3 works with most headphones without making it necessary to install the Widcomm BT stack. It seems, however, it doesn't work with the 590A - using the standard, built-in A2DP support of WM5 AKU2, the music transfer to my 590A would stop after some 0.2-0.3 seconds. The case is exactly the same with the AKU 2.0 HTC Universal. Interestingly, FirstLoox owner Duncan hasn't run into this problem with his 590A, using the built-in A2DP support on his F-S N560.
Adding A2DP (and AVRCP) support the HTC Wizard
The HTC Wizard, unfortunately, which doesn’t have support for A2DP at all even in AKU2+ ROMs. Therefore, you'll need the CAB file available here (linked from this post in this thread; to be on the safe side, I’ve also made it available here. Note that it’s highly recommended that you also import this registry file after installing the CAB file (the latter is discussed here, here, here and here).
Note that, even with the registry hack, the sound quality of the Wizard over A2DP has remained considerably worse (it has pretty bad compression effects) than with my other test Pocket PC’s (with all media player apps - this means it's not a media player issue but that of the A2DP hack). Give it a try to see if you can live with the (comparatively) lower sound quality. Furthermore, unlike with the other solutions, after finishing a call, the music doesn’t automatically restart – you must manually press the Pause button on the headset.
Making the Pocket Player AVRCP work under WM5
(Big thanks to PPCT / AximSite forum member Haesslich for summarizing it so that I didn’t need to look / experiment with it up myself much.)
Get the Conduits WMP Plugin Adapter 1.1 from the plug-in page (I really recommend it if you, for example, want to get FLAC or MOD support for your Pocket Player) (direct link to the download).
Unzip gen_wmhost.dll from the archive and put it in the home directory of your installed application ([Storage card name]\Program Files\Conduits\Pocket Player).
Go to Menu/More/Options (in 3.0; in 2.8, Menu/Options) and select the Plugins tab (it’ll be on the far right)
Single-click “Conduits WM Plugin Adapter”, when the context menu comes up, select “Configure”.
Click the “Configure WM plugins to load” button.
Under version 2.8, it’ll ask four questions; under 3.0, two. Click “Yes” in all cases.
Click OK and restart Pocket Player. Now, remote controlling should work OK.
The results shown in the comparison chart
As can clearly be seen, with the Plantronics Pulsar 590A stereo headset, none of the four third-party applications supported it under all OS’es flawlessly. For example,
MortPlayer only supported AVRCP on WM5 devices with the Widcomm BT stack; it won’t work on WM5 devices with the Microsoft BT stack or on any pre-WM5 device
Pocket Player only supported pre-WM5 devices without additional hacking; it doesn’t work under WM5 (with neither of the two most common Bluetooth stacks). Fortunately, with the above-explained "hack" it's working just great on all my WM5 devices.
Finally, the case is just the opposite with TCPMP, which only supports WM2003SE devices, AVRCP-wise. It doesn’t work on WM2003 / WM5 devices at all.
The most AVRCP-compliant multimedia player is iPlay - it worked flawlessly on all my test devices, except for the Widcomm 1.6-based WM2003 ones. In there, previous / next wasn't available.
As can also be seen, you don’t need to be afraid of the CPU usage (battery consumption) figures of these applications. While Pocket Player uses about two times more CPU cycles than TCPMP or iPlay (the latter two without the equalizer), it’s still way better than some other, non-AVRCP-capable (and, therefore, not reviewed) multimedia players like ViTO SoundExplorer, which (at least in older versions) consumed way more CPU time when playing plain MP3 files as can also be seen in these benchmarks. Enabling the really nice Reverb feature on 40iPlay “only” doubles its CPU usage – then, it’s still not much worse than that of players that otherwise consume considerably more CPU cycles even without any DSP’s or equalizers enabled (MortPlayer, Pocket Player). That is, if you need the reverb effect (give it a try – it’s really cool), you can safely enable it.
N.B. Once again, the compatibility chart is based on my compliance tests with the Plantronics Pulsar 590A. With other headsets, you may have (slightly) different results (as has also been mentioned in the chart – see my comments in parentheses). I will continue posting compatibility information with other stereo headsets hopefully as early as next week.

Menneisyys said:
As can clearly be seen,
none of the three third-party applications support all OS’es. For example,
MortPlayer only supports AVRCP on WM5 devices with the Widcomm BT stack; it won’t work on WM5 devices with the Microsoft BT stack or on any pre-WM5 device
Pocket Player only supports pre-WM5 devices; it doesn’t work under WM5 (with neither of the two most common Bluetooth stacks)
Finally, the case is just the opposite with TCPMP, which only supports pre-WM5 devices, AVRCP-wise. It doesn’t work on WM5 devices at all.
Now, you have all the necessary information to select a compatible multimedia player for your particular OS and Bluetooth stack version
Click to expand...
Click to collapse
So, I guess that I have no choice. I have WM5 with the MS BT Stack. Am I right? If someone would be willing to tell me how to change the MS BT Stack out for the Widcomm BT Stack, I'd be very appreciative.
Also, this thread is very much needed in my opinion. Thank you for starting it.

Article heavily updated.

Another thorogh update

Menneisyys: said:
Making the Pocket Player AVRCP work under WM5
(Big thanks to PPCT / AximSite forum member Haesslich for summarizing it so that I didn’t need to look / experiment with it up myself much.)
Get the Conduits WMP Plugin Adapter 1.1 from the plug-in page (I really recommend it if you, for example, want to get FLAC or MOD support for your Pocket Player) (direct link to the download).
Unzip gen_wmhost.dll from the archive and put it in the home directory of your installed application ([Storage card name]\Program Files\Conduits\Pocket Player).
Go to Menu/More/Options (in 3.0; in 2.8, Menu/Options) and select the Plugins tab (it’ll be on the far right)
Single-click “Conduits WM Plugin Adapter”, when the context menu comes up, select “Configure”.
Click the “Configure WM plugins to load” button.
Under version 2.8, it’ll ask four questions; under 3.0, two. Click “Yes” in all cases.
Click OK and restart Pocket Player. Now, remote controlling should work OK.
Click to expand...
Click to collapse
Hopefully, this is what I've been looking for. We'll see.
Am I the only one that sees the value of this thread? I can't believe that I've had the only replies.

porterx said:
Am I the only one that sees the value of this thread? I can't believe that I've had the only replies.
Click to expand...
Click to collapse
Also make sure to link it from A2DP / AVRCP threads when needed so that the information gets to everyone

Mr
porterx said:
Hopefully, this is what I've been looking for. We'll see.
Am I the only one that sees the value of this thread? I can't believe that I've had the only replies.
Click to expand...
Click to collapse
These procedures didn't work for me. I tried 10+ times. I give up in frustration.

porterx said:
These procedures didn't work for me. I tried 10+ times. I give up in frustration.
Click to expand...
Click to collapse
Try connecting your headphones BEFORE starting PocketPlayer and the whole procedure. I didn't find this necessary, Haesslich, with his equipment, did (or at least it seems he neeeded it)

UPDATE (10/14/2006): thanks to FirstLoox and AximSite forum member androabo, now I know how iPlay can be started on the Pocket Loox 720 (or on any device that it refuses to run on because of the incompatible CPU type): just click the “info” button,
{
"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"
}
, two times immediately after starting the application so that it displays the CPU/battery info panel (screenshot of the latter here).
Note that I've just heavily updated my generic Plantronics Pulsar 590-related article (the current one is the AVRCP-specific, not a generic, one). Make sure you read it for further information on the headphones.

Mr
Menneisyys said:
Try connecting your headphones BEFORE starting PocketPlayer and the whole procedure. I didn't find this necessary, Haesslich, with his equipment, did (or at least it seems he neeeded it)
Click to expand...
Click to collapse
It doesn't work for me.
The funny thing is that I had AVRCP working for one day. That was awhile ago and I understood less than I do now. The only thing that didn't work was FF/REW. Next/Prev track, pause, etc. worked.
I have HT820 headset. I don't get it.

porterx said:
It doesn't work for me.
The funny thing is that I had AVRCP working for one day. That was awhile ago and I understood less than I do now. The only thing that didn't work was FF/REW. Next/Prev track, pause, etc. worked.
I have HT820 headset. I don't get it.
Click to expand...
Click to collapse
Do AVRCP work with MortPlayer / WMP / iPlay with your headphones?

Mr
Menneisyys said:
Do AVRCP work with MortPlayer / WMP / iPlay with your headphones?
Click to expand...
Click to collapse
No, I can't get it to work with any of those. iPlay is a little complicated to use. That may just be me though.
I was going to put a link to the roundup thread but this is it. duh.
I should be able to get this to work. Others have. Why not me? Oh well.

porterx said:
No, I can't get it to work with any of those. iPlay is a little complicated to use. That may just be me though.
I was going to put a link to the roundup thread but this is it. duh.
I should be able to get this to work. Others have. Why not me? Oh well.
Click to expand...
Click to collapse
Making a backup & hard reset? It should work. (At least I think so - I don;thave a HT820 so I'm not absolutely sure, knowing the vast compatibility issues of both A2DP and AVRCP. HT820 users may be out of luck.)

Mr
Menneisyys said:
Making a backup & hard reset? It should work. (At least I think so - I don;thave a HT820 so I'm not absolutely sure, knowing the vast compatibility issues of both A2DP and AVRCP. HT820 users may be out of luck.)
Click to expand...
Click to collapse
I've done a hard reset between now and when it did work. I don't think it was working when I hard reset it but I can't be sure. I'll have to think about that one because setting back up after a hard reset is a PITA and I've never attempted a backup.

porterx said:
I've done a hard reset between now and when it did work. I don't think it was working when I hard reset it but I can't be sure. I'll have to think about that one because setting back up after a hard reset is a PITA and I've never attempted a backup.
Click to expand...
Click to collapse
It's certainly worth using backups - now, all the four major backup apps are fully WM5 (and, more strictly, PPC PE) compliant - see my Backup Bible ( http://www.pocketpcmag.com/blogs/index.php?blog=3&p=1270&more=1&c=1&tb=1&pb=1 ) for more info if interested.

Thank You!
I have the 8525 and the Sony DS HBH970, and have been trying to get something better than WMP so I could use the AVRCP functions and have better sound, bookmarking, etc. I'll give it the 30 day trial period, and may actually have to buy this program...
Using the information here, I am now listening to tunes - using stop/play forward/backward (however, I am used to forward/backward from my bluetooth being an entire track while this goes forward/backward within a track - I'll have to play around to figure that out).
In case anyone else is techno challenged like me, here are the steps that I took:
1) Install the Pocket Player program first. It is an exe file, so you download it to your PC then install via ActiveSync.
2) Then get the Plugin as directed. Download to to PC, then put the file on your device via ActiveSync. Then you need to unzip on your device, putting the file in where you installed Pocket Player as directed.
3) If you have Pocket Player open, close it. Open Pocket Player, tap Menu - More - Options - arrow over the tabs to tap on Plugins - tap WM Plugin - Configure as directed in these instructions.
4) My initial playing would not route to the headset, but it works when you have BT on first, hit the play button to establish the connection, then open Pocket Player, play your song.
Thank you for all of the information! Great article!
--------------------------------------------------------------------------
Making the Pocket Player AVRCP work under WM5
(Big thanks to PPCT / AximSite forum member Haesslich for summarizing it so that I didn’t need to look / experiment with it up myself much.)
1. Get the Conduits WMP Plugin Adapter 1.1 from the plug-in page (I really recommend it if you, for example, want to get FLAC or MOD support for your Pocket Player) (direct link to the download).
2. Unzip gen_wmhost.dll from the archive and put it in the home directory of your installed application ([Storage card name]\Program Files\Conduits\Pocket Player).
3. Go to Menu/More/Options (in 3.0; in 2.8, Menu/Options) and select the Plugins tab (it’ll be on the far right)
4. Single-click “Conduits WM Plugin Adapter”, when the context menu comes up, select “Configure”.
5. Click the “Configure WM plugins to load” button.
6. Under version 2.8, it’ll ask four questions; under 3.0, two. Click “Yes” in all cases.
7. Click OK and restart Pocket Player. Now, remote controlling should work OK.

scharnet said:
Thank you for all of the information! Great article!
Click to expand...
Click to collapse
Thanks

Just read about Core Player 1.1 Mobile (commercial version of TCPMP)...these articles say it has AVRCP.
http://fairdeal.modaco.com/product.asp?id=8905
http://software.pocketnow.com/product.asp?id=8935
However, their own website does not acknowledge AVRCP. http://coreplayer.com/content/view/28/44/
Just curious if anyone knows or has tired it? Would it work on the 8525 running WM5? I really like the Pocket Player, but it does not play AVI videos. Core Player does not offer free trials, so I was trying to find out...thanks!

GSPlayer
For everyone wants to use the GSPlayer with AVRCP:
http://forum.xda-developers.com/showthread.php?t=316730
I´ve developed the app on the universal under WM6, but it SHOULD work with every device under WM5 and WM6.....
If i have the WM_ messages, i could control EVERY media player with this app....
Any feedback is welcome...
Greets,
Thomas

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.

Great sound enhancer SRS WOW HD released for all Windows Mobile devices!

Anyone having had a O2 XDA Flame have already seen SRS WOW HD, which helps at both widening the stereo (a particularly useful technology on handsets with stereo speakers like the Flame, the HTC Wizard or the HTC Universal) and enhancing / modifying the sound in other ways as well. For example, it adds the, for lon-time audiophiles / Hi-Fi geeks, the well-known loudness-based bass control.
One of the reasons I love the Nokia N95 are the built-in, loud speakers with extremely good frequency response. In the N95, the built-in Music Player has a dedicated stereo widening mode, which can be en/disabled from inside the player:
{
"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"
}
Its results, when used together with the built-in stereo speakers, are simply phenomenal. It really widens their stereo, making listening to music via the built-in speakers a true pleasure (also taking the very good quality speakers into account, unmatched by any Windows Mobile device so far). This has been one of the main strengths of the N95.
Up until now, there wasn’t a generic, non-OEM, similar solution for Windows Mobile-based devices, except for the built-in applet in the already-mentioned O2 XDA Flame. The multimedia players available haven’t really supported stereo widening either, the only exception being Conduits’ excellent Pocket Player, which does support stereo widening at External Pitch/Echo/Stereo Wide DSP (listed as “DSP Stereo Example”). While it lets for the settable widening of the stereo:
it’s in no way as good as on the N95. It certainly makes the stereo a bit wider. No effect at all on mono sounds (as opposed to Nokia’s widening). (Note that, in Pocket Player, there’s another, similar DPS, but it doesn’t do any widening, just makes the center far quieter than the two sides. It’s, strangely, a bit more useful than the first DSP with the built-in speaker.)
Now, the plug-in that has only been available for the Flame has been released for the entire public. It can be installed on any WM5+ Pocket PC and Pocket PC Phone Edition. I’ve tested it with the following Pocket PC (phones):
Dell Axim x51v (A12 official ROM)
HP iPAQ hx4700 (WM5 AKU3.5.2 ROM)
HTC Universal (Midget’s WM6 AKU0.2.0 ROM)
HTC Wizard (mfrazzz’s XDA Mobile 6 Release 3)
and it worked just great on them.
Note that it isn’t compatible with MS Smartphones (WM6 Standard) and Pocket PC’s with operating systems prior to WM5.
(screenshot of the 3D parameter setter tab)
(screenshot of the Truebass tab – it’s here that you can set the bass level)
Additional screenshots:
it’s HERE that you can switch between headphones and internal speaker output. The two have entirely different stereo widening characteristics: while headphones, in general, don’t benefit much from stereo widening, especially built-in stereo speakers benefit a lot from them.
Unfortunately, the switching isn’t automatic – that is, the controller doesn’t notice when you switch back to either wired or A2DP headphones from using the built-in stereo speakers and vice versa.
The lack of the automatic switching is indeed pretty annoying: the contraphase effects are, in general, are pretty bad when played back in headphones and it’s only with fully mono signals that they don’t have any bad effect on.
This is also a problem with the Nokia N95, even as of firmware v20, by the way. In there, enabled stereo widening has a definitely nice effect if and only if you play back mono contents. Then, it prettily widens it so that it is no longer in the center of your head, but somewhere in there. Stereo sources, of course, are pretty much messed up when played back via headphones.
HERE and HERE, you can see two (of the several) pre-defined profiles. Of course, you can also play with the sliders yourself.
Resource usage
Based on my past articles (see for example THIS), you may already know that
software-based equalizers can require a lot of additional CPU time and, consequently, radically decrease the battery life on older and, in this respect, inferior platforms (most importantly, Windows Mobile devices based on the Intel Xscale PXA-2xx CPU series - see THIS for more info on how they compare to other CPU's; most importantly, Samsungs and TI OMAP's)
hardware equalizers (see for example THIS) don’t result in a decreased battery life (not even on the PXA-2xx CPU’s) but aren’t compatible with several models and can only be used with wired (!) headphones. Finally, unless the player plays special attention to NOT closing the channel between songs, you will end up having to re-enable some of them manually (!) after a song switching. (See the "Hardware equalizers (HTC Equalizer) keep their settings when switching songs? Tested on HTC Universal" row in the chart of THIS article for more info if interested in which players do this.)
Fortunately, this app, while it has pretty nice equalizer capabilities, doesn’t really cause any really bad CPU usage increase. I’ve measured the following results (these figures were largely independent of the active profile / output used):
HTC Universal (520 MHz): CorePlayer: +5%; WMP: ~7-8%
Dell Axim x51v (forced down to 208 MHz) CorePlayer: +5%; WMP: +13%
HP iPAQ hx4700 (624 MHz): WMP: +5%
HTC Wizard (195 MHz TI): WMP: +14%
As can clearly be seen, the music player will have a somewhat increased CPU usage but it’s in no way as drastic as with some players out there. As a rule of thumb, the already CPU- and battery-friendly players like CorePlayer fare definitely better than the built-in WMP.
Getting, installing
If you have a XDA-Devs forum account, you can download the CAB file right from the related thread (which is, BTW, worth reading!). If you don’t have an account and won’t bother to register one, download it from my mirror. Transfer it to your handset, tap the CAB file and soft reset the device. After rebooting, go to Start / Settings / System / WOW HD Settings and you’re set.
Using, tips
If you have stereo headphones, make sure you only use it in the Headphones mode (see the upper drop-down menu; it’s activated in THIS screenshot). Otherwise, the sound quality will be plain awful. Again, there’s no sound source type it can enhance when it’s in speaker enhancement mode and you listen to it via headphones, unlike with the Nokia N95, where strictly mono sources become definitely more pleasing to listen to (again, via headphones) with widening enabled.
If you have a handset with only one (mono) speaker (the vast majority of current Windows Mobile handsets belong to this category, excluding for example the HTC Universal, Wizard and the O2 XDA Flame), there isn’t much point in using it at all.
If you have external speakers, you may want to give it a try. Note that if they aren’t close to each other, you may want to refrain from using the loudspeaker mode – switch to either the headphones mode (if you need for example the support for extra bass) or deactivate it entirely.
Evaluation on the HTC Wizard / Universal, using the built-in stereo speakers – compared to…
… the Nokia N95: there isn’t much competition: the Nokia N95 has still better stereo, is much louder (when it needs to be) and has much better frequency response.
… Conduits Pocket Player: on both the test devices, WOW HD delivered better (wider) stereo than Conduits Pocket Player, even with the latter set to 100% stereo widening. You, however, will want to make sure you, in some way, decrease the treble level. With the thin, bass-less speakers of both the Wizard and the Universal, the treble-rich sound of WOW HD will quickly become really tiring.
the default mode: the Wizard has almost no stereo sound – only when you have a (not very close; for example, a wall) surface reflecting the sound back to your ears. WOW HD definitely helps this – again, better than Conduits Pocket Player. The difference between the default (non-WOW HD’ed) and the widened mode isn’t that articulated with the Universal, which, particularly if you keep it pretty close to your face, was already able to generate some kind of a stereo field.
(Note that, naturally, in this test, I’ve only tested handsets that do have stereo speakers as it’s mostly on them that, unless you have headphones, you’ll want to use this tool.)

http://forum.xda-developers.com/showpost.php?p=1772622&postcount=29 <-- maybe this post is interesting for you.

LordDeath said:
http://forum.xda-developers.com/showpost.php?p=1772622&postcount=29 <-- maybe this post is interesting for you.
Click to expand...
Click to collapse
Thanks! BTW, hacks / software like this should also be announced in the Dev & Hacking forum as well - I rarely visit the Prophet forums and, therefore, don't notice local development there.

UPDATE (01/07/2008): as my original review mostly concentrated on stereo widening with handsets with stereo speakers, I need to re-emphasize that this app isn’t only useful for stereo widening or adding (comparatively) CPU-friendly loudness+megabass support. It can also be used to enhance the sound (make it more characteristic), which works even on the built-in mono speakers. See the comments for example in THIS and THIS threads.

i have tested this on a spm m3100 with wm6 rom and i noticed that it does change automaticly from internal(speakers) to headphones and vice versa...

at10ti0n said:
i have tested this on a spm m3100 with wm6 rom and i noticed that it does change automaticly from internal(speakers) to headphones and vice versa...
Click to expand...
Click to collapse
Thanks for the update; I'll post this info in the next update .

Menneisyys, did you try it over BT?
The instructions on the other thread aren't very clear:
Alexx~ said:
That worked through BT headset it is necessary to copy all parameters from [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Wave Dev] in HKEY_LOCAL_MACHINE\Drivers\BuiltIn\BtA2dpSnd
Except for value of parameter "OldDriver", he should be such, as was "DLL"
For example:
Before
"DLL" = "bta2dp.dll"
After
"DLL" = "WOWHD_ARM_WCE_PPC2005_Driver.dll"
"OldDriver" = "bta2dp.dll"
Click to expand...
Click to collapse
Not giving Alexx~ grief, quite the opposite, much appreciated... but if you have anything to add it would be appreciated.
-Richard

rpodos said:
Menneisyys, did you try it over BT?
The instructions on the other thread aren't very clear:
Not giving Alexx~ grief, quite the opposite, much appreciated... but if you have anything to add it would be appreciated.
-Richard
Click to expand...
Click to collapse
Nope; will give it a try.

rpodos said:
Menneisyys, did you try it over BT?
The instructions on the other thread aren't very clear:
Not giving Alexx~ grief, quite the opposite, much appreciated... but if you have anything to add it would be appreciated.
-Richard
Click to expand...
Click to collapse
I concur with this statement. It would be good to know how well and consistently it works with A2DP.

For those with 240*240 screens and cannot see all of the WOW HD gui settings, the registry values are stored in:
HKLM\Software\WOWXT\WaveDev
Just in case it was not obvious straight off...

I´am using the MDA Compact III (its the same as the HTC P3300 or Artemis, branded by T-Mobile Germany) and I installed SRS WOW. It works fine with MP3-Files but it does not work together with the integrated FM-Radio.
Is there any posibility to "arrange" the registry to make SRS WOW working with the radio?
Thanks for answers.
roadrunner159

Does anyone know if this has any (positive or negative) effect on the A2DP skipping issue experienced for example on the Hermes?

roadrunner159 said:
I´am using the MDA Compact III (its the same as the HTC P3300 or Artemis, branded by T-Mobile Germany) and I installed SRS WOW. It works fine with MP3-Files but it does not work together with the integrated FM-Radio.
Is there any posibility to "arrange" the registry to make SRS WOW working with the radio?
Thanks for answers.
roadrunner159
Click to expand...
Click to collapse
Probably not. The sound from the FM-radio goes straight from the receiver to the speakers/headset without entering the digital part of the device. Meaning that no signal processing algorithms can be applied as these all take part before the signal goes analog.

UPDATE (02/27/2008): see THIS thread on making it work on the MS Smartphone platform.

SRS, tytn ll, bluetooth and phone
I've been playing around with this, and when I've had it working over bt to my Jabra Bt3030 it sounds great, however, it kills my ability to make phone calls - phone works but I can't hear anything, through the headset or the handset.
Anyone had this working?
Cheers, A.

SRS WOW HD v. XT?
Menneisyys said:
Fortunately, this app, while it has pretty nice equalizer capabilities, doesn’t really cause any really bad CPU usage increase. I’ve measured the following results (these figures were largely independent of the active profile / output used):
HTC Universal (520 MHz): CorePlayer: +5%; WMP: ~7-8%
Dell Axim x51v (forced down to 208 MHz) CorePlayer: +5%; WMP: +13%
HP iPAQ hx4700 (624 MHz): WMP: +5%
HTC Wizard (195 MHz TI): WMP: +14%
Click to expand...
Click to collapse
Hello. I'd be interested to see a comparison of its CPU utlization (v. WOW HD) to the ealier SRS WOW XT for Mobiles? Are Motorola e.g. well-founded to continue XT in their MotoQ handsets?
WOW HD was towards PMP or high-end Windows Mobile devices in 2006/07, whilst XT for Mobiles included "special capability for mobile phones with ultra-wide stereo imaging and optimized single speaker playback" optimized for "low-MIPS, low-memory" plus "TI's OMAP processors have been a key platform".
http://forum.xda-developers.com/showthread.php?t=356589 (binary for WOW XT for Mobiles)

Does this work on Atom black, WM5? Not the Atom Exec, the model before the Exec. The plain Atom Black.

wm2003 dont working

I get driver issue errors. Is there a reason for that. I have a samsung and a htc wing.

UPDATE (02/27/2008): WMExperts frontpage (http://www.wmexperts.com/improve-your-wm-sound-srs-wow-plugin ); definitely worth checking out.

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 YouTube Bible

Watching YouTube videos is a favorite pastime of many. With data charges constantly decreasing (or, should I say, plummeting), not-that-expensive flat 3G data rates getting common, Wi-Fi’s getting pretty ubiquitous and, of course, YouTube’s getting really-really full of videos worth checking out, you might be tempted to watch YouTube (or other) videos on your handset. After all, it's a great pastime and these handhelds have both the processing power, the necessary hardware and, in most cases, connection speed to render these videos well.
In this YouTube Bible, I show you how this all can be done on the three major non-iPhone platforms: Windows Mobile, Symbian S60 and BlackBerry. (As the iPhone, as opposed to most other solutions, already comes with a decent player, there isn’t much point in elaborating on it. You just fire up the YouTube icon and off you go at – if you have Wi-Fi connectivity – very good quality. Nothing needs to be installed and there’re no alternatives you will need to know to make an intelligent decision.)
Note that I’ve published several YouTube-related articles (a quick search for YouTube on my blog reveals these tutorials). These, however, are pretty outdated now – particularly that a lot of vastly superior solutions have been released in the meantime. I’ll, however, refer back to for example the HTC Streaming Media tutorial.
Also note that this Bible is multiplatform, as with the majority of my later Bibles. If you're a fanboy of any of the three reviewed operating system, don't post angry messages like "Why on earth did you include operating system X? I hate it, it's sooooo inferior and lame!". Sorry, both as a gadget-loving geek and as a professional IT advisor / consultant, I MUST know all the mobile operating systems. (Particularly now that the Microsoft folks have just told me they would be interested in some of my week-long lectures on the differences on BlackBerry and Windows Mobile devices. I need such kinds of work because I (more precisely, my employer) prefer getting mobility-related IT consultant contacts as opposed to non-mobility-related ones. This is also why I keep posting on other operating systems - as I need to know them, why wouldn't I post on them? Finally, I won't create a separate version of the Bible for Symbian, BlackBerry and Windows Mobile devices for two reasons: 1. it'd cause me a LOT of additional work not only initially but also when I post a revised, updated version: restructuring the entire Bible, taking out all references to other OS'es; 2. knowing what other operating systems are capable of won't do anyone any harm - you may even find that having read info on another OS useful if you are given a handset running a different OS.)
Also note that, Windows Mobile-wise, the discussion applies to both touchscreen-less MS Smartphones (Windows Mobile 6 Standard) and touchscreen-enabled Pocket PC’s (Windows Mobile 6 Classic / Pro) models. All the reviewed Windows Mobile solutions run on both platforms. In the compatibility lists, I've listed the earliest Windows Mobile operating system a given solution is compatible with but didn't list them all. This means if you see WM2003+, it means compatibility with WM2003 and all subsequent operating system versions (WM2003SE, WM5, WM6, WM6.1), not only with WM2003.
1.1 Browsing the desktop Web version of YouTube
This section applies to both platforms of Windows Mobile starting with WM2003+ and used with Internet Explorer Mobile (IEM) and Opera Mobile; Symbian with integrated Flash Lite 3.
1.1.1 Windows Mobile
1.1.1.1 IEM / Opera Mobile + Flash 7 plug-in
If you install the Flash 7 plug-in (see the Flash Bible HERE for more info on the availability etc.) on your Pocket PC and either use the WM5+ (not earlier: due to bad JavaScript support, they won’t work) Internet Explorer Mobile (IEM) or WM2003+ Opera Mobile (any version), the videos will be played back in-line, just like on the desktop.
This is, however, the worst approach you should ALWAYS avoid because it, in some cases, grinds the entire handset to halt and is very slow, even on high-end Windows Mobile devices. All in all, it’s in NO WAY recommended - there are far superior approaches.
1.1.1.2 IEM + FlashVideoBundle
This is an immensely better solution having all the advantages of the desktop version; most importantly, direct access to YouTube, Google Video & Veoh links sent in, for example, mails. Then, when IEM is invoked, you’re shown a context menu, where you can instruct IEM to show the video in TCPMP, save it into a file or, alternatively, take you right to the page so that you can see for example the comments / related videos:
{
"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"
}
If you directly enter the URL in the address bar (by, for example, pasting it to there), it’ll too present you with the same context menu; the same will happen if you just click a video link on YouTube (GV etc.) pages.
The current version is 1.4.4; CAB file available for download HERE (if you don’t want to register, I’ve mirrored it HERE); my old, now-outdated article HERE. Installing it is pretty straightforward; just follow the section "Installation instructions" in the tutorial on the homepage.
This is one of the most recommended ways of playing back online videos, particularly if you get links in e-mails / other, offline documents like Word files.
1.1.2 Symbian with Flash Lite 3
In order to play back (Flash, including YouTube) videos embedded in Web pages, you’ll need to have a device with Flash Lite 3 preinstalled. One of them, the, currently, best multimedia handset of all, the Nokia N95 received Flash Lite 3 support in firmware version v21 released some weeks ago.
If you have a compatible handset, you don’t need to install anything else (no third-party apps at all): videos will be played back right in the pages that contain them, with much-much less adverse effects than (currently) with Windows Mobile relying on the CPU-hog Flash 7.
As has already been emphasized, Flash Lite 3 on Symbian behaves much-much better than the full Flash 7 on Windows Mobile. While the latter is in no way recommended, the former – if you have a Symbian device – is. Note that you can still use the Mobile YouTube Web and the MIDlet-based interface too (see sections 1.2 and 1.3, respectively), but they only deliver 3GP videos at a much lower quality than Flash Lite 3. Alternatively, if you need high-quality (Flash / H.264) videos, you may also want to prefer Mobitubia – or the soon-to-be-released, YouTube-capable version of CorePlayer.
Note that Portrait playback will always be oversized as can be seen in THIS screenshot (source link HERE). Also, if you use the standard Nokia Web menu (Options / Rotate Screen) to switch to Landscape mode, it’ll stay oversized. The trick is clicking the Flash Lite 3 surface with the Action button – it’s then that it’ll be resized to fit into the screen as can be seen in the first screenshot.
Also note that there’s still no Flash Lite 3 on Windows Mobile but will, hopefully, be soon released; see THIS and THIS for more info.

1.2 Browsing the mobile version of the YouTube on the Web (Windows Mobile (WM), Symbian, BB(?))
If you fire up YouTube in your mobile Web browser for the first time, you'll be taken to the mobile version available at http://m.youtube.com/ - as opposed to the desktop one. This is vastly different from the desktop version in that it uses 3GP / RTSP - and has much less bandwidth usage even for rendering Web pages themselves.
This, of course, has both advantages and disadvantages. While it has much lower video/audio quality and is incompatible with firewalls (except for directly Net-connected Access Points, which almost all do decent RTSP NAT'ing), it uses applications most likely to be already present on your handset. For example, most Symbian handsets have the RealOne Player sufficient for playing back RTSP streams, but comparatively few have the latest, recently released Flash Lite 3. Similarly, on Windows Mobile, several, mostly HTC-branded devices come (but if your device doesn't have it, you can safely download and install it) with HTC's Streaming Media as is explained HERE. Finally, it MIGHT be compatible with more recent BlackBerries too as they too have an RTSP-capable media player; in my tests, however, it reset my OS 4.5.0.9 (beta)-based BlackBerry 8800 - unlike vTap's streams. (This doesn't necessarily mean it resets all other BlackBerries!)
Note that m.youtube.com already has ALL the videos available, unlike some months ago when it was first announced. That is, if you can live with the lower video / audio quality of 3GP streaming (and/or you don't have a network connection making RTSP streaming impossible), it might be a better choice than the desktop version - on both Symbian and Windows Mobile. Also, its interface offers exactly the same capabilities as that of the desktop version - in a much more bandwidth- and memory-conserving way. This also means you don't need to learn a brand new interface - your can safely rely on your already existing knowledge of the desktop YouTube interface. (Not that the alternative apps and interfaces would be THAT hard to master...)
Also note that if you ever click "View Desktop Version" link once (at the bottom of the page), after that, you'll always be taken to the desktop version.
1.3 Using the official YouTube MIDlet, YouTube for Mobile (beta) (currently, Symbian)
If you navigate to http://m.youtube.com/app from inside the browser of your (select) Nokia or Sony-Ericsson handsets (N73, E65, N95, 6120c, 6110n / k800i, w880i), you can easily download and deploy the client by just clicking the Download link.
This client is a standalone app; that is, you don’t need to fire up for example the Nokia Web browser to get to your videos.
It has both restrictions and advantages. The biggest problem with it is that it can’t work over Wi-Fi connections (even with RTSP NAT correctly working, which is pretty much the case with most current Wi-Fi access points), unlike other clients. That is, you can only use wireless data to access videos. Another problem is that it’s only able to access 3GP streaming, meaning low playback quality.
However, it has a very nice and capable GUI, much better and powerful than that of most of the standalone alternatives on all platforms (not only Symbian). For example, it supports upload, account; it has related videos and is VERY polished – for example, it has search history support, which is even saved through restarts. Some screenshots showing it in action:
(searching in progress)
IMG]http://www.winmobiletech.com//042008YouTubeBible/NativeYTJavaClientRelVideos.png[/IMG]
(related videos)
(search history)
(flagging videos)
(A GUI screenshot of portrait and landscape playback is HERE and HERE; unfortunately, the screen capturer app couldn’t capture the rendered video.)
Note that this app, currently, is NOT compatible with any MIDlet Manager on Windows Mobile, as has also been explained HERE. The reason for my not putting it in the strictly Symbian-only section is that it hopefully will be made compatible with Windows Mobile as well – if Google doesn’t release a native (C++) version for the operating system, as they have done with Google Maps.
Related threads HERE, HERE and HERE.

1.4 vTap (WM, Symbian, BlackBerry)
vTap is an RSS-like content syndication service with integrated, multi-site searching (including all major video sites, WikiPedia etc.) It has both a standalone (Windows Mobile / BlackBerry) client and a Web interface. The latter is of paramount importance with BlackBerry, as it’s, currently, the only way to access online YouTube videos.
First, let’s take a look at the standalone Windows Mobile client. After installing and starting, it presents you a single input field, where you can enter for example the video you’re looking for – as with the traditional YouTube search. It, however, also presents Wikipedia (and other video) hits.
(a Windows Mobile screenshot showing the collected results of a search – again, not only from YouTube)
Its GUI is pretty powerful as it allows for for example feedback, account login etc. Its settings capabilities are also pretty cool (1 2). Also allows for showing related videos which is pretty rare as of the writing of this article.
As far as the BlackBerry is concerned, the native client is only able to search from the Wiki as can be seen in HERE. The vTap folks do state the standalone client is, as with Windows Mobile, able to play videos (or, at least, pass videos to the system-level multimedia player) starting with BB OS version 4.3. This doesn’t seem to be the case with version 4.5[0.9] beta of the operating system (see the 04/23 update of THIS article for more info on acquiring and installing the beta). As can be seen in HERE, there’s no Play icon at all and the menu (screenshot HERE) is much less powerful than that on Windows Mobile. (These are all 4.2.1 BB 8800 screenshots; the client behaves in exactly the same way on the same device with the latest 4.5.0.9 beta OS). Some Pearl users with native 4.3, on the other hand, did state it worked for them.
See for example THIS for more info.
However, this isn’t a problem! There is, fortunately, a way to play back online, streamed content on the BlackBerry too. (Note that the following part has only been tested under 4.5.0.9. It might work on "official" 4.2 / 4.3 OS versions as well.)
1.4.1 The online Mobile vTap
If you navigate to http://m.vtap.com/ on your BlackBerry, you’re presented an interface pretty similar to that of Mobile YouTube. It allows for searching and a lot of other goodies. On BlackBerries, it’s the only way to get online, non-reconverted content, unlike the ways described for example HERE or in the well-known, related CrackBerry.com tutorial. Screenshots showing it in action – again, under OS version 4.5.0.9:

(note that, as with Symbian, I couldn’t make a shot of the rendered contents)
Note that Mobile vTap is also compatible with Symbian; in there, it uses the built-in RealOne player (and RTSP). It must also be compatible with HTC’s Streaming Media on Windows Mobile (haven’t tested this), should you want to prefer it to alternate solutions.
1.5 Operating-system specific, other apps
1.5.1 Windows Mobile
1.5.1.1 CorePlayer
I don’t think anyone needs to introduce CorePlayer (particularly not to readers that have been following my past multimedia-related articles), which has recently received native YouTube browsing / searching support – in addition to, of course, playing it back. And it does the latter extraordinary well. Being based on the fastest AVC (H.264) and HE-AAC decoders, it plays back high-quality (non-3GP) videos with much less overhead than any other YouTube client on Windows Mobile. See for example THIS and THIS post for more info on this.
If you know iPhone’s YouTube player, you already know that of CorePlayer – the latter is very similar to iPhone’s. (Except for, for example, the lack of related videos.) This means it’s very easy to use and, again, has the most CPU-efficient decoding algorithm when it comes to playing back quality AND firewall-friendly, H.264 + AAC content - as opposed to the low-quality RTSP-streamed and, therefore, not firewall-friendly, 3GP content, which has considerably lower demands and can be played back by even non-optimized code without major CPU hits. Some screenshots:
(standard list view)
(detailed view of a selected video)
It’s still worth explaining how you can switch between the RTSP + 3G (low/medium-quality) and H.264 (high-quality, firewall-friendly HTTP-streamed) modes. By default, CP is configured to use the former. If your network topology / connection doesn’t allow for RTSP connections, the current, 1.2.3 version doesn’t display any error message – just times out after some minutes. (This will be fixed in a future version, as is also explained by the developer: "Automate the YouTube Quality Control 'seeking'... this will help incase one setting appears to hang (spinning buffering icon).") If you either want to fix this problem or just want much better audio & video quality, just switch to "High Quality" in Menu > Tools > Preferences > Select Page > Network > YouTube Format:

Note that QTv Display is set by default as the video renderer; therefore, if you don’t see any video (only sound), you’ll need to set the video mode to Raw Framebuffer or, if your PDA has a graphics co-processor (for example, the Intel 2700G), to it in Menu > Tools > Preferences > Select Page > Video > Video output:
Note that with the (unfortunately, still very few) stereo high-quality (H.264) videos (like this) aren’t played back in stereo, unlike with TCPMP-based H.264 / FLV players - or simple 3GP players like that of Nokia Flash Lite 3 or the BlackBerry. This problem will be fixed really soon, as HE-AACv2, the state-of-the-art sound compression technology I’ve often elaborated on in my articles, finally gains support in CorePlayer in the near future. This is just great news – so far, Windows Mobile clearly lagged behind both Symbian S60 (on N-series devices) and BlackBerry 4.5 (which both support HE-AACv2 out of the box, with minimal CPU usage and AVRCP support not available with Windows Mobile) when it came to playing back HE-AACv2.
Also note that, while the YouTube client of CP currently lacks a lot of additional functionality like clip upload, login, online favorites etc., this will soon be fixed as is explained HERE: "we have omitted some features till later on when we add it as a module with login, uploading, related, and bookmarking".
Finally, should be interested in why I recommend CP so much, take a look at my H.264 Bible (if you haven’t already done so), where I’ve thoroughly benchmarked the H.264 (and AAC) decoding efficiency of all media players.
1.5.1.2 Milesmowbray’s YouTubePlay - YouTube Player
There’s another, free(!) and pretty cool, but, being based on the old TCPMP libraries, compared to CorePlayer, less efficient standalone player, Milesmowbray’s YouTubePlay available HERE.
(the search results, highlighting a clip - as you can see, there isn't much you can do - no related videos, flagging, account support and the like)
(it uses a built-in video player for playback - that is, it doesn't rely on external players)
It’s pretty straightforward to use as it’s a stand-alone app: you just install it and fire it up. No further (external) app installs are necessary. See the above-linked thread for user discussion & new versions (albeit, of course, I’ll try to keep you updated).
If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
1.5.1.3 YTPocket
YTPocket is a decent Web-based interface offering Flash-based, that is, high-quality (as opposed to low-bitrate and, hence, low-quality 3GP streams) and HTTP (meaning firewall-friendliness) streaming. The interface is pretty much similar to that of the Web interface of Mobile YouTube.
As it’s FLV-based, you must have a FLV-capable player to play the videos it downloads. Shouldn’t you already have TCPMP with the FLV plug-in installed, you can easily download them over-the-air from the setup tutorial page of YTPocket.
(the thumbnail list)

(a direct URL can also be entered – or, better, pasted – should you have received a direct link in, say, an e-mail and don’t want to fire up Nokia Web or Opera Mini to find out the title or other parameters of the clip to be able to quickly find it)
(you can also supply the YouTube ID – see the remarks of the previous screenshot)
Note that there used to be another Symbian app to play back YouTube, emTube, but it’s been down for some months and it’s still not known whether it’ll be restarted at all. Also see THIS.
Finally, the Symbian version of CorePlayer will receive the same functionality than the Windows Mobile version in 1-2 weeks (this being written on 04/24/2008). See section 1.5.1.1 for more info.
2. Comparison chart
The feature / comparison chart available HERE is pretty easy to understand based on the info above. It lists the compatibility, quality, protocol (whether it’s using high-quality, firewall-friendly HTTP / H.264 or the low-quality, firewall-unfriendly RTSP 3GP), standard YouTube features like uploading, editing / reading comments, related videos, logging into your account and the ability to save videos for future use (in which YTPocket really rocks).
3. Verdict - what to go for?
There're no hard-and-fast rules for choosing the right solution. First, you need to decide whether the quality (or the lack thereof) of 3GP streams are sufficient for you. If they aren't (and you aren't a BlackBerry user) OR you can't play back RTSP streams (because of your restricted network connection), go for something FLV / H.264-based. Fortunately, both Symbian and Windows Mobile has several apps offering FLV / H.264 playback. For WM, I recommend FlashVideoBundle and/or CorePlayer the most. For Symbian, Mobitubia is a really decent solution - and the forthcoming CorePlayer, if you don't mind the higher price tag. Of course, on Symbian, you can also safely stick with Flash Lite 3 if you have a compatible handset / firmware version (again, remember that Flash Lite 3 being comparatively new, your otherwise compatible phone may still running an older, incompatible firmware - as was the case with the Nokia N95 before firmware version v21).
On the other hand, if your connection isn't firewalled (which would make incoming RSTP connections impossible), the 3GP "quality" is sufficient for you and/or you must reduce network traffic (or, you are on the BlackBerry), you can safely stay with http://m.youtube.com/ (see section 1.2) if you're a Windows Mobile (making sure you do have an RTSP player (pre)installed; for example, the free HTC Streaming Media) or Symbian user or the online Mobile vTap (see section 1.4.1) if you're on BlackBerry.

UPDATE (04/25/2008 12:02PM CET): note that BlueApple.mobi is another great transcoding service compatible with, among other mobile platforms, the (4.3+) BlackBerry. See for example THIS for more info on its BB compatibility.
Also note that I may haven't included some other YouTube transcoder services in the Bible - there're quite a few of them, and I've found the reviewed ones the best.

I thought overall this was a good review. I would take exception on one thing.
You say: If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
I disagree if we are talking purely about youtube. YouTubePlay plays youtube videos much better than CP1.2.3 on a US 3G network. Sure CP's youtube integration is very nice with the favorites and most viewed etc, but when it comes to play the video you have to decide if you want to lower the resolution or watch it stuttering. Y2P works fine with little buffering using h264. It may work fine over Wifi, i havent been able to test that. Betaboy has said this should be fixed in the next milestone, and if it is, then yes, CP will be superior for youtube viewing. I hope thats the case , as I really do like the CP integration

volwrath said:
I thought overall this was a good review. I would take exception on one thing.
You say: If you want a standalone (non-Web-based) app and don't want to pay for the, otherwise, technically superior CorePlayer, this app is worth checking out. Note that, however, it's pretty much inferior to CP, capabilities-wise.
I disagree if we are talking purely about youtube. YouTubePlay plays youtube videos much better than CP1.2.3 on a US 3G network. Sure CP's youtube integration is very nice with the favorites and most viewed etc, but when it comes to play the video you have to decide if you want to lower the resolution or watch it stuttering. Y2P works fine with little buffering using h264. It may work fine over Wifi, i havent been able to test that. Betaboy has said this should be fixed in the next milestone, and if it is, then yes, CP will be superior for youtube viewing. I hope thats the case , as I really do like the CP integration
Click to expand...
Click to collapse
Yup, many complain about the buffering issues with YouTube and CP; will definitely emphasize this in a future article update. (BTW, interestingly, here in Europe, I have no similar problems with Vodafone (using an unlimited data plan via HSDPA).)

UPDATE (05/10/2008): there is a lot to report on; most importantly, the just-released CorePlayer with its, on Windows Mobile, heavily bugfixed and enhanced YouTube support – and, on Symbian and Palm OS, its pure existence. I, in addition, elaborate on the differences of the three major formats used on YouTube: H.264, FLV and 3GP and give you some excellent screenshots of the real-life difference between them.
First, however, let’s take a look at the operating system-specific news.
1. Symbian
a. some people have asked me to elaborate on myZen, a Java-based and YouTube-compliant player. It’s not recommended at all - it's 3GP / RTSP only with all its drawbacks (sub-par video and audio, not compatible with several wireless operators etc.) Besides, it's, being based on Java, a bit slow. (Albeit this isn't really visible at playing back video as it uses the underlying media player.)
b. I haven’t emphasized this in the initial version of the Bible, but it’s surely worth mentioning: not even the latest (build 4) version of MobiTube can play about 20% of the (FLV) videos off YouTube without (on the high-end N95 with the latest-and-greatest v21 firmware) major stuttering problems. One of these videos can be found HERE. Fortunately, the just-released CorePlayer can play all these videos without problems – or, for that matter, the Flash Lite 3 plug-in, if you don’t mind having to browse the full (and bloated) YouTube site from Nokia S60 Web. The developer has promised to look into the problem. In the meantime, I recommend getting CorePlayer for Symbian to play videos that MobiTube can’t play back. (YouTube does have some advantages over CorePlayer, though; for example, any number of hits. More on this later.)
2. Windows Mobile
milesmowbray has been busily enhancing his youtubeplay app (see the review of an earlier version above) and adding nice features like getting the list of Related videos, a new, much more capable in-play GUI and saving a particular video to the file system. (Screenshots of the latter HERE and HERE). Currently, it’s at version v1.0.0.6 and is worth checking out if you want a free solution, don’t want to browse the bloated, original YouTube site in order to be able to utilize FlashVideoBundle, don’t want to watch low-quality 3GP streams (HTC Streaming Media, http://m.youtube.com/ etc.) and don’t want to use third-party, but FLV-based Web interfaces like YTPocket. Otherwise, if you don’t mind being commercial, the lack of clip saving and Related videos and/or have a VGA Pocket PC, CorePlayer might be a better, more mature solution.
3. CorePlayer 1.2.4
Fortunately, CorePlayer, which has only recently received YouTube support, has received a lot of bugfixes in the meantime, which is certainly very good news for Windows Mobile users. Also, Symbian and Palm OS users rejoice: now, you also have YouTube support!
3.1 Windows Mobile
Let’s start with Windows Mobile. Two huge YouTube problems with pre-1.2.4 versions was the lack of FLV support and the buffering issues have been fixed. I’ll elaborate on what FLV is and how it compares to the other two streaming formats supported by CorePlayer.
As far as the buffering is concerned, the new version no longer exhibits the bad buffering problems of the previous versions, which stopped for buffering quite often even when the connection was far faster than required. In the old versions, this could only be partially fixed by increasing the system buffers to 32M (and enabling microdrive mode). There are no buffering problems with FLV playback either.
Unfortunately, it still has some major functionality problems; most importantly, it still doesn’t list related videos and, even more importantly, it’s only capable of listing 13 videos at most in ANY list. Just an example: if you look for, for example, all parts of Scandinavia: The Forgotten Front - see THIS for the first part - , at least one part will pretty surely be missing if you search for “winter war” using the built-in search tool. (Fortunately, the CorePlayer folks have promised me they would fix all these issues, along with adding support for other video sites – that is, not only YouTube, but also for example dailymotion (which already works in internal test versions) and, hopefully, Google Video.)
This problem is pretty huge on Windows Mobile; for example, with milesmowbray’s youtubeplay as of version v1.0.0.6 (it lists only five items as can also be seen HERE). On Symbian, MobiTube don’t suffer from this: there, 25 clips are shown at a time and you can switch to the next (previous) 25 hits by simply selecting Next / Previous page from the menu.
3.2 Symbian
The Symbian version, which has just received YouTube support, still suffers from the lack of H.264 hardware acceleration. That is, H.264 (480*320) clips are practically unwatchable. On the high-end Nokia N95, it drops about 30-40% of the played frames and has heavy buffering pauses. The somewhat lower-quality FLV playback has no such problems. Therefore, before hardware acceleration is added (or the H.264 playback efficiency seriously enhanced), you’ll want to stick to FLV playback instead of H.264 on Symbian (but not on Windows Mobile, particularly if you have a VGA device).
4. Differences between the three streaming formats: H.264, FLV and 3GP
You may not understand what the three streaming formats, H.264, FLV and 3GP, are, and how they compare to each other, quality-wise. Let’s take a closer look at this question, particularly now that CorePlayer introduced support for FLV in addition to the other two formats.
4.1 H.264
H.264 is the best of all and, currently, is only supported by CorePlayer on both WinMo and Symbian. (The other players are either FLV or 3GP-only.) It has the highest video resolution (480*360), the highest video and audio bit rate with the most advanced codecs (H.264 for video and stereo 44 kHz AAC audio). This, however, also means that it has much higher data usage than the other formats: about 1.8 times more than that of FLV and 3-4 times more than 3GP (also somewhat depending on the audio codec used with the latter). Also, it has much higher CPU demands than FLV or 3GP; this is why, for example, Symbian devices currently can’t play back YouTube videos in the H.264 format. Let’s see an example (the first frame of THIS clip); make sure you compare the quality to that of the two other videos. I’ve deliberately selected a clip with some subtitles; it’s mostly on the latter than you can really see the resolution differences between H.264 and FLV. Also make sure you check out the general blockiness of the videos. (Note that I’ve taken these shots with 95% JPG quality; that is, I haven’t introduced almost any additional blockiness.)
The additional strength of the H.264 format is the support for stereo 44 kHz sound. While, currently, very few (see for example THIS) real-world clips have a stereo soundtrack - and the ones that work on mobiles, like THIS and THIS, don’t necessarily have stereo audio on the desktop.
4.2 FLV
Now, let’s turn to FLV, which is the most widely supported format on mobile platforms. On Windows Mobile, for example, there aren’t other players with H.264 support, while ones with FLV support abound (for example, FlashVideoBundle, milesmowbray’s youtubeplay, YTPocket etc.)
YouTube FLV is, technically, far inferior to H.264: it only has the resolution of 320*240, has much lower bitrate and the technically inferior (worse quality at the same bitrate) H.263 video and MP3 audio format. It doesn’t support stereo audio either.
While on a low-resolution (for example, QVGA) screen the quality difference isn’t so visible as on a high-resolution one (where the difference in the resolution plays a big role in rendering FLV much inferior to H.264), it’s still preferable to go for H.264 even on QVGA handsets because the H.264 videos are just less blocky (much higher bitrate and much more advanced format). Also, the audio is much better (44 vs. 22 kHz and, when possible, stereo). An example screenshot showing the resolution / blockiness on a VGA device:

4.3 3GP
Finally, 3GP, the worst of all – the format that you should avoid at any rate (unless you absolutely need to reduce data usage or don’t need video at all because it’s static like with, say, THIS clip) uses the resolution of 176*144 and a very low video bitrate resulting in a lot of blockiness. An example screenshot follows so that you can see how bad it is:
Note that, audio-wise, there’re two sub-formats of YouTube 3GP streams. The first (better) uses 22 kHz AAC mono audio and is referred to as “Medium-quality” by CorePlayer (as with FLV); the second (worse) uses the 8 kHz AMR speech vocoder to further decrease data usage (and to further reduce audio quality). Of course, the gain is marginal; therefore, if you absolutely need to go 3GP, try preferring the former format.
4.4 Setting the YouTube format in CorePlayer
Don’t forget to set the format in CorePlayer according to your needs and the restrictions of your handheld. (For example, as has already been explained, on a VGA device it’s always worth trying to use H.264 because of the higher source resolution. On a QVGA device, the difference isn’t that big - H.264 is a bit less blocky but, again, requires far more CPU cycles and has much higher data usage. Of course, you should also keep in mind the superior audio quality of the H.264-based streams too.)

Maybe not the best place to post here, but outside of the YouTube support, do you think CorePlayer is worth the money?

TheChampJT said:
Maybe not the best place to post here, but outside of the YouTube support, do you think CorePlayer is worth the money?
Click to expand...
Click to collapse
Depends on what you want to use it for and on which OS. For example, it can't be used for HE-AACv2 playback. If you wouldn't use for it but, say, general non-WMV (ASP, AVC etc) video playback, then, surely.

Great, thanks! Also, great work on all the "Bibles".

Audio with NO video???
Ok, I dont know if this is the correct thread to post but I'll start here...
I'm trying to play saved .flv video files from the storage card on my Hermes/TyTn.
I'm running a Hermes (8525) SuperCID with Schaps4.01
CE OS 5.2.1933 (Build 18533.0.7.0)
I've tried tcpmp.pocketpc.0.72RC1.cab,
TCPMPflvplugin-v0.4.2.CAB,
youtubeplay_1006.CAB
All with no luck. All I get is audio with NO video.
Any advice?
Regards,

UPDATE (05/12/2008):
1. (Symbian):
a. I've tested the last about 20 latest featured videos on YouTube with MobiTubia. All played well. Therefore, it's possible it's only with some older videos that MobiTubia delivers sub-par results; with newer ones, it doesn't seem to.
The Symbian version of CorePlayer, on the other hand, doesn't seem to like firewalled cellular connections. These cause it not to download any clip lists. This works just great under Windows Mobile (and, of course, with MobiTubia under Symbian) and, therefore, must be an internal bug.
b. I've very thoroughly compared the power consumption of MobiTubia to CorePlayer 1.2.4. While MobiTubia consumes a tad more power when it's still loading (caching) the clip in the background, after the clip is cached, it delivers considerably better results (much lower power consumption) than CorePlayer. Therefore, it's always worth going for MobiTubia when your Internet connection speed is much faster than the ~320 kbps stream of FLV videos because, after the caching is finished, the power consumption will be really decreased. CorePlayer, on the other hand, doesn't cache the file and, consequently, it'll use the (with both Wi-Fi and 3G connections, power-hungry) wireless unit all the time.
The following screenshot shows this in effect: the first ~5:30 show CorePlayer playing back a 6-minute clip; the second show the latter with MobiTubia. As can clearly be seen, the latter manages to cache the file in the first about 60% of the total playback time of the clip; after this, it doesn't use the wirleess unit any more, resulting in a heavy power consumption decrease. CorePlayer, on the other hand, streams the YouTube contents all the time, resulting in much higher net power consumption:
I've made another screenshot showing CorePlayer only, repeatedly playing the same 6-minute clip. As can clearly be seen, the power consumption is constantly the same (high) because there's no caching at all.
Let's see some other screenshots comparing the power consumption using HSDPA. As you'll see, the difference won't be as articulated as with Wi-Fi and the average power consumption will be pretty similar because buffering, with much bigger excess power consumption, takes much more time than over Wi-Fi. The following shot shows playing the same clip thru Wi-Fi and, then, HSDPA using MobiTubia:
As can clearly be seen, the average power consumption is bigger because the system were in the low-power (~1.1W) area for a much shorter time than with Wi-Fi. (And, of course, streaming anything (!) via HSDPA will always take much more power than via Wi-Fi, as has also been explained in my Multiplatform Radio Stream Transcoding Bible.)
Let's see the CorePlayer results. Two HSDPA examples follow:

As can clearly be seen, while there indeed isn't any kind of buffering, the overall lower CPU usage of the H.263 / MP3 decoder has resulted in about the same average power consumption as that of MobiTubia.
All in all, as a rule of thumb: on Symbian:
- when you watch YouTube videos over Wi-Fi and would like to have as long battery life as possible, prefer MobiTubia
- when over 3G, both will behave almost the same way.
2. (Windows Mobile): I've continued comparing milesmowbray's youtubeplay to CorePlayer 1.2.4.
a. in youtubeplay, you can fetch the first 50 hits of any search / "Related" operation; but, it seems, no more (it, then, complains about the network's not working.) To set this, go to Config (button in the bottom left) and just increase the number of hits shown with the second slider (Results returned).
b. on the test iPAQ 210, youtubeplay uses about 62-64% CPU time to decode and play back (FLV) videos (in both Portrait and Landscape). CorePlayer, at the same time, uses about 21...23% (again, in FLV). With H.264, of course, CorePlayer requires far more CPU time (more than 80%) and if you run other even slightly CPU-intensive tasks (like acbTaskMan to track CPU usage), there will be some (about 10...30%) dropped frames, particularly with really dynamic videos like those of Call of Duty 2.
This means if you plan to stick to the FLV format (because you're on a QVGA device and, therefore, you couldn't take advantage of the higher resolution of the H.264 video or you're on VGA but the source video is already of bad quality making it unnecessary to stream in H.264), you can save a lot of battery if you go for CorePlayer on CPU architectures that have much higher power consumption with high CPU loads than with low ones. Typically, Intel / Marvel Xscale CPU's belong to this group, where the difference in battery life can even be 1.5...2-fold between two players using 22% and 63% CPU cycles. Of course, with activated Wi-Fi and higher levels of backlight, the difference won't be this pronounced. The only architecture that (somewhat strangely) doesn't exhibit excess power consumption with higher CPU loads is that of Samsung (at least the older architectures; I haven't tested the latest, 6400-series in this respect.)
What about buffering, you may ask. Do alternative solutions like milesmowbray's youtubeplay have an advantage over CorePlayer in the same way as was certainly visible on Symbian? The answer is, unfortunately, no. Just look at the following screenshot, taken via Wi-Fi without power saving enabled on the Dell Axim x51v running WM6.1. (Note that, while CorePlayer had absolutely no problems playing back clips without dropped frames on this particular model, youtubeplay fared much worse. That is, using youtubeplay is in no way recommended on the x51v.)
The CPU usage is shown in the upper and the power consumption on the lower pane. The first ~8 minutes show CorePlayer playing the clip; after that (there's a small discontinuation in the chart) youtubeplay follows. As can clearly be seen, the average power consumption of youtubeplay is much higher than that of CorePlayer. Raising the buffer size from 2048 kbytes to, say, 16Mbytes (to allow for the complete buffering of most clips) won't help at all.
With Wi-Fi power saving enabled, the power consumption is far lower - but, with youtubeplay, it's still definitely larger than with CorePlayer:
All in all, unlike on Symbian, on Windows Mobile you'll always want to stick to CorePlayer in order to absolutely minimize power usage when playing back FLV YouTube videos. (Again, the above power usage tests only only show FLV playback power usage as it's FLV playback that the other players support, not H.264.)

UPDATE (05/12/2008, later): I’ve forgotten to elaborate on the other implications of CorePlayer 1.2.4 having just received FLV support.
One of the most important consequences of this is that you no longer need to use TCPMP as a player together with FlashVideoBundle, should you want to stick to browsing the "full" YouTube in IEM and invoke an external player to play back the videos on them.
That is, you only need to install CorePlayer and, then, the single CAB file of FlashVideoBundle (as of this writing version 1.4.4) available for download HERE and, then (making sure you restart it at least once so that the plug-in is loaded), just fire up YouTube in your (WM5+) IEM and click any video link. In the context menu, just select “Play video” and CorePlayer will be invoked. Cool, eh? You’re no longer dependent on the aging TCPMP but can invoke CorePlayer to play your videos instead. One less programs to install on your handset, not to mention the other advantages (more refined, more battery-friendly drivers, decoders etc.)
If your handheld already has TCPMP pre-installed, you’ll want to either uninstall it or, in CorePlayer, override the file associations. Unfortunately, I couldn’t find out how you should force FlashVideoBundle to pass the execution to CorePlayer instead of TCPMP (without a chance to remove it) with ROM’s containing TCPMP built-in, without any way to uninstall them, like that of Ranju's HTC Universal ROM (v7.6). I’ve tried everything including deleting HKEY_LOCAL_MACHINE\ SOFTWARE\TCPMP in the Registry (the plug-in uses it) – in vain. Unfortunately, simply unassociating the files from inside TCPMP won’t work. I'll let you know when I find a solution.

Great points on the new Coreplayer. It is definitely operating much better.
One question I had that you might be able to answer is what does My Src and My Lists do in the youtube menu? I think my src may be my submitted videos but I dont have any. I do have some videos in quicklist, and they won't show up in My List.
Any ideas? and nice writeup btw

volwrath said:
Great points on the new Coreplayer. It is definitely operating much better.
One question I had that you might be able to answer is what does My Src and My Lists do in the youtube menu? I think my src may be my submitted videos but I dont have any. I do have some videos in quicklist, and they won't show up in My List.
Any ideas? and nice writeup btw
Click to expand...
Click to collapse
They might be reserved for future use (1.3 with its brand new Channels etc.)