RDS Setup

RDS is a digital sub-carrier on the FM stereo signal - 57 kHz, low bandwidth, carried piggyback on every FM broadcast. It exposes several fields to the receiver: the 8-character station name (PS), the program type (PTY), the list of alternative frequencies (AF), and a free-form text channel (RT). The RT+ extension on RT carries structured Artist and Title fields. That is what a modern car dashboard reads to show the listener what is on air right now.

Some of those fields are static and live on the encoder itself - PI, PTY, AF get configured once and forgotten. The dynamic fields - RT, RT+, and optionally a scrolling PS - need a fresh value on every track change, and the only place that knows when a new track starts is the playout system sitting in your studio.

The chain is short. Playout decides what is playing. A bridge at the tower side - in this case MetaRadio on Windows, run by the operator of the transmitter site - receives the now-playing line over the network and forwards it to the RDS encoder. The encoder writes the Artist and Title into RT+ (and RT, for older receivers), modulates the result onto the 57 kHz sub-carrier, and the listener's car shows what is playing.

This page is the playout-to-bridge half of that chain. It assumes the tower side already has MetaRadio reachable on the network and an RDS encoder downstream of it. The studio side is what you configure - the steps below are for the playout machine talking to a MetaRadio endpoint someone else manages.

MetaRadio is not the only option. Thimeo Stereo Tool, a broadcast-grade audio processor, has its own RDS encoder and metadata routing built in - so on sites where Stereo Tool already sits in the audio chain, RDS can run through it without a separate bridge machine. That path gets its own page later in the Infrastructure section. The setup below covers the MetaRadio variant.

Test connectivity first

Before you configure anything in the playout software, prove that the studio machine can reach MetaRadio on the chosen port. If the port is firewalled, every test below will look like a configuration problem when it is actually a network one.

The IP and port below are placeholders. The tower operator gives you the real values - usually a private IP reachable over a site-to-site tunnel, plus a port chosen on their side. Every x.x.x.x and xxxx you see anywhere on this page is the same pair, the one they hand you.

On Linux:

nc -zv -w 5 x.x.x.x xxxx 2>&1; echo "Exit code: $?"

On Windows, in PowerShell:

Test-NetConnection -ComputerName x.x.x.x -Port xxxx

Look for TcpTestSucceeded : True in the PowerShell output, or succeeded from nc. If you do not see it, stop here and open the firewall before going further. MetaRadio almost never lives on the same machine as playout - it sits closer to the transmitter, often on a different subnet, sometimes across a site-to-site tunnel. A TCP hole has to exist between your playout machine and MetaRadio before any of the rest of this works.

Zetta to MetaRadio

RCS Zetta sends a Live Metadata stream that MetaRadio reads natively as the ZettaLite XML format. There is no plugin to install on either side - both products were built to talk to each other.

1. Open Zetta as Administrator. You need elevated rights to change system settings.
2. Choose Configuration > System Settings.
3. Open the Live Metadata tab.
4. Add an entry with these values:
   • Active: True
   • Name: a short label - "FM RDS" is fine
   • Description: enough to identify the entry later. Something like "Radio X. FM. RDS. Tower 1"
   • Station: pick the station whose now-playing you want to send
   • Computer: pick a machine on the Zetta network with route to MetaRadio - preferably the one that actually broadcasts the station
   • Format: Zetta Lite
   • Data Encoding: UTF8
   • Device: TCP
   • IP Address: the IP of the machine running MetaRadio
   • IP Port: the port MetaRadio is listening on
   • Connection Style: Close connection after each message
5. Save.

On the Zetta machine you picked in step 4, open the Startup Manager and confirm that Live Metadata under External Services is running. If it was running before you saved, restart it - settings changes do not always take effect live.

That is the entire Zetta side. If the connectivity test passed and the Live Metadata service is running, the next track Zetta plays should arrive in MetaRadio within a second or two.

RadioDJ to MetaRadio

RadioDJ has no native Zetta-equivalent metadata format. It does have a generic Metadata Export plugin that fires an HTTP request on every track change, and that is enough - MetaRadio accepts a custom HTTP payload with the fields it cares about.

1. Open Metadata Export from Options > Plugins > Metadata Export. There is also a Metadata Export button on the main RadioDJ window, usually below the current playlist.
2. Open the Web tab.
3. URL: http://<metaradio-ip>:<port>
4. Custom data: the payload below - more on what goes in it next
5. Export method: POST
6. Enable: True
7. Press the Plus button to add the entry.
8. Save.

The custom data is where you map RadioDJ's track variables to MetaRadio's expected field names. The minimum that covers RDS plus most downstream surfaces:

Type=$track-type$&Artist=$artist_enc$&Title=$title_enc$&StartTimestamp=$now-year$-$now-month$-$now-day$%20$now-hour$:$now-minute$:$now-second$&Duration=$durationinSeconds$&Album=$album_enc$

Append &PlayoutId=<id> or &ExternalId=<id> if your MetaRadio instance is configured to route on those. <id> is whatever stable identifier you want MetaRadio to key on - typically the RadioDJ internal track ID, but the exact token name is in the Stream Variables reference linked below; pick the one that matches what the bridge expects.

Note the _enc suffix on $artist_enc$, $title_enc$, and $album_enc$. Those are the URL-encoded variants of the same fields. Use them, not the bare $artist$ / $title$ / $album$ tokens - special characters (&, +, spaces, non-ASCII letters) will break the parse otherwise, and the breakage is silent until a track with an & in the title shows up months later.

The MetaRadio examples online often show $artist_enc$ next to a GET request, so it is reasonable to wonder if POST removes the need. It does not. RadioDJ's Web export sends a key=value&key=value body - the same application/x-www-form-urlencoded shape a GET puts in the query string. The HTTP verb only decides where those bytes travel; the encoding scheme is identical, and the bridge parses the body the same way it would parse a query string. URL-encoding stays required. A JSON-bodied POST would skip it - that is a different transport.

The StartTimestamp field uses a space (encoded as %20) between the date and the time, not the ISO 8601 T. That is intentional - MetaRadio reads the space-separated form. Do not "fix" it to ISO 8601 unless your MetaRadio instance is configured to parse that variant instead. The %20 is not optional: RadioDJ does not encode literal characters in the template, so writing a raw space there would ship a raw space inside a application/x-www-form-urlencoded body. Permissive parsers (MetaRadio is one) accept it, strict ones do not. Hardcode %20 and stop worrying about which side of that line your bridge sits on.

Two more RadioDJ quirks to know before you trust the payload in production:

• $now-month$, $now-day$, and the time tokens are not zero-padded. The output is 2026-5-19 12:48:12, not 2026-05-19 12:48:12. MetaRadio parses it correctly; anything strict downstream of MetaRadio (a DATETIME column with a fixed format, a date library on the website) may not. If you find yourself debugging a date that "almost looks right," check the padding first.
• $track-type$ returns RadioDJ's internal enum integer, not the string name. A song lands as Type=0 (or whatever the first enum value is on your build). The Stream Variables PDF lists the full mapping. When you configure the songs-only filter on MetaRadio's side, match on the integer, not the word.

Two references to keep open while you fill this in:

• MetaRadio Custom Inputs and Outputs - the canonical list of MetaRadio field names and what each one does downstream.
• The RadioDJ variable reference, shipped with the install at Docs/Radio DJ - Stream Variables.pdf. Every $variable$ token in the payload is documented there. The same PDF is also kept at Stream Variables.pdf for convenience.

The configuration you settle on depends on what your MetaRadio instance is wired to. RDS itself only needs Artist and Title, but the same MetaRadio entry usually feeds the website, the stream encoder, and the socials at the same time, so you may as well send the full payload.

Filter to songs only at the bridge

MetaRadio has built-in filtering on what it forwards. Use it. Send the full stream of track changes from playout, and let MetaRadio drop everything that is not a song before it reaches RDS.

You do not want comments, jingles, station IDs, or spot names showing up on a listener's car display. The dashboard scrolling STATION ID 03 or AD - LOCAL FURNITURE STORE every few minutes is worse than no metadata at all - it tells the listener you are not paying attention.

The filter lives on whichever machine runs MetaRadio. If you administer it, configure the track-type filter to allow only Song (or your playout system's equivalent). If someone else administers it, ask them to set the filter on their side - it is a one-time configuration and they will probably appreciate the request, because the alternative is them debugging "why is the car display showing jingle names" themselves later.

Confirm data is flowing

Before you wait for the car dashboard to react, confirm the bridge is actually receiving what playout is sending. MetaRadio exposes a status dashboard on its own host - typically a web UI on the same port the encoder targets, sometimes a separate management port. If you cannot reach it directly, the tower operator can pull it up while you cue a track from playout.

What you are checking for: a fresh entry per track change, with Artist and Title populated and the timestamp matching the start of the song on air. If the entry arrives but fields are empty, the issue is in the Custom Data payload (RadioDJ) or the Live Metadata format (Zetta). If no entry arrives at all, the issue is upstream - back to the connectivity test.

Clock and locale sync

When it works

If the connectivity test passes, both playout systems are configured, and clock and locale are consistent across the studio network, the artist and title on the next track should reach the FM transmitter within a second or two of the audio. The dashboard in the car is the final test - if a track changes on air and the car display does not follow, the problem is downstream of this page, in MetaRadio's configuration or at the RDS encoder itself.