Maximize listeners and quality

[BerntStone]

Please excuse this if it's been explicitly answered somewhere. I am asking since I can't find the answer, but learned a while pile looking. Here's the background:

We are a non-profit (we don't want to spend more than is necessary) community station with 2.5Mbps up and up to 250GB/mo. We have been hosting our own sc1 with 128,56, and 24 MP3 streams. Our (2) 128 slots are often full, often 4-5 of our (6) 56 slots full, and many 24bit slots used. It should be noted that most listeners currently receive our terrestrial broadcast as opposed to our streams.

We are testing a new sc2 install and would like to do our best to get this right, or to at least make the greatest number of happy listeners with the least additional cost (if any).

The new sc2 requires an MP3 license which I assume wasn't needed in sc1 until Fraunhoffer asserted its rights and is potentially part of the reason for the change to sc2.

I am considering switching to AAC [HE-AAC or v2(??)] as: A) free B) ++ quality/size vs MP3 C) overall net increase in listeners/same bandwidth D) increased prevalence of 3g/4g smartphone/tablet listeners which may not have the same bandwidth available to residential plans.

and questions:

1. Can you offer any real data as to preferred format, in your experience or of your listeners? Statistical preferences of listeners? If given a choice, will most listeners simply choose MP3 due to familiarity?
2. Would eliminating MP3 alienate a large number of listeners? Looking at the w3c log (without parsing) shows mostly winamp/itunes (should be no decoding issue), some various other players (real/VLC/etc - unsure of realplayer+AAC) - but unsure of how to interpret MPEG-OVERRIDE [possibly the shoutcast web client?]
3. Should we leave a couple 56K or 24K mono MP3 streams up for legacy players without AAC support?
4. Should I ask someone like Rusty at SomaFM, since they have all the bases covered?
5. Is it worth bothering with OGG?
6. Any issues to be aware of using VBR? I've never experience a problem except for something with editing. Intuitively, it sounds more like a more efficient use of bandwidth
7. We may change to a new IP and keep the static line for other needs. If the new line is DHCP and DDNS is through someone like no-ip.org, couldn't there be an issue if the ISP assigns new IP at renewal time and someone is streaming? Won't their stream drop? SURE, DDNS will resolve for new connections to the new IP, but what about current connex? Spend the extra ten bucks for static IP on this line too, I suppose. Although, a case could definitely be made for putting the other services on the DHCP/DDNS line.

Also, this IP would be serving ONLY shoutcast - no other throughput on this line.

Sure, the tool at http://www.radiotoolbox.com/online_tools/bandwidth.php is a help, and we could theoretically support approx 36 listeners at 64Kbps AAC which would give us many more than current max listeners, and equivalent if not better quality than 128 MP3, but what about a lower bitrate AAC? The thing that concerns me is that if people find out there are more streams that sound good than before, we might exceed monthly limits and overages aren't something we want to incur.

I know I am asking a lot and I also know that I should probably learn how to parse the logs to historically know our listeners. I do also know that some are tech savvy and want more and better streams, but some are not at all familiar with anything technical and I don't want alienate them by not providing MP3.

I await your reply and look forward to reading and learning more... Thanks for your time.

[DrO]

i'm only going to answer a few parts that i've the time to and can safely answer.

The new sc2 requires an MP3 license which I assume wasn't needed in sc1 until Fraunhoffer asserted its rights and is potentially part of the reason for the change to sc2.

that's only needed if using the Transcoder (sc_trans) - if just using the v2 DNAS and a 3rd party source then there is no fee - the DNAS itself is _always_ free.

[*]Would eliminating MP3 alienate a large number of listeners? Looking at the w3c log (without parsing) shows mostly winamp/itunes (should be no decoding issue), some various other players (real/VLC/etc - unsure of realplayer+AAC) - but unsure of how to interpret MPEG-OVERRIDE [possibly the shoutcast web client?][*]Should we leave a couple 56K or 24K mono MP3 streams up for legacy players without AAC support?

if you have an idea of what your user base generally goes with and AAC+ is generally supported then that would be better for better audio quality at a lower stream rate. it probably would alienate some people, though the best would be to have say the AAC+ stream with most slots and a MP3 one with few connection slots available for those who cannot or will not go to AAC+.

[*]Is it worth bothering with OGG?

it's not supported with SHOUTcast. nothing is stopping you running something else which supports it but OGG streams cannot be listed in the Directory.

[*]Any issues to be aware of using VBR? I've never experience a problem except for something with editing. Intuitively, it sounds more like a more efficient use of bandwidth

depends if the source you're using properly supports it since the official tools generally output the MP3 streams as CBR (with the m3pmode option in the Transcoder not working due to library issues and so will be removed in the next drop of it).

[*]We may change to a new IP and keep the static line for other needs. If the new line is DHCP and DDNS is through someone like no-ip.org, couldn't there be an issue if the ISP assigns new IP at renewal time and someone is streaming? Won't their stream drop? SURE, DDNS will resolve for new connections to the new IP, but what about current connex? Spend the extra ten bucks for static IP on this line too, I suppose. Although, a case could definitely be made for putting the other services on the DHCP/DDNS line.

tricky one since the YP in it's current state (if you're listing in it) will likely start throwing errors if the IP changes. though i'm hoping some changes i'm making to how it works will allow for IP changes to keep listings running (just no eta on when that'll go live). yes it'll cause the clients to fail, there's nothing which can really be done about that. though it's probably safer in the long run to have a static IP as clients do seem to get cranky when their stations suddenly go away due to such things like IP changes.

-daz

[BerntStone]

Thx DrOfor your prompt reply - you really do do a huge amount of work here and I appreciate your time and input. So far, all I can say is you have validated that much of what was thinking of and trying to say. I eagerly await any other input from others. Peace