JesseG

[quote author=”Otto”]But the bigger stations here they have for example an Orban 8500 in the studio and a 2300 at the transmitter…
What is the reason behind that?[/quote]I would have to say that they don’t know what they are doing, and that their audio quality is without a doubt suffering because of it.

[quote author=”Otto”]If I understand correctly, BBP clipping is audible on the normal output and not only on the MPX out?[/quote]Any clipping at all is audible to the trained ear. The thing Breakaway avoids is audible distortion. Hearing clipping and hearing distortion artifacts of clipping are two different things. But yes, the FM backend processes in L/R, and that is available for the L/R outputs, then it goes on to the stereo encoder and is optionally mixed with RDS input, and that is available for the MPX output.

[quote author=”Otto”]My idea was just a littlebit of clipping to compensate any overshoot due to the STL.[/quote] Think about it this way… Breakaway (and any other audio device of any kind… digital or analog) only has so much headroom before it runs out.

In the digital world, 0db is the max, so there is a common "headroom" of "none" without compensating to adjust for that. Let’s say we’re compensating by considering 0dBu to be -12dBfs. So now we have 12dBfs of headroom above 0dBu. Whatever your broadcast engineering team has decided is best for your setup and the way you work should be what is stuck to, unless it’s not working of course. Either way, a standard for where your studio’s 0dBu is at in relation to dBfs should be defined, if you guy have not done so yet. I wouldn’t recommend going with less than 12db headroom. The "old" analog studio standard is +24dBu headroom, which is a LOT of headroom, but they also are not using such high gains and often better equipment (and noise reduction) than many broadcast studios.

Anyways… that being said…

If there is an "over" the headroom sent down the digital chain, does it matter if it hits Breakaway 1st or your STL 1st? Well it depends on how your STL handles clipping. You did mention that you were considering using a "Protection Limit" down the line to compensate for overshoots from the STL?? If you would have to do that, then your STL is just not lossless, it would HAVE to be doing something to the audio, and that is all the more reason to have Breakaway Broadcast at your transmitter.

[quote author=”Otto”]But if it’s better to just send pure audio (unprocessed) to BBP at the transmitter than that’s an option for sure. But how to control the outgoing level to make sure that it isn’t clipping at the input…[/quote] Imho it is better, you can always put a remote control application (i recommend RealVNC Enterprise) on the host computer and then it doesn’t matter where it is (or for that matter where you are) at to be adjusting your on-air sound.

As far as controlling outgoing level, that’s the mixer’s JOB to do. The only thing you can do is allow some headroom for mistakes before the audio processing. Putting something like a Compellor before your STL will NOT make any problems go away, in fact it can just make them worse, because a Compellor eventually runs out of headroom just like everything else AND it’s applying gain (which will change your sound, and it’s NOT remote controllable with VNC 😉 ) and possibly contributing to distortion. See what I’m getting at?
💡

[quote author=”Otto”]unbelievable that it can be achieved on a windows computer.[/quote]A modern computer could probably run 10 Omnia6’s on it. 🙂

[quote author=”Otto”]Everyone who listened to the sound thought is was an Orban or Omnia but definitly not software 😉[/quote]Even though an Orban or Omnia actually is software too? That’s a good sign that you have been a victim of marketing. 😉 In a way I know what you mean, but all digital audio processing is in fact software, and it goes to show how people’s thinking has been skewed by marketing… and Omnia and Orban are hardly the only companies responsible for that.

[quote author=”Otto”]What I wanted to do is to place a PC with BBP in the studio and one at the transmitter to do the finishing touch.[/quote]The argument against that is you’ll be limiting & clipping the audio twice in the final stage. That will cause distortion to happen, and you won’t get as loud or clean an output from the final BBP as it’s FM backend will compensate to try not re-distort those clipped waves as bad. Remember clipping IS distortion, BBP just does it with control never before heard.

I would take sam’s advice and think about using Breakaway Broadcast at the transmitter, and using Breakaway Live in your studio. Live will just process your studio monitors/cans sound, with MINIMAL latency (about 5ms total with a decent ASIO capable AD/DA converter). And BBP will just process the transmitter. The STL will be fed with the same audio being fed TO Live in the studio, not fed the output of Live (as that would double process, and you would get the same distortion product i mentioned above too except more IMD vs THD)

I tested Breakaway Live down to about 5-6 ms total latency, with an RME. But most converters that support ASIO should be able to get down round there is there is not a problem with the OS – mainly bad device drivers.

Try checking the DPC Latency
http://www.thesycon.de/deu/latency_check.shtml
and going through each device in your Device Manager, and disabling one at a time to track down the problem.

Actually, what I usually do is disable all of the network and usb/firewire devices first, and see if that overall fixes the problem. If that does fix the problem then it’s a lot easier to spot when you turn each of them on one at a time.

Oh, and make sure to use a card that actually supports ASIO. ASIO4All is just an interface between ASIO and Kernel Streaming, and you’ll get more delay from using that, than just using the Kernel Streaming already build into Breakaway. 😉

[quote author=”richardjames2005″]Thought I could still hear some IM distortion, so I dialled back the final drive to -3.5db on Twente preset. I think its gone, although, I can still hear some occassionally….. Must be the source mp3’s I think… I have heard another dance station that wont touch a tune unless its in uncompressed WAV format, now I am starting to understand why!!!![/quote]

Most of my collection is digitized as FLAC and good quality layer-3 (Lame apx or V0 with low-pass as high as it goes, the extra size is worth it). For 99% of everything I would be hard pressed to ABX it against the originals.

Even though some/most/whatever of your mp3s might have artifacts, the problem you’re having is not one inherent in layer-3 coding itself. It’s probably some problem with the ripper (not too likely unless it’s processing the audio, still you should switch to Exact Audio Copy w/ Secure + AccurateRip) or the playback/transport (most likely).

Why don’t you share here one of the songs that you think is especially effected by whatever is causing this for your end-stream sound, so we can check out the mp3. 😉

Oddly enough, it’s not so much that the attack is too slow. That’s part of what going on there, and as Leif said it’s a compromise that has to be made. There’s a number of things at play.

That being said, here’s an example of a new preset with considerably slow attacks, that handles it fine (only because I recently tweaked it after hearing that cut you uploaded, lol, i cheat, i really do 😆 ) But I did run the "Torture Test" over it, and it handles that flawlessly.

This is a combination of Rusticity and Plutonium, if you didn’t figure that out by the name – two imho very good sounds by myself and Leif. This sound is not possible with any other audio processor, period. There are parts of this sound that rely on some things that only Breakaway has.

It’s a work in progress, but worth showing off already. Check it out:

Yes, sounds too dense and mainly the high frequency, seems like there’s something going on there… you’re not using Ots’ EQ either?

I bet it feels good to finally be able to make that one public Leif. I can only imagine how hard that was to keep a secret for you (and I knew the whole time too 😛 )

[quote author=”lpy”]Out of interest JesseG, any particular reason why 3.90.3?[/quote]
Because after a lot of extensive testing even using recent "fixes" for CBR (ala v3.98b) I still think that v3.90.3 is the best for streaming in the 96kbps to 192kbps range. It may also be as well for under 96kbps, but I could care less. 😛

There was one other preset that was close, and it was v3.98b with preset 5. The tonality and pureness of notes/pitches seemed to be slightly more accurate. I was telling Leif that I even found one harmonic of a chord that was completely missing in preset 12 that preset 5 "nailed" on all of the versions of Lame that I recently tested. But preset 12 seems to have the best accuracy in the treble areas with transients and airy/spacey very hard to encode stuff, it performs flawlessly with. And most listeners (read: most people’s gear) are much more likely to hear artifacts happening there, than a slight loss in the quality of the tonality of the codec. Preset 12 is still really close, and I do have to consider that I’m listening on high-end mastering-grade gear. 🙂

And so that’s why I recommended preset 12, and Lame 3.90.3. Lots & lots of testing.

3.90.3 is a custom version of Lame 3.93 which was done by Dibrom and John33, two of the several main guys behind the Lame project. It has a number of tweaks which can not be accomplished using any configuration string or dll interface. For CBR I have yet to hear better. And even for lower-kbps VBR it does a VERY good job at keeping the quality up and the rates low. Around the 160kbps VBR area, it just dominates all of the other codecs I have tested.

Also, I always do my testing of stuff like this as blind ABX, unless the difference is totally apparent. To make sure that I’m not a victim of my own bias.
😆