How a Radio Broadcaster Opened Remote Access to Skimmer Audio Without Moving Its Six-Month Archive

A US radio broadcaster runs radio stations across more than a dozen markets alongside syndicated programming, cable television networks, and digital brands.

A radio station's product is what goes out over the air, and every station keeps proof of it. The broadcaster'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 one market 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 window of recent audio through Files.com.

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

In that market, the logger machine records four radio stations around the clock, in 15-minute MP3s. Six months of that audio lives on a multi-terabyte 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: moving someone to a new machine meant drive letters remapped by ticket. 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.

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, the market is one of more than a dozen 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. The broadcaster chose Files.com as that access layer.

A Filtered Sync From a Machine That Never Stops Recording

A second market built the pattern first. That 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.

The first market 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 a rolling window of recent audio behind group-based permissions, where the market's staff open the web interface and play a segment directly in the browser.

One Path to the Audio, From Any Network

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.

• 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. Moving someone to a new machine no longer means a drive-mapping request.
• The 60-day retention requirement is met with margin: months of audio reachable through Files.com, six months held on local storage.
• The design was proven in two markets: the one that built it first, then the one that copied it, 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 multi-terabyte 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. One market built the design and another copied it, proving the Agent-and-filter approach was a pattern, not a one-off.