Tags Follow the Program

The library is the station. The previous page argued that case. This one starts from it.

If the database is the operational truth, the next question is what fields belong in it. The default answer in most tutorials is a checklist. Required fields, optional fields, custom fields. I do not buy that framing.

Tagging is a chain. The idea drives the program. The program needs a rotation, because anywhere there are songs and time to fill, a rotation exists. The rotation needs rules. The rules need tags to filter on. Every field in your library should answer one question: which rule on this station depends on this field being present? If the answer is none, the field is decoration.

Different programs, different tag priorities. The chain holds across stations; which tags each station actually carries varies with what the station is trying to deliver. The examples below come from stations I have worked with directly. The reasoning generalizes to any radio.

Start with the idea, not the field list

There is no universal "you must tag X" list for a radio station. There is only the program you want to deliver, and the tags that program needs to filter on.

A 70s rock station and a 24/7 lo-fi station share almost no tag priorities. A station with language quotas needs a language tag on every row; a single-language station never touches it. A station that beat-matches in the mix needs BPM on every row; a station with hard-cut transitions rarely touches it. The framing that says every station needs these required fields is a shortcut that hides the actual question.

The actual question is: what is the idea, and what filter does the idea require?

Rotation is inevitable

If you have a finite library and time to fill, you have a rotation. Even shuffle is a rotation. Just one without rules. The interesting question is not whether to rotate. It is what rules the rotation obeys.

This is where most beginners drift. They build a library, they press play, and they discover the rotation has been making decisions for them the whole time. Badly. The choice is not "rotation or no rotation." It is "rotation you control or rotation you accept."

Rules express the program

The program lives in the rules. The cleanest way I have found to teach the structure of rules is GSelector's three-layer model: Goals, Rules, Spread. Selector expresses the same idea in older vocabulary. Rivendell is the open-source option in this space, but I have only read its documentation, never run it, so I will not characterize how it handles rules. I lead with GSelector because the layering is clean and I have actually run it.

RadioDJ, the playout I run at Radio Nemiers, does not belong in this category at all.

Breakable vs unbreakable

Unbreakable rules are the ones the scheduler is never allowed to violate, even if it means leaving a slot empty. Breakable rules are the ones the scheduler will try to honor and can fail without breaking the hour.

A common mistake is making everything unbreakable. The scheduler paints itself into a corner and gives up.

Breakable rules are a feature, not a weakness. The scheduler needs slack to find a coherent hour. A goal of "60% mid-tempo this hour" that the scheduler hits 55% of the time is doing its job. The same goal set as unbreakable would either succeed exactly or fail entirely.

The set I keep unbreakable

On any scheduler that can enforce them, I keep three rules unbreakable. Minimum Separation, Yesterday, Hour Restriction. Everything else is breakable.

That is my preferred set, not a universal recommendation. A commercial format station with hosts and ad breaks will have a different list. The number is small on purpose. The more rules you mark unbreakable, the harder the scheduler has to fight to find a valid hour, and the more often it gives up.

Radio Nemiers runs on RadioDJ, which is not a real scheduler. None of those three rules are actually enforced by the playout there. They are approximated through clock structure and library design instead. The subsection below explains why.

Goals, Rules, Spread

Three layers stack.

Goals are what you want the hour to look like in aggregate. Newly Added, Timing Goal, Clock Goal. Targets the scheduler tries to hit across the hour. Mostly breakable by nature - a target you sometimes miss is still doing its job.

Rules are the constraints the scheduler weighs when picking the next track. Minimum Separation, Yesterday, Hour Restriction, and many more. Rules can be marked breakable or unbreakable; the three I mark unbreakable live here.

Spread covers separation across attributes. Artist, Title, Vocalist. It prevents clustering even when individual rules pass. Mostly breakable too.

Deep treatment of how each layer wires up belongs in the Programming section.

RadioDJ is a row-filler, not a scheduler

RadioDJ does not fit the model above. The reason is structural, not cosmetic.

RadioDJ does not track yesterday's plays. It has no Yesterday concept. It does not respect previous-song state across clock transitions; the decision for the next slot is local. It will ignore Minimum Separation if it cannot find a track that satisfies it, because the slot must be filled and the rule loses.

Working with RadioDJ means holding the program in your head and embedding it into the structure of the system. Rule logic gets baked into clock structure (which category fires in which slot) and library design (which tracks live in which category, and how those categories are tagged for separation). The scheduler will not do the embedding for you.

This is the operational version of "do what you can with what you have." RadioDJ plus creative clock plus tight library hygiene gives you a workable rotation. You just do the scheduling work GSelector would do for you. The Radio Nemiers three-day rotation window, covered in the Programming section, exists for exactly this reason.

Tags as filter substrate

Tags are not pre-ranked into tiers. They earn their place by what the rules need to filter on. The system cannot auto-build an 80s set without a year tag. It cannot enforce artist separation without an artist tag. It cannot daypart without daypart tags. Tags are mandatory in the sense that the rules you want to express require them, not in the sense of a global "everyone must tag this."

Two fields come closest to universal because almost every rotation rule depends on them: artist and title. No rotation survives back-to-back same-artist plays, which makes artist the field separation rules cannot live without. Title follows by the same logic. The scheduler needs to say "do not play this song twice in three hours," and there is no way to express that without a stable identifier per song. Beyond those two, the program decides.

Titles are especially load-bearing for seasonal stations and themed playlists. You do not want to play all versions of Last Christmas back to back.

Fields by purpose

Song identity

Artist (canonical, not raw - one canonical artist per row, featuring artists in a separate field) and title (with a canonical form plus an "as released" form for stylized cases).

The scheduler uses its own internal row ID for database uniqueness. Artist and title are how the human identifies a track. How the operator searches at 7:55am when something has to be added by hand. How the music director scans the library. How the separation rule knows two tracks are by the same band.

Timing

Duration, intro marker, outro marker. Measured facts about the audio.

Duration is how the scheduler fits a track into a slot, and how the playout knows when the next-track decision is due.

Intro is the king anywhere a voice runs over the music. A live host speaking over the song's intro needs the marker to know exactly when to stop the sentence. A sweeper - RadioDJ's term for a voice-only Link that plays over the intro section - cannot land cleanly without it; one that runs into the vocal is broken. The classic question every on-air presenter eventually gets asked: how do you always end your sentence right before the singing starts? The answer is two-part. Practice, and a flashing intro counter on the playout console that gives the last few seconds visually.

Outro is more debatable. Hosts handle it by feel. Most songs continue past the lead vocal with an instrumental tail or a fadeout, so the outro marker is the point where the singing stops and the tail begins. That makes it closer to when can I start talking than when does the song end. Talking over the singing part is amateurish; talking over a drum-out or a fade is normal radio.

Without intro and outro markers, the host loses the visual countdown and times by ear; sweepers run into the vocal. Scheduling itself does not depend on these markers - the scheduler still picks the right next track from category, separation rules, and goals - but the on-air result is a station that sounds slightly off, every time.

Rotation and separation

Artist again, the field the separation rule reads. Featured artist. Producer. Hook. Lyrical theme. Song family.

Same artist back-to-back is the obvious case. Same featured artist and same producer are the cases most schedulers miss until you tag for them; the upstream article flagged the featured-artist version of this.

Scheduling and dayparting

Energy, mood, tempo class, daypart restrictions, hour exclusions, seasonal flags. The fields the clock reads when shaping the hour.

Energy goes on a 1-10 or low/medium/high scale, depending on how much granularity the program wants. Mood is orthogonal to energy. A high-energy melancholy track is not a high-energy euphoric track, and a separation rule that lumps them is throwing information away. Tempo class is a bucket; the clock cares about the bucket more than the raw BPM.

Daypart and hour fields are sets of restrictions, not a schedule. The scheduler reads them and decides.

Operator display

Album, album artist, cover art. These live inside the studio system, not on anyone's lock screen.

The web player, the lock screen, and the in-car media center read from a separate API and CDN, on different infrastructure. The broadcasting PC is never exposed to the internet. Nothing from outside requests anything from it. The isolation is there on purpose: security, stability, and - controversially - the right to refuse automated Microsoft Windows updates. I am not claiming every station runs old software without patches. I am claiming that automated Windows updates will silence your station the moment Microsoft decides you need that update right now, and the blue screen of death does not care about your broadcast clock.

Reporting and legal

ISRC, country of origin, release year.

ISRC is mandatory for identification across system boundaries. It is not mandatory for the system to function. The licensing societies that process your reports know what to identify by ISRC. An API finds (if any) the right track by ISRC faster than by a fuzzy artist+title match. The credit that flows back to the artist whose track is being played anchors on the ISRC. The rotation itself does not need any of this. You can run a station with no ISRC, or with all wrong ISRCs, and the schedule will keep running - you just lose every system that has to talk about your tracks to anything outside the playout chain.

Two tracks can share an ISRC; it happens. "No ISRC" is a different problem from "wrong ISRC."

Country of origin drives quota reporting for public broadcasters. Latvijas Radio leans on it heavily; a station with no quota obligations may leave it empty.

Release year is also a rotation field for stations with a rolling "current" window, so it pulls double duty.

Field conventions

Short rules applied consistently. The discipline that keeps the schema from rotting.

Capitalization and character sets

Title Case for English. For non-English titles, transliterate to Latin script as the primary searchable form. The host or program director needs to find any track in the library by typing what they remember on the keyboard they actually have. A station running music from 50 countries cannot assume the operator's keyboard handles Cyrillic, Arabic, Hindi, Chinese, or anything else. The transliterated form is the operational anchor; native script is enrichment, not the master record.

ISRC carries identity underneath. If the ISRC is correct, the canonical track is always recoverable, regardless of how messy or inconsistent the title transliteration ends up being. That is what makes transliteration safe. You do not lose the track by writing its title in Latin script, because the identifier underneath is stable.

Native-script preservation has two clean paths. In GSelector, a custom field holds the original-script title alongside the transliterated primary; both are queryable, the search field stays Latin. In RadioDJ, native-script forms live in an external source - an API the web player, lock screen, or RDS encoder queries when display needs the original glyphs. The playout itself does not need native script to schedule. UTF-8 everywhere, so both forms can be stored cleanly when they are stored.

Featuring artists

How you store featured artists depends on what your playout and scheduler can actually express. There is no universal rule. Three patterns from setups I have run, ordered by how cleanly the tool supports the case.

Zetta paired with GSelector is structurally the cleanest answer. Zetta supports multiple artist entries per song; the scheduler reads them. Caveat - the GSelector and Zetta integration had order misalignment between the two systems when I last hit it, around ten years ago. I have not revisited it and the setups I currently run work without it. Treat as a historical note, not a current claim.

GSelector standalone uses a dedicated Vocalist field. The critical detail: Vocalist is an attribute of the artist, not the track. You configure the artist record once, and every track by that artist inherits the Vocalist value. Add a new Tool track and the field auto-populates because Maynard is on the Tool artist record, not on each individual song row.

This is what makes the band-overlap case clean. Tool, A Perfect Circle, Puscifer, and Maynard James Keenan solo all share Maynard as Vocalist. Configure the attribute on the four artist records once, and the rotation refuses to play back-to-back tracks across any combination of them - even though the Artist values are four different bands. The same pattern handles Josh Homme across Queens of the Stone Age, Eagles of Death Metal, Them Crooked Vultures, and solo; Mike Patton across Faith No More, Mr. Bungle, Tomahawk, Fantômas. Pure Artist separation would miss every one of these collisions.

Separation rules read Vocalist alongside Artist. The Artist field stays canonical and singular; the shared or featured vocalist goes in Vocalist. The Jay-Z feat. Alicia → Alicia solo case is the simple version; the Maynard / Josh / Mike case is the load-bearing one that makes Vocalist worth implementing.

RadioDJ has no secondary-artist field. There is no native way to mark a guest artist alongside the primary. The pragmatic choice at Radio Nemiers is to drop featured artists out of the Artist field completely and append them into the Title field in parentheses - Children of Light (feat. Max Cavalera). The Artist field stays clean for separation; the parenthetical is for me as the music director when I am looking at the library inside RadioDJ. It is not what listeners see. Listener-facing surfaces at Radio Nemiers - web player, lock screen, mobile apps - pull track metadata from an external API, the same pattern that holds the native-script title forms. The playout database carries the operator's working form; the API delivers the listener's canonical form. RadioDJ has recently added an Associated Artists field that takes a comma-separated list of names, but I have not yet validated whether it integrates with separation rules.

Whichever pattern you land on, pick one notation for the conjunction and never alternate. feat. is the most common. The alternatives - featuring, ft., &, with - get collapsed to one canonical form. Separation and search both fail silently on inconsistent notation.

Multi-value separators

When a field can hold many values, pick one separator and never mix. Semicolon is the safest default. Comma is a trap, because commas appear inside artist names. Example: Tyler, The Creator.

ISRC format and validation

Twelve characters in three parts per ISO 3901:2019 - prefix code + year of reference element + designation code. Older sources describe ISRC as four parts (country code, registrant, year, designation); the 2019 revision collapses country and registrant into a single allocator-issued prefix. The three-part form is the current one.

No hyphens. Hyphens are not part of the spec. They are not part of storage. Some style guides allow hyphens for display; I keep them out of display too, because they confuse audiences who think the hyphens carry meaning, and the pattern is short enough to read without them. If a label-provided ISRC arrives with hyphens, strip them on ingest.

Year of reference is the assignment year, not the recording year. A song recorded in 1925 and assigned an ISRC in 2026 will carry 26 in the year position. Do not derive the release-year tag from the ISRC; the two fields answer different questions. The release-year tag holds when the recording was made; the ISRC year holds when the identifier was issued, which can be decades later.

A 12-character, no-hyphens regex against ^[A-Z]{2}[A-Z0-9]{3}[0-9]{2}[0-9]{5}$ catches the common label-provided mistakes. Strip hyphens before validating. When the regex fails on a label-provided ISRC, the right move is to bounce it back to the label rather than invent a fix. A wrong ISRC is a different problem from no ISRC.

Where the metadata actually lives

The upstream page said it. Once a track is ingested, the file tags are not the truth. The playout database is.

FLAC stores metadata in Vorbis Comments - free-form key-value pairs in a metadata block, UTF-8 native, room for custom keys like ISRC. WAV has no embedded tag space at all. Either way, the file's tag situation matters only at ingest. After that, the database row is the row, and the row is the station.

Two sources of truth, never mixed. The database is the single source of truth for metadata. The file is the single source of truth for audio. Decoupled by design.

The systems I have direct experience with behave the same way. RCS Zetta ingests files. RadioDJ ingests files. GSelector manages only the metadata; the audio lives elsewhere, and GSelector reads the database row, not the file. The pattern is uniform: once the row is written, the scheduler reads the row, never the file.

A re-tag of the audio file does nothing. The database does not look at file tags after ingest. Change the artist field on the FLAC and the rotation keeps using whatever the database row holds. Replacing the audio file under an existing entry does not touch the metadata either. The audio is the payload; the row is the operational identity.

Re-importing the file does not update the existing entry. It creates a new one. The custom fields you set on the original (energy, mood, separation categories) live on the old row; the new row starts blank. This is the gotcha that catches people trying to "fix" a library by re-ingesting. What they actually do is spawn a second set of rows next to the first. There is no round-trip between file and database, and trying to engineer one breaks the model.

RadioDJ does ship a Tag Synchronization feature - database to tags, or tags to database. I leave it off. The moment two sources of truth disagree, you have no way of knowing which one is right. Someone edits a FLAC outside the playout, or someone touches a field in the GUI, and now the two diverge silently. The rotation keeps running on whatever the database has; the file tags become decorative; eventually they confuse whoever inherits the system. There is no use case where mixing the two sources beats keeping them separate.

The schema lives in the database. The file tags are the seed, not the canon.

Different programs, different tag emphasis

Not a complete reproduction of any one station's schema. That would be wrong for two reasons: the schema is private to each station, and this site is not documentation for any one of them. The same chain (idea → rotation → rules → tags) produces visibly different tag emphasis across stations.

Radio Nemiers on RadioDJ

Fully automated, no hosts, more than 50 countries in the library. Tagged for artist, title, ISRC, duration, intro markers, associated artists, year.

The "schedule" is not a scheduler. It is a custom rotation mechanism built from RadioDJ primitives - Track Rotations (the airplay buckets that fire), Song categories (the library's identity layer), custom database triggers, and year tags. Songs cycle out of active rotation and back into their original Song category based on playcount inside the active Track Rotations. That is how the rolling window works without a Yesterday concept in the playout.

The one unbreakable rule I work to - Minimum Separation - is approximated by this design, not enforced. No daypart restrictions, because the Track Rotations run flat. The Programming section's three-day rotation window page covers the mechanism in full.

Latvijas Radio on RCS Zetta + GSelector

Public broadcaster with hosts. Heavier on language and country of origin, because of quota reporting obligations. Lighter on energy granularity, because the host shapes the hour, not the scheduler.

A historical note on commercial format stations

Three commercial format stations I have direct experience with - Radio 101, Rīga Radio, and Radio 3 - no longer exist. The Radio SWH group, which includes Radio SWH Rock among several stations, was running RCS Selector when I worked with them; they have since migrated to RCS Zetta paired with RCS GSelector. I keep those stations out of a present-tense tour because the systems they ran on then are not the systems anyone runs them on now.

The lesson they taught is still portable. Commercial format radio runs heavier on energy granularity, daypart restrictions, and seasonal flags, and lighter on language tagging, because the format runs in one dominant language. If your station is in that shape, expect those tags to do the heavy lifting in your rule set, regardless of which scheduler you land on.

Out of scope

ID3 (MP3 tagging) is a consumer-audio concern, and increasingly irrelevant even there as streaming services replace local files. Radio runs on WAV and FLAC, outside the ID3 model entirely. Not covered here, not covered later.

Tags follow the program. Build the idea, derive the rules from what the program needs, and let the rules tell you which tags actually matter. Skip that chain and you end up with a tag set that fights your rotation instead of feeding it.