Virtual Concerts 201: A Followup on Matt Stevens’ article

About a month ago, my friend and music collaborator Matt Stevens has posted an article on entitled “10 Things You Need To Know About Gigs on Ustream“. In the article, Matt would summarize the basics of doing your own virtual concert, that is streaming a performance from a club or even from your home via the internet.

This here rticle doesn’t take another view on the topic or contradict Matt’s article – simply because everything Matt, a pioneer in the area under discussion,  says is true. Rather, it goes into more detail with regard to some topics: how to optimize audio quality, use of creative realtime video editing and so on. See it as a “201” on the topic.

Note that I will assume that you’re familiar with what Matt’s article teaches you already, and I also take for granted that you know how to make good-sounding music (sound-quality-wise).

1. Services:

Matt did write specifically about It is, however, worth of note that there are several other similar services around. Two others which I’ve used myself are and All of them share the concept that they allow you to send a video stream to a number of viewers free of charge for you and the viewers.

The differences are more deeply: offers some very powerful options regarding using multiple video stream sources, prepared videos, texts etc., which can be assembled in advance as a storyboard and then cued during the performance. On the downside, it limits bandwidth to 500kbps (see section 2 below for details on that). allows you to do the feed using FME without having to run a web browser at the same time. For more on this, see section 3 below.

I’m sure there’s even more services available than these three. Your best bet is to make up your mind what you need feature-wise, and then check the available service which works best for you.

2. Bandwidth Considerations

Unlike most other things you usually do on the internet, the important feature here is your upstream bandwidth. Typically, for consumer broadband connections, this is much smaller (up to one magnitude) than the downstream bandwidth. In other words, if you have an internet connection that is described as a “2Mbit” connection, your upstream bandwidth may only be around 192 or 256kbps.

Another thing is that ISPs only specify the maximum available bandwidth, and the one available to you may be lower. So the trick is to find out yourself. Here’s how:

First of all, available bandwidth may differ with time of day. Especially if you’re planning to do your stream during a high-traffic time (e.g. early evening, when people come home from work), it makes sense to do your test run under identical conditions – i.e. same time and same weekday.

Then it’s time to find a service that lets you determine the transfer rate. Typically, your ISP may have one you can find on his website. Using an ISP-independent one may make more sense, however: after all, what you’re after is how fast the data gets from your computer to “the internet” (more specifically, the streaming server). One such service which seems to work internationally is

The procedure is also explained in detail on the site, but here’s the basics: first, switch off all programs on your computer (and best all computers on the same internet connection), except for the browser you’re using for the test. Then, start the test. You get one figure called “upstream bandwidth” or similar – this is the one you’re interested in. Note that this may be in kbits per second (kbps) or kbytes per second (kBps). With the simple rule of 1 byte=8 bits, you can translate that easily. Also, figures in mbits or -bytes are possible (here the translation is 1/1024, or roughly 1/1000th).  If not mentioned specifically, we’re talking about kbps bandwidths here.

Now that we know that bandwidth figure, we also know how much we can send over that line. We’ll address that in more detail in the next section, where we’ll talk about customizing your audio and video quality using Flash Media Encoder.

3. Using Flash Media Encoder with UStream (or other services)

The technology used by all of these streaming sites is Adobe Flash Media. This basically works with the service having a server, to which you connect with some encoder, and the server sends the data to your viewers who use a simple plugin in their browsers to watch it.

The basic approach for you to encode is to use the browser-based encoder supplied by the streaming site (which may require you to install additional plugins for your browser). Typically, these encoders only allow you a very basic access to audio and video quality and bandwidth settings. As we musicians usually (and in contrast to most other applications) put a higher emphasis on audio than on video, this is a problem. The solution: use Adobe’s free Flash Media Encoder (FME for short) program, availabe for download from Adobe.

The first thing you should do is inform FME where to stream to [1]  – usually, this is accomplished by downloading a XML file from the streaming service. Open that in FME, and you can concentrate on your individual settings. Best you also choose your camera (video source, [2]) and soundcard input (audio source, [3]) right now.

The important settings here are the audio and video bandwidth, which you can set independently. We’ll start with the audio bandwidth considerations: typically as a musician you’ll be using a stereo signal, and you’ll also want a sampling rate of 44.1kHz (“CD quality”). Now choose “MP3” as the format, and finally set the bandwidth [4]. With the common knowledge that 192kbps typically also works for higher-quality applications, I’d suggest 128, 160 or a maximum of 192kbps, depending on your requirements and available bandwidth.

We’ve already found out our available bandwidth in section 2. Now the audio+video bandwidth must be below your available bandwidth. How much below? Simply for stabilty considerations, I try to keep that in the 15% range of the total bandwidth.

That way, you can set the bandwidth for video: Let’s say your measurement in section 2 resulted in 700kbps.  Subtract 15% of that as a limit for your net bandwidth, then you got around 600kbps remaining. For your high-quality audio, you already chose 192kbps above, then the remaining bandwidth for video is 400kbps – simply set that in FME [5].

It also makes sense to have a look at the resolution and framerate settings here: as a simple rule, don’t set the resolution higher than the resolution delievered by your camera. If it’s a simple camera which only gives you 320×240 pixels, then set that to the same, but nothing higher. Generally, in my experience, the 320×240 works well in most cases, and add a framerate of 15fps, which with the 400kbps we’ve determined above will give you quite good video without any visible compression artifacts.

4. A Word on Audio

Getting your audio stream into the proper shape for transmission can be considered harder than for a gig in a live venue, and there’s two reasons for that. First, the listening environment for each audience member is different, so you’ll need to consider people listening on anything from a cheap set of laptop speakers playing on the side to a high-quality home stereo system in an acoustically treated environment. The second reason is that you’ll be working with compressed audio (MP3). Now lots of different tests have shown that especially higher-bandwidth MP3 streams (see section 3 for bandwidth recommendations) can sound pretty good, but most of these tests address properly treated audio material. Why is that important? The compression methods in use are very sensitive to “bad” audio, most specifically digital clipping and a bad signal to noise ratio – those effects come out much more pronounced on a MP3 stream than they would on a CD or in a live venue.

Now there’s a solution for both of these problems, and it’s called audio mastering. As you will most probably not have a mastering engineer at your disposal, here’s some things you can do.

  1. If your signal stream is created in a computer (e.g. because you’re using a DAW like Ableton Live for music-making), then at best keep it digital – that is, use digital S/PDIF or AES/EBU interface to go from the music-making computer to your streaming computer. This may require you to get audio interfaces that are capable of this – most consumer-style built-in audio cards don’t offer digital input.
  2. At any point where you’re going analogue to digital (e.g. when sending an anlogue signal, like from a micpre, into the stream computer’s analogue ins), make sure you don’t clip the converters. This can be accomplished by using an analogue limiter before the converter, or by adhering to proper level practices (i.e. ensure during soundcheck that it won’t happen). Of course, the latter one may lead to an overtly large headroom, and thus a bad signal to noise ratio (SNR).
  3. Use a good-quality compressor and EQ in your streaming signal. If you’re using a computer to make your music, there’s a lot of free plugins to accomplish that in fine quality, or your DAW may already come with such solutions.
  4. Also a standard for any gig, but: remember to mute unused input channels.

I personally use a TC Electronic Finalizer in my chain between the music computer and the streaming computer. This may seem overkill (and I do this basically because otherwise the thing is just collecting dust), but going in that general direction can really help – e.g. the much cheaper TC Triple-C Stereo can also be very well used for this.

5. Video Considerations

First of all, there’s also quality considerations, which may seem trivial to anyone experienced in the field, but a musician may (like me) never have had to do with such things:

Light – if playing during the daytime, the lighting situatio might change radically, even during a 40-minute performance. So what starts during soundcheck with a well-lighted picture can very well turn into some “dark grey on black” imagery during the performance. Using additional artifical lighting can help a lot here, as can thinking about this before the session, especially when your performance time is in the late afternoon or early morning. As with the bandwidth measurements: do your test runs during the time in question for your session if possible!

Image Section – Fortunately, this is somewhat similar to a live gig, in fact even simpler. Unless you’re using multiple cameras, you only have one POV to consider, and arrange yourself and your gear in a way so it works fine for that POV.  Still, remember you may take different positions during your performance: getting a detail view of your shapely posterior may be in the interest of your audience, but not necessarily in yours.

Advanced Stuff – working with multiple cameras, video effects etc. – that’s also possible. One lowcost solution for that is the free program Manycam (with Camtwist being a Mac-only alternative I have no experience with). Manycam allows you to switch between different cameras, include prerecorded videos and put in a multitude of video effects. Using this is the point where I’d recommend working together with someone who will be responsible for the video and operates it. Luckily, Manycam is easy on the computer load and can run on the same computer you’re also using for streaming (which is good, because it needs to). Just see an example of an excerpt from a sessions live-processed in Manycam above. Still wanting to go further? Of course, Adobe’s Premiere software will do about anything you’d like here (and works very fine because it can stream directly to the server), but it comes at a price…

6. And finally…

Now you know some of the technical details for making a streaming concert work. Note, however, that more important than all of this is that you make music that matters. And for that most challenging aspect, I leave you completely alone…

Best of luck!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s