Soundcore MASR H5

Overview

For Soundcore and Catalyst agency, I designed and shipped the full-stack platform behind the MASR (Multi-dimensional Audio Spatial Recording) experience event in London — bridging on-site Unity recording stations with a mobile-first web playback page that visitors take home in their pocket. The mechanic: record at a Unity station on the event floor, scan a QR code, and your recording lives on a personal H5 page you can play back, download, and share from your phone.

Role division: Catalyst led brand experience and event design and brought in a Unity team for the on-site recording stations. I owned the full-stack web platform — the API, the storage layer, the H5 itself — and the Unity-to-Web bridge protocol that connects the two halves.

What I Built

• Unity-to-Web bridge. A clean REST API that accepts an audio upload from a Unity station and returns a short-lived, single-use QR code resolving to the visitor's personal playback page. No backend logic on the Unity side beyond the API call — a deliberately low-friction integration point for the Unity team.
• Serverless storage and delivery. Cloudflare R2 for audio storage, Vercel functions for the API — chosen over an S3 + AWS stack for operational simplicity, fast cold-start behaviour under live event pressure, and predictable cost.
• Audio processing pipeline. The initial implementation ran FFmpeg in-process inside Vercel functions, but hit the serverless platform's binary-size and execution constraints. I pivoted within hours to Rendi, a specialist FFmpeg-as-a-service API, rather than fight the platform — keeping the project on schedule and the runtime profile clean.
• Mobile-first H5 playback. A Next.js page tuned for fast first-paint on phones pulled out of a pocket immediately after scanning, with reliable audio playback across iOS Safari and Android Chrome.
• Downloadable artifact. The recording can be downloaded directly from the H5, so visitors leave with a tangible souvenir from the event.

Technical Solutions

The defining engineering decision on this project was the Unity-to-Web handoff protocol. The constraint was real: two separate technical teams (Unity and web), a live event floor with no tolerance for integration failures, and a visitor experience that had to feel seamless despite spanning two entirely different runtime environments. I designed the bridge as a minimal REST contract — Unity POSTs audio, receives a QR URL — so neither side had deep knowledge of the other's internals, and either could be updated independently with no blast radius.

The FFmpeg pivot was the other significant call. Recognising early that fighting serverless platform constraints wasn't worth it — and moving to a specialist API rather than an in-process workaround — kept the project on schedule and the system operationally clean for the live event.

Why It Matters

Live event tech has a hard constraint: any backend failure is immediately visible to the visitor and to the brand on the floor. The platform ran without incident through the London event — no dropped recordings, no QR handoff failures, no audio playback issues. The system also shipped with effectively zero ongoing operational cost between events, which matters for a platform that runs intensively for a few days and then sits idle. The design point — fluid, install-free handoff from professional on-site capture to consumer-grade mobile playback — is the difference between a forgettable booth and a moment worth sharing.