How Urban One Opened Remote Access to Skimmer Audio Without Moving Its Six-Month Archive

Urban One is the largest African-American-owned broadcasting company in the United States. Its radio stations, syndicated programming through Reach Media, cable television networks, and digital brands reach roughly 80 million consumers a month, and its radio business spans 14 markets, from Columbus and Indianapolis to Houston.

A radio station's product is what goes out over the air, and every station keeps proof of it. Urban One's stations record themselves continuously, producing what broadcasters call skimmer audio: everything that airs, captured in 15-minute segments and retained for a minimum of 60 days. The archive is not paperwork. Market staff go back to it to hear what a jock actually said, to confirm that a paid live element or a commercial really ran, and to pull air checks when clients ask for them.

The problem in Columbus was never the archive. It was that reaching it depended on being in the building.

The answer was to move access instead of the archive. That meant keeping the six-month archive on inexpensive local storage, syncing only completed recordings, and giving staff anywhere a rolling three-month window through Files.com.

Audio Everyone Needed, Behind Drive Letters That Only Worked in the Building

In Columbus, the logger machine records four radio stations around the clock, in 15-minute MP3s, at roughly 600 MB per station per day. Six months of that audio lives on a 14 TB drive attached to the machine.

Access ran through Active Directory. IT created network shares for selected users and mapped them to drive letters on each person's computer. Those shares work only on the office domain, and that drew a hard line through the staff. Anyone in the building could reach the audio. Remote employees had no path to it at all, and the remote desktop environment they work through never connected to the shares either.

Every change on the working side of that line was a per-user IT request. When the Columbus chief engineer needed drive letters remapped to a new machine, the request sat in the queue for about four months. So the audio was always there, recorded and retained as required, while whether a given person could actually hear it depended on which network they sat on and how deep the ticket queue ran. When a client asked for an air check, that was the wrong thing for the answer to depend on.

Why the Archive Couldn't Simply Move to the Cloud

The obvious fix was to lift the whole archive into the cloud, and it was the wrong one. Deep retention is bulk audio: keeping six months of it on a local drive costs little, Columbus is one of 14 markets recording the same way, and the audio people actually pull from is recent. Duplicating every market's full archive in cloud storage would mean a recurring bill for files whose job is to sit still.

There was a second constraint. The machine holding the archive can never stop working. It records four stations every minute of the day, so anything that syncs from it has to know the difference between a finished recording and one still being written.

What the fix had to do was narrower than a migration. Urban One chose Files.com as that access layer.

A Filtered Sync From a Machine That Never Stops Recording

Indianapolis built the pattern first. The market's engineer installed the Files.com Agent on the logger machine, pointed a sync at the archive, and had it running in a single day. The Agent connects outbound from inside the station's network, so the logger is never exposed to the internet.

The detail that makes it safe is a filter. Recordings land on the logger in daily folders. The sync carries an exclude filter so that only completed daily folders move to Files.com. The folder the recorder is still writing into is skipped. The machine records exactly as it always has, and finished audio follows it up on its own.

Columbus replicated the design: the same Agent on its logger's drive, the same filter, the same structure on the Files.com side. The local drive keeps its six months. Files.com carries the rolling three-month window behind group-based permissions, where Columbus staff open the web interface and play a segment directly in the browser.

One Path to the Audio, With Nothing Left in the IT Queue

With the sync in production, reaching the archive stopped depending on which network an employee sits on. Files.com replaced a per-user drive-mapping process with one governed path to the audio.

“Files.com gives me one place to put all the audio for everyone, so I don't have to manage two systems.”

• Remote staff can reach the skimmer archive for the first time. The same login works from any network, with no domain membership and no remote-desktop workaround.
• Granting access is a Files.com permission instead of an IT ticket. The kind of change that once waited about four months in a queue no longer goes through the queue at all.
• The 60-day retention requirement is met with margin: three months of audio reachable through Files.com, six months held on local storage.
• The design was proven in two markets: Indianapolis first, then Columbus, where replication required an Agent and configuration file on the logger.

Moving Access Instead of the Archive

The archive never went anywhere. Six months of audio still sits on a 14 TB drive next to the machine that records it, which is where bulk retention belongs. What moved is the part people use: a rolling window of recent audio, synced up by the Files.com Agent and reachable by everyone whose job touches it.

Today, when a client asks for an air check or someone has to confirm a spot really ran, the person who needs the audio signs into Files.com and presses play, from the station or from home. Indianapolis built the design and Columbus copied it, proving the Agent-and-filter approach was a pattern, not a one-off.