Reportal & CUED

Music reporting by hand

Every time a TV or radio channel plays music, someone has to report it so the songwriters and publishers get paid. Broadcasters send those reports to collecting societies, each with its own format and deadlines. Production companies have a similar job: every programme they make needs a cue sheet listing each piece of music, who wrote it, who publishes it and how long it played.

Done by hand, this is slow and error-prone. Music gets missed, metadata is incomplete, and collecting societies send claims back.

One platform, two products

• Reportal is music reporting for broadcasters. It monitors channels around the clock, identifies the music with audio fingerprinting, builds cue sheets automatically and delivers reports in each society's format.
• CUED is the cue sheet tool for production companies and music publishers. They upload a video or audio file, or an edit list, and CUED fills in the cue sheet with the music it recognises and the metadata behind it.

Underneath, they share the same services: file ingestion, music recognition, match import, metadata enrichment, cue sheet generation and report export.

As an engineer, 2018 to 2022

I joined BMAT's TV & AV team to build the reporting system that became Reportal, starting with a group of public broadcasters.

Much of the back-end logic was mine: the claiming module, the repertoire enrichment tools and the code that turns monitoring data into cue sheets. The XML report formats for collecting societies took the longest. Each society wanted its own fields for TV and for radio, and the formats changed after every round of feedback.

Around that sat the API that delivers reports to the societies, the EPG sync that lines music up with programme schedules, and a feedback channel that brings the societies' claims back into the system. For another public broadcaster, Reportal was hooked into its radio playout and publishing systems, so cue sheets were created from the audio as it aired.

On Reportal and CUED v2 my work moved to the match importer, cue sheet exports, a faster statistics module, user activity history and a version for the US market.

As Product Owner, 2022 to 2024

• CUED's cue sheet workflow. I designed the lifecycle a cue sheet moves through, from In progress to For review, Approved and Submitted, plus the states for files being analysed, so producers and their reviewers always know where a cue sheet stands.
• Automated reporting. I led the launch of automated reporting to collecting societies for a broadcaster, working through the rules for which programmes go into each batch and supporting the societies' validation of the first batches.
• Metadata enrichment. I specified how both products fill in each music work's details from BMAT's central metadata service, with a priority and fallback rule for every field.
• Organising the work. I set up the development project around the platform's services, with one stream of work per service, plus templates for setting up new customers.
• Archive migration. I ran the migration of a broadcaster's legacy cue sheet archive into Reportal, so users didn't have to redo years of work and the music didn't have to be recognised again.

From one copy per customer to one platform

The first version was a monolith on virtual machines, and every customer had its own copy of each service. Setting up a customer meant creating five new repositories, and some customers were stuck on old versions.

The second version is generic and multi-tenant: a GraphQL API on Kubernetes with a namespace per customer, a shared front end, and base processors that each customer extends instead of copying. I documented both generations side by side, so the team could see what had changed and why. Unifying the remaining per-customer services carried on into my time as Engineering Manager.