Audio File Prep: WAV Settings for Distribution

What file should I actually hand my distributor?

Hand over a lossless file. That’s the whole answer, and most of the rest of this page is just the settings on it. Spotify strongly prefers FLAC for delivery and also accepts WAV as long as it meets the same technical bar. Apple accepts WAV (PCM), FLAC, or ALAC. Pick whichever your mastering chain spits out cleanly. There’s no audible difference between a correct WAV and a correct FLAC going in; FLAC is just smaller because it’s losslessly compressed.

The one thing you cannot do is deliver an MP3 or any other lossy file as your master. Here’s why it matters from the production side. The platform takes whatever you give it and encodes it into its own lossy format (Spotify uses Ogg Vorbis, Apple uses AAC) for streaming. That’s one lossy encode, and it’s unavoidable. If the file you delivered was already an MP3, the platform encodes it a second time, and that second pass stacks on the artifacts the first one already baked in. Double-encoding like that produces audible damage, usually swirly, garbled high frequencies. Start from lossless and the platform’s encode is the only one your listeners ever hear.

What sample rate and bit depth should the master be?

At least 44.1 kHz, and 24-bit if you have it. Both Spotify and Apple set 44.1 kHz as the floor, so that’s the lowest you should ever deliver. On bit depth, Spotify is direct: if a track was mastered in 24-bit, deliver 24-bit, and only fall back to 16-bit when no higher-bit-depth master exists. Apple requires 24-bit for its Apple Digital Masters badge.

A couple of don’ts that catch people out. Don’t make a 16-bit version from your 24-bit master just to deliver, and don’t deliver both bit-depth versions of the same track. And don’t downsample before delivery. If your session ran at 48 kHz or 96 kHz, deliver it at that rate. Spotify and Apple handle whatever downsampling they need on their end, and doing it yourself can introduce conversion artifacts for no quality benefit. The cleanest move is to deliver the native resolution your project was at.

One thing worth being honest about: a 24-bit, 44.1 kHz file does not qualify for Apple’s Hi-Res Lossless badge. That badge needs a sample rate of at least 88.2 kHz (88.2, 96, 176.4, or 192). And you can’t fake it. Apple explicitly prohibits up-sampling or bit-padding a 44.1 kHz/16-bit file to pass it off as a higher-resolution source. If your master genuinely is high-res, deliver it at its native rate and it qualifies on its own.

Stereo, not mono

Deliver a stereo, 2-channel file. Spotify specifies stereo only, and Apple states plainly that single-channel audio will not be accepted. A mono file exported by accident is one of the most common upload errors there is, and it’s the kind of thing you don’t notice until the file bounces. Check your export setting before you deliver.

If you genuinely have no stereo source, an old field recording or a vintage tape, the fix isn’t to deliver a true mono file. Apple wants two identical channels, a left and a right carrying the same audio, so the file is technically stereo even when the content isn’t. Your DAW can do that on export. The point is the file has to be 2-channel.

Why you shouldn't master to the platform's LUFS target

This is the one that trips up a lot of people, so let me be clear about it. Spotify normalizes playback to -14 LUFS integrated at its Normal setting. That number is a playback level, applied when someone presses play. It is not a delivery requirement, and Spotify does not reject a file for measuring louder or quieter than -14. So you do not need to, and should not, master your track to hit -14 LUFS.

Here’s the mechanism. If your master comes in louder than the target, the platform applies gain reduction and turns it down. If it’s quieter, the platform may lift it. Either way the loudness gets matched on playback. What that means in practice is that crushing your master to be as loud as possible buys you nothing. The platform just turns it back down, and the dynamic damage from the over-compression stays in, so you end up with a flat, lifeless sound played back at the same level as everyone else. Master for how the song should feel, and let normalization do its job.

Other platforms normalize too, around similar levels. The figures you see quoted for Apple Music (about -16 LUFS) and Amazon Music (about -14 LUFS) are widely accepted working numbers from third-party measurement, not specs either company has published. Treat them as estimates, not gospel. The takeaway doesn’t change: every major platform normalizes loudness on playback, so the integrated loudness you deliver at isn’t the thing that decides how loud your track sounds next to the others.

Headroom and True Peak: the one number to respect

If there’s a single loudness-related number to actually master to, it’s the True Peak ceiling, not the LUFS target. Spotify recommends a True Peak maximum of -1 dBTP for masters that get encoded to lossy formats. If your master is louder than -14 LUFS integrated, Spotify suggests keeping True Peak below -2 dBTP to cut distortion risk further. Apple Digital Masters and EBU R128 both land on -1 dBTP as the ceiling too, so it’s well-supported guidance, not one platform’s preference.

The reason is inter-sample peaks. When your lossless file gets encoded to a lossy format, the way the audio is reconstructed can push the actual output peaks above the sample values that were sitting in your original file. Spotify says outright that it leaves headroom for lossy encodings to preserve quality. So if you master right up to 0 dBFS, the encode can tip those peaks into clipping that wasn’t in your file to begin with. Leaving that -1 dB of headroom is what stops it. To be straight with you, the often-repeated “up to 1 dB” rise is a mastering-education rule of thumb, not a hard measured maximum from a standard. The -1 dBTP ceiling itself is the guidance worth following.

And don’t strip headroom out chasing loudness. Spotify does apply a playback limiter in its Loud volume mode (a -1 dBFS sample ceiling, 5 ms attack, 100 ms decay), but it states that’s specifically for soft, dynamic tracks, and it’s a playback-side behavior, not a reason to flatten your master. Leave the headroom in. It costs you nothing audible and it protects the file through the encode.

run your release through the free metadata checker to catch the field mistakes before you deliver →

What gets an audio file rejected

A handful of mistakes account for most audio rejections, and every one of them is avoidable before you upload. Clipping or peaks at or above 0 dBFS. A mono file delivered where stereo is required. A lossy source file submitted as the master. A WAV using the wrong internal format code. Extended silence at the start or end of the track. And an up-sampled or bit-padded file passed off as native hi-res, which Apple explicitly prohibits.

That WAV format-code one is worth knowing because it’s invisible in most DAWs. If you deliver WAV to Spotify, the file has to use format code 0x0001 (WAVE_FORMAT_PCM), not 0xFFFE (WAVE_FORMAT_EXTENSIBLE). It also needs valid fmt and data subchunks, audio data only after the start of the data subchunk, and it has to be a full track, since clips get rejected. Most export presets do this right by default. If a WAV keeps bouncing for no obvious reason, this is a likely culprit, and delivering FLAC instead sidesteps it.

Once the audio file itself is clean, the rejections that are left tend to live in the metadata: the title casing, the credits, the copyright lines, the codes. The album art specs have their own set of hard rules, and your ISRC code has to be right per recording. For the full field-by-field picture, start with the release metadata guide.

check your metadata for free before you distribute →