Vocal Record Collectors' Society Upcoming Monthly Program


Internet Radio for Techies

Make a Donation to Support OperaCast

Help support OperaCast

Buy CDs, DVDs, Books and lots more...

(Find out more about each station and bandwidth requirements to receive streaming audio)
(A Guide to Regularly Scheduled Opera on the Net)

. . . List of Reviews of Recordings of 85 Operas


Downlaod Real Player - FREE

(we recommend Version 8 - you can download it here)

Download Windows Media Player

Orban aacPlus plugin for
Windows Media Player

WINAMP (MP3 Player)
(Preferred Version 5.09 may be downloaded here)

Download Quicktime
Download Chaincast






Casanova 2010 Master Classes!
New Edition Available



    Of the six audio applications, Winamp and Media Player are relatively straightforward in operation.  Just click on the streaming link on the relevant site and the players will attempt to load the stream.  If it's available the players will load it and play it; it's as simple as that.

    Two properties of Windows Media Player can come in handy on occasion.

    Windows Media Player can also play Real Player plain (non- or pre-G2) codecs.  I find this convenient if I wish to conserve my computer resources.

    The second one is a very user-friendly option which can come in handy with slower-speed connections.

    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 


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


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


     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, TCPReal 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 ConnectionsReal 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.


    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?


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.


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.


    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.



We welcome any and all comments and suggestions. Contact us at admin@operacast.com.

This page last revised 07/22/2013 6:30 PM EDT

Copyright ©2000 - 2018 G . S. Riggs & E. Hubbell