To stream a jazz internet radio station to YouTube with live track metadata, you need to solve two linked jobs: send the station audio to a YouTube live broadcast, then show changing artist and title information in the video. YouTube’s reviewed API documentation describes broadcast details such as title and description, not a track-by-track player metadata field.
The practical route depends on how your station exposes its audio and now-playing data. An encoder such as OBS may be part of the workflow, but first confirm that it can receive your exact feed; then test that your metadata source updates the visible overlay as songs change.
Separate the audio feed from the track display
Think of the setup as two pipelines that meet in the finished YouTube video. The audio pipeline carries the station’s programme to YouTube. The visual pipeline reads current track details from a station system or metadata source and renders them as text over the video. The viewer hears one and sees the other, but they are not the same signal.
This distinction explains why a radio station can sound correct while its YouTube image shows stale or no track information. The encoder may be receiving clean audio, while the overlay has no access to the station’s artist/title data. Conversely, an overlay can update perfectly in a local preview while the audio input is silent or disconnected. Test each pipeline on its own before checking them together.
Start by writing down how the station delivers audio: a local device or file, a network stream, or an output from its broadcast automation system. Separately, find out where its now-playing information comes from. It might be produced by the automation system, exposed through a metadata endpoint, or available through another station-specific method. Do not assume that the audio URL itself also provides data in a format an overlay can use.
A useful comparison is not “which encoder is best?” but “which route accepts this audio input and can be paired with this metadata source?” The right answer varies with the station’s feed, automation and operating constraints. If you already have a reliable local audio output, that may be simpler than adding a network-feed route. If your station exists only as a network stream, verify ingestion before building the rest of the scene.
Keep the responsibilities separate when troubleshooting. If sound is missing, check the selected audio input, its connection and the encoder’s audio meters. If the song text is wrong, inspect the data source and overlay refresh behaviour. If both look right locally but not on YouTube, review the live preview and the selected broadcast rather than changing the station’s automation settings blindly.
Send the station feed to a YouTube broadcast
A YouTube live event and the media sent into it are related but distinct. Google’s YouTube Live Streaming API overview describes a liveBroadcast as the event and a liveStream as the audio-video content transmitted to YouTube. The broadcast is associated with a stream. That model is useful even if you configure the event in YouTube Studio rather than through the API.
Create or schedule the broadcast, check its title and description, and identify the ingest path YouTube Studio provides for that event. Your encoder must then send the station’s audio, together with a video image or scene containing the overlay, into that path. An audio-only radio feed does not by itself make a complete live video; the composed output needs a visual layer, even if that layer is a simple station image with track text.
Before settling on an encoder route, confirm the station’s exact output format and access method. A radio hosting arrangement may expose a web player, a network audio URL, a local monitoring output, or a connection intended for broadcast automation. Those are not interchangeable inputs. A URL that plays in a browser is not proof that your chosen encoder can ingest it continuously or obtain its metadata.
OBS can serve as an encoding and scene-composition layer when its available inputs fit your setup. If the station audio is delivered to the computer as a supported audio device, select that device and confirm the meters move. If it is a network stream, verify an appropriate ingest method with the station’s documentation and test it before relying on it. The OBS Media Sources guide documents local media types; it does not establish compatibility with every Icecast, SHOUTcast or other station URL.
A persistent setup also needs a plan for what happens when the source stops. Check whether the station feed reconnects, whether the encoder reports input loss, and whether the live image remains understandable during a brief interruption. A still station card can be a sensible fallback, but it does not restore missing audio or prove that the broadcast is healthy. Check the YouTube live dashboard during the test, not just the local encoder preview.
For a computer-based workflow, you can also review OBS reconnect settings for a continuous YouTube stream. Reconnection settings address a dropped connection between encoder and platform; they do not repair a station feed that has stopped upstream. Keep those failure points distinct in your operating notes.
Build a now-playing visual overlay
The track display is video text, not a special label that YouTube automatically derives from a radio station. Your overlay needs a dependable way to read the current artist and title, then place that text in the composed video. The station’s automation system or metadata endpoint is the logical place to investigate first, but the exact wiring depends on what that system offers.
A simple overlay has a background or transparent layer, a text area for artist and title, and a fallback identity for times when the data is absent. Keep the text away from the edges and from any controls or captions that viewers may need to read. Use a sample of your actual longest track titles; names that fit in a design mock-up may wrap awkwardly when a collaboration, remix or subtitle appears.
Decide how frequently the display should check for changed data, based on the station’s source and the available integration. Avoid presenting a guessed title as fact if the metadata is missing or delayed. A neutral fallback such as the station name is clearer than leaving yesterday’s song on screen. If the station’s metadata includes status markers or inconsistent punctuation, clean those deliberately rather than allowing raw source text to spill into the scene.
The connection between metadata and overlay is often the most station-specific part of the job. Confirm whether the data source exposes artist and title as separate values, a combined line, or another structure, and whether it changes at the point the track changes. Then check that the chosen overlay method can read that form of data and refresh it. Do not assume a ready-made OBS integration exists merely because the station has a website with a now-playing widget.
Keep the overlay’s visual purpose modest: identify the station and make the current selection legible. A listener tuning in mid-song benefits from the title, while a viewer who leaves the stream open can still recognise the channel if metadata temporarily disappears. If you want a reminder or other fixed text as well, treat it as a separate design element; guidance on adding a subscribe reminder to a 24/7 YouTube stream can help you keep a fixed message from crowding the changing track display.
StreamNeo can remove the need to keep your own computer switched on for a file-based continuous broadcast, but it does not turn a station’s changing metadata into an overlay automatically; you still need a video file or composition that contains the information you intend viewers to see.
What YouTube API broadcast details cover
The API documentation helps clarify what YouTube treats as broadcast information. Google’s LiveBroadcasts reference describes fields on the broadcast resource, including title, description, scheduled times, status and recording or archive settings. Those details identify and configure the event; they are not a live per-song display field in the reviewed reference.
That means updating a broadcast title or description is not a practical substitute for an on-screen now-playing label. A song may change frequently, and editing event details does not compose text into the video frames. The track-by-track display belongs in the video output, where your overlay can change with the station’s data source.
There are two useful checks here. First, make sure the broadcast metadata describes the station and programme in a way that is still useful over time. Second, test the overlay independently to see whether it follows track changes. Do not build a workflow around an assumption that YouTube’s player will show the current song because the broadcast title was set once or because the audio feed carries radio metadata.
The API is relevant if you are automating event creation or managing broadcast settings, but you do not need to use it simply to show a song name. For a manually configured station, YouTube Studio may be enough to create the live event and obtain the connection details. If you do use API features, check the current documentation for the resource and operation you intend to use; the reviewed pages do not document a track-level player field.
This separation also makes future changes easier to reason about. You can revise the broadcast title without changing the overlay design, and you can fix a metadata formatting issue without altering the live event. Keep a note of which system owns each value so that a title mismatch is not mistaken for an ingest problem.
Check OBS media-source compatibility
OBS is a plausible choice when you need to assemble audio, an image and a text overlay into one live output. But compatibility has to be checked against your station’s actual source. OBS’s Media Sources documentation lists local media types such as MP3, AAC, OGG and WAV. That information does not prove that every internet-radio URL, Icecast endpoint or station-hosting arrangement can be opened as a media source.
First identify whether the feed is a local file, a local audio device, or a network stream. For a device input, select the right device in OBS and confirm that the audio meter responds while the station is playing. For a network feed, check the station host’s connection instructions and verify that your chosen ingest method supports its exact format and authentication requirements. If the feed cannot be received directly, consider a supported output from the station’s automation or a separate audio routing method, then test for delay and dropouts.
The media source and the metadata source may be different. A feed can deliver audio without exposing usable artist/title data, and a station website can show a current song without giving your overlay a stable way to retrieve it. Ask the station or automation provider what data output is available and how it behaves when a title is unavailable. Avoid assuming that a URL copied from a web player is the whole solution.
A short compatibility test should answer practical questions: does audio start without manual intervention, does it continue through track changes, and does it recover after a temporary connection interruption? Listen for silence or repeated audio while watching the meter. Confirm that the overlay is using the expected source rather than a manually entered sample value. Keep the test long enough to include at least one actual change in the station’s programme; a single static preview cannot validate the relationship between the pipelines.
OBS’s help portal describes the software as open source and suitable for commercial use, but that says nothing about the rights to the music you transmit. If you want an alternative encoder or a more automated arrangement, compare it against the same input and metadata requirements rather than selecting one based on a generic compatibility claim. A practical guide to running an always-on YouTube stream with FFmpeg on Linux covers a different operating approach; it is relevant if you are comfortable managing a command-line setup, not a guarantee that your station feed will work with it.
Test track changes in the stream output
A correct local preview is necessary, but check the actual YouTube output as well. Start with a private or otherwise appropriately limited test if that suits your channel plan, then verify the correct broadcast is live. Listen to the received audio and watch the overlay in the player. The encoder preview can show the intended scene even when the wrong event is selected or the remote output is not receiving the same signal.
Test a normal transition from one track to the next. Confirm that the old title clears, the new artist and title appear, and the change is not so early or late that the display misidentifies what listeners hear. Some stations announce tracks or insert transitions; decide whether the overlay should follow the metadata immediately or retain the last confirmed title until the next one is available. The goal is an honest, readable display, not an appearance of precision unsupported by the data.
Include cases that can expose weaknesses: a long title, a missing artist, special characters, an empty metadata value, and a temporary interruption in the data source. Check whether the text wraps, clips or disappears into the background. A predictable fallback such as station identification is usually more useful than a stale song name. If the station’s metadata source delays updates, document that behaviour rather than tuning the overlay around an unverified assumption.
Keep a basic check routine for the person on duty. Confirm that the broadcast is still receiving audio, that the track display is changing when expected, and that the live dashboard has not raised a content or connection issue. If something fails, identify whether the break is in the station feed, metadata retrieval, scene composition or YouTube connection before restarting components. That makes recovery less disruptive and prevents a recurring problem from being hidden by repeated restarts.
For longer-running streams, think through how the scene behaves when the operator is away. A still card can keep the station recognisable during a metadata outage, but it cannot tell you that the audio is absent. Use the platform dashboard and the encoder’s own indicators as separate checks. For a computer that must remain responsible for the continuous stream, looping videos with OBS on YouTube Live offers related considerations about continuous operation, though a radio feed has different input and metadata requirements.
Review music and metadata rights
Before configuring a public simulcast, confirm that your permissions cover the music on YouTube, the territories where it will be available, live transmission, and any replay or archive you intend to keep. Rights for terrestrial or internet radio transmission do not automatically establish permission for a YouTube simulcast. The station’s catalogue, territory, rights holders and archive policy all matter, so obtain guidance from the relevant rights holders or distributor for your specific use.
YouTube Help says that live streams are scanned for matches to third-party content and that a stream may be interrupted or terminated when matched content remains. Its guidance also warns that licensed third-party material may still trigger an interruption if the rights owner has not allowlisted the channel through Content ID. Check YouTube’s current copyright guidance for live streams and discuss allowlisting arrangements with the rights holder where appropriate. A licence is not a promise that automated matching will never interrupt a broadcast.
Do not treat YouTube’s live Content ID matching feature as a way to obtain music permission. YouTube’s overview of live Content ID matching describes a feature with specific availability and rights conditions. It is not a general licence for a station that lacks the relevant permissions. Check the current official guidance and your own agreements rather than relying on a general description of the feature.
Also consider whether the metadata itself can be shown publicly. Artist and track names are ordinarily identification information, but station agreements may set conditions around credits, artwork, or presentation. Use text you are entitled to display and avoid assuming that permission to transmit audio includes every associated visual asset. Keep records of the rights advice and channel arrangements that apply to the station’s catalogue.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I show the current song on a YouTube live stream?
Read the artist and title from a reliable station automation output or metadata source, then display them in a visual overlay that is part of the video sent to YouTube. Test actual track changes and provide a fallback for missing data. The reviewed YouTube API documentation does not describe a track-by-track player metadata field.
Can I stream my internet radio station to YouTube using OBS?
Possibly, if the station feed can be received through an input route supported by your OBS setup. The OBS Media Sources page documents local media types, not compatibility with every radio URL or hosting arrangement. Confirm the exact feed format and test audio continuity before relying on it.
Will changing the YouTube broadcast title update the song name?
No. The broadcast title is event-level information, while a changing song name needs to be rendered into the video by an overlay connected to station metadata. Keep the event title useful for the programme as a whole, and test the track display separately.
Does a radio licence guarantee that a YouTube stream will continue uninterrupted?
No. Rights, territories and replay permissions need to be checked for your particular catalogue and use, and YouTube’s live matching can interrupt a stream. Ask rights holders about channel allowlisting and review current YouTube guidance; neither a licence nor an overlay guarantees uninterrupted streaming.