25 Apr How to Mix and Burn Your Songs for Spotify?
It’s undeniable: Spotify has changed some rules of music production and the record market. I don’t like to think it’s worse than before: I’m more inclined to understand the mechanisms and use them to produce better. I decided to write this article to collect official guidelines taken from Spotify and some tips on mastering that come from my direct experience with production.
How to Mix and Burn Your Songs for Spotify?
To burn a song by optimizing it for Spotify, you need to consider the operating algorithm that the platform applies during streaming: the songs are encoded directly while listening, in short, when you press “play”.
Let’s say that, as it is “sold” by Spotify, the algorithm puts all the songs at the same “volume” level; this is to avoid that higher tracks are more advantaged than other lower ones.
A democratic system! However, it is important for those who produce music to understand how to exploit this logic of operation in a coherent way: the first thing to know is that Spotify normalizes a song based on the data relating to its “volume”.
In Spotify, the normalization is activated automatically: look at the image that shows the “settings” menu (I’ll take into consideration the “normal” level, which is the one I recommend you use).
Volume data is generated through ReplayGain: a system that assigns a volume value to each song by writing it in the file’s metadata.
What scale and method do you use to measure?
Here’s the problem: in the studio, we are used to considering LUFS (loudness unit full scale) our reference scale for “volume”. While Spotify, using ReplayGain, does not release a real conversion to LUFS, unfortunately.
In the guides of the platform and in those of ReplayGain, -14dB LUFS is communicated as a reference data (“normal” selection): therefore, it means that all the songs are “brought” from Spotify to -14dB LUFS.
Spotify states:
When the streaming system receives a file, when it is played, it undergoes a “downward” or “upward” gain normalization based on the data written by ReplayGain, as follows:
Downward if the song is higher than -14dB LUFS. And in this case, without particular distortions.
Upwards if the song is lower than -14dB LUFS, a more delicate operation, especially because a limiter is inserted on the song.
Our master will therefore have to get as close as possible to -14dB LUFS, but we are often forced to “play” our mixes higher than -14dB LUFS! So we are already starting on the wrong foot. The Spotify algorithm does not act only and exclusively by taking into consideration a trivial reference level (-14dB LUFS) and respecting other logic inherent in the ReplayGain system: the peaks, the type of signal and its composition also count. In frequency as well as the dynamic factor.
However, there are some objective parameters now tested by various professionals with whom I have had the opportunity to collaborate and compare myself:
The advice I received is to burn the songs with maximum reference.
-8 \ -7dB LUFS (to be precise “short term”), considering the points of the songs with more “volume”, i.e. their maximum energy point. The limiters are set to -1dB (actual peak) if you are mastering around -14dB LUFS or lower; -2dB (actual peak) if our song is higher than -14dB LUFS.
What level should you mix?
As much as we want to fight the loudness war alone, any mix positioned at -14dB LUFS will sound lower than our references and will not satisfy us.
Therefore, after several tests and comparisons, I noticed that mixing at -11 \ -9 dB LUFS gives a good compromise for the mastering phase; in fact, it is possible to reach -8dB \ -7dB LUFS without having to upset the mix and ruin the work.
In conclusion, the argument is not mathematical and straightforward because I repeat it: ReplayGain is not based only on the analysis of volume data.
If I have increased your concern about Spotify, don’t worry: the platform has stated that very soon, it will almost certainly adopt the ITTU 1770 standard for encoding so that it will use LUFS as a reference scale.
No Comments