Our “DAW-First” Approach

Preface

Some audio comparison players normalize the volume in real time. They perform a loudness measurement in the browser, adjust the volume of each version to a fixed target value, and present the result as a “fair comparison.”

But how do you implement this consistently? Make the loudest version quieter? Make the quietest one louder? Or a mix of both? All of these approaches have unpredictable weaknesses, like the need of a peak limiter – and many more….

That’s why we designed Studio Player differently. The DAW is the authoritative source for volume-and the player takes into account what was exported, not what it would normalize. 

This also applies to the pre-calculated waveforms. Each variant has its own waveform, measured and calculated directly from the source file right when dropped into Muxer-Uploader.

All levels and any gain matching are adjusted in the DAW – you have full control!
We call this the “DAW-first”, and it’s part of the Studio Player’s architecture.

What we hear and see in the studio is what the visitor hears and sees online.

 

The DAW-first workflow

Since we have to adjust the player’s variants on the timeline anyway (sample-accurate alignment of the start point), we have to export the file from the DAW again anyway.
We’ve adapted Muxer’s logic so that we can implement a seamless workflow with all modern DAWs.
The workflow is straightforward.

Lay the variants into one timeline. All aligned sample-accurate. The timeline is the truth – every variant starts at exactly the same point every variant will be bounced to the same destination. By the way, the total length doesn’t really matter – for playback in Studio Player, you just need to synchronize the start points.

This alignment is essential. The Muxer combines the four variants into one multichannel FLAC, and the player switches between them sample-locked on one single timeline. If the start points drift in the DAW, they drift in the player. If they’re sample-accurate in the DAW, they’re sample-accurate in the player. The DAW sets the truth; the player respects it.

All the engineering decisions happen here.
Every decision that distinguishes variant A from variant B is made in the DAW, on our monitors, in our room – before the export ever runs.

Loudness matching happens here too – if we want it for our specific use case.
Because we already have all four variants on one timeline, we can gain-match any pair of them with a LUFS meter on the master bus. We decide where matching serves the comparison, and where it doesn’t. 

Where loudness is the story, we leave the levels alone.
The final master stays louder than the mix – because that’s what makes it the final master. The binaural version stays at its measured loudness – because that’s how binaural works. The DAW lets us choose, variant by variant, which comparisons should be matched and which shouldn’t.

Multi-export with naming. Once the variants are aligned and the levels are decided, we export all of them in one pass (“Multiple”, “Track Bounce” or “All Tracks as Audio Files” depending on your DAW), for example like this:
01_SongName-demo.wav
02_SongName-mix.wav
03_SongName-master.wav
04_SongName-binaural.wav

The leading numbers are the sort criterion – the Muxer reads them and places the variants in the correct slots automatically. In Cubase/Nuendo the track numbers are added by default when performing a “Multiple bounce”, in Logic set “Track Number” in the export dialog, in Pro Tools look for “Batch Rename”.
The identifier after the leading number, in our case “SongName” number will be taken as Title and passed to the playlist (but can be changed anytime).

So the DAW is the definitive source of truth for loudness. The player reproduces what was exported in the specified order and at the levels we set. What we hear in the studio is exactly what the listener hears online!

 

Why DAW-first is a feature, not a missing piece

Skipping loudness normalization isn’t a shortcut. It’s the architectural decision.

The DAW is where loudness decisions belong – where we can hear them, revise them, and own them. The player’s job is to play back what we bounced, faithfully.

“The browser doesn’t need to second-guess me as the engineer. It needs to decode the multichannel FLAC, switch between channel pairs without latency, stream adaptively on whatever network the visitor is on, and stay out of the way. Adding a loudness engine on top of that – for a result that overrides our decisions – would be complexity spent against the work, not for it.”

 

Why runtime loudness normalisation doesn’t fit this workflow

Once the DAW is the source of truth, the question of whether the player should normalise loudness looks different.

Most audio comparison players ship with auto-level-match – a loudness engine that runs in the browser, measures each variant, and applies gain to align them to a target. It’s the obvious feature to build, and it looks like fairness in a product spec.

But the DAW-first workflow already handles loudness. We gain-matched where matching served the comparison. We left levels alone where loudness was the story. Every loudness decision that needed to be made, we made – on our monitors, in context, with the option to revise.

If the player also normalises, it overrides those decisions. A master we delivered at -9 LUFS gets turned down. A rough mix at -22 LUFS gets turned up – and may need to be true-peak-limited, altering transients we spent hours shaping. Variants we gain-matched to within 0.5 dB in the DAW may measure differently in LUFS (because of spectral content or duration), and get pushed apart again.

In each case, the player second-guesses decisions that were already made in the studio. The visitor hears a version of the work that doesn’t match what was bounced.

What LUFS is, briefly

LUFS – Loudness Units Full Scale – is a perceptual loudness measurement defined in ITU-R BS.1770-4 and the basis for EBU R128. It exists because peak meters don’t tell the truth about perceived loudness. LUFS combines a frequency weighting (K-weighting, which approximates the ear’s sensitivity), a measurement window, and silence gating into a single integrated number.

The spec is public, the math is unambiguous, and any compliant implementation produces the same number for the same input. LUFS is good at what it does.

Where LUFS belongs

LUFS belongs in the studio. On our master bus, with a LUFS meter we can trust, we make loudness decisions every day – gain-matching a reference track, aligning a plugin on/off comparison, checking the final master against a streaming target. Often combined with a gain matching plugin.

LUFS also belongs in broadcast and streaming platforms. EBU R128 enforces -23 LUFS on broadcast programmes so viewers don’t get loudness jumps when they switch channels. Spotify normalises to -14 LUFS, Apple Music to -16, YouTube to -14. These targets exist because the use case is track-to-track normalisation across many artists – and LUFS is good at that.

In both cases, LUFS is applied where a loudness decision is being made. In the studio, by us, on our monitors. Through the normalization pipeline on a streaming platform – perfect for balancing the volume of playlists featuring tracks from many decades and genres.

The portfolio player is neither of those. It’s a playback layer that respects decisions already made. LUFS doesn’t belong here.

What happens when a player normalises at runtime

If a player auto-normalises to a fixed LUFS target, for example -14 LUFS, several things happen to the work:

• A master delivered at -9 LUFS gets turned down by about 5 dB. It plays back quieter as it was bounced.
• A rough mix at -22 LUFS is boosted by about 8 dB. The peak levels may exceed 0 dBFS, which the audio player must then limit using a true-peak limiter—otherwise, distortion will occur.
• Binaural files, which often measure quieter in LUFS than stereo masters because of inter-aural time differences, get more gain applied – throwing off the binaural comparison.

In each case, the player overrides a decision made in the studio. The visitor hears a version of the work that doesn’t match what was bounced.

What we built around it

Studio Player doesn’t run a LUFS engine at runtime. What it does, concretely:

• Decodes a multichannel FLAC in the browser. Up to four stereo variants in one file. The muxing runs in the browser via WebAssembly.
• Switches between channel pairs with zero latency. No synchronisation, no buffer alignment, no drift correction. A channel-pair swap, sample-accurate, on the same timeline with a crossfade ramp (adjustable!)to prevent audible clicks.
• Streams adaptively. The Muxer creates one file with all variants. The player fetches byte-ranges as needed. On fast connections, it requests larger byte-ranges; on weak mobile networks, it reduces chunk size and buffer targets.
• Protects the source files. Token-secured, non-public storage. IP-based rate limiting. Files are not exposed as direct download URLs.
• Renders waveforms from the source. Each variant gets its own waveform, generated from the source file, rendered exactly as the audio was bounced.

You set the loudness levels in the DAW. The player handles playback.
Both do what they do best.

Conclusion

The DAW-first approach starts from a simple question: where does a loudness decision belong? The answer is in the studio – on our monitors, in our room, with our ears  -or with the meters we trust. The visitor hears what we bounced, at the levels we decided, in the order we set up.

These decisions depend on the use case. What do we actually want to present?
Do we want to show differences in levels, or do we want what’s called a “fair comparison”?
Both are possible – even in a mixed form. 

 

This is something that automatic normalization could never achieve with a single checkbox.