Metadata Manipulation with Steve Johnston

How do you push meaningful metadata to 34 FM and HD transmitter sites across a large state radio network? Gathering data input from statewide news bureaus, web sites, and live programs? Then add in EAS data for each coverage area? Steve Johnston joins us to talk about how Wisconsin Public Radio is doing all this and more.

Watch the Video!

Read the Transcript!

Kirk Harnack: This Week in Radio Tech, Episode 257, is brought to you by Axia Audio and the Axia Radius Network IP Audio Console. Throw your budget a curve and meet Radius. By the Telos Hx1 and Hx2 telephone hybrids, the most advanced hybrids ever developed for use with analog phone lines. And by Lawo and the crystalCLEAR virtual radio console. CrystalCLEAR is the radio console with the multi-touch touch screen interface.

How do you push meaningful metadata to 34 FM and HD transmitter sites across a large state radio network? Gathering data input from statewide news bureaus, websites, and live programs too? Then add in EAS data for each coverage area. Well, Steve Johnston joins us to talk about how Wisconsin Public Radio is doing all this and more.

Hey, welcome in to This Week in Radio Tech. I'm Kirk Harnack, your host. So glad to be here. It's our 257th episode. TWiRT is the show where we talk about radio technology, broadcasting, audio, RF, everything from the microphone to the light bulb at the top of the tower and streaming and everything in between.

Glad you've joined us for this show, if you would stay tuned for the whole show and tell your friends about This Week in Radio Tech.

And by the way, if you're tuning in to the show live, thank you, but you can also subscribe to the show. Use your favorite pod-catching software, whatever that may be, and subscribe to This Week in Radio Tech. There are instructions on the website. You can catch those instructions at GFQNetwork.com. Just click on any of our episodes and you'll see the directions for subscribing. You can do the same thing at ThisWeekinRadioTech.com.

Our show is brought to you by the folks at Axia, also the folks at Telos, and the folks at Lawo. We'll be telling you more about those guys as we go through the show today.

Hey, let's bring in from Manhattan, a beautiful day in New York City, it's the best-dressed engineer in radio, Chris Tobin. And once again, you did not disappoint.

Chris Tobin: Hello Kirk.

Kirk: Hey, Chris, you did not disappoint. Wearing a jacket today.

Chris: Yes, well, I have to. Actually, I'm going to a gala, a volunteer gala, this evening across town, for First Book. They're folks who get books for communities and schools that don't have access to a lot of literature. Folks like Scribner and Penguin Books. Disney helped that along. So I'm off to that this evening, right after our broadcast, actually. And yes, I'm in an undisclosed public location. It's somewhere in Manhattan. There are plenty of squirrels, pigeons, and some other interesting livestock running around the place, but we're good.

Kirk: Are there any transmitters? Sometimes you come to us from a place where there's transmitters.

Chris: Sadly, the only transmitters is in my bag, for a ham radio, and I think there's two Parks Department law enforcement folks talking on their two-way radios, so that's the transmitters I have at the moment.

Kirk: Are they talking about you?

Chris: Not yet, but they are looking in my direction, so we'll see how things go.

Kirk: Just tell them you're with a network. Maybe that'll work.

Chris: Yeah.

Kirk: Chris Tobin, always here to add great commentary. He's my right-hand man in doing this show, and he's been here for just about every one of the 257 episodes.

All right. We've got a guest this week. Let's go ahead and bring him on in. Steve Johnston, the Director of Engineering and Operations at Wisconsin Public Radio. Hey Steve, how are you? Glad you're here.

Steve Johnston: How's it going? I'm sure glad to be here, thanks.

Kirk: Glad you're here. Steve, I don't know if you and I ever met before this past NAB. Or actually, I should say, the Public Radio Engineering Conference. Had we met before that?

Steve: Oh, probably just in passing.

Kirk: Maybe so. Maybe at the Telos booth or something. Well, I was very flattered to be part of the Public Radio Engineering Conference. They asked me to be on a panel about IP audio, so I was on this panel with some other luminaries in the IP audio world. While I was waiting to be on that panel, I got to sit in for a couple of sessions at the Public Radio Engineering Conference, and one of those sessions was a presentation delivered by our guest, Steve Johnston. I was so impressed with this presentation I thought we've got to have Steve on the show, and explain this maybe all over again. Or at least have a conversation about the technology, Steve, that you were describing here. I don't know, but Chris Tobin, were you in the room during Steve's presentation?

Chris: I did not make it to the PREC conference, no.

Kirk: Okay, okay.

Chris: I [inaudible 00:04:28] his paper, no.

Kirk: Got you. Okay. Well then you'll learn something and I'll get a refresher on what Steve had talked about. But tell you what. Before we get started with that, and I want you to stay tuned for what Steve has to talk about.

It's pretty amazing what Steve did to get some different vendors to come together and create a solution for disseminating emergency and perhaps other information across the vast network they have of 34 radio stations and 3 networks covering the state of Wisconsin.

It's really amazing what Steve put together, and I guess he had some help. We're going to find out about that, coming up in just a few minutes.

Our show, This Week in Radio Tech, is brought to you in part by my friends at Axia, and specifically, brought to you by the little console that could. It's the Axia Radius. This is an 8-fader console, it is expandable if you want to, but generally it's sold as an 8-fader console. And in fact, listening to this show right now, our audio is going through an Axia Radius console. That console is actually automatically producing a mix-minus audio feed for each of the participants.

I'm getting a custom feed right out of this console. So is Chris Tobin, and so is Steve Johnston. We're all hearing the other people plus the show, if Andrew Zarian wants to come into the show or play some audio, we'll hear that, but we don't hear ourselves back through Skype, because that would be really confusing. That would be this terrible, long echo and it would just be awful. That's just one of the things that the Axia Radius console can do.

In fact, all the Axia consoles create a mix-minus for every single channel, every channel that can have a backfeed. Now, you wouldn't send a mix-minus back to a computer or to a CD player, but you would send a backfeed to an in-studio guest, for example.

You would send that guest probably a mix of everything, but you could give an individual IFB, that is, you could interrupt that channel to tell the guest something. You can have hybrids, codecs, like we're using codecs here for Skype. So each participant gets their own backfeed, their own mix-minus feed.

It's very flexible. If Andrew Zarian, who's producing this show, wanted to move my channel, my audio, to a different fader, guess what? The mix-minus would follow automatically. It's just amazing the way this works in all Axia consoles. And the little 8-fader Radius console makes it affordable and very, very convenient.

Now, speaking of Radius consoles, I've got a couple of these consoles myself at our radio stations in American Samoa. I installed these things almost three years ago now, and they are doing just great. They're on the air on WVUV, the farthest-west W call letters on the planet. Also KKHJ, our little 93 KHJ station that we have in American Samoa. And we also have the little brother -- little sister? -- of the Radius console, the RAQ, the R-A-Q, the RAQ console, in our newsroom in American Samoa.

And of all things, just yesterday here in Nashville where I live, I was very blessed to take a tour of the RFD TV facilities here in Nashville. They built some new facilities where GAC, Great American Country, used to be on Music Row here in Nashville. And I'm walking through this facility, getting the tour, and we walk into the studios that are used by RURAL RADIO, that's a 24-hour radio network that feeds SiriusXM satellite network, and bam. Right there in the master control console for RURAL RADIO is an Axia Radius console. I had no idea that they had it. And it's just a beautiful installation. In the main room, they have an Axia Element console.

So great consoles, easy to hook up, audio over IP with Livewire. And you add an Xnode to it and you've got Livewire+, which means it's compatible with RAVENNA and with AES67.

If you're in the U.S., you may want to check this out through Broadcasters General Store. They are the dealer for Axia in the U.S. And most every country in the world has an Axia dealer. So check out the website. You can go to axiaaudio.com and that'll redirect you to the TelosAlliance.com website, and you can go to Axia from there. Check out the little Radius console. It's very affordable, easy peasy to install and make it work great. Thanks, Axia, for sponsoring This Week in Radio Tech.

All right. Let's jump in now. Steve Johnston. Steve, you did a presentation at the PREC about consolidating information from various sources and then disseminating it. Walk me through what you're talking about here.

Steve: Well, over the past three years or so, I guess, Wisconsin Public Radio has really expanded our efforts to use RDS, the data display, on radios as well as the program-associated data, sometimes called PSD, for HD radio displays. We've been using that for both static information like call letters and slogans and things like that, as well as using it for dynamic information about the program segment that's playing right at that time. That can be challenging with our kind of formats. Public radio has a wide variety of program sources and shows coming in, so that's challenging.

But it came together pretty well, and so once that was working, I started to think what's the next step? We had to disseminate this, first to our local stations here around the headquarters in Madison to test it, and then we just deployed it to all the stations around the state. But what was next in terms of the information?

Something that I'd heard for years, I bet 20 years I've been hearing in the business, that we could send emergency alerts out by RDS and later by HD PAD data. But I wasn't aware of anyone who'd actually ever done it. We all said it, and every conference there was a talk about it, but nobody had actually done it. And I thought, well, I could see if this is possible.

Kirk: Okay. Okay. Now let me see if I understand a couple of things. Most radio stations, especially commercial stations, they use RDS for, as you said, call letters, slogan, maybe title and artist if you get fancy and you've got some mechanism to get dynamic title and artist information there. Then, of course, there's HD radio. You've got 34 stations. Are all or most of them transmitting HD as well?

Steve: I think roughly two thirds now have been converted to run HD, and that's both AM and FM stations. We've got a few AMs, mostly FMs. We're taking it to another level even just setting aside the emergency alert information. We provide information on who's the host of the talk show, for example, that's on the air, and the name of the guest and what is the topic of the show. We repurpose that same information for our website, and also later it goes into the archive, so that you have something you can search on.

The music programming is actually some of the hardest. The network providers of classical music and other formats, jazz and things that are popular on public radio, do not seem too inclined to provide these data streams. So we end up having to write a little software to steal it off their websites and get it into the system that way.

Our own shows that are hand-crafted from a host sitting at a console with CD players, those are the hardest of all, because they're doing it on the fly, it's a human involved. We're just now on the cutting point to cut over to a system where that, based on the music log, they'll be able to say "I have started this piece" and let the data flow at the same time.

Kirk: Let me, if I could, back up just a second. Then we'll recover to what you're talking about now, because I've definitely got some questions. Some of the viewers and listeners of the podcast are not necessarily full-time into broadcast, and I know it's very possible to be in radio and not really be aware of RDS, or as we call it in the U.S., RBDS. And this is the slow-speed text that can go along with your radio programming and it's not too expensive or difficult to transmit static text, like your call letters. It's a bit more involved to transmit dynamic text, like title and artist, and as you mentioned, program host or other programming information.

So we have RDS that's part of FM broadcasting, and then we have the PAD, or as you said, the PSD data, that can go along with HD radio, and HD radio, oftentimes you've got a radio that has a much more sophisticated display, it might be color, and it's got more room for text.

There's a lot of specifics that I don't know about that, how much text room that you have, how often you can update this, when you can put in graphics or not. But I want to point out that for decades and decades and I guess really for a century, radio broadcasters have been concerned with audio. There's been no infrastructure for this data, this program-associated data, PAD.

So we've had this little side chain going, or built them where we needed them, often started out with being serial data coming out of an automation system and then going directly into an RDS encoder. And then we got some middleware involved. We got some software involved that would massage this data, if you will, that it would put it into maybe a better-looking format for the RDS, maybe at the same time give you another output for HD radio, for the PSD there. This is an area that, as an engineer, I've been in the business for, what, 35 years now, and I just recently had my first experience in putting this kind of data on our web stream. I have yet to go put dynamic data on our RDS, on my radio stations.

I guess we're doing it in Samoa, we have been doing that for a few years, at our stations in Greenville. So this is kind of new to a lot of folks, and it's almost the kind of project that you get into it, you do it once, especially you program your call letters, your format, and that kind of stuff into your RDS encoder, and then you forget about it.

Yet, Steve, you've taken this on to be a very active thing, and I'll bet it requires some consistent updating and input as you take on new programs, and here I am just yapping too much. Why don't I let you describe a bit more about creating infrastructure that hadn't been there before, to grab this data. Go ahead.

Steve: Well, you have to think about the inputs and the outputs. Where are you going to get this information? In a lot of cases, you might have it already in an automation system. Like if you're playing music from your automation system, it's bound to be able to send out the title and artist information that you've already entered into the database, the library, if you will. That's the most simple way. And I wish, I couldn't even do that in our operation. We just don't do it that way. We've got a music library of 10,000 CDs and none of that, hardly, has been digitized at all.

But there was a breakthrough that really made this sort of large-scale work possible, and that was maybe twofold. One was widespread interest in doing online work with our website. Once people had to enter information about their shows for that purpose, it wasn't too hard to repurpose it to use it in our program-associated data stream for the radio stations. So that it would be displayed on the radio. So my goal was that people would at least only have to enter it once.

Part of the selling point, I think, was to convince – and admittedly a lot of the folks who were doing this were younger people, more entry-level positions. They were more excited about being on the Web, having their information on the Web, than they were the radio displays. I just kept my mouth shut and let them do their thing, because I could repurpose that data very effectively.

The other piece of the breakthrough that made this really possible was we went to an interconnection around the state of a wide area network IP protocols. Once we did that, to move linear audio around as audio over IP, using point-to-point links, in some cases multicast, and so on. That's a whole other complicated thing that mostly was done by our partner agency here in the state, known as the Educational Communications Board.

Once we had that infrastructure in place for the audio, I realized, well, now I've got a lot of stuff I can do as far as remote access and maintaining computers at a distance over that network, and I can send this data to all the stations.

Kirk: So having all the transmitter sites connected via IP, wow, that opened up incredible possibilities. You did that, obviously, because IP is the technology of the decade or the century.

Steve: Du jour, yeah.

Kirk: Yeah, du many jours. So you can send audio that way, and you said you're sending linear audio to the transmitter sites. But obviously, IP lets you send almost any kind of data.

Steve: That's right.

Kirk: Including this RDS data.

Steve: That's right. Text is just a tiny, tiny little bit of data. It's a drop in this otherwise full stream, and we actually have a TV network that also uses some of the same infrastructure, and their signals are the largest. Their bandwidth occupation is gigantic. This text is nothing at all.

I would emphasize, though, that this idea of interconnection made so many things possible. Now I can do two-way linear links between our bureaus around the state where we have studios and offices in different cities, do those links between studios, back to headquarters.

We can have talk show guests in another city and those links are up 24 hours a day. You don't have to establish an ISDN or a connection over the Internet. This is a private wide-area network that we can take advantage of.

It is used, actually, for emergency alerting here in Wisconsin, because the National Weather Service contracts with our partners at ECB to provide a maintenance and interconnection for the National Weather Service transmitter. So we have a big part to play in emergency alerting in this state. We form the backbone of distributing emergency alerts from both the state Emergency Management and National Weather Service. So that's the way that messages get to individual stations for EAS.

Then the problem I faced in this particular little scenario, where I want to put emergency alerts through our PAD system and have it appear on the front of a radio while that person is hearing the alert or shortly thereafter. The key to that, or the breakthrough really was in fact to have this interconnection, to be able to send the data in a timely fashion. Organizing it is a whole other problem.

You mentioned at one point middleware, and this idea of organizing, and we certainly had to embrace that. We have a multi-level organization of that. We have a sorting system, that I tend to call it. It's actually provided by a company called Arctic Palm. That's the one we settled on. It's their Center Stage Live product. There are others, though, that do similar work. And this system, then, takes all these various inputs from entries that have appeared on a website, maybe, entries that were typed by somebody, entries from an automation system, maybe from a satellite-delivered program, and brings all these things together and decides which network it applies to, where's it going, which stations need to get it.

Then on a regional level, we also do some sorting because we have regional shows, just to complicate things, that only appear on a sub-set of our stations.

Kirk: Oh, yeah.

Steve: So they want their data. So it gets very complicated fast, but I knew once we had learned enough with these other messages, emergency alerting wasn't too much further down the road.

One complication, though, is that it's geographically based. The emergency alerts' EAS system, as a matter of fact, is entirely based on geography. And I thought how will I handle that? I said to myself finally, I don't have to, because if I take the emergency alert information from the EAS encoder/decoder, for that particular station and route it through the system, it's automatically the right data for that station and those listeners.

Kirk: I want to find out more about that, but also I want you to take us through the story in just a minute, about how you identified what you needed, what I call the middleware, to do. Then how you worked -- you mentioned Arctic Palm as the vendor, so let's pick on them or praise them, as we go along, and see how that development process worked.

But I want to see if Chris Tobin can swing into the conversation here for a minute. Chris, you know I'm smiling from ear to ear, delighted to hear Steve talk about what you can do with IP. It thrills my heart to know that he's doing audio and data and he can put cameras and phones and backup drives and all kinds of things at transmitter sites, and run that all through the same IP pipe. Isn't that what you're involved in quite a bit?

Chris: Yeah, yeah, that's what I've been talking about for years, actually. Steve and many others have taken advantage of it and realized what you can do. It takes planning, as you pointed out, and it's something that you just take time with and if you do it correctly the first time, you shouldn't have any issues coming back to expand or evolve it. If you don't do it right the first time, yes, you're going to spend a lot of time trying to catch up and fix things. That just gets messy after that.

Kirk: From what you've heard so far, Chris, from what Steve's described, and we'll ask Steve, but if you were thinking about a statewide network, private WAN, and distributing some audio, he said that some was unicast and some was multicast, if I understood him right. Chris, what would be some of your questions and concerns about setting up this kind of thing that could be a little complicated, depending on how you wanted to handle it, and what you wanted to disseminate?

Chris: Well, I would ask the question of how was it implementing the wide area network portion? So if you're doing multicasting, I'm assuming using Layer 2 switches or Layer 3 and 2. Then, as you put it, the pipeline around the state, does that have divergent paths, is it set up in such a way that there's a fail-over capability or some type of continuity planning so once you've built out this network and you've got everything going on your [inaudible 00:23:56], you've got your other stations, what was the disaster recovery approach, or I guess built into it?

Kirk: Yeah, okay, all right. So Steve, I want to hear the story about developing the needs of the software and what different things that you're ingesting and how decisions are made. Let's get to that after the next break. So for right now, Steve, give us a little bit of a hardware overview of the network, how you're getting stuff physically into this WAN and then how does it appear out at transmitter sites?

Steve: Well, the idea of reliability in emergencies is vital, just for normal service to the listeners, putting aside any emergency alerting. So that was very important. We have three levels of redundancy on the wide area network, and then we have a fourth level, which doesn't use that network at all.

The different levels are mainly in terms of what we expected from the vendors, as to if they had multiple paths to deliver our data, and if they were able to use the kind of switches and routers that were necessary to create this wide area network. It's not on the Internet, it's all within private circuits.

If we didn't have the resources of an infrastructure of the university system, it would be more difficult and more expensive, no question. But that also means if we're getting a bargain in a sense, you sometimes get what you pay for. So you don't want them to cheap out or not pay any attention to your needs. So that was critical. I wasn't too closely involved with that.

Like I say, our partner agency, the other half of Wisconsin Public Radio, one half being the university system and the other half being a state agency. The other half, just by the historical arrangement, has the primary duty to worry about interconnection. But I certainly know the story.

The redundancy, then, in terms of the hardware, we have encoders provided by a company called Barix, and they've proved pretty reliable and pretty well suited to the challenge. I have other makes and models that I've used for other things, and do have them on the same network. Our primary method is to use these Barix encoders, model 500 and 1000 in some cases. We have a set of them that originate the networks here in Madison at our headquarters.

We have another set of them that picks up a set of the same program lines at the agency's offices in another part of the city. Then we have encoders at two of our bureaus, in Milwaukee and La Crosse, which we had designated long before, as our continuance of operations locations for our two main networks, the news and classical and then the talk network, which is known as the Ideas Network.

So we've got those levels and the receiving devices that are receiving the multicast transmissions of the network. So we've got one device feeding multiple receivers around the state, at our bureaus, at transmitter sites. They are programmed to, automatically if they lose the feed from the main unit here at my place, the headquarters. They fall over to the backup set that's at the other building. And indeed, then, should that go away, then they're programmed to look to the continuance of operations locations.

If the whole network were down, we have silence sensors that detect that situation and will then go over to a backup that is an over-the-air relay using the hidden signals that ride on our HD television transmitters around the state. So we have another delivery mechanism. Now, that would bypass all our regional inserts and data and stuff. It would just be the raw programming, the audio programming, but that comes in very handy when the poop is hitting the fan.

Kirk: Yeah. That's really smart, to embed. So you've embedded the stereo program material in the statewide HD public television network. Is that what I heard you say?

Steve: That's right. They have their version of multicast channels that allow you then to have, I suppose, second language programming and things like that. You can make those so that they're not tunable on an ordinary receiver. You can have them, in a sense, private. And that's the way these are. It works out pretty handy as a way.

Now, there's still things that could totally take you down, no question. In that case, I've got plans, which are more manual in nature, to rebuild the network using interconnections of a more primitive sort, I guess.

Kirk: Okay. Hey, if you're tuning in, you're watching This Week in Radio Tech. It's our 257th episode. Steve Johnston, the Director of Engineering and Operations at Wisconsin Public Radio, is our guest. Also with us from a beautiful park in Manhattan, New York, Chris Tobin is along with us for the ride and listening in and chiming in from time to time.

Our show, brought to you in part by the Telos Alliance and the Telos Hx1 and Hx2 telephone hybrids. Now, you've known Telos for 30 years now for telephone hybrids. It's 30 years ago that Steve Church introduced and, actually, it's probably 31 years or so, that we've been selling hybrids, digital telephone hybrids.

They connect to an analog POTS phone line, most of the models do, and digitize that audio and then, using DSP technology, really do a fabulous job of separating the send and the receive audio, and then using, now, Omnia audio processing, really processes that caller audio so that it's very listenable, very consistent from caller to caller.

The levels are consistent, the EQ sounds consistent from caller to caller. And the send audio, from your microphone, your radio station, to the caller is also processed so that it sounds good, and it's less likely to feed back in any kind of an open mic, open speaker situation.

The Hx1 and Hx2 hybrids represent real workhorses. They're like fifth generation, now, of the hybrid technology that goes inside these. The Hx1 and Hx2 have got dip switches that you can set up for any country in the world. They can draw all kinds of things about the POTS line, like the loop current, the ringing cadence, the current with the set on-hook, so to speak, or off-hook. They also have built-in auto-answer, so no longer is auto-answer on your hybrid an option, it's built in to the Telos Hx1 and Hx2.

Now what's the difference? The Hx1 is a single phone line telephone hybrid, and the Hx2 is a dual-phone line telephone hybrid. Something else cool about the Hx2. If you want to use the Hx2 as your talk show system, maybe a two-line talk show system, the Hx2 can actually conference its two hybrids together. That way, you can provide just one mix-minus from your audio console into the Hx2.

So let's say you've got an older audio console, or maybe even a very inexpensive mixing console like a Behringer or a Mackie console. You can provide just one mix-minus out of that console and feed both phone lines and the Hx2 will conference the two phone lines together, so the callers hear each other and they hear the talent who is on the air.

Again, they'll auto-answer and auto-hang up, so they're great to use in, say, a television operation, where you need auto-answer hybrids for the remote trucks, the remote reporters to call in on, and get their IFB information right there.

So these are awesome hybrids. You see them in news stations all over the place. You see them in production rooms all over the place. And if you want a hybrid that works and works well... By the way, you can plug it into your business phone system with a POTS adapter on your business phone system, like for a fax line, and they'll work great in that situation, too. Automatic EQ, Omnia processing, the Hx1 and Hx2 are just incredibly good values, and they sound great. In fact, I heard one on the air just yesterday, at RFD-TV.

Check it out. The website is TelosAlliance.com. Click on Telos and click on the hybrids right there. Thanks to Telos for sponsoring This Week in Radio Tech.

All right. Chris Tobin is with us from a park in Manhattan. He looks very comfortable. And also, Steve Johnston is our guest. The Director of Engineering and Operations at Wisconsin Public Radio. So we're talking now, we're going to get to the meat and potatoes about this ability to gather programming information, textual programming information, and assemble that. Figure out what's important and what's not, and then send it out to various transmitter sites all over the state of Wisconsin for encoding into their RDS or HD radio streams, so it appears on listeners' radios. Steve, where would you like to take us next in this story?

Steve: Well, I mentioned that we have these different sources of text data. It might be people entering it manually, might be something coming from an automated system, might be picking it up from a website. One of the coolest examples of that is the Arctic Palm Center Stage software does have the ability to scrape data off of websites, including the National Weather Service. So it's a cinch to have weather information appear on the radio display. That's actually been a feature that many listeners have commented on.

We have a whole department for interacting with the listeners, because they're also often members of Public Radio. And so we get a lot more feedback than might otherwise be the case. I know that was hard for me when I was in commercial radio. I didn't get that much contact with the listeners. So I hear from listeners, and the one thing that I think has stood out is something they were excited about, was seeing the weather forecast appear there.

It's just the bare bones of information, what the high is, what the low is going to be, and the basics of like "mostly cloudy". It has to be short. As you pointed out, the RDS displays are very limited in terms of their number of characters. I think in many cases, the display on the radio is even smaller than what the specification limits are, which is, I think, 64 characters.

The HD has more data bandwidth. It still doesn't take much, but there was not much in RDS. In fact, there is more room to display, but you also have the problem of you want to have a message that is short and concise so that people can see it easily in a glance.

That would be true of this emergency alerting information. I felt it was important to keep it very short. As we'll probably discuss, you're going to get a lot of detail from the EAS messaging, but we really just want the basics. We want to know, for example, it's a tornado warning, and we want to know the time period involved.

I started to go down the road of saying where is the time and location, and then I realized the station's coverage area's already defining the geography. If we're using the right emergency alerting information, only the messages for that coverage area are going to be available. So I didn't need that. Didn't need the time, either. I decided to put the message in rotation in our sorting system for the duration of the alert. So if the tornado warning, taking that example, would last for two hours, that message will be in rotation among our various other slogans and program information and weather forecasts for the next two hours.

Kirk: So help me understand some of the routing here. Let's say you've got, and I hope I get the name of a town right here, Fond Du Lac, Wisconsin. Is that a town that you cover?

Steve: We don't have a station there.

Kirk: Sorry, I picked the one market.

Steve: We've got stations everywhere, unfortunately for me.

Kirk: Okay, so pick a town, and there's an emergency weather, there's a tornado watch for some area. How do you pick that up, where does it go, and how does it get back out the transmitter?

Steve: Certainly. The emergency alert device, the Sage, in our case, in that the encoder/decoder might be located at our bureau in that region. Or it might be at the transmitter site. Either way is okay. I did learn in the process of this work, though, that the Sage devices were not ready to send this data out their Ethernet port. That would have been ideal, if that could be done.

In fact, what I ended up having to do, and a big part of my paper was describing this idea of taking the serial output from the Sage encoder/decoder, and instead, putting it through a tunnel on the Ethernet, so that it sort of provides a virtual serial path across, it could be across the whole state, but we usually don't want it for the emergency alerting. It's going to a fairly nearby point where we had the computers that do the sorting of the program-associated data for that region. So the example that you're describing, a station that serves Fond Du Lac, it has an EAS device that's already programmed to only react to messages for that area, and those messages . . .

Kirk: Right. There's the filter, there's the regional, the coverage area filter right there.

Steve: That's right. And so if you'd accept that point, you can then use the Center Stage software to catch that data, to be the receiver for that transmission, a serial transmission over Ethernet. It seems kind of paradoxical, but the device to do it is a cinch. It's a hundred-dollar project for each one of those, and the devices are readily available online. I'm drawing a blank on the name of the manufacturer of the device we used, Lantastic or something like that.

Kirk: Lantronix.

Steve: Lantronix, that's right.

Kirk: Yeah.

Steve: And I bought them from, I think, Grid Connect was vendor online.

Kirk: By the way, here's a piece of trivia for you. One of the brains behind Lantronix and their products some years ago, doing exactly what you say, serial to Ethernet conversion, that same person is one of the brains behind another product you mentioned, Barix, the Barix codecs that you're using.

Steve: I can see parallels in the thinking there, definitely. In fact, I only needed one device. You would think you would need two of these devices to turn it back into serial at the server end, but in fact you can just run a virtual COM port on that computer, the same computer where the Center Stage software is running, and catch that data. The software doesn't know it isn't a real serial port. It's actually coming in as packets on Ethernet. It works like a charm.

You mentioned something, and I should emphasize this point. So far, this has been a fairly trouble-free system. You'd think it would be breaking every time you didn't look at it, but in fact it has been very stable. It had every chance of going wrong, because if nobody's done this before, that's a strike one. Strike two is it's running in the back room. It's not running in front of your face, so you're going to forget about it in heat of battle. But so far it has not inappropriately crashed or done anything strange. It keeps a log of all its activities so I can check periodically and see what kind of traffic.

But you program, continuing our example of the Fond Du Lac station, you have this already-defined amount of data coming out of the serial port of the Sage ENDEC. It's just the basics of the alert, and it also includes a number, just one, two or three, that defines the severity of it. Is it a real alert, like a threat to property and life, or it just a watch, something might happen, or is it a test. So those are the three levels.

We chose, at least so far, we've chosen only to do real alerts. We don't send anything out on RDS or HD PAD for tests or watches. So we're just doing the alerts. But that filtering occurs easily based on just a single digit, a single byte, one, two, or three there in that message. The Center Stage software then decides: okay, I've caught this data. Which station is it meant for? So it has to know, based on which port it's come in on, what call letter station it's going to be driving it to.

There's multiple modules in the software that are handling different functions, different pieces, and it would vary with your sources of information. The one that's used for EAS work is actually a modified version of their weather module, so it works great.

Then from that point, we talked about that, it goes out as packets on the Ethernet network, this wide area network, and they are addressed to the RDS or the HD exciter device that is the destination. It's just addressed by IP, but it has to be in the right format for that device. We use Inovonics encoders for RDS primarily, and it's a mix of vendors for the HD, whoever had the lowest price, I suppose. The formatting, though, the options are there. So there's a lot of details to configuring it, but once you do it, it's done and it stays done.

Kirk: Now, fill in a blank that I'm having on how this works out. At each transmitter site, I take it you've got some software running there that does scheduling and sorting of the messages coming to that individual site, programming, who's on the air, title and artist information if that's important. Then you've got weather. You may have other announcements that run in rotation on RDS. Is that handled at each transmitter site?

Steve: No, that's generally handled at one of the bureaus that serves that region, so we have these six bureau offices where we have a server room and we have some studios and so on. So there was computer support there, at least mechanically so. That was the place to place it. So I'm envisioning in this example you're providing, the Fond Du Lac station, you have to pull the EAS data back to the bureau over the network, sort it, encode it, send it back to the transmitter site so it can get to the RDS generator or the HD exciter. It wouldn't have to be done that way. It's just the way that we've arranged things.

If we placed a computer at each site, that would work, and you might not need to do the tunneling. You could just do real serial then. However, now we've got a lot more locations, 34 of them in fact, with these computers at, and it might be more of a support problem.

So we decided to make it more centralized, and also buy fewer instances of the software. Some stations are driven in parallel, so that one audio stream and one data stream will serve them both pretty effectively, maybe just a little customization.

So at these bureaus, we're doing our program choices. We have different times of the day a station might do a regional show instead of taking our network. It might periodically, through each hour, it's going to run some underwriting messages, which would be the equivalent of a commercial spot break. Those are generated in this same bureau setting from an automation computer. We use the AudioVAULT system, but of course it could be any of the vendors.

Kirk: Got you. Okay. You had some pictures and graphics in your presentation at PREC, and that helped me to visualize this. But if I recall from that presentation, you've got this Arctic Palm Center Stage software running in the center of everything at your headquarters in Madison, right?

Steve: That's correct.

Kirk: Then you have it running at the different bureaus and those are what I guess are the final decision-makers as to what feeds into each transmitter?

Steve: That's right, for each individual station. So the one at headquarters is deciding what goes out on each network stream of data, just like we decide what audio goes out on that network.

Kirk: Ah, okay.

Steve: And then in the regions, it decides do I just pass that along or are they doing a different show right now? In which case, I can substitute at least the static information about the name of that regional show. I might not have dynamic data. It depends a little bit on the staffing that's available for those shows as to whether there's someone available to do that kind of data entry. It might not always be the case.

So it's sort of this multi-level idea for us. But once you've built that system, I thought there's no reason not to try to run the emergency alerting through it as well. It's a big project, but once you've built it, you start to see other ways you can use it.

Kirk: So you said it's big project. Was it big in terms of the scope of just figuring out what was important and how you wanted to get it done? Big in terms of dollar cost for hardware? I take it that that wasn't so big a cost.

Steve: No, I don't think that was the case at all. Most of our FMs already had RDS generators. I think in some cases, though, they weren't ready to accept a practical way of putting dynamic information in. In other words, you could program them with call signs and frequencies and whatever network of stations they belong to, the usual RDS configuration stuff. But they didn't have a port on them to accept outside data, so those had to be replaced. I think I ended up buying about twelve, maybe a dozen or so Inovonics generators to help standardize our fleet. We had quite a few. I tended to buy them with new transmitter installations just as a matter of course.

The HD system, once you have an HD exciter, there's different generations of those, and so I'm sort of avoiding the usual terminology and just calling it the exciter, the generator of the HD signal. Once you have that, you're ready, already, to do the data. It's just a connection across the network. So that was easy, that was already bought.

In fact, when I first tried this emergency alerting idea, well, actually, as well as all the other stuff, I did it in Madison first, because it's convenient. The server room's down the hall from my office, so it makes it a lot easier to play with it. The remote access is simpler, and in fact the stations, if it's not acting right, I can go out and reset the generator or whatever.

The deployment at two other stations is more complicated and involves the assistance of our field engineering teams, which are mainly from the other agency, so I'm not the boss of them. So it has to be a co-operative effort between these different teams. I was really impressed with how this went over.

I think as we started the discussion, there's a tendency for some people to sort of say, "Well, that's cool, but I don't really care about this text over radio stuff." I didn't encounter any of that at all. People were very into it, and I think the driving force was that it wasn't going to be just static information. It was going to be dynamic information that was actively about the show that was happening at that moment.

I still have some wishes, I suppose. I wish National Public Radio, which of course is the number one provider for public radio stations, I wish they did provide real dynamic information about their shows. They still don't.

Their satellite delivery system, which is known as ContentDepot, does indeed have that capability, but they're not generating the data at the source. They do for their website, so I made the case several times that they might easily automatically repurpose that information.

Sometimes you have to be conscious of writing a short sentence so that it can fit into the available field. Metadata, to go along with audio and video, is increasingly important. We've tried to build archiving capability here so we can reuse content in the years to come and also find old content when we want it.

It's all about the metadata. Having that information that describes this piece of audio or video is very important. And if you've made it for RDS and HD, you've made it for the web, you've made it for the file storage. Once and done.

Kirk: When you archive an audio show, and I think most any engineer listening or watching this podcast would understand how to do that, but how do you also archive the metadata that went out about that show?

Steve: There's two ways, and I tried to do them both. One way is to actually place it in the header of the file. On a wav file, that's not a cinch, because the original linear wav format didn't include any space for metadata. But there is the thing that popular in the broadcast circles 10 years ago called CartChunk?

Kirk: Yeah, CartChunk.

Steve: And that CartChunk idea provides a space for the metadata, and so that information can be stored with the file, and I try to make that happen. It's not always a cinch. It depends a little bit on the software involved as to whether it's ready to write that kind of file.

MP3 files, if you're saving files in a compressed form, I think all the compression algorithms provide space for metadata. For example, if you're on a Windows computer and you do a listing of your audio on your computer, those MP3 files can have additional fields right there in the Windows Explorer that show you the metadata that's in that file. Not so for the WAVE file, because it was from an earlier generation.

Kirk: Yeah, if you're using iTunes or other things, you can "more info" or "get info" on the file and, as least in iTunes and maybe this is common across all, you can see it in a lot of things like that.

Steve: I want to bundle it with the file because then at least you've always got the data, it's not lost. But it's much more powerful if you have it in a database where you can do more elaborate reports and searching. So you've got to have that flow happening.

Most any modern website that has a content management system is working from a back-end database. So I'm thinking in many cases it can be handled using the same tools, the same infrastructure that your website uses for archival purpose.

We've been saving audio files to our website since the mid '90s here at Wisconsin Public Radio, so we've built up quite a collection. Unfortunately, a lot of them were in a highly compressed form, the original few years, because people were on dial-up and stuff like that. So there was no sense to have big files, they couldn't even download them. But that means that that material was saved in a lossy format...

Kirk: Sure.

Steve: ...we converted them to MP3s, but that only makes it worse as far as the sound quality goes.

Kirk: Are these files in RealAudio format, perchance?

Steve: They were indeed, yes.

Kirk: Oh wow.

Steve: So if you go to our website, WPR.org, you can see a rather extensive library that you can search and it's a collection... I'm also working on archiving audio files in linear form for our production purposes, so that we have an archive of both old material, so we're digitizing old material, old shows, as we can. It depends on staffing and resources and those are a little skimpy right at the moment. We had a flurry of activity and some grants that made that more active a couple years past, and material that's at the historical societies, the museums, the libraries.

WHA, our flagship station, started broadcasting in 1917, and so we've got a rich history here. It has been pretty well preserved, so there's a lot of interesting material. Some of the best are tape recordings and acetate disks that we have in storage that are from kids' shows of the '40s and '50s that were meant for students, little kids, grade school kids. They would listen to the radio and shows like "Let's Draw" and "Let's Sing", so that these rural schools could have arts programs by radio. Pretty cool stuff.

Kirk: Wow, stuff from the '40s and... so WHA went on the air in 1917. Wow.

Steve: Yeah. And in the pre-World War I period, it was a radio club, I guess you could say, in the science department. But they had a license. The call sign was 9XM. It was an experimental license. And it was a sort of a hybrid between a broadcaster and a ham station, which was true for hams in that period in general.

The reason that I feel pretty confident to say that it was a matter of broadcasting at that point, is that at noontime the station would come on, initially with Morse code transmission, and later with both Morse code and voice, with farm market reports, weather forecasts, things like that, that people around the state would write down and post in their post office on a bulletin board.

So that was broadcasting by my definition. It's meant for anybody who can hear it, and it's meant to be of use to the public. But early days, a lot of cool stuff going on.

Kirk: Wow. We are, unfortunately, almost out of time. We're going to take a quick break. You are listening or watching This Week in Radio Tech, the weekly podcast where we talk about audio technology as it applies to radio, radio broadcasting, and sometimes we talk about RF and transmitters and towers and things like that. Streaming, websites, and just taking care of audio entertainment and information.

We're talking to Steve Johnston. He is the Director of Engineering and Operations at Wisconsin Public Radio. Chris Tobin is with us. He's been awfully quiet, but he's in a beautiful park and may have even fallen asleep amongst the pigeons there in the...

Chris: I don't think so.

Kirk: No, you haven't fallen asleep? Okay.

Chris: No, the squirrels are running about, people are sitting on the benches, park benches, and enjoying some sandwiches. They are snuggling up with the squirrels. It's been interesting, watching people scream.

Kirk: Has anybody come talk to you yet about your microphone and laptop?

Chris: I did have one park ranger just walk by, look at me, nod his head, and continue on. So I'm okay at the moment.

Steve: It is New York, after all. They've seen it all.

Chris: They have, trust me. I could sit here in an armored suit and nobody would question it.

Kirk: You should put a hat out in front of you and maybe people would toss you money.

Chris: Probably.

Kirk: You are performing.

Chris: I could take a TARDIS and put it out here and people would have fun with it.

Kirk: Hey, we've got to do a quick commercial break, and Chris Tobin and Steve, when we come back, I think we probably ought to end the show on a tip, a tip of the week. Or, if there's something interesting that you did this past week or you're about to do, let us know about that. But we're going to wrap the show up in just a couple of minutes with some information, whatever's titillating that you'd like to pass along to our listeners and viewers.

Our show is brought to you in part by our friends at Lawo. L-A-W-O, pronounced Lavo. They make some audio consoles. They've been famous for making great, big, huge audio consoles. But Lawo has a line of smaller consoles as well that is their radio line, and one of those consoles is the crystalCLEAR console.

We've been talking about that console for about a year here on This Week in Radio Tech, and it has a really interesting concept. First of all, it's like a number of other consoles on the market nowadays, where you have a rack-mount DSP mixing engine. You plug your audio inputs and outputs into that DSP engine. It's available over Ethernet, so you can remote-control it. You can set it up with a browser, and you can also do audio over IP through that Ethernet connection. In this case, with the Lawo system, you can do RAVENNA and AES67.

Well, the crystalCLEAR console has another interesting aspect to it, and that is that you can operate the console, move the faders up and down, hit the buttons, turn channels on and off, do options, do panning, set up mic levels, and that kind of thing, you can do that with a multi-touch touch-screen monitor. So your console is virtual.

It's like put your hands right there on the screen and move the faders up and down. That's how it works. I dreamed about that 20 years ago, and now the technology is here to make that happen. So Lawo takes a multi-touch touch screen monitor with a Windows PC built in to the back of it, and they put an app on there. This app gives you the GUI, the graphical user interface, to be the console. And if you want to move several faders up and down at the same time, push a button, push several buttons at the same time, it's a 10-touch monitor. So you can touch 10... I don't think I can operate 10 fingers at the same time. I can do two or maybe three at the same time. That's what the console lets you do. That's what the Lawo crystalCLEAR lets you do.

Now of course, like any modern console, it's got a couple of program buses, a record bus, a telephone bus. It's got preview for any source. It's got automatic mix-minus going on so it's got backfeeds for feeding remote talent, codecs, and hybrids and so forth. It has a couple of built-in mic pre-amps. If you want more mic pre-amps, you can supply those separately outboard, and plug the resulting audio into the analog inputs on the console. It's got AES inputs and outputs on it. It's got some GPIO for tally lights and speaker or other kind of muting. Any kind of function that you need to do around the studio with a relay you can do that with this console as well. Hey, it's got redundant power supplies available, too.

So check it out if this kind of console is intriguing to you, at Lawo.com, L-A-W-O. They have representation in the United States and Canada, and in many countries around the world, too. Lawo's a big organization with a lot of sales representatives and technical representation all around the world. Lawo, L-A-W-O, Lawo.com. Thank you very much, Lawo, for sponsoring This Week in Radio Tech.

All right, let's see if we can hit up Chris Tobin for some kind of a tip or exciting thing this week. What would you like to leave with us, Chris?

Chris: This week's tip, let me see if I get this right. I was actually helping someone today, a film critic, who's going to be doing some reports for a radio station out of Cannes. He's going to use RecordPad, which is a sound recorder for your iPhone. The reason we went with that was because he was concerned with too many attachments to his MacBook, trying to record interviews and do stuff.

So he's going to use a nice microphone adapter into the iPhone, and then using RecordPad and an FTP site that we've set up, he will record his stuff and then send it to the FTP site from the phone, and then off it goes. I thought it was pretty cool for this gentleman, who's going to be running around. He told me what his days are going to be like. This made the best sense for a work flow and form factor, rather than trying to use a MacBook.

Kirk: I've heard of RecordPad. You can record on it and then when you're finished with the file, it automatically FTPs it where you want to go?

Chris: Well, it gives you a choice. You can set up, I think, to do an automatic, but it gives you a choice of email, FTP, and one other options.

Kirk: Yeah. Would he use an external mic with his iPhone or the mic that's in the iPhone?

Chris: I told him he had two options. When he's at the hotel room, if he can get the microphone, plug it in, and go with the W grade. Use a blanket over his head to keep the room noise down to a minimum. Or if he had no choice, to go with the microphone in the phone, try to hold the phone in such a way that it puts the sound source and the microphone in the phone close to each other, or at least in the right direction. So we did a few tests today and it seemed to work out really well.

Kirk: Nice, nice. Yeah, so that's RecordPad. That's an app that's in the App Store?

Chris: Yes, yes, it's free and I've talked with a couple friends of mine who do freelance reporting and they've used it and it does work very well. There are some limitations, but I guess if you want to get crazy with editing. Just for quick chats, to get interviews going, get them in the can, so to speak, and off to your destination, seemed to be fast and really easy.

Kirk: Cool. All right. Thanks, Chris. RecordPad. Steve, how about you? You have a tip or something you'd like to leave us with before we go?

Steve: I do indeed, I do indeed. I'd like to mention that I have a couple of job openings.

Kirk: Oh wow. We've never had that kind of tip before. Tell us about it.

Steve: I do, I do. I have a position for a broadcast automation specialist. So it's somebody on my team who concentrates on taking care of our computerized automation and playout systems, and that's a really cool job. Also I have a very conventional position opening up shortly for your regular broadcast engineer, what you think of as a guy who can work on system-level stuff as well as down to the component level. And both of these are full-time, serious positions and working with some very cool stuff here at Wisconsin Public Radio.

Kirk: If people are interested in applying for those jobs, is there a website?

Steve: WPR.org, and you can choose the Careers tab and have a look.

Kirk: All right. WPR.org and Careers, and that's where you put your information in for an automation specialist and a run-of-the-mill, spectacular engineer for Wisconsin Public Radio. Cool.

Steve: That wasn't a good way to put it, was it? They're not ordinary.

Kirk: Not ordinary at all. All right. Well, thank you so much, guys, for being with us. Chris Tobin, you do, as we mentioned during the show, you're kind of good at this IP stuff. Folks can reach you... tell you what. You've got a noisy microphone. Let's put the camera onto Chris and I'll tell them where to go… If you send an email to that address, you'll reach that guy right there, who's panning his camera around, and he's about to go raise money for kids' books.

What finer individual could you find on the planet to help you with your broadcast facility? AM, FM, TV, Internet, Chris Tobin's got you covered at support@IPCodecs.com. Chris, thanks for being with us. Appreciate you.

Chris: You're welcome. And by the way, the park is Madison Square Park in Lower Manhattan.

Kirk: Ah, okay. Well, have fun at your gala event.

Chris: Thank you. It's First Book.

Steve: The groupies are coming.

Kirk: The groupies are coming.

Chris: That's why I wait until the conclusion of the show.

Kirk: All right. And Steve, thank you very much for joining us, thanks for taking time out of your day and getting set up a couple days ago with this. I really appreciate it, and thanks for the expertise you passed along.

Steve: It's certainly enjoyable, and thanks for doing a great job with it.

Kirk: All right. And also thanks to Andrew Zarian and to Suncast, co-producers on this episode of This Week in Radio Tech. Be sure you patronize our sponsors, check them out, go to their websites and give them a call and all that, because they do make the show possible. We really couldn't do it without their help. And without the help of the GFQ Network. Check out the other fine podcasts at GFQNetwork.com.

Thanks a lot, everybody. We'll be back next week with another episode of This Week in Radio Tech. Bye bye.

Telos Alliance has led the audio industry’s innovation in Broadcast Audio, Digital Mixing & Mastering, Audio Processors & Compression, Broadcast Mixing Consoles, Audio Interfaces, AoIP & VoIP for over three decades. The Telos Alliance family of products include Telos® Systems, Omnia® Audio, Axia® Audio, Linear Acoustic®, 25-Seven® Systems, Minnetonka™ Audio and Jünger Audio. Covering all ranges of Audio Applications for Radio & Television from Telos Infinity IP Intercom Systems, Jünger Audio AIXpressor Audio Processor, Omnia 11 Radio Processors, Axia Networked Quasar Broadcast Mixing Consoles and Linear Acoustic AMS Audio Quality Loudness Monitoring and 25-Seven TVC-15 Watermark Analyzer & Monitor. Telos Alliance offers audio solutions for any and every Radio, Television, Live Events, Podcast & Live Streaming Studio With Telos Alliance “Broadcast Without Limits.”