The Radio Stream Transcoding Bible - Part II

(Continued from Part I)

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:mennpwd@127.0.0.1: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:mennpwd@127.0.0.1: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:mennpwd@127.0.0.1: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:mennpwd@127.0.0.1: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

1. there are several tutorials on it – use Google
2. 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.

Transcoding technology:OrbStream Transcoder V3 + (direct) Icecast2OddcastV3 + (mixer) Icecast2, with, say, WinampOddcastV3 - WinAMP plugin version + Icecast2VLC + Icecast2 (note that WM clients don’t necessarily need the additional Icecast2!)WME (mixer) with, say, Winamp
Input: MP3 (SHOUTcast)+++ (Mixer-based; therefore, able to transcode anything the mixed source is able to play back)+ (note that it can also use the system-level mixer!)++ (Mixer-based; therefore, able to transcode anything the mixed source is able to play back)
WMA+- See above+Partial (ONLY with non-Icecast2 output streams!)See above
AAC (SHOUTcast)+- See above++See above
OGG (SHOUTcast)+- (it failed with my test OGG sources)See above++See above
RealAudio+ (full!)- See above- (no RA support at all in WinAMP)? (partial only – works with some streams and doesn’t with others)See above
Output: SHOUTcast MP3? (for Symbian users)-++++-
SHOUTcast HE-AAC v2? (for WM users)Restricted (AAC-LC, which is really inferior to HE-AAC v2 at the same bitrate; only broadcast via RTSP – no HTTP SHOUTcast support)+++--
SHOUTcast OGG?-+ (n/t)+ (n/t)+ (n/t)- (only in theory)-
WMA?+ (32 kbps mono only – params not configurable)----+ (configurable params – still much inferior to HE-AAC v2 at the same bitrate)
RealAudio?+-----
3G technologies like AAC-LC / AMR?+, but ONLY via RTSP (no SHOUTcast HTTP support)!-----
Misc: Transcoding multiple radio stations at the same time?- (switch initiated from client; therefore, no CPU problems and seamless almost client-side switching is possible)+ (CPU usage problems may arise when running more than 10-15 instances; note that the servers, then, must be separated in the file system because they use the same config files describing the source and the target streams – unlike with VLC, which is passed the same info from batch files)- (uses the mixer – only one stream available)- (transcodes the currently played back stream – only one stream available)+ (CPU usage problems – max. 10-30 on a current CPU)- (uses the mixer – only one stream available)
Client-side remote control?+ (excellent!)- (only with fully fledged, bandwidth-hungry generic remote desktop control apps)+ (the audio source itself needs to be controlled)+ (direct Winamp remote controllers)So-so (very bad and bandwidth-consuming HTTP remote control interface; might want to use the TELNET interface instead)+ (the audio source itself needs to be controlled)
Uses audio mixer of the PC as input?--+- (but you can switch it to using the system-level mixer; that is, you can use other sources than the WinAMP DSP)-+
If not, volume overdriving-related distortion problems common?-+ (BAD – distortion with several source streams!)n/an/a (albeit sometimes the MP3 output is more distorted than with VLC. No such problems with HE-AAC v2 output.)-n/a
Metatags transferred (tested with THIS stream)?++-+--

3. Verdict

As usual, there’s no winner because several factors may influence your decision. Let’s walk over some of them.

1. 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.
2. 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.

3. 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).

Cross-posted to (might be worth checking out for additional info / discussions!): PPCT, AximSite, XDA-Developers - 1, XDA-Developers - 2, FirstLoox, BrightHand, HowardForums, HowardForums - 2, SPT, MoDaCo, AAS, Symbian-Freak.

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

1. even the oldest (much older than those of Samsung!) Intel PXA-series CPU’s are already ARMv5TE,
2. 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)
3. 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.

UPDATE (01/04/2008): AAS frontpage; MoDaCo frontpage