As perhaps some of you may have already noted, some stations choose
to dress up their audio streaming links with fancy graphics and flashy
advertisements. This can cause streaming problems with connection
speeds of 33.6K or slower. Windows
Media Player
offers a useful and simple solution to this.
Take a look, for example, at the
WCNY audio frame.
Once this is loaded, pass your cursor over the Windows
Media Player
transport bar. Now right-click and the Windows
Media Player
menus will come up. Go to Properties
and then File
and then Content.
There you will see displayed the URL JUST FOR THE AUDIO STREAM ITSELF.
The domain is listed under File
and the file name is displayed in Content.
Now combine these two pieces of information. The File
is listed as
http://main.str3am.com/wcnyweb.
The
Content
name is listed as wcnyweb. Usually, when one sees that Windows
Media Player
symbol it means the file extension is .asx.Therefore the URL
for the audio stream itself is
http://main.str3am.com/wcnyweb/wcnyweb.asx.
Open
up your Windows
Media Player
in standalone
mode and plug this address into the File
Open URL
window and click OK.
The stream will then load up, minus the accompanying graphics, in
one's standalone player rather than in one's browser.
We understand that there are reasons why it might be desirable to
load up the full browser audio frame accompanying the stream rather
than performing the above operation. A full browser audio frame
can perform useful functions, e.g. it can keep the surfer apprised
of the selection currently playing. So consider the above operation
as an option which can be exercised at the surfer's convenience rather
than a technical operation which must be performed.
There are some sites which disable this function altogether.
If one loads up the Radio
Classique audio frame,
for example, one finds that the Windows Media Player graphic has been
buried and replaced by the station stream provider's own graphic.
It is understandable why this should be so in some instances.
Some stations are not very rich and desperately need to protect their
advertising revenue. This is one means by which they do so.
Of course, the process of sitting there while all those graphics and
animations load up can be not a little annoying. But don't forget
that this service is offered free and did not even exist a few years
ago. The emergence of this new technology is an exciting event,
however frustrating the experience occasionally can be.
We hope the above information will increase your enjoyment of Windows
Media Player
streams.
REAL
PLAYER
Real
Player
is a horse of a somewhat different color. It helps to be aware
of its peculiarities.
You see, in fact, Real
Player
is not ONE format, or codec, as the engineers like to put it; it's
THREE.
Up until four or five years ago Real
Player
utilized an audio codec which was frankly not very good sonically.
About the only way one could receive quality audio with the codec
was by implementing stream rates well in excess of the connection
speed of the average surfer.
Real
Player has
since come out with two significant
"upgrades",
Version 6 G2 and Version 8 G2,
and audio streaming on the Net has never been the same.
The two G2
formats are not only totally different from anything previously offered
by Real Player; they are even separate
and distinct from each other. They use different streaming frequencies,
and operate differently beneath the surface, as far as the surfer
is concerned.
The 9 most common streaming rates offered by Version 6, in descending
order of quality, are 96.7K stereo, 64.7K stereo, 44.1K stereo, 32.5K
stereo, 32.1K mono, 20.7K mono, 20K stereo, 16.2K mono, and 11K mono.
The 20K stereo (and its mono equivalent of 11K mono) are not high
fidelity.
The 12 streaming rates offered by Version 8, in descending order of
quality, are 352.8K stereo, 264.6K stereo, 176.4K stereo, 132.3K stereo,
96.5K stereo, 64.1K stereo, 44.1K stereo, 32K stereo, 20.7K stereo,
16.5K stereo, 16.2K mono, and 11K mono. The 11K mono stream is not
high fidelity.
Scaling
Both
Real Player and Windows
Media Player Version 9 offer a feature called
scaling in
their latest versions, which is non-defeatable. Some stations
choose to activate it, others don't. But the surfer has no choice
in the matter. Scaling, when activated, senses when a stream
is not being processed sufficiently quickly. If the current
connection is inadequate to process the stream at its current speed,
scaling
forcibly moves the stream rate to a lower one, with correspondingly
lower sonic quality, in order to protect the stability of the stream.
After streaming at a lower rate for a minute or two the program 'sniffs
the waters', as it were, to see if conditions have improved.
If the program decides they have, it
will restore the previous higher-quality higher-frequency stream rate.
There are two flaws to this feature in practice. First, as the
audio switches from stream rate to stream rate the changes in audio
quality, whether for the better or the worse, are very clearly audible. In
addition, in Real Player Version 6, they
are heralded usually by a startling, disruptive, and loud click, which
can be very annoying and unsettling when listening to classical music.
With slow connections on Version 6, the clicks can also be followed
by a break in the sound of as long as a minute.
In Version 6 the scaling process is supposed to take the stream back
up to its previous maximum level when it senses that conditions have
improved. This process is extremely unreliable. In my experience,
it usually only works around 30% to 40% of the time. Most of
the time when one finds oneself stuck in the slow lane with substandard
audio quality one usually has no choice but to hit the stop button
eventually and then reload the stream again. Once again this
means that one misses completely a minute or two of the program.
Scaling with Real Player Version 8 seems to operate much more smoothly,
with no loud clicks and no or fewer sound "dropouts" as the stream
scales up or down the speed spectrum. We are still experimenting with
the different "fixes" discussed below to see which ones work well
with Version 8.
There is absolutely nothing one can do to override these programs
from
scaling. However
there are steps one can take which can sometimes minimize its occurrence.
Protocol
Experimentation
Protocol
experimentation is one way by which one can fine-tune Real
Player's
and Windows
Media Player's
reception of audio streams. There are four possible transport protocols
one can utilize to load a stream. Their controls are located
in Real
Player's
View
Preferences Transport
menu and Windows
Media Player's
View
Preferences Transport
menu.
In Real Player there are two sets of
controls for the transport, one labeled RTSP
settings,
and the other labeled PNA
settings.
The RTSP
settings
apply to G2
codec feeds and the PNA
settings
apply to plain codec feeds. But the parameters one adjusts in
the two windows are identical. In Windows Media Player there is only
one set of controls for the transport.
The parameter
choices
are
1) Multicast
2) UDP
3) TCP
4) HTTP
In my experience, as a general rule of thumb, the most reliable protocol
to use is number 3, TCP. Real
Player
will tell you differently, recommending in most cases that one turn
on numbers 1, 2, and 3, and allow the Real Player to try them all
in turn until a good connection is achieved, with HTTP
to be used only as a last resort and manually selectable by the surfer
when all other options have failed. In my experience, without
going into the gory details, Real
Player's
proposed approach is as often a hit-and-miss proposition as it is
a guaranteed path to a good connection.
In fact, a few stations are now ever-so-slowly and grudgingly coming
around to the same point of view. Minnesota Public Radio, for
example, came right out and told the surfer to enable TCP
as the best protocol to use to load their audio stream, -- and promptly
lost its financially favorable arrangement with Real Player. It
no longer streams high fidelity!
My experience has been that the other protocols can be useful when
and if an audio stream is acting in a temperamental or unreliable
manner. In fact, in such cases, I have usually found that one
of the other protocols solved the problem.
Finally a word about the HTTP
protocol:
It has one very useful characteristic. While normally not very
stable with high-speed and/or broadband streams (though I have experienced
some exceptions to this), it also streams, when at its best, more
stably than the other protocols. This can be particularly convenient
if one is experiencing constant scaling with a stream.
For you see HTTP
basically needs an atom bomb to scale. Unless there is a really
dramatic interruption or disruption to the feed the HTTP
protocol will
hold on to its current stream rate for dear life.
There is a downside -- if the irresistible force meets the
unmoveable object and the HTTP
protocol
is indeed forced to scale downwards it will NEVER then scale back
up. It will simply hold on to its new stream rate as tightly
as it held on to the previous one. Nature of the beast.
Assigned
Connection Speeds
And then there are assigned "connection speeds."
No, these
programs don't actually reach out and monkey with your modem connection
speed. But they are quite good at mimicking the performance one
would get if one WAS hooked up to a particular modem speed. And this
parameter can also be manipulated to prevent scaling.
Real
Player
frequently activates upward scaling when it thinks that it's got a
connection speed that's too good for its current stream rate. When
that happens Real
Player
will move up to the next stream rate,
--- or will TRY to. Many's the time in the old days, when I
used to have a 56K connection, that I'd be cruising along at 32.1K
and suddenly I'd hear scaling breaks in the sound as the Real
Player tried
repeatedly and unsuccessfully to move up to the 44.1K level.
But in reality the rule of thumb is that the fastest audio stream
rate that is sustainable for ANY speed connection is usually equal
to somewhere between two thirds and three quarters of the connection's
rated speed. For example, in the case of a good 56K connection,
a stream rate equal to between two thirds and three quarters of the
56K speed will equal somewhere between 37K and 42K approximately,
which places the 44.1K rate firmly out of Real
Player's
reach.
But try telling that to Real
Player
and you will not go very far; therefore you have to lie to it.
You do so as follows: Open up the View
Preferences
window and go to Connections. Real
Player
offers two adjustable parameters, the Maximum
Bandwidth
speed and the Normal
Bandwidth
speed. In my experience, you're always better off if you maintain
an identical speed for both parameters.
Now set both parameters for a speed no more than 50% higher than the
stream rate at which you desire the Real
Player
to stabilize.
For example, for years KBYU used a very poor 20K Stereo Real
Player
feed. Its saving grace was that scaled below its wretched 20K
rate was an excellent 16.2K Mono feed.
Solution: Set
the Normal
and Maximum
Bandwidth
rates to 19.2K. This has the effect of tricking Real
Player
into believing that it will be unable to stream anything much over
16K. Usually what happens is that after a minute or two the player
will settle on the 16.2K stream as being the fastest available to
it, considering its purported 19.2K connect speed. And once there,
it will stream solid as a rock.
This principle applies no matter what your connection speed. For
example, if you have a Dual
ISDN
line that's experiencing some difficulties, and you know that you
will not be able to stream a scaled G2
feed rate of 64.7K which a given station is offering you, but you
know that the 44.1K rate just underneath that on this station's scaling
ladder will stream fine, all you do is set your Preferences
for 56K Modem
and sit back and enjoy.
Conversely if you're dealing with a non-scaled feed, which you are
confident your connection can handle, simply set the Speed
Preference
at maximum, 10mpbs
LAN,
and enjoy. Real
Player,
in this instance, has nowhere to go since there is only one speed
available from the stream. Consequently it will stream the unscaled
feed with the greatest efficiency, and load it in the most expeditious
manner possible.
And then, of course, you come across those feeds which sometimes suddenly
refuse to stream at their maximum rate. This can happen occasionally
even with Broadband
connections. It is my belief that most such occurences are NOT
the result of network congestion but more likely the result of overload
on the transmitting server. I have come to that conclusion based
on the fact that most of the time when I experience this problem it
is confined only to one isolated stream.
Solution? Simply ratchet down your connection speed in the preferences
until one achieves a stable stream rate.
REMEMBER
THAT YOU MUST MAKE SUCH ADJUSTMENTS BEFORE LOADING UP A STREAM
AND NOT WHILE RECEIVING A STREAM, AS SUCH ADJUSTMENTS DO NOT TAKE
EFFECT WHILE IN THE MIDST OF STREAMING.
In other words, you have to play a game of start and stop. For example,
if WUOT, which streams at a maximum rate of 176.4K, is exhibiting
this problem, hit the stop
button, adjust the speed to avoid the 176.4K rate, which would be
Dual
ISDN,
and hit the play
button. If you get a stable stream rate of 96.5K you've succeeded
in your task. If you do not, move the speed down to 56K Modem,
and try again. If you get a stable stream rate of 44.1K you've succeeded
in your task. If you do not, move the speed down to 33.6K
Modem
and try again, etc., etc.
The annoying, in fact, downright galling, fact here is that this was
precisely the sort of situation which scaling was supposed to remedy. In
practice, however, any loaded stream where the Real
Player has activated scaling normally winds up with a more
UNSTABLE stream load experience rather than a more STABLE stream load
experience. In our opinion, the entire scaling concept, particularly
its non-defeatability on the part of the surfer, is a fundamentally
flawed one, and a feature AROUND which one needs to work rather than
a feature which operates in the interest of the surfer's greater CONVENIENCE. We
regret that Windows Media Player Version 9
has chosen to add this concept to their player now and we think this
technology has laid a real egg with this one.
But for all its technological wrong-headedness, there is no doubt
that Real
Player,
the player which first introduced reasonable sound for live streams,
opened the door for classical music buffs to enjoy great music in
good sound the world over. It represents a paradigm shift in
the enjoyment of music in one's home, and for that reason if for no
other we must gratefully acknowledge Real
Player's
ground-breaking technological contribution.
At this point, it should also be noted that the latest incarnations
of Windows Media Player, Version 9 and
later, use some slightly different connection speed options from Real
Player. Windows Media Player lists
the following connection speed options, from fastest to slowest: LAN
(10 Mbps), T1 (1.5 Mbps), 768k, 384k, 256k, 128k, 64k, 56k, 33.6k,
and 28.8k. Real Player lists the following
connection speed options, from fastest to slowest: 10 Mpbs LAN, T1/LAN,
512k, 384k, 256k, 112k, 56k, 33.6k, 28.8k, 19.2k, and 14.4k.
Apparently these differences are caused by considerable confusion
in the industry over how to characterize the typical download speeds
at these various connection speed configurations. For example, if
you set Windows Media Player 9 to any
of these connection speeds, take a look at the numbers given in the
View Statistics menu once the stream
starts to play. The View Statistics window
tells you at what speed you have configured your player, i.e., it
tells you whether you're configured for ISDN or for T1 or whatever.
But it doesn't tell you in terms of their names (ISDN, T1, etc.).
Instead it tells you what connection SPEED is currently configured
in your Tools Options Performance menu,
as described in my paragraph above. And here is the really weird part:
the speed given for each type connection in the View
Statistics menu DOES NOT MATCH the speed given in the Tools
Options Performance menu. For example, when one chooses a 64k
ISDN connection in the Tools Options Performance
menu that same connection shows up as a 58k connection in the View
Statistics window. And the connection type listed as a 128k
Dual ISDN connection in the Tools Options Performance
menu shows up as a 115.2k connection speed in the View
Statistics window!
I do not know why there appears to be this confusion but, as you can
see, either there is confusion over terminology here, even within
the Version 9 Windows Media Player itself,
or Windows Media Player and Real
Player are talking about entirely different types of connections,
or there is a serious lack of standardization over how to characterize
Internet connections. For example, perhaps calling a Dual ISDN connection
a 128k connection is because that is the fastest that a Dual ISDN
is physically capable of operating. And calling it a 115.2k connection
is perhaps because that is the average speed of a Dual ISDN connection,
while calling it a 112k connection may be due to the fact that that
is the minimum guaranteed speed of that kind of connection under ideal
Internet circumstances. But whatever the origin of this bewildering
variety of nomenclatures, the fact remains that the most important
operating principle for you, the average listener, is to match whatever
speed option in the player's menu is the closest SLOWER speed to what
you believe your connection speed to be. For example, if you have
a 700k DSL connection then you need to adjust your Real
Player maximum connection speed and normal connection speed
to 512k and your Windows Media Player
connection speed to 384k. If you have a 5000k Cable Modem line, then
adjust your Real Player maximum connection
speed and normal connection speed to T1/LAN and your
Windows Media Player connection speed to T1 (1.5 Mbps), and
so forth and so on. Good luck!
The
Latest Versions of Real Player - Should you upgrade to Real One?
At this point, I think we need to add a few words of clarification
concerning the newest version of Real Player,
called Real One. It is supposed to succeed
and update Version 8. However, for our purposes, this new version
of Real Player offers very little. In
fact, we have concluded that it is actually a step backward. There
is no presentation on the main window, either at the bottom or anywhere
else, for that matter, to tell you whether you are experiencing reception
problems. About the only way you can gather that sort of information
is in the Tools Playback Statistics window,
and this information is not complete. As many of you may have noticed,
momentary interruptions in a stream, which can result in a momentary
burbling effect in the audio, are generally indicated ONLY by the
reception dot on the main window of Version 8; it does NOT usually
show up in the Statistics window. And
yet Real One, in its wisdom, has chosen
to eliminate that presentation on the main window. Very unhelpful
decision.
In addition, some of you may have noticed that there are some Real
Player scaled streams (for an explanation of scaling, see above)
we list which have a high fidelity mono stream which runs at 16.2k
and run a LOW-fidelity stereo stream just above that at 20k. Bartok
Radio is an example of such a stream. With Version 8, the procedure
for accessing the higher fidelity, lower speed 16.2k stream is simplicity
itself: simply set your maximum bandwidth to 19.2k. But Real
One, again in its wisdom, has ELIMINATED the 19.2k connection
option, which means that anyone who doesn't want to listen to a low-fi
20k stereo feed, or who has a connection slower than 28.8k, is out
of luck: they can't access the high-fidelity 16.2k and 16.5k streams
with which many Real Player streams are
equipped. How a design team, which continues to offer the 16.5k stream
as a standard part of the Real Player scaling
package, could decide to remove the very means by which one accesses
and listens to that option is beyond me.
The bottom line: Real One is plagued
with terrible design decisions, and, in addition, does not even offer
the capability of playing an audio format/codec that is not available
in Version 8. Therefore, for these and many other reasons, we continue
to recommend that OperaCast visitors use Real
Player Version 8, and all Real Player
instructions on this site use Version 8 as the standard.
And
what about Real Player 10?
Recently
we have discovered a couple of Real Player
streams that won't load and play unless one upgrades to Real
Player 10. We are still experimenting with this new version
- will it allow one to play the older Real Player
6 streams that still exist (although in ever decreasing numbers)?
or to connect to slow 19.2k mono streams, or will it (mis)behave more
like RealOne?
WINAMP
& MP3 STREAMS
We
have recently received a number of queries from visitors who have
had difficulty playing MP3 streams on
either Real Player or Windows
Media Player. In our experience, MP3
streams WILL NOT play properly (or in some cases at all) with
these players. Download and use WINAMP
to play MP3 streams. Real
Player has a tendency to "hijack" file associations
from other programs. If after downloading WINAMP,
an MP3 stream still tries to play in
Real Player, simply copy the stream's
URL from the error message that Real Player
generates, paste it into the Location
box in WINAMP and click on the Play
button in WINAMP.
WINAMP
is unique among audio players, to our knowledge, in that it offers
listeners a choice of more than one audio driver. The two drivers
which are standard with every version of Winamp are the waveOut
driver and the DirectSound driver.
The default configuration utilizes the waveOut
driver. For most stations the waveOut
option is preferred but certain stations on certain computers sound
better with the DirectSound driver. If
you would like to switch your WINAMP
audio driver, or have been advised to do so, the operation is as follows
(the exact menus vary slightly from version to version; we are using
WINAMP Version 5.09 as our standard):
Right-click
anywhere in a free area within the WINAMP
interface (but not in an area where there are buttons or displays).
Select Options. Select Preferences.
Select Plugins Output. You will see a
list of the various WINAMP drivers available
to you. Different version have different lists, but all versions have
at least the waveOut and DirectSound
drivers. Select the DirectSound option.
Click Configure. Click Apply.
Click OK. Click Close.
To
set the driver selection back to its normal waveOut
configuration, right-click any free area within the WINAMP
interface. Select Options. Select Preferences.
Select Plugins Output. Select the waveOut
option. Click Configure. Click Apply.
Click OK. Click Close.
WINAMP
& OGG VORBIS STREAMS
One
of the newer formats to hit the streamways is Ogg
Vorbis. It has no proprietary player of its own. Rather there
are several players out there which can handle its streams. Of them
all we recommend WINAMP Version 5.09.
A
WORD ABOUT IMPROVING SOUND QUALITY (WHICHEVER PLAYER ONE USES)
If one has a Windows computer, then double-click your volume
control, open up Options, open
up Properties, check EVERY ONE of your
volume controls, and click OK. You will then see a display of several
volume controls. Please mute EVERY SINGLE ONE OF THOSE VOLUME CONTROLS
EXCEPT FOR THE WAVE BALANCE AND VOLUME CONTROL SLIDERS. Believe it
or not, this significantly improves the noise picture of your analog
output. Based purely on my own listening tests, I would say there
is about a 30% to 40% improvement by employing this procedure. The
CD Audio and PC Speaker outputs are particularly culpable in this
regard. I'm a Windows user myself, and I regret that I do not know
whether it is possible to make similar adjustments on a Mac computer.
Just remember, if you encounter any problems as you music-surf, that
without this technology we would never have the opportunity to listen
live to Chicago Lyric Opera broadcasts (which, as of the 2007 season,
are now back on the air on WFMT's opera network), to live broadcasts
from Vienna of Janacek's Jenufa with Karita Mattila, and myriad
other operatic offerings which would otherwise be the strict provenance
of opera lovers in a narrow geographical area.
If it is true that the Internet has played its part in transforming
us into a global village, then it is certainly just as true that it
is now also playing its part in bequeathing to us and to our music-loving
children a sparkling new virtual opera house constructed on that global
village's Main Street. For that we must surely be grateful.
