Old 30th January 2015, 06:46   #1
dnewhous
Member
 
Join Date: Dec 2006
Location: Cedar Rapids, IA
Posts: 87
Newb question on how broadcasting works

Is there any enforced dependency on the source files used to broadcast and the bit rate and codec of the broadcast stream?
dnewhous is offline   Reply With Quote
Old 30th January 2015, 07:39   #2
DJ-Garybaldy
Major Dude
 
DJ-Garybaldy's Avatar
 
Join Date: Sep 2003
Location: Harpurhey, Manchester UK
Posts: 1,240
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.



Proud USER of RadioDJ since 2010

Online: Twitter - Blog - RadioDJ
DJ-Garybaldy is offline   Reply With Quote
Old 30th January 2015, 08:06   #3
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 576
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.
neralex is offline   Reply With Quote
Old 30th January 2015, 10:08   #4
jaromanda
Forum King
 
Join Date: Jun 2007
Location: Under the bridge
Posts: 2,289
Quote:
Originally Posted by neralex View Post
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

Is it just me or are shoutcast users getting dumber?
jaromanda is offline   Reply With Quote
Old 30th January 2015, 16:23   #5
DrO
 
Join Date: Sep 2003
Posts: 27,873
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.
DrO is offline   Reply With Quote
Old 31st January 2015, 22:23   #6
neralex
Major Dude
 
Join Date: Mar 2011
Posts: 576
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!
neralex is offline   Reply With Quote
Old 31st January 2015, 22:57   #7
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by neralex View Post
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.
DrO is offline   Reply With Quote
Old 1st February 2015, 00:29   #8
jaromanda
Forum King
 
Join Date: Jun 2007
Location: Under the bridge
Posts: 2,289
Quote:
Originally Posted by neralex View Post
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

Is it just me or are shoutcast users getting dumber?
jaromanda is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Shoutcast > Shoutcast Discussions

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump