• Get involved.
    We want your input!
    Apply for Membership and join the conversations about everything related to broadcasting.

    After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
    If you use a disposable or false email address, your registration will be rejected.

    After your membership is approved, please take a minute to tell us a little bit about yourself.
    https://www.radiodiscussions.com/forums/introduce-yourself.1088/

    Thanks in advance and have fun!
    RadioDiscussions Administrators

TCP STL to cable headend: AAC or OGG?

I need to get a signal to a cable headend where it will be distributed both digital (muxed) and analog (plain modulator). I would like to crank up the quality as high as I can so I would like to go with AAC 320kbps. This is the receiver the cablecompany uses. The same company also offers an encoder. But the encoder offers only OGG Vorbis, at max 256kbps. It seems the receiver only offers AAC+ and not AAC. Combining the encoder with the decoder does offer some advantages, but I could also use a software-encoder on the Breakaway-PC and still go for AAC. I hear good things about OGG but have no experience with it whatsoever. Any wise advice?
 
At 256kbps, I think you'll be hard pressed to hear the difference between OGG and AAC.

I can hear the difference between AAC 320 and the uncompressed CD, but only on certain tracks and only if I really listen close. The AAC licenses are expensive for the encode option, that's why they don't have it.

If you're using Breakaway on a PC already, just keep it in the box and use the AAC encoder on your PC.
 
I can't think of an AAC+ capable encoder or decoder that can't also handle AAC. To get the software licensing for one, you usually end up getting the other included as far as I can tell. Unless you've tried it and it doesn't work, I'd suspect it will.

Given the option I'd pick the 320k AAC every day. It may be possible for some people to hear the difference between that and uncompressed source, but it's going to be awfully tough.

That's my vote.
 
Generally, if AAC+ is available, so is AAC, so do check it out.

AAC+ (aka AAC-HE) is optimized for very low bitrates and is not preferred for higher rates. AAC+'s trick is Spectral Band Replication (SBR) which is a predictive algorithm where, to save bandwidth, the codec doesn't bother properly encoding the high frequency energy. It then estimates what the HF energy should be and produces fill-in energy. This works surprisingly well, but is not really a very close copy of the original. AAC+ should not be used for streams over about 64kbs if regular AAC, or a comparable codec, is available. Above 64kbs, you can start getting better results from some of the low bitrate Ogg codecs. Above 100kbs, mp3 starts to become an option, though mp3 is generally best above 192 or 256k.

Ogg is a very high quality, open source, codec that has evolved quite a bit since first introduced in the late 1990s. The current versions of Ogg are considered by many (so-called) experts to be better than mp3 at all bitrates and equal to or better than AAC at bitrates over 100k. Supposedly, at bitrates of 100k or more, most people cannot distinguish between the uncompressed source and Ogg. I've worked with it quite a bit and Ogg is good above 80kbs and very transparent at 100kbs. Streams at 135kbs are nearly indistinguishable (to me) from the original. All stereo Ogg streams are true stereo as opposed to joint stereo for AAC below 128k.

Now, the bad news: Although a very high quality codec, Ogg-Vorbis was written for file storage, not for streaming. For a variety of technical reasons that are beyond the scope of this forum, Ogg may, or may not, be satisfactory for long term streaming despite its better than mp3 quality. The main problem with Ogg is a tendency to overflow or underfill its streaming buffer resulting in drop-outs or glitches. These can occur at any bitrate or network speed and regardless of the buffer size. This can be a real problem if not properly managed.

We've done quite a bit of work on hardware Ogg stream encoders and decoders. There are some tricks that can be employed to improve reliability for Ogg streaming between two hardware devices, but it's hard to determine if these have been employed in the streamer that you are considering. For that reason, I would strongly suggest that you test the devices, as a pair, to ensure that the streaming is reliable before adopting a codec. If the streaming between the two boxes is reliable and free of artifacts, then Ogg can work well for you.

Finally, I note that both the encoder and decoder offer mp3 as an option. Be sure to also test mp3 streaming as a possible fallback mode if Ogg proves unreliable on these boxes. You should not consider AAC+ unless streaming at a low bitrate, however, if AAC is available, you should strongly consider it as an option.
 
Chuck said:
Any suggestions for an affordable AAC encoder?

Omnia A/XE - runs as Windows service, very reliable and resource efficient, includes basic 3-band processing with look-ahead limiter, supports running multiple encoders with different settings for the same audio source.

Adobe FMLE (designed more for video streaming) with MainConcept AAC plug-in - a bit cheaper, single stream encoder that runs as application. Not as stable, has been known to crash when running 24/7.


Regards,
Goran Tomas
 
SAMcast was very reliable for my needs in the past. I encoded my stream as an OGG stream and 2 MP3 streams of different bitrates and SAMcast almost never had an issue.The streams could automatically restart on their own if something happened at the server side.
 
weskeene said:
Spacial.com also sells a standalone encoder that does AAC. It's called SAMCast. I've been happy with it.

I've been using their previous version, called Simplecast. It has worked well for years but doesn't support AAC. It may be time to upgrade to SAMCast.
 
Status
This thread has been closed due to inactivity. You can create a new thread to discuss this topic.
Back
Top Bottom