Music files for big stations?

[Studio1]

Interesting comments all round.

I note the general theme of analog airchains not affecting lower bit-rate mp3s, but I'd like to hear comments from people as to why I can noticeably hear such mp3s when they are broadcast on analog airchains.

The stations concerned have mixed playlists. Most files are waves, but there are a bunch of mp3s thrown in, and they sound AWFUL when they're on.
I can hear the difference. It does something strange to my ears, not quite sure what, other than they seem harsh compared to a wave file and there's a noticeable 'warbling' effect in some parts of the music.

Thoughts?

 

[WNTIRadio]

The distortion in analog airchains, say an 8100, will mask some of the garbage in an MP3 more than an 8600 or O11 will. You're trading artifacts for distortion.

 

[PTBoardOp94]

To Tom's point about syndicated programs: It always bugged me that PRN (Nascar) sent down all their recorded programs as 128 kpbs MP3. That was OK for most of the talk shows like Garage Pass, but Racing Country has the same problem.

Cumulus Media has reduced the bit rate on their program streams a couple of times, but I don't know what they actually use now.

 

[The F Mister]

Now we come up to the problem of cascading codecs, that you mention with the STLs. There are uncompressed digital STLs that are transparent in the audio quality sense. And there are compressed ones, that are not, because they use perceptual coding to reduce the data rate to be able to push more channels, or to push audio through a smaller data pipe. Everything above, applies here. The difference being you don't use perceptual coding on your source file, but you use it in transmission. But the same thing happens in the audio processor. There are some additional caveats depending on where the audio processor is in the chain, but we'll skip that here.

Regards,
Goran Tomas

Goran,

If you have to deal with bitrate reduced STL's what would be the best place to apply processing? Before the STL or after? The way I see it, before the STL would stress the codec, after the STL would stress the processor making the codec's artifacts more noticeable. On the other hand perhaps with the processor as last in the chain you could tune it to mask some of these. What's the general opinion?

 

[test123]

PTBoardOp94

PRN is one of my clients. I completely agree 128 is too low for music shows. I did not know they were sending it that way. I will talk with the production people and see if it would be possible to get it up a few notches...

I know in the past spoken word shows were sent at lower rates because stations complain about the time it takes to download the files. I fought that and finally got them up from 64 to 128.

All that being said the best way to record PRN programs in via your Cumulus Media XDS receiver. That should be a better quality feed.

hh

 

[chriscollins]

Now we come up to the problem of cascading codecs, that you mention with the STLs. There are uncompressed digital STLs that are transparent in the audio quality sense. And there are compressed ones, that are not, because they use perceptual coding to reduce the data rate to be able to push more channels, or to push audio through a smaller data pipe. Everything above, applies here. The difference being you don't use perceptual coding on your source file, but you use it in transmission. But the same thing happens in the audio processor. There are some additional caveats depending on where the audio processor is in the chain, but we'll skip that here.

Regards,
Goran Tomas

Without a doubt, you would process after... But, that would be the chain anyway. Bit reduced STL's send 2 Channel Audio, so the processor would be at the site anyway. You would typically have some light AGC at the studio, but I think it is smarter to just run the chain with nothing at the studio and give 10 db of headroom for peaks.

Goran,

If you have to deal with bitrate reduced STL's what would be the best place to apply processing? Before the STL or after? The way I see it, before the STL would stress the codec, after the STL would stress the processor making the codec's artifacts more noticeable. On the other hand perhaps with the processor as last in the chain you could tune it to mask some of these. What's the general opinion?

 

[chriscollins]

That all posted as a quote...

What I said was...


Without a doubt, you would process after... But, that would be the chain anyway. Bit reduced STL's send 2 Channel Audio, so the processor would be at the site anyway. You would typically have some light AGC at the studio, but I think it is smarter to just run the chain with nothing at the studio and give 10 db of headroom for peaks.

 

[gtomas]

Goran,

If you have to deal with bitrate reduced STL's what would be the best place to apply processing? Before the STL or after? The way I see it, before the STL would stress the codec, after the STL would stress the processor making the codec's artifacts more noticeable. On the other hand perhaps with the processor as last in the chain you could tune it to mask some of these. What's the general opinion?

That's an excellent question!

The ideal solution would be if you could split the processor in half, and have one half (the leveller and the multiband AGC) before the bit reduced STL and the other half (limiting, clipping and stereo generation) after it. Come to think of it, with the latest version of firmware for Omnia 11, that's actually possible to do! Though you would need to have two boxes

To clarify, it's beneficial to have the multiband AGC in front of the bit reduced STL to feed it consistent levels and to protect it from clipping. However, a complete processor in front of the bit reduced STL would employ pre-emphasis and having pre-emphasized audio going into the codec is a really, really bad idea. Perceptual codecs were designed for flat audio, and something with 17dB of HF boost will not sound good after encoding. You can have the audio de-emphasized at the processor output and pre-emphasis enabled again in the stereo generator at the other end of the STL, but the performance of this configuration will largely depend on the processor and stereo generator used (you want at least the same brand). Typically, it doesn't sound as good as the processor alone.

So the better option is to have the processor at the far end of the bit reduced STL (at the TX site). There is no better way to connect the processor and the transmitter, than through a short length of coax. And the STL would operate on flat audio. If your bit reduced STL has 16 bit resolution, then as I mentioned, it would be good to have an AGC in front to protect it or be smart how you set up levels. If it has 24 bit resolution then you wouldn't need aynthing in front as you'd have the same or even more (in case of analog console) dynamic range than your console .


Regards,
Goran Tomas

 

[stephend2]

I did some experimentation with lossy codecs for STL just to see the effects, not nice. I've settled in on using a comrex bric-link running FLAC over a t1 circuit. This has worked quite well for nearly 4 years now. dsp-xtra at tx site working great, demo'd omnia.9, wanted to keep it, just wasn't in the budget

 

[WNTIRadio]

That's an excellent question!

The ideal solution would be if you could split the processor in half, and have one half (the leveller and the multiband AGC) before the bit reduced STL and the other half (limiting, clipping and stereo generation) after it. Come to think of it, with the latest version of firmware for Omnia 11, that's actually possible to do! Though you would need to have two boxes Wink

To clarify, it's beneficial to have the multiband AGC in front of the bit reduced STL to feed it consistent levels and to protect it from clipping. However, a complete processor in front of the bit reduced STL would employ pre-emphasis and having pre-emphasized audio going into the codec is a really, really bad idea. Perceptual codecs were designed for flat audio, and something with 17dB of HF boost will not sound good after encoding. You can have the audio de-emphasized at the processor output and pre-emphasis enabled again in the stereo generator at the other end of the STL, but the performance of this configuration will largely depend on the processor and stereo generator used (you want at least the same brand). Typically, it doesn't sound as good as the processor alone.

So the better option is to have the processor at the far end of the bit reduced STL (at the TX site). There is no better way to connect the processor and the transmitter, than through a short length of coax. And the STL would operate on flat audio. If your bit reduced STL has 16 bit resolution, then as I mentioned, it would be good to have an AGC in front to protect it or be smart how you set up levels. If it has 24 bit resolution then you wouldn't need aynthing in front as you'd have the same or even more (in case of analog console) dynamic range than your console .

IF the budget allows, the best way to do this is with an Ariane in front of the STL and the processor at the TX site. Either open the window up to 6-8dB on the wideband AGC on the main box or turn it off. Keep in mind that the following sections of the processor are meant to work with the AGC on, so you will have to get the levels in those sections back under control. Usually turning the multiband AGC drive down by the average G/R of the wideband AGC will put everything back to normal.

 

[PTBoardOp94]

test123, thanks for the tip about XDS -- we started doing that several months ago.

 

[davideduardo]

I don't know of any stations that have standardized on MP3.

Funny, because there is a de facto use of MP3s since many record companies distribute new releases first as MP3's. Some, later, make .wav files available later, but not everyone gets them and many stations just keep playing the original MP3 release. ..

As I said, I don't know of any station that has standardized on MP3. Which music service distributes in only mp3 and which station has standardized on that format as a result? As I said, I don't know of one, although I obviously don't know the formats of all stations. I've certainly seen music services use MP2, as I've already stated. In fact, MP2@256 was used by CC for many years. Don't know if it still is.

My point is that the MP3s creep in, and often get converted to other schemes, worsening the effect.

And I am speaking of the record companies themselves, not programming or music services. The problem is that we don't know where program services got their original material and in what format it arrived. I see upconverted things all the time.

 

[test123]

PTBoardOp94

I believe Racing Country will be stepped up to 256 kbps for this week's download.

hh

 

[ChiefOperator]

I don't know of any stations that have standardized on MP3.

Funny, because there is a de facto use of MP3s since many record companies distribute new releases first as MP3's. Some, later, make .wav files available later, but not everyone gets them and many stations just keep playing the original MP3 release. ..

As I said, I don't know of any station that has standardized on MP3. Which music service distributes in only mp3 and which station has standardized on that format as a result? As I said, I don't know of one, although I obviously don't know the formats of all stations. I've certainly seen music services use MP2, as I've already stated. In fact, MP2@256 was used by CC for many years. Don't know if it still is.

My point is that the MP3s creep in, and often get converted to other schemes, worsening the effect.

And I am speaking of the record companies themselves, not programming or music services. The problem is that we don't know where program services got their original material and in what format it arrived. I see upconverted things all the time.

Fair enough. Yes, I agree with you. Thanks for the clarification.

 

[radiogooroo]

My point is that the MP3s creep in, and often get converted to other schemes, worsening the effect.

And I am speaking of the record companies themselves, not programming or music services. The problem is that we don't know where program services got their original material and in what format it arrived. I see upconverted things all the time.

Yup. No doubt about it. Your automation system and air chain can be 100% linear digital and either a label rep or music director will inevitably convert an MP3 to WAV somewhere along the way.

After hearing compression artifacts in several songs on one of my stations, I asked the station's MD about it. As it turned out, he was downloading the MP3 version from a label's distribution site because he didn't want to wait for the WAV files to download. This is with a relatively fat pipe to the internet, so it shouldn't have taken that long for the WAVs to download.

Then I heard artifacts in custom intro mixes that our imaging guy made for another one of my stations. The difference was plainly audible because the normal versions, that the jocks would talk over or run with other imaging pieces, sounded so much better. As it turns out, this imaging guy was exporting his mixes as MP3 files at a relatively low bitrate.

This is in a top 10 market.

Many programming people just don't grasp how an MP3 file that sounds OK to them isn't an OK option.

 

[chriscollins]

My point is that the MP3s creep in, and often get converted to other schemes, worsening the effect.

And I am speaking of the record companies themselves, not programming or music services. The problem is that we don't know where program services got their original material and in what format it arrived. I see upconverted things all the time.

Yup. No doubt about it. Your automation system and air chain can be 100% linear digital and either a label rep or music director will inevitably convert an MP3 to WAV somewhere along the way.

After hearing compression artifacts in several songs on one of my stations, I asked the station's MD about it. As it turned out, he was downloading the MP3 version from a label's distribution site because he didn't want to wait for the WAV files to download. This is with a relatively fat pipe to the internet, so it shouldn't have taken that long for the WAVs to download.

Then I heard artifacts in custom intro mixes that our imaging guy made for another one of my stations. The difference was plainly audible because the normal versions, that the jocks would talk over or run with other imaging pieces, sounded so much better. As it turns out, this imaging guy was exporting his mixes as MP3 files at a relatively low bitrate.

This is in a top 10 market.

Many programming people just don't grasp how an MP3 file that sounds OK to them isn't an OK option.

You have to teach the staff what to do. I had a class. It took me months to make everyone 'get' it. They do now... It's all .wav.

Even in our branded intro's (where the workparts come from .mp3), after the intro, it switches to the .wav version. I hope at some point we convince the services that do that to go to .wav. Because of this, I only play one branded intro song in an hour.

 

[TimmyWA]

My question is if you HAD to only use MP3, would 320 CBR be better than the highest settings for VBR, I think -q0 -v0 or something. I've heard some swear by the latest Lame using VBR over the 320 CBR settings... Any info on this?

 

[Jack Griffin]

My question is if you HAD to only use MP3, would 320 CBR be better than the highest settings for VBR, I think -q0 -v0 or something. I've heard some swear by the latest Lame using VBR over the 320 CBR settings... Any info on this?

If you HAVE to use MP3, DO NOT use VBR.

The idea behind VBR was to use lower bitrates in some parts of the file to reduce its overall size. It does NOT produce higher fidelity.

That being said - due to the nature of the MP3 codec, you won't notice a HUGE difference between say, 256kb/sec and 320.

I've worked with compression for well over two decades now...here's the preferred order of things:

1. WAV (naturally)
2. Lossless codecs (FLAC, APE, etc)
3. MP2 at VERY high bitrates (384 kb/sec)
4. MP3

 

[chriscollins]

My question is if you HAD to only use MP3, would 320 CBR be better than the highest settings for VBR, I think -q0 -v0 or something. I've heard some swear by the latest Lame using VBR over the 320 CBR settings... Any info on this?

If you HAVE to use MP3, DO NOT use VBR.

The idea behind VBR was to use lower bitrates in some parts of the file to reduce its overall size. It does NOT produce higher fidelity.

That being said - due to the nature of the MP3 codec, you won't notice a HUGE difference between say, 256kb/sec and 320.

I've worked with compression for well over two decades now...here's the preferred order of things:

1. WAV (naturally)
2. Lossless codecs (FLAC, APE, etc)
3. MP2 at VERY high bitrates (384 kb/sec)
4. MP3

That is a good post, Jack. I would agree. Also, VBR can wreck havoc on Automation Systems.

High bit .mp2 sounds better than .mp3 to me as well.

Our only mp3 is the commercials, which is the norm now... I do blow them back to .wav, as my Automation is happier with .wav. When a file gets blown up in my building, it gets a special tag I can search that shows MP3SOURCE.

 

[gtomas]

1. WAV (naturally)
2. Lossless codecs (FLAC, APE, etc)
3. MP2 at VERY high bitrates (384 kb/sec)
4. MP3

High bit .mp2 sounds better than .mp3 to me as well.

MP2 is also less sensitive to cascading with another codec that might happen down the line... As is AAC (LC). MP3 is actually the worse bit reduction codec you can use...

Our only mp3 is the commercials, which is the norm now... I do blow them back to .wav, as my Automation is happier with .wav. When a file gets blown up in my building, it gets a special tag I can search that shows MP3SOURCE.

That's an excellent practice! So many WAVs (and even FLACs) originate from poor MP3 files and people assume just because it's WAV, it's good audio quality. Unfortunately, that's no guarantee. Quite often you can tell by the poor sound and the artifacts, but people on the station just don't bother to listen or are not sensitive to that (which doesn't mean your listeners aren't!). So having a tag is a very useful technique.


Regards,
Goran Tomas