Newb question on how broadcasting works

[dnewhous]

Is there any enforced dependency on the source files used to broadcast and the bit rate and codec of the broadcast stream?

[DJ-Garybaldy]

General rule on thumb is to have the mp3 files ripped at 320kbps CBR Then you can stream at 128kbps and everything will sound OK.

[neralex]

If you are streaming with 128kbit then can encode the mp3 files directly to 128kbit. There is no reason to rip it with 320kbit and let the DNS encode the mp3 to a lower bitrate. In a perfect world should have the source the same bitrate as the stream.

[jaromanda]

Originally Posted by neralex

If you are streaming with 128kbit then can encode the mp3 files directly to 128kbit. There is no reason to rip it with 320kbit and let the DNS encode the mp3 to a lower bitrate. In a perfect world should have the source the same bitrate as the stream.

DNS (you probably meant DNAS) doesn't do any encoding.

In the case of shoutcast toolset for broadcasting, it's the shoutcast DSP that encodes the stream ... which it does regardless of the source format .... i.e. if your file is 128kbit mp3 and your stream is 128kbit mp3, shoutcast DSP still encodes it

This is because shoutcast DSP receives the DECODED data (eg 16bit stereo PCM at 44,100Hz sample rate) - winamp sends this data to the DSP before it then sends it to the output plugin that is in use

a really simplistic view of the winamp "pipeline":

code:
input plugin (decodes the file) -> winamp -> DSP (encodes the file) -> winamp -> output plugin 

technically, the DSP could alter audio, so it sounds different ... after all DSP stands for Digital Signal Processor - in broadcasting situation, as far as winamp is concerned, the DSP is doing nothing, as the data is unchanged by it.

in the shoutcast world, all source clients (shoutcast DSP, altacast, liquidsoap) behave the same way, source audio is always somehow decoded, the source client (shoutast DSP, altacast, liquidsoap etc) encodes this raw audio and sends it to DNAS, which distributes the data to the listeners unchanged (at least the audio part)

For this reason, it's best to have the source audio in the BEST quality you can manage (lossless is king) - because it will get decoded then re-encoded.

also, having the files in 320kbit means you can use them for other purposes that you may want higher quality for, as well as streaming

edit: this is much longer than what I was going to originally write, which was "magic elves do things for you" - but I couldn't let the misinformation go through to the keeper

[DrO]

in addition to jaromanda's post, you need to keep re-processing of input media for a stream to a minimum as generally you're going to be loosing more information the more that gets done, especially if you have a DJ connect to an auto-dj and that then re-encodes the stream.

e.g.
the defunct sc_trans did that even when it shouldn't have been needed if it already matched the existing format of the stream. as doing that means the DJ audio will sound worse than the directly played files via the auto-dj, though often having the DJ stream at a higher bitrate to the auto-dj than needed for the stream (doubling the DJ bitrate vs stream bitrate seemed to work reasonably well from those having issues) and that should then not be too noticeable.


though however you look at it, most streams are going to be compromised on their audio quality and unless you stream lossless formats (which eat up bandwidth like a fat kid in a sweet shop), you have to pick what is best for a) what you can afford and b) what gives you / the listeners a reasonable listening experience based on the content you're providing.

as there's little when it comes to players or specific encoders having an effect on the audio quality, it's primarily how many stages of re-processing of the audio that may have gone on and what the quality of the input media is to begin with that is the cause of bad stream audio.

[neralex]

Sorry for the confusion but i'm working since some years with DNAS v2 and sc_trans. I know all the bugs around sc_trans but it works for my 3 streams on a linux based station. I think Gary was on the same way because this way of encoding is sc_trans based or tools likes that. It's clearly to hear if the source on another bitrate instead as the same bitrate as sc_trans is configured. That's what I meant. Maybe sometimes the DNAS will provide features like sc_trans. The combination of auto-dj, scheduled playlists and user-management together with the DNAS is for my little person the perfect way to manage a stream. Anyway... i hope it make it clearer what I meant. Cheers!

[DrO]

Originally Posted by neralex

Maybe sometimes the DNAS will provide features like sc_trans. The combination of auto-dj, scheduled playlists and user-management together with the DNAS is for my little person the perfect way to manage a stream.

it's not viable to have an auto-dj like sc_trans in the DNAS itself, primarily due to the aspect of (re-)encoding certain formats and doing things 'legally' (despite what a lot of products fly in the face off doing).

of the sc_trans feature set, scheduling / management of sources is probably the most viable to port across in some form i.e. when and which DJ can connect or when to use a relay instead of a DJ (though you'd probably not be able to have cross-fading due to my prior comment as that involves audio processing). other aspects mentioned against sc_trans are better suited at the source level rather than at the DNAS level. as controlling who can connect as a source (other than as a general password for the stream) is something I've seen requested a number of times.

[jaromanda]

Originally Posted by neralex

It's clearly to hear if the source on another bitrate instead as the same bitrate as sc_trans is configured.

if you're saying that if you use sc_trans to send 128kbit, you need to have files encoded in 128kbit, you're still wrong. sc_trans can send multiple streams in multiple bitrates and multiple codecs - it re-encodes just like shoutcast DSP, altacast, liquidsoap etc etc