Elio Antoine logo
← Writing

SoundCast Streamer: a technical case study

A broadcast encoder built for the gap between "too basic to trust" and "too bloated to need," paired with a backend built to keep a station's dashboard accurate without leaning on the streaming server it depends on.

PlatformWindows desktop
Server protocolsIcecast 2, SHOUTcast v1/v2
CodecsMP3, AAC, AAC+, OGG, OPUS, FLAC
Bitrate range32–320 kbps
DSP chain10-band EQ, compressor, true-peak metering
Source securitySSL/HTTPS source connections

The problem it had to solve

Broadcast encoding software tends to sit at one of two extremes. On one end, bare-bones tools that connect a soundcard to a stream and little else, no DSP, no real stats, nothing to help diagnose a bad connection. On the other end, full station-automation suites that bundle an encoder inside a much larger, heavier product, overkill for someone who already has playout software and just needs a clean, dependable bridge to Icecast or SHOUTcast.

SoundCast Streamer is built specifically for the space between those two: a dedicated encoder, not a playout system, with enough signal processing and protocol coverage to be a station's actual on-air path, not a stopgap.

Encoder architecture

The encoder captures audio from any Windows input, physical microphone, USB audio interface, or line-in, or alternatively relays an existing HTTP/HTTPS internet radio stream and re-encodes it outward through the user's own server. That relay path matters for stations that need to simulcast or rebroadcast a feed they don't originate, without standing up separate infrastructure to do it.

Codec and bitrate handling

Output covers MP3, AAC, AAC+, OGG, OPUS, and FLAC, spanning 32 to 320 kbps. Supporting that range isn't just a checkbox, AAC+ in particular exists precisely because it holds up at lower bitrates where plain MP3 degrades audibly, which matters for stations bandwidth-constrained on the listener side. OPUS support was added specifically because at low bitrates it consistently outperforms AAC in perceived quality, giving low-bandwidth listeners a materially better stream at the same data cost.

Sample rate as a first-class concern

A subtlety that shows up constantly in real deployments: the encoder's configured sample rate has to match the sample rate of whatever virtual or physical audio device feeds it. A mismatch, say the encoder set to 48kHz while a virtual audio cable is set to 44.1kHz, doesn't fail loudly. It produces periodic audio cutoffs, often every couple of seconds, that look like a network problem but are actually a clock mismatch between the capture device and the encoder. Because this is a common real-world failure mode rather than an edge case, the encoder treats sample rate matching as something to actively surface to the user rather than something buried in an advanced settings tab.

DSP chain

Signal processing runs a 10-band EQ ahead of a compressor with threshold, ratio, and master gain controls, plus true-peak metering so a station can see actual peak levels rather than sample peaks, which matters for anyone mastering their chain to broadcast-safe levels rather than just watching a VU meter and hoping. This sits entirely inside the encoder, before the signal ever reaches the streaming server, so the processing is consistent regardless of what the server side does or doesn't apply.

Protocol and connection security

The encoder speaks Icecast 2 natively and both SHOUTcast v1 and v2, covering the two server families that make up almost the entire self-hosted streaming ecosystem. Source connections support SSL/HTTPS as a toggle rather than a separate configuration path, since an encoder that only supports plaintext source connections is a non-starter for any server run behind a reverse proxy with TLS termination, which is the default posture for anything hosted seriously today.

The encoder's job ends at the stream. Everything past that, who's listening, from where, for how long, is a separate system with its own constraints.

What happens after the stream leaves the encoder

Once a station is live, the dashboard side has a different problem to solve: reporting listener data without adding load to the server actually serving audio. That's handled by splitting "live" and "historical" into separate data paths rather than one polling loop. A live listener count polls the streaming server's admin interface every few seconds, cheap, because it's just a connection count. A full breakdown by country, session length, and player type is aggregated separately from stored session history and refreshed on a much longer interval, since that data doesn't need second-by-second freshness to be useful. Geo lookups for listener IPs are cached per-IP rather than re-queried on every poll, so a busy stream doesn't turn every dashboard refresh into a burst of outbound API calls.

The practical effect: the dashboard can show a station "how many people are listening right now" with almost no lag, while the historical view stays accurate and cheap to serve, because neither one is trying to do the other's job.

Where the free and pro tiers split

The Free edition covers real, unrestricted live streaming, audio capture, MP3 encoding, Icecast and SHOUTcast connection, with no time limit and no account requirement beyond the basics. Pro unlocks the full codec and bitrate range, the complete DSP chain, and priority support, licensed per machine as a one-time purchase rather than a subscription. That split exists so a hobbyist broadcaster on Free isn't blocked from going live at all, while a station that needs true-peak metering and OPUS at 320kbps has a clear reason to upgrade.