Quit Streaming with MP3 Audio

Processing and stream encoding guru Greg Ogonowski shares tips on audio encoding on "This Week in Radio Tech."

Greg Ogonowski says “Stop using MP3 and encode with a modern codec. Save money and sound better, too.” So, what’s wrong with our beloved MP3? And what should Internet streamers be using? And what about the Opus codec?  Learn more from Greg on this episode.

Watch the Video!

Read the Transcript!

Kirk: This Week in Radio Tech, episode 193, is brought to you by the Telos Z/IP One IP audio codec. Remote talent outside broadcast studio transmitter links and convenient remotes with Lucy Live smartphone apps. All possible with the Z/IP One. See it online at telos-sytems.com.

And now our feature presentation. Two words. Stop using MP3, its 2013 for crying out loud. Greg Ogonoski tells us why MP3 is history.

Voice 1: All right, calm down, he says that to everyone.

Voice 2: This calls for immediate discussion.

Bugs Bunny: What's up, Doc?

Voice 3: All your bases belong to us.

Fat Albert: Hey, hey, hey!

Kirk: From his palatial office of important business...

Voice 4: Or in a choice hotel in a distant land...

Kirk: This is Kirk Harnack.

Kirk: Chris Tobin joins me discussing the best practices in audio coding with Greg Ogonowski of Orban. You're dialed in to This Week in Radio Tech.

Hey, welcome back to This Week in Radio Tech. I'm Kirk Harnack, your host. This is our 193rd episode. Glad you're with us. You're in for an hour of fast paced entertainment and information. Our Guest is Greg Ogonowski, and we'll introduce Greg in just a minute. He's been on the show before. He's a great guest and he's full of great information about streaming and coding. He's a real pioneer in using the latest and newest technologies for streaming to get that to work as well as possible. So we'll bring Greg in in just a minute.

Also, our co-host on the show. The best dressed engineer in radio. From Manhattan, New York, Chris Tobin. Hey, welcome in, Chris.

Chris: Hello, Kirk. I'm doing well, it's a good time. And I see you are on location so that's some good times finding out what you're doing.

Kirk: I'm in Cleveland, Ohio. Getting ready for the big snow storm, I suppose. It's . . .

Chris: Oh yes, the cold . . .

Kirk: Yeah, I'm up here at the headquarters of Telos, the world headquarters of the Telos Alliance. Actually, we're having a Christmas party tomorrow night, so that's another reason why, why I'm here.

Chris: Oh. Watch out for those mistletoes.

Kirk: Well, I won't be under any mistletoe for this party. And actually I'm doing something fun tomorrow. There's a store, here in Cleveland. Actually it might be out in Lakewood, called "Play It Again Sam". It's not a bar, and it's not a piano bar. It is a high-fi stereo store where they have a lot of old stuff, Macintosh tuners, and amplifiers and such, and Pioneer and Kenwood stuff from the 80s, and they have a website. It may even be playitagainsam.com. I'm not sure, but if you google "Play It Again Sam" for a stereo store you'll find that.

Well, I'm taking a field trip there tomorrow with Denny Sanders. A lot of you know who Denny Sanders is. He's in the Ohio Broadcasting Hall of Fame, and very, a famous WMMS Disk Jockey and Program Director in Ohio for years, well respected guy. And he's the marketing director for our Omnia division. Also Tim Carol of Linear Acoustic, who's our Chief Technology Officer for Telos Alliance. He's going too. So you have three guys going to go out and look at some old amplifiers and tuners and stuff, and I was looking at the pricing online. All the stuff costs exactly what it did in 1982 plus inflation. So there's no bargains.

Chris: That's great.

Kirk: I won't be buying anything, I don't think.

Chris: Oh gee.

Kirk: Hey, I've been promoting the fact that he's going to be on so here he is. Let's bring in our guest, Greg Ogonowski of Modulation Index and of Orban. So Greg, welcome in.

Greg: Thanks a lot. Welcome everybody, and hello sports fans. So, I've heard about those Telos Christmas parties so I know why you're in there four days early. You've got to get prepared.

Kirk: I think the parties you've heard about were . . .

Greg: Well, you're getting in four days early. What you don't realize is that you're not getting out of there until eight days after.

Kirk: My flight is on a Saturday morning, early. So I won't be doing much inbibing. I'll be getting to bed early. So, Greg you've been on before...

Chris: Let's go on before he starts.

Kirk: Yeah, exactly. Greg, you've been on before to talk about streaming and most particularly the HEAAC and the HEAAC V2 format. And, in fact, the last time you were on I believe you talked a bit about an AES paper you did about some of the really poor quality player implementations for HEAAC V2 and hopefully some of those problems have gone away now.

So this episode, we're going to be talking about streaming and the technologies of where people need to be going with their streaming. And Greg, I know you've got some very strong opinions and thoughts about that. If anyone listens to a stream that Greg Ogonowski is responsible for, you will find a very high quality experience. It will sound great. Of course the process will be great. Greg works with folks at Orban and designs algorithms there. But you'll also find that the implementation of the encoding algorithms is really spot on.

So Greg, what are some of your opening thoughts about what you want to talk about this evening?

Greg: Well, just to give a brief background as to how this all started, anyone who has followed what I have done over the years knows that I am pretty much responsible for a lot of audio processing on radio stations throughout the world. But somewhere back around 2000 I officially went to work for Orban, and one of the things that I told everybody that I wanted to accomplish there was to fix the audio on the Internet.

I had been on a couple of previous world tours. Had been trapped in hotel rooms for time on end and nothing to do except tool around the Internet and I found myself listening to some of the streams.

And it was kind of interesting. I'll never forget this. One of the life-changing, interesting things I heard actually came out of Cleveland. Was one of the oldies FM stations, and, Kirk, you may know what it is. I don't even remember the call letters, but they were one of the early pioneers of MP3 re-streaming. And although the stream held up fairly well on the other side of the planet here, it basically sounded like an AM radio and I kind of thought that, well, there's got to be something that we can do about this.

So when I went to work for Orban, the first order of business was to build an audio processor that could go on a PCI card and take basically a

$6,000 digital audio processor and put it on a PCI card, that obviously the price had to come down. So we put that ball park price about $1,500. And that kicked things off. But that was only the tip of the iceberg because then there was still the codec to be left to deal with.

We had MP3 at the time, we had the dreaded Real Audio, and also the dreaded Windows Media. And none of these, as far as I was concerned, was going to provide good entertainment grade digital audio. So I went codec shopping. It took two years to do this, but I found myself at an AES in LA, of all places, close to home. And I'm coming around the bend and I see this little stand, from a little company called Coding Technologies.

Chris: Oh, yeah.

Greg: Yep. And they had some sign that attracted my attention about this and I went over there. And to cut to the chase, I put the headphones on. I don't think I had them on for longer than about 10 or 15 seconds. And I lifted them up and I said, "Andreas, what bitrate did you say this was?"

And he says, "32 kilobits". I said, "Listen, when you get back to Germany, don't unpack. Send me all the papers, we're done here."

And he looks at me with his eyes wide open and he goes, "What are you going to do with this?" I said, "Well, Andreas, I'm going to fix the Internet." And he says, "Oh. Oh, let me tell you." He says, "You know we're all from Fraunhofer Institute, where MP3 was developed." He says, "You know this is going to take you 8 to 10 years to get everybody to embrace and what not."

And I looked at him and I said, "Andreas," I said, "people are going to hear this and they're going to want this tomorrow." Well, let me tell you something. There is one thing I've learned about this today. It's really, really hard to change the world anymore.

And I could have set my watch by that comment. Because it was about eight years that I got the attention of Adobe, Microsoft, and Apple, which is what I needed the attention of in order to make this go. But I'm pleased to say that here we are now in 2013. This is just, it's displacing MP3 all over the place. And it's for several different reasons.

It's not just because it's the latest and the greatest. Number one, and this is the most important thing that people don't realize. MP3 requires a streaming license. If you are on the Internet making money with MP3 streams, you owe of all people, Technicolor. Yes, Technicolor.

Chris: Wow.

Greg: You owe Technicolor 2% of your revenue. Fact.

Kirk: Is that enforced?

Greg: Yes. I was just going to say, if you're not paying it now they will hunt you down and you will eventually owe. So, the licensing for AAC and HEAAC doesn't work that way. They realized that in order to get a new format going that this kind of licensing wasn't going to work. So all of that got revamped.

You pay for the licensing when you buy an encoder from either us or Telos, or wherever you may get it from. The license gets covered there and you're done. You play as much music as you want, you play as much voice as you want. The only thing you have to deal with is music and program rights. But that's something totally different. It's got absolutely nothing to do with the technical end of this.

Secondly, and these sort of go hand in hand, you can get very close to comparable audio fidelity, and when I say that, I'm talking about 15, 16 kilohertz audio at 32 kilobits, but comparison to the 128 kilobit that you need for MP3. And I don't have to tell you, the streaming costs on both the transmission side and the consumer side for the data plans on mobile gets cut by 25%. And not only that, here comes four times more reliability. Because no matter what Verizon, no matter what AT&T, no matter what Sprint tells you about how good their network is, it's not good. None of them are any good. They all think it is, but it's not. And in order to get real time audio through it, you need to give it as little bit rate as is absolutely possible. It's the only way it works. And 128 k in congested and crowded networks, especially in places like LA, simply doesn't work.

Kirk: Not consistently you're not going to get that, not driving around, moving from cell to cell.

Greg: That's right.

Kirk: Or the buffering just has to be pretty enormous. But even driving around Nashville on T-mobile with not a lot of users on 4G LTE recently, streaming at 128, various stations, it does cut out. Streaming at 32 or 40 kilobits per second using HEAAC V2 stations, it works very consistently.

Greg: We've added a feature, and it's an additional feature in the streams player. And let me just call it up here. It's a real nice embarrassment tool for all the providers, actually.

Kirk: An embarrassment tool?

Greg: I don't know if you can see this very well, let's just see what happens. Yeah. Let me start a stream here.

Kirk: Okay. I'll start with one too. I wonder, do I have the latest and greatest version here? How would I know? Under settings? No.

Greg: I'm in WiFi land here right now, because I'm in my home office so it's on WiFi. So it's going to plot out WiFi, but that's okay. You change the page and you can plot different traffic. But going back to WiFi, you can see where it's plotting the actual network traffic.

Kirk: Really? Oh, neat.

Greg: It's sort of interesting to put this on various networks. You can see it's pretty much. It bursted on connect because we support a protocol of the streaming servers that's burst on connect and it allows the player to start immediately.

Kirk: Not every player, right?

Greg: Yeah, it buffers up really fast but you can see the spike. It came in as fast as possible. What did it do? It came in at about half a megabit.

Kirk: Is that network graph that you had, is that available on the iPad version that I have right here?

Greg: Yes, it is.

Kirk: How do I do that?

Greg: You have to go to the stream store. And Unfortunately I can't give anybody any promo codes for this. I would if I could. But Apple doesn't give us a mechanism to give us promo codes for add ons.

Kirk: Okay.

Greg: So, just do that and, coerce me to buy you lunch some time.

Kirk: Okay. So I would need to go to the Stream store. So how would I go to that, I'm sorry.

Greg: Yeah, that's okay. Go to more, and then the Stream store is in Stream tool.

Kirk: Okay, where's the more. I'm sorry, I'm just. . .

Greg: Oh, you're on the iPad. I. I don't remember where it is over there. It's a funny looking icon.

Kirk: Well, there's a, let's see here.

Greg: It should be with, it should be over there.

Kirk: There's a help. There's an "I" for information, and a settings. That information's has got your name all over it. The help . . .

Greg: "More" on the phone is in there, and the Stream store is in there.

Kirk: Okay.

Greg: I can get with you offline on that later.

Kirk: Okay.

Greg: If you want, Kirk. Because I don't have my. Oh, here we go. Oh, it's not available for iPad yet. I've just been handed a note. Okay. What do I know?

Kirk: Okay. Well, it will be later. You know.

Greg: But it will be later. Yeah.

Kirk: Okay, good. Good. I'd love to see that bandwidth usage. Or I'll buy a copy of this for my wife's iPhone and I'll play with it on that.

Greg: Yeah, no. I'll get you a promo code for it and you'll have to add the accoutrements.

Kirk: Sure.

Greg: Okay, sure.

Kirk: Actually, let's talk about this buffering up real quick. You have a better name. I call it, always called it . . .yeah, because Winamp did that. With the, when you used Shoutcast. You could, you would buffer up, it would load the buffer up. . .

Greg: Winamp. The official term for that on the Icecast server, you'll see it in the Icecast config. It's called "burst on connect".

Kirk: That's burst on connect. Okay.

Greg: Yeah, burst on connect. And, one of the features of Icecast and Shoutcast is, they actually cache a good amount of audio data.

Kirk: Right.

Greg: For this very reason. And this is fundamentally different than the way the Flash, or the Wowza server works. Those servers are dumb. They don't cache any audio. And I've tried to explain this to the developers so that they could add this feature. But, you know, they don't even speak English, so. It's another problem. But it's their loss.

That said, the servers these cache the audio give you the ability so that you can put the feature in a player to do the burst on connect and it will fill the buffer as absolutely fast as possible. I'm sitting in here with 50 megabits, so I can, you know, I can hit it really fast and it will fill the buffer as fast as the network will allow. And then what happens is, is you're playing and as network congestion goes up and down this thing helps self-regulate everything. And you can see all of this in action when you get this, when you get this plotter. It's sort of interesting to look at. When the network is working really well all you'll see is a just a jiggly little line in there. And when it's not working very well you'll see it have all of these massive spikes going up and down.

Kirk: Right.

Greg: So, I remember when Verizon's LTE network was first brought up here. I guess that's about two years ago or so. It was right about this time of the year as a matter of fact. I actually clocked 30 megabits across that thing before it got any usage on it. And I notice the AT&T cell site, which services our location here, they just did something recent to that because I pulled like 28 across it the other night at about 3 am. So things are getting better. The one thing you have to understand too is that if these networks can do, you know, 30 megabits at a time, that's great. They need to be able to do 32 kilobits all the time.

Kirk: Yeah. Yeah, that's a good point.

Greg: And a lot of them can't even do that. It's the all the time that's important for real-time streaming. So, we can build the buffers up and we, we've got like 30 seconds of buffer at 32k, and I would say that for 95%,

maybe even higher than that you never get a drop out, even driving around LA. I mean you can drive around, listen to Paris, listen to Asia, it's absolutely amazing what you can do with this.

Kirk: Yeah, I listen to our American Samoa station on stream some times. And some stations in East Europe and it works just great. In fact, I just want to point out something, that if you're watching our show and you, and you're learning a bit about streaming here and there, a lot of times, in the context of broadcasting and doing content contribution and content creation, we talk about trying to get a very minimal amount of buffering and latency between two points over the public Internet, or over a private network. And in fact our sponsored product, the Telos Z/IP One, which we'll talk about in a few minutes, that has a feature there where it always tries to minimize the buffering and the latency depending upon the connection.

For the Link to the consumer, we're usually not concerned about... it's okay if we're 5, or 10, or 30 seconds behind real time. What we, what's more important is a reliable experience for the consumer. And it doesn't matter that the audio that you hear is actually 30 seconds behind the audio that was actually played. So, that's why buffering is useful if you want high reliability under challenging conditions. And actually some product like the Z/IP One does the same thing, but we're actually trying to do it the other way.

In what Greg's talking about with the burst on connect, and in keeping a number of seconds with the buffering in the server so it can do the burst on connect, and then a number of seconds for the buffering in your player, that just adds to the reliability. So that if it's missing a packet or a bunch of packets. the client can request them over again and get those packets there in time before it's time to play.

Greg: Yeah.

Kirk: Did I kind of explain the two concepts there from buffering or a lack of buffering? Greg.

Greg: Yes. And, Kirk, you know, now it is, especially for the technical types that are here for this program, now would be a really good time to explain something about streaming versus the studio protocols that we're all actively working on now, commonly known as audio over Ethernet. A lot of people call it audio over IP. Now, certainly the Axiom protocol is an audio over IP protocol, but many of them, and a lot of people don't know this, but just because they go over that blue Ethernet cable doesn't necessarily mean they're IPs.

Kirk: Right.

Greg: So that's why I call these all, I group them all together and I like to call them audio over Ethernet because that's really more correct. But what I wanted to say was there's something very fundamentally different between those protocols and the streaming protocols that are being used for all of these players today.

Kirk: Okay.

Greg: Much to everybody's surprise I must say, that streaming the way we know it, including what's used in the streams player, and the Icecasts, and the Shoutcast, and all the Flash streams, they are all fundamentally flawed.

Kirk: Ooh.

Greg: And what do I.

Kirk: Pained by this. That sounds juicy. Okay.

Greg: The man with two clocks doesn't know what time it is. You have a send clock, which is coming from the encoder, and you send that out over the public Internet at a clock rate. And then you have a consumer clock that goes in the player app, which is run by the player's clock. And neither one knows anything about one another.

So you basically connect to a stream, and you hope it stays up. You throw lots of buffer in it so that everything can sort of self-regulate. And you can get 95% pretty good performance. But of course it's at the expense of all this latency. Obviously in a studio you can't deal with that. Hence why we're dealing with these audio over Ethernet protocols. And with very single competent audio over Ethernet protocol comes a clock layer, and all the different proponents have different ways of doing clock.

But I just wanted to, I don't want to get into all of that because that really is another program altogether different. But I just wanted to bring up that that is the fundamental difference between these two types of moving audio over Ethernet.

Kirk: Yeah, and this is a challenge for product designers. I said, I mentioned before our sponsor is the Telos Z/IP One, but there are a number of places within the Z/IP One depending on how it's hooked up and what it's hooked up to, where we have to do resampling and we have to use some, where we can, use some of Fraunhofer's error concealment, or frame concealment protocols and tricks so that once in a while when this buffer is out, out of data -- and I don't mean the packet buffer, I mean if the two clocks are different -- we've got to resample and play it out according to the local clock at the receive end. Well, at some point you're going to have either an extra sample or a lack of a sample. You're going to have that happen.

Greg: Correct.

Kirk: So you have to conceal that, or resample it in such a way that you can smooth over it.

Greg: Like you say, sooner or later there is going to be a buffer overflow or an underflow. It's going to happen. Because the chances of those two being dead nuts on the money are slim to none as you very well know.

Kirk: Well, this even happens with Void Telephony. You know Telos makes this VX phone system that connects to Z/IP providers, and invariably, invariably the sample rate coming from the Z/IP provider is not exactly quite 8 kilohertz. It's something else. And I'm talking about for a G.711 codec. And so, yeah, we have to resample or drop a sample, or double a sample to, you know. But in Telephony, you almost don't notice this. If you're having a phone conversation with a G.711 codec, if you miss a sample it's just not a big deal. But it is a bigger deal when you're talking about wide band HiFi audio. You've got to do some really smart things to cover that up. You can't just design these things and let it just, let the propellers windmill. You've got to work to put them together.

Greg: Absolutely. Of course I would never be able to get anyone to admit this but I swear everything at DirectTV is free running. I'm a DirectTV subscriber and I'm telling you, I just watch television with glitch, after glitch, after glitch in the audio. I've complained to the point where I don't even waste my time with it anymore. But I don't think they have things clocked up right over there.

Kirk: So I want to remind our viewers, you're watching This Week, or listening to This Week in Radio Tech. It's our 193rd episode and, hey, along with me is Chris Tobin. Chris, are you still there? Did I put you to sleep yet?

Chris: No, no, no, no. It's always entertaining and fun to listen to Greg, and he's right. The clocking is an issue and that's something most of us have overlooked in the days of digital. And I can assure that watching television on my cable system that is IP based, with my Cisco set top box, timing and buffers and under and over flows definitely occur when I watch videos suddenly disappear and the two words "please wait" appear on a black screen. Then I watch video come back and it's the last three seconds of what I was watching before, that just was buffered and then released. It's entertaining.

Kirk: Greg, this interesting problem of digital buffering, and sample slipping, and clocks, and different rates, this is a problem that we never had with analog technology. Isn't it?

Greg: It is indeed true. We've actually had very little trouble with it with the AES transport as well. That's all fast and furious. But, the problem is trying to get a synchronous signal over a protocol TCP/IP. Bless its heart. Getting a synchronous signal over something that was never designed to do this.

Kirk: Yeah.

Greg: And the reason we're trying to do this of course is because we want everything to run, you know . . . do you know what the three S's are? I'm not going to say the words because they're not very nice.

Kirk: I guess I don't. But you'll have to tell me after the show.

Greg: I'll tell you after the show. But everybody wants to S, S, S on port 80 these days. If it's not on port 80, they don't want to hear about it.

Kirk: Yeah.

Greg: You know?

Kirk: Yeah.

Greg: They want it. Everything must be a web app. The streaming must go over a webserver. You know? Because nobody wants to have any expertise anymore.

Kirk: It's true.

Greg: Haven't you noticed, like, Windows 8 is like a dumbed down version of Windows at this point?

Kirk: Yeah.

Greg: Everything is getting dumbed down. I had to laugh. I've got a Microsoft Surface Pro here. And, there were a lot of issues with the HDMI audio. One of the reasons I bought the damn thing was to be able to demonstrate our multichannel streaming. And it's got an HDMI output. You can buy this nice little display port adapter to HDMI.

I plugged it into the big system in the media room, video comes up on the big screen with no problem, it looks like a million bucks and there is no audio. And in the audio driver, it looks like nothings even plugged in. So you know, I go on a witch hunt to try to find out what's going on. Long story short, for some reason this thing will not propagate through the Sony HDMI switch that I have on that system. If I pull that out of the system, everything works fine. So somebody didn't the dot the Is and Cross the Ts. I've already been in contact with Microsoft about all this.

But, you know, here's a perfect example of these guys trying to dumb this thing down, and I downloaded the manual for the Surface. And right there on the front page, the nice little Microsoft Surface Logo is printed thusly. And the PDF that they promptly provided me, and it's all jaggies. That all used to be nicely done with post script. With Vector art. And now nobody even knows how to do that anymore. It is just absolutely amazing to me to watch all of this go down. But, as I said -- we got a little off topic -- everybody wants to put everything over TCP/IP. So these are the challenges that we'll be faced with.

Kris: You know and, even you can build systems. Remember the days, and some people still do, plug an ISDN line into an ISDN codec, like from Music Cam or from Telos. And there's a light on there. Or an ISDN modem. And there's a light on there that flashes and it slow flashes slowly and then finally it's steady. And same thing with your cable modem or your DSL modem. And when it's steady that means that these things are synchronized. And, and okay, that's well and good. We actually do that with audio over IP systems. That's one way that they're clocked. It happens to be a separate clock stream, but, so they get synchronized over time. You can average the packets that you receive, and determine their time signatures and then build a PLL that works over this. In other words you're transmitting highly accurate time or you're getting another device to synchronize highly accurately over a jittery network.

Greg: Correct.

Kirk: And that's what we're trying to do here. With . . .

Greg: Exactly.

Kirk: But even if we do this, even if we build a stream player or an IP codec, and we have its front end, its receiving end, overtime synchronize with its sending end, despite a dropped packet here or there, over time we have it synchronized, we still have a problem. At the front end of it is synchronized to the far, can be to the far clock. But we still have to resample for play out locally. We can't slave the entire machine to the clock at the other end over a jittery network. Or we don't want to. Maybe we're feeding into an AES network or a live wire, or other IP audio network that has its own clock system. Point is, you're just exactly right. A man with two clocks doesn't know what time it is. And that is a difficult problem to solve. No matter where you are.

Fraunhofers come up with some interesting resampling schemes and actually here at Telos, at the Axia department they've come up with some smooth ways to get that done. But none of it's easy. It is a difficult problem.

Greg: It is indeed true. That is the current challenge. As I showed you earlier you saw that I've got an Axia note in the lab and we're working right now what that was all about. We didn't get into that because of course we are talking about other things at the moment. But, we're working on some other things to support the Axia protocol with the Orban products and getting it going with RAVENNA. So I'm working with the RAVENNA stuff currently right now. And that is what the Axia node is involved with in that lab at the moment.

Kirk: Hey, we're going to take a quick break and hear from our sponsor. But when we come back, Greg you've got some really strong opinions about MP3, and Opus. I got a little taste of those earlier today when we talked, and I want to hear the rest of what you have to say about MP3 and Opus. You, you're.

Chris: That'll be fine. So we'll be right back after station identification.

Kirk: That's right. You're watching This Week in Radio Tech. Episiode 193, I'm Kirk Harnack, along with Chris Tobin, and our guest Greg Ogonowski, from Orban and his own company Modulation Index. And he makes this really cool software for iOS devices called Streams Plus. And we're going to give away a copy of that in just a few minutes.

But I want to tell you about our sponsor, which is Telos systems. By the way, that's where I'm at right now. I'm in the training lab at Telos in Cleveland Ohio, getting ready for the snow, and the sleet, and the rain, and the Christmas Party. Behind me are a bunch of Telos products, and I want to tell you about the one at the top here. That's the Z/IP One IP audio codec.

You know one of the problems about streaming across the public Internet is that the internet's not perfect. It drops packets. In fact, TCP/IP is all about dropping packets. And if you want more real time audio, at a lower, less overhead, you don't use TCP/IP, you use UDP. And with UDP we just have to assume the packet got there. Well, that doesn't always work real well. You need to have a device that's going to, at both ends, talk to each other and say, "Hey, did you get my packet?" "No, I didn't. I missed that one." "Well, let me send it again." Or, "Let me increase my buffer because I'm dropping it. Enough packets aren't arriving in time."

We'd like to have some intelligence in our IP audio codec over an imperfect network, like the public Internet, we can just some intelligence back and forth. One end can tell the other, "Man I'm getting all of your packets just fine. I'm going to reduce my buffer to the point where packets are arriving just in time." That's very possible. You can get very low latency using two Z/IP Ones over the public Internet.

And if the conditions become worse, let's say you go do a remote podcast at a ballgame, and you're using, I don't know, maybe you've got a cradle point router and Verizon 4G card in there. And everything's fine until the last four minutes of the ballgame when people start to get on their cell phones and use up more of the bandwidth from the cell tower and your bandwidth goes down. You started out having a couple megabits up and down and now you're down to, you know, 120 kilobits up and down if you're lucky and that even drops out from time to time. You need to have a codec that can kind of ride those waves and adjust its bitrate up and down, adjust the buffering at each end up and down and that's exactly what the Z/IP One does.

It's a little complicated but it does all of the work under the hood. Telos worked with the folks at Fraunhofer in Germany to take this, to make this agile connection technology where we can wrap this metadata around the encoding process and adjust the coding and the buffering in real time. It's just as cool as can be. It works where other codecs just couldn't work. Instead of having to provision your codec, your IP codec for the worst possible moment of transmission time during an event, a ballgame, maybe from your studio to your transmitter site STL. You get to provision for the best possible time and it automatically throttles back when it has to.

So check it out on the web. Go to telos-systems.com. I'm so proud we have a new website, and it's, so I think it's easier to find stuff up there. The product page for the Z/IP one will tell you all about how the Z/IP One works and what it can do for you. And there's so many success stories, people using Z/IP One for studio transmitter links, for all weekend remote broadcasts for music festivals. In Nashville, a station there Lightning 100 uses a pair of Z/IP Ones for all kinds of local live music events, that's what the station's known for covering. WSM in Nashville, they just picked up a couple of Z/IP Ones and they're doing live country music interviews with stars and artists with their Z/IP Ones.

It's everywhere, we're shipping them all around the world and so I wish you'd check it out too. On the Telos website. Telos-systems.com. Thanks a lot Telos for sponsoring This Week in Radio Tech.

I'm Kirk Harnack our guest is Greg Obonowski, and Chris Tobin is with us from Manhattan, New York. Now, Chris Toban, I'd like for you to query Mr. Ogonowski about his feelings about MP3. I'm going to, I'm going to duck.

Chris: Oh, no need to duck. We all know how it goes with MP3. No one's a stranger to the craziness of the history of that algorithm. But then again there is Opus, and that name is enough to bring some questions to mind. I am curious, I've been reading lately a lot of email blasts I'm getting regarding this Opus codec. And the word free comes along with it. And all of these wonderful things that they claim that is much better than what you're familiar with, already with audio algorithms.

So, Greg as you have always done in the past, and your point of view opinion, and approach to problem solving has always been spot on. And though many people don't enjoy your candor, I do. What could you tell us about MP3, Opus, and why broadcasters should wake up and realize it's time to wake up and learn how technology works?

Greg: Well, I'll try to behave myself. But you know, there's no fun in behaving yourself, I'll tell you that right now.

Chris: It's true.

Greg: The responses you get when you don't behave yourself, that's uplifting. Here's the story. MP3 has a very long history, as we all know. And, let me just put it real simple. Not all MP3 encoders sound the same. Not all of them are the same implementation. A lot of people are under the idea that just because something is digital, it's done right. And that could not be farther from the truth.

Kirk: Oh my god, I'm so sorry now.

Greg: If there ever was a time when people need to pay attention to knowing how to do arithmetic and mathematics, now would be a real good time. Because if you're a software engineer, if you're a programmer, and you expect to do digital signal processing and do anything in the media, you've got to understand arithmetic, otherwise my best advice to you is to get out of the business because we don't need you. There's plenty of people who've made messed up encoders, and decoders, and screwed all of this up and given products a bad name that shouldn't have necessarily gotten a bad name.

I'm going to tell you something. Just, I think it may have been either last week or earlier this week, things move fast here in the West here, and things tend to blur together for me. But I just recently made a comparison of an old MP3 from Fraunhofer no less, to a new MP3, to the current code that we use in the opti codec PC. Because contrary to popular belief, being the father of HEAAC and whatnot, we do have MP3 in the opti codec PC because it's in there for compatibility for a lot of the older devices, so we know about this.

I am here to tell you, that the current MP3 encoder at 128 kilobits doesn't sound half bad. Yet the older ones, like the ones that you would find in 1.5, 2.0, those codecs didn't sound very good. And hence the LAME community. LAME. I forget what that, it's an acronym for something. I forget what it stands for. Easy enough to look up. Google it. Go for it. Hence they came out and it was an open source implementation of the MP3 algorithm and its claim to fame was that it sounded better than the Fraunhofer. Well, probably back at that time it did. I don't think that that's anywhere near the case.

The current, what they call the Thompson implementation, which is the FHG Fraunhofer, it's not half bad. Now it's more political in business than anything else. If you want to do 128 kilobits stream you're better off using AAC. All of those iTunes audio files are all AAC.

Chris: Yeah.

Greg: None of them are MP3. And they chose AAC because it's a higher quality, it's a higher quality codec. It doesn't have the pre echo issues.

And as far as Opus goes, just to sum all of that up very quickly. Opus is a good sounding codec. It's not half bad. And at 64 kilobits for example, it does blow the doors off MP3, but it doesn't blow, it doesn't blow the doors off HE. And if anybody's interested, I've got a bunch of samples at www.indexcom.com/streaming/codec/opus. Everything is lower case. And there's a bunch of comparisons there. I also have another index of a bunch of everybody else's codec. But I'll have to find that because it's been a bunch of years since I've pointed anyone to any of that. But yeah, LAME stands for Lame Ain't an MP3 Encoder. Would you trust software from that?

Anyway. I lost my train of thought. I'm sorry.

Kirk: I went to that directory of files. Thank you for providing that. It's Opus at a lot of different bit rates.

Greg: Oh yeah. I've got, I've got another place here. I have got to find it but I did a thing several years ago that's got just about every single sample that you could ever imagine. Let me just take a look real quick. Somebody can fill while I'm looking.

Kirk: So, Greg and I were talking about MP3. I remember back to when the first time I heard a MP3 was at a NNAB show. And I want to say that it was, it was, well of course Telos was the very first licensee of MP3 back in the early or mid-1990s for the Telos Zephyr ISDN codec. And at the time, this was the way to get 15 kilohertz stereo audio from one point to another over an ISDN line. Over two BRI circuits, you know, bonded together you could get 128 kilobits of real bit space and fill that up with an MP3 thing. And that was the thing to do at the time.

We do have so much better technology now with AAC came along 10 years later in the early to late 2000s. And in fact there is a whole wide paper, and Greg maybe you want to also on this, but it's a great wide paper that Steve Church wrote, and it's on the Telos-systems.com website. It's something, it's called something like about beer and coding and AAC.

Greg: Oh yeah, I remember that paper. That was a famous paper. Yep.

Kirk: And Steve does a great job explaining some of the real benefits of AAC and some of what was learned through 10 years after MP3 and cycle acoustic audio coding. But then along came along the folks at, I'm sorry, the name just slipped my mind. The guys that you met, Greg.

Greg: Codec Technologies.

Kirk: Codec Technologies, yeah. That, that, figured out how to do the spectral band replication. Which, okay, it's not perfect but it's really good in most cases.

Greg: Yeah, the thing is that once you get below 64 kilobits per second, the game completely changes because you just don't have enough data to build a colorless codec. At least with today's processing power. It's just not enough information. So you have to use the synthesis mechanism. Which is, is the SBR as you say.

Kirk: And I'm, and Greg I believe, and maybe it was a bad encoder but, I've heard of a codec with spectral band replication, SBR, the synthesis of the higher frequency of that should mention. I've heard it done badly, where it was definitely out of time alignment with the fundamental frequencies that were queuing or hinting to make the higher frequencies. But I've also heard it done really, really well and it sounds really, really good on most material. What do you have to comment about that? Maybe the time that I heard it didn't sound good.

Greg: Right. Well, insterestingly enough. I mean, it comes as no surprise. The best implementation is going to come from the inventors, and that would be Coding Technologies. Coding Technologies by the way, to give you a little bit of history, has now been acquired by Dolby. Dolby markets the product under a product name. Nobody knows about because nobody buys the stuff from Dolby anymore. It's called Dolby Pulse. P-U-L-S-E. And they basically bought the company because they didn't want to lose . . . this all has to do with the Brazilian television market.

As you already know, the television markets in most of the world all mostly use Dolby AC3. And the Brazilian television market is absolutely huge. And they didn't want to lose any of this so they wanted their fingers in that, so the best way to do that is to just go buy the company. If you're Dolby you can do this like this. "Ah, let's go buy the Codec Theater this afternoon." "Yeah, sounds like a good idea."

Kirk: Oh geez.

Greg: That's what happened there. And now what's happening, and I think you guys are in the same basic boat we are, and it's not really a boat at all. It's a very good partner. The Fraunhofer folks now have an HEAAC implementation which is incredibly competent. And I do believe you guys are Fraunhofer licensees for your HEAAC as are we. We're actually both because we come from the legacy of this whole thing. We've been at this for so long, obviously since from the beginning, we actually have two licenses: one for the AAC and one for the SBR itself. You no longer have to do that. But ours is so legacy hat that's how it was.

I found the other URL, which I think everybody's going to be interested in. And I was reminded just now how long I've been at this. This is dated 2006, 11-2006. It is www.orban.com/audio/1010/codecs_1.html. I apologize for the . . .

Chris: The number one, or spelled out?

Greg: Yeah, the number one, codecs_1.html.

Chris: Okay. Yeah.

Greg: And I apologize for funky link but it has links from the Orban website.

Kirk: We'll put this in the show notes, so people can wait for us to publish the show at GFQnetwork.com or at thisweekinradiotech.com. We'll put these links in the show notes.

Greg: Yeah. And you know, just looking here. This is a good reminder. I'll add the Opus to this. I'll get the Opus added to this so that everything gets in the same place.

Also, I'm looking at one other thing that reminds me of another interesting little tidbit. For those who don't know, the infamous Winamp player is coming to an end. As of the 20th of this month, the Winamp player will no longer be available so get it while you can. Interestingly enough the last version is version 5.6.6.6. And that's not my candor.

Kirk: You know, the first version that had MPEG surround it was version 5.1.

Greg Correct. Interestingly enough do you remember the Orban plug in for the Windows Media Player?

Kirk: I do remember that, yeah. Well, the version that supports multichannel there is 5.1.

Chris: Ah, there you go. Yeah.

Greg: There was a talk show guy, I think Leykis.

Kirk: Yeah, Tom Leykis. He's still on streaming.

Greg: Right. Tom said something kind of humorous a couple of weeks ago. As most know, may he rest in peace, Ray Dolby is no longer with us. And Tom Leykis said, at the service, that they all enjoyed 5.1 seconds of his free silence.

Kirk: Okay.

Greg: What can I say at a time like this?

Kirk: Oh. But that was almost too inside baseball. I think I got that.

Greg: Yeah.

Kirk: 5.1 seconds of his free seconds. Dolby. Noise reduction and . . .

Greg: Yeah. Just to clarify that so everybody gets the joke. I know the worst jokes are the ones you have to explain.

Kirk: That was really inside baseball.

Greg: Ray Dolby's claim to fame was of course developing noise reduction for the recording and the movie industry, the cinema industry. And he did very well with that. And they also had the hindsight to know that sooner or later, noise reduction was not going to be a problem in the digital domain. So being the astute individual that they were they got into codecs. Smart Move.

Kirk: Yeah.

Greg: So that's where the jokes comes from. His free 5.1 cinema. Everybody can laugh now.

Kirk: So I want to go back to the MP3 subject. You were really adamant earlier in our conversation that MP3 needs to go away. Or you point out an article where an author says, MP3 needs to die, needs to go away. And I'm thinking that this is, well, we have better stuff now. And, we have stuff that's less encumbered by ongoing costs, as you were talking about. You actually owe Technicolor money if you're using MP3 to stream. And so much streaming needs to be done, it wants to be done, entertainment streaming that's of perfectly good quality to enjoy in your living room, wants to be done at a bit rate between 24 and maybe 70-80 kilobits per second. Maybe a sweet spot there is 32, 48, 56, 64 kilobits per second. And to think of using MP3 for using that kind of bit rate is, is, is a mistake. Would you agree?

Greg: That's correct. Yeah, you just don't get the audio bandwidth. You basically get high quality AM radio bandwidth with that. Over on the FTP server for Orban, in the ftp.orban.com/1010. I believe it's in the documentation directory, there are two charts in there. And if anybody's interested there's an MP3 chart and an AAC which includes the HEAAC family. All the audio bandwidths for all the various bit rates are all cited within there. It's a PDF document that I had done a few years ago. Everybody might find that of some interest. But you'll never get entertainment grade 15 kilohertz bandwidth with MP3 down at 64, it won't happen. It needs a minimum of 128.

Kirk: Yeah, so you feel that MP3, to be useful, means 128. And there are plenty of content of streamers on the Internet. I've got a couple of Grace Radios, and other WiFi radios around the house. And so many channels that I like, they don't have an AAC version available. They're still streaming at MP3, at typically at 128 or 96, a few of them. . .

Greg: Yeah, well, the Internet brings information to people fast. But sometimes it's still, you know 10 years behind. I don't know what these people are waiting for. May I extend a personal invitation right now? Join the rest of us, folks. You know? All the CBS streams, all the Clearchannel streams. Everybody's up there with HEAAC at this point. There is really no excuse not to do that.

Hey, all we are trying to do, you know, you guys at Telos included, all we are trying to do is save everybody money.

Kirk: Save money and make the quality exceptional to the point where people would want to listen to it and not shut it off and say, "Aw, that blasted technology, that's not very good either." We can't pick up AM radio anymore, and these streams are terrible. They cut out, and they don't sound good. Or get they get on my nerves.

By the way. One thing, Greg I want to ask you a question about, about the audio problems that you have with codecs, what kind of problems you have. And I want to give you, you know the first time I ever heard MP3, It was 120 kilobits and I thought it sounded amazingly good. I didn't have a reference for other, you know cycle acoustic coded audio. And I just thought it was fabulous. At that moment, I couldn't tell it from linear audio.

But now, almost 20 years later, probably 15 years after the first time I heard it, I think when I hear MP3 at 128, and I'm guessing it was done with a good codec, I know. I've got WAV files and MP3 files that I've encoded myself, and I can A B them and I think, wow. You know, the WAV file, the linear file, is absolutely what I want to listen to. What is it?

What has our brain learned about, you know we used to listen for cross over distortion and clipping distortion, things that happened in the analog realm to audio. Now, different things happen to audio in the cycle acoustic encoding realm and I think my ears and finally, and my brain is finally getting use to identifying those aberrations. What do you say about that?

Greg: Yes, you are very correct. The analog world has its own family of distortions that the get into the act. And, the digital domain has a lot of things that happen that are generally very unnatural, generally unnatural and very nonmusical. And when you do bad things you really do bad things.

But to try to explain this and put it into words, codec artifacts will manifest themselves in the form of watery sounds. I call another artifact like talking through a toilet paper roll where things will start to sound dynamically like this. And, you know, if you listen to the voice on Sirius Satellite Radio, there's a perfect example of how everything falls apart. Because they're using, on Sirius, not XM now, Sirius uses a codec called PAC, which came out of some early AT&T development. It's grossly obsolete at this point in time. I mean, it's 15 almost 20 years technology.

Unfortunately, they didn't have the hindsight to do a software updatable receiver. So, they're kind of stuck. I would not want to be them with this problem right now because that is a bad problem to have.

On the other hand, XM uses a derivative of HEAAC, it's a very early version of HEAAC. It's not quite as good as the HEAAC that we have now. But, just sort of got off topic there a little bit.

Getting back to these other digital distortions, as it were, that can happen, you've got the watery, you've got the phasing flanging thing is another thing that's very unnatural. A classic example of this to the nth degree. Does anyone remember a Supremes song called "Nathan Jones"? Or the Beatles, which one was it that had all the phasing stuff in there? It was from, I think it was from Sgt. Pepper. Right about that time period everybody was looking for cool effects.

Kirk: Yeah, yeah.

Greg: And the phasing and flanging was one of the effects that got used a lot during that time. Well, now without even trying, all you have to do is bring a bad codec to the plate and you can have your very own phasing for free. But.

Kirk: Okay, here's a question that I wanted to ask actually early on in our conversation. We were talking about just the wonderful qualities of HEAAC V2, especially at bitrates that make sense for mobile, moving around. And we know that mobile data is coming to the dashboard in a lot of cars here. We've been saying that for a couple of three years, and really, it's coming. You're going to have, you know, 4G LTE in your dashboard and a lot of options there. What are the downsides, what are the things that sound bad and maybe are fixable with good processing, or just attention to detail when you do HEAAC V2 at 32, 48, 56 kilobits per second? What's the downside.

Greg: Okay, for starters, a picture is always worth a thousand, a thousand words.

Kirk: There you go.

Greg: This is a representation of a bad codec.

Kirk: Yes. You're out of the help you need and if you talk through it, it sounds bad.

Greg: Okay. I just had a very similar conversation with Dr. Orban about this very thing, I think we were talking about this last night. We're talking about those of us in the audio processing domain, do you have to do anything in the audio processing special to feed coded audio? Well, you know what? On a good codec, no. Plain and simple. No. Otherwise it's just a set of, a set of more compromises that happen here.

And why do I say no so strongly? Okay. These codecs get developed, and they're listened to for thousands and thousands of hours with many different types of program material. Well, remember, today's program material on CD has already been smashed much tighter than Frank Fodor or Greg Ogonowski ever thought of doing to a radio station. So if these codecs have passed the muster of being able to reproduce CDs and program material of this kind of production value, then I dare say, they're going to survive anything that you guys, or that we do in the audio processing department with no problem whatsoever.

So the answer there, plain and simple is, you really don't have to do much of anything. With SBR, I would just be very careful not to overdrive the high end. I don't know why anybody wants to overdrive the high end anyway. There are certain markets in the world that seem to think that all of that is cool. Paris always comes to mind. But that's their problem.

Chris: It's true.

Kirk I think New York City comes to mind too. There's a lot of high end in New York City on the FM dial, a lot of density.

Chris: A lot of things on the FM dial in New York City. Yes, it's true.

Kirk: Maybe a lot of denseness, but anyway. Alright.

Greg: I don't know that the audio signals are responsible for all of the density there. But that is, again, is another topic.

Kirk: Exactly.

Greg: And that's more of my candor coming out.

Kirk: Greg, we've spent a little over an hour here and have had just another delightful conversation. I guess we ought to see if we can wrap this up. Obviously you are a proponent, a believer in the best technology we have at the moment, and the best practice is to use HEAAC for consumer level delivery of content. Right? Is that your bottom line?

Greg: That's the executive bottom line. Yes, sir.

Kirk: And if you're streaming with MP3, at anything less than 128 kilobits, then you're well, you may be wasting your money at 128 or over and you're wasting the ears of your audience at under 128 kilobits with an MP3.

Greg: Indeed. And you're running up their mobile bill.

Kirk: Yeah. And we touched, we touched on Opus. We didn't touch on it a whole lot, it's interesting but it's certainly not without problems.

Greg: Do you want me to touch on that, just briefly?

Kirk: Sure, take another couple of minutes and let's hear your thoughts on Opus.

Greg: Real simple, as I said, Opus is a good codec at 64k. It's free and that's part of the attraction to it. The only thing is, I've spent since 2002 getting AAC where it is now. I don't know that I'm interested in doing this again, for one thing. Because, now you've got a cart before the horse, horse before the cart syndrome all over again. There are no players. So now have to start with that. Okay?

HTML5 makes all of these promises that it's going to be, "Ferris Bueller, you're my hero." Well, yeah. HTML5 has got a long way to go before the media gets right. And there's no codec consensus to this very day. It might get some traction with Google, because Google's revenue stream is all about inbound. They've got nothing to do with outbound. So, that might happen there, but that's a big maybe.

I don't see Apple embracing it. I certainly don't see Adobe Flash embracing it. I certainly don't see Microsoft embracing it. And if you don't have those three, forget it.

Kirk: Isn't it in a lot of a browers?

Greg: That's what I mean about the HTML5. It's in, I believe I tried it in Chrome and it didn't work. It was supposed to be there but it doesn't work. It is in Firefox. Because I used it to test some streams because we've got a streaming encoder with it and I tested it all in there. That's where, by the way, if memory serves me correctly, that's the browser you're going to want to use to test those samples that I pointed to you earlier.

Kirk: Which one, Firefox or Chrome?

Greg: Yeah, Firefox.

Kirk: Okay, good. All right. Good. Now I said something to you earlier. Were you saying that Opus is actually open source? You said there is a certain differentiation, Kirk, you want to understand between open source and what was the other one you mentioned?

Greg: There's open source and open standards, or open standards is used really a little bit incorrect. "Standards based" is really the term there.

Kirk: Okay.

Greg: You've got these two things that people confused things with: open source and standards based.

Kirk: Okay.

Greg: Okay? AAC is standards based. But it's not open source. Opus is in the process of becoming standards based, but it is definitely open source. So that means if you find some source code to implement Opus into your product, you can use it and you don't have to worry about paying anybody. That's not the case with AAC.

Kirk: Right.

Greg: You can do your own implementation of AAC. Apple has. Apple does not use Fraunhofer, they do not use Coding Technologies. They won't tell anybody what they did. But that doesn't matter. If they did their own then so be it, fine. They certainly have the resources to do that. But they do pay into the patent pool for that privilege, just like the rest of us.

Kirk: Oh, okay.

Greg: So, Kirk, as you very well probably know, you guys have an implementation license and you have a patent license, as do we. Because I don't believe you did your own AAC implementation.

Kirk: Right.

Greg: Yes. Okay, so that's how that works. That's the differentiation there.

The other thing to consider, like let's say for example, let's say we added Opus to the streams player, which we actually tossed around here from time to time. We would have to put that in the objective C code, and then here comes the battery life issue. Because right now we're able to taxi on the AAC decoder that's in the Apple DSP, which is very battery efficient. But a lot of these app developers are bringing their own encoders and that's really bad news for the batteries on these things.

Kirk: Yeah, yeah, yeah.

Greg: Kirk, you've mentioned. Let me just get this out really quick.

Kirk: Oh, I'm sorry.

Greg: You've mentioned the thing about a bad SBR implementation, the FAAD, which is an open source implementation of AAC and an HEAAC decoder, that thing doesn't necessarily sound all that great. Because I don't think the necessary details were paid attention to there. And there's another example of something that is open source, you can download it, you can use it for yourself, but should you put that into a commercial product, you're now faced with having to pay the patent fees.

Kirk: Okay. Something I mentioned earlier when we were chatting was the notion that just because a piece of some code is open source, unfortunately it doesn't mean that it is not subject to intellectual property claim by others, claims which may not have been registered yet with a judiciary system or a patent office. And that, if you pay Fraunhofer, or Dolby for codec implementation, part of that contract is that you won't get sued, that Fraunhofer or Dolby indemnifies you from legal responsibility. They say, "Don't worry, we've checked it all out. We're responsible for all the code in here," or, "We've paid the other people who are responsible for it." And you've got to be careful, I think, if you're a monetary target and you're using something that's open source, again, open source doesn't necessarily mean that it is free from intellectual property claim.

Greg: That is correct. That is very, very correct. And you'll notice that if you go tooling around the net and you see some of the AAC implementations, almost every single site -- I do know a couple that don't state this and their time will come -- but almost every single site does make a mention that if you use this in a commercial product, you are subject to having to deal with this. So it, that's just the way it is.

Sometimes, I don't know, it's just a classic example of you do get what you pay for. I know that doesn't necessarily always hold true. I can think of one piece of open source code in an application that I live and die by, and I think the world of the work that these people have done to this piece of software, and it's the packet sniffing software that had it's...

Kirk: Do you mean Wireshark?

Greg: Wireshark.

Kirk: Yeah.

Greg: I was just thinking of the legacy name, which is Ethereal.

Kirk: Ethereal, yes.

Greg: Where it had its originations. I mean, those people have done a beautiful job on that and I'm going to tell you, I would have never gotten to where we got with any of this without Wireshark.

Kirk: And we use it here.

Greg: Yep. Hat's off. All of us do. And my hat's off to those guys.

Kirk: Hey, we've got to go but we've got some prizes to give away. Greg Ogonowski generously offered four licenses, or four promotion codes actually, to download and install the Streams Plus software. I bought this a couple of years ago when Greg first brought it out and personally love the software. It sounds great, it's easy to find radio stations on there and my little stations are on there from, Mississippi and from American Samoa. And there are plenty of stations that probably sound better than mine too that are on there as well.

What I did was we had a promotion back a couple of years back, and you retweet the fact that, you know, I tweet that the show's going to start. Here's our guest. Here's where to watch. And if you retweet that it gets us a bigger audience, it helps spread the word. And we haven't done that in a couple of years now, since we gave away a bunch of Omni AAC software. Which by the way, Omni AAC does work fine in streaming audio to Greg's Streams Plus program because I'm doing it on a radio station.

So anyways, we did that today. Late in the day today, I tweeted out that, hey, if you retweet this you'll be eligible to win. And I picked four folks who either shared it, reposted, retweeted it on the various different social networks and here are the winners. I have, First name Greg, he is

@pcguy88. Greg from Canada. Congratulations, we'll be getting in touch with you. Also mediacastguy, congratulations. He's @mediacastguy. Brian Monroe, longtime friend of the show, @brianmonroe is a winner. And Eric Addler is a winner as well. We'll get those names and emails put together for you, Greg Ogonowski, and we'll get them some promo codes so they can get thrown a copy of Streams Plus. Thanks for giving those, bud.

Greg: Kirk, no problem at all. Make sure that you get the information from those guys as to whether or not they want the iPad or the iPhone version because they're two different versions.

Kirk: Oh, yeah. Good deal. We'll do that. I'll give those to you in the next couple of days. Let's see. Chris Tobin, did I put him to sleep again?

Chris: Not at all, not at all. I'll have to say one thing, though. My wife's here listening to the webcast and she feels that the term packet sniffing has some negative connotations.

Kirk: You'll have to explain what that really is, and it's just a geek term. Meaning, yes there's no Freudian meaning there.

Chris: But that's just how we roll here in New York.

Kirk: "Well, let's see here. Mabel, get me a packet sniffer over here."

Chris: As I go to a bodega for a coffee. That's exactly how it goes.

Kirk: Oh, gee. Well, so if Lisa was tuned in, glad she was, and she once again saw how I didn't let you get a word in edgewise.

Chris: It's okay.

Kirk: We're going to have to get a new show host. You know what I should do? I should just take a couple of weeks off, Chris, and just let you do the show.

Chris: No, no, no. What I'll do is I'll just, I will hook up at Andrew at the GFQ network operations center and at certain intervals, something like the free software I'll just suddenly mute the microphone and just start talking.

Kirk: That'll work. That'll work.

I hope everybody had a decent holiday. Obviously we didn't do TWiRT last week, for the Thanksgiving Holiday. It was right on Thanksgiving Day. We also won't do the show on Christmas Day. We're debating about New Years, and Andrew Zarian's going to be telling us if we're going to be having a new show time for the coming year. So we'll make that announcement and get with you later on that.

Our show's been brought to you by our friends at Telos, my employer. I sure appreciate them sponsoring the show. Our show is brought to by the Telos Z/IP One IP audio codec. It is really cool, and it is not expensive. And you want to check it out on the web at telos-systems.com and look for the Z/IP One. Greg Onogowski, thanks for being with us there from your lair on the West Coast. Appreciate you being here, taking the time to be with us.

Greg: Not a problem at all, Kirk. I really appreciate the opportunity, thank you very much. Chris, it's good to see you. I would like to wish everybody happy holidays from moi and from all of us at Orban. Thank you.

Kirk: All right. I thank you. And we're glad to have you on again any time. Chris Tobin, we'll see you again next week here on This Week in Radio Tech. Right?

Chris: Yes, Absolutely. You know either from my lair in Manhattan, or maybe from the studios themselves.

Kirk: We have a guest next week, and I'm pretty sure, let me go double, double check this, but I am pretty sure that next week we have Scott Fybush. Yeah we do. And I should point out, next week is at a special time. Special time means I've got to do something else that night. Yeah. That's what it means. TWiRT is going to be on the air at 11:00 a.m. Eastern Time, on Thursday, December 12th, 11:00 a.m. Eastern Time. I hope I checked that with Andrew. Did I just schedule that myself? I don't know.

Andrew: Oh good, because there is a Paul Thurgot webinar at 12:00 at that day. Okay, good. Perfect.

Kirk: Andrew, Did I make a mistake scheduling this at 11:00 Eastern Time on Thursday the 12th?

Andrew: I don't know but I could have been drunk when you did it. That's fine.

Kirk: Does that sound okay with you?

Andrew: No, that's fine. Perfect.

Kirk: Okay, good. 11:00 a.m. Eastern Time a week from today and we'll have Scott Fybush as our guest. Alright guys, we've got to go. Thanks for being with us on This Week in Radio Tech, we'll see you next week at 11 am. Take care everybody. Bye bye.

Announcer: That's all the bandwidth we can pilfer this week. Another TWiRT is propagated. And all new transmitters and audio equipment live happily ever after thanks to the handsome engineer and his kind benevolent care.

We'll be back next week. Lord willing and the creek don't rise. This Week in Radio Tech. Subscribe to iTunes and you'll never miss a show. Search for "This Week in Radio Tech" in the iTunes store. Soliciting is strictly encouraged. If you liked today's show, tell a friend. If you didn't like it, we were never here.

Kirk Harnack's wardrobe provided by the Salvation Army and the Red Cross Disaster Relief services. Hair and makeup provided by Penne Lupe Garcia Hernandez Weinberg. This ends this transmission. Tango, Whiskey, India, Romeo, Tango. Signing off. Okay.

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