This post is not a tutorial on loudness and metering in game audio. It is rather about sharing my findings on something I am currently researching on, hoping it can help those of you who would be in a similar position as me. I will definitely revisit this post at a later stage of my current project to share my experiences and conclusions on this info.
Since this is a work in progress, or rather a learning in progress, feel free to comment and let me know about any better/other ways to see or do these things.
I’ve been working on my current project for a few months now and, although I’ve been wondering about loudness and metering earlier in the process, the time has only recently come for me to make decisions on the matter, and hence look deeper into it.
First, I found this amazing resource which helped me understand more about all of it very quickly. This article from Stephen Schappler is a real gem and I strongly recommend you have a read. I will mention some of the things he shared in his article here, as well as develop according to my own experience.
This interview with Gary Taylor from Sony is equally very instructive, going into further details about Sony’s Audio Standards Working Group (ASWG) recommended specs.
Industry standards (or lack thereof) and game audio solutions
There are currently no standards set for loudness measurements in game audio, resulting in wide variations and discrepancies in loudness from one game to another. The differences in gaming set ups and devices also present a challenge in terms of developing those standards.
One way to start looking into this is to refer to the BS.1770 recommendations to measure loudness and true peak audio level.
To put it simply, these algorithms measure Loudness Level at three different time scales:
- Integrated (I) – Full program length
- Short Term (S) – 3 second window
- Momentary (M) – 0.4 second window
What these mean for game audio will probably be different than what they mean in TV, as there is no full program length in interactive media, and 3 and 0.4 seconds may prove to be too short cuts to take any accurate measurement, again relating to the dynamic and interactive nature of the medium.
This is what Gary Taylor recommended about adapting the BS.1770 measuring terms to game audio (in this interview) :
We recommend that teams measure their titles for a minimum of 30 minutes, with no maximum, and that the parts of any titles measured should be a representative cross-section of all different parts of the title, in terms of gameplay.
As BS.1770 also indicates, it would be wise to consider the Loudness Range (LRA) and the True Peak Level. In order to do so, you would need good tools (accurate Loudness Meter) and a good environment (calibrated and controlled).
In terms of numbers, let’s look at the R128 and A/85 broadcast recommendations, which we could assume would present a similar objective if working on console and PC games, where your environment and set up would be the same/similar as your TV set up.
Those recommendations are:
- Program level average: -23 LUFS (+/-1)
- True peak maximum: -1 dBTP
- Program level average: -24 LKFS (+/-2)
- True peak maximum: -2 dBTP
However, these numbers may not apply to the mobile games industry, and different terms would need to be discussed in order to set standard portable devices levels. Some work has already been done on that matter by Sony’s ASWG, who are among the first ones (if not the first) to consider standardising the game audio loudness metering process and providing recommendations. Here are their internal loudness recommendations for their 1st party titles:
- Average loudness for console titles: -23 LUFS (+/-2)
- Average loudness for portable titles: – 18 LUFS
- True peak maximum: -1 dBTP
Gary Taylor mentioned in his interview that studios such as Media Molecule and Rockstar are already conforming to Sony’s specs, both in terms of average loudness and dynamic range. This seems to indicate that progress is being slowly but surely made in terms of game audio loudness standardisation.
How to proceed?
The recommended process is to send the audio out from your game directly into your DAW and measure loudness with a specialised plugin. Be careful to make sure your outputs and inputs are calibrated and that the signal remains 1:1 across the chain.
Gary Taylor’s plugin recommendations to measure loudness:
As far as analysis tools, I personally have yet to find anything close to the Flux Pure Analyzer application for measuring loudness, spectral analysis, true peak, dynamic range and other visualisation tools. As far as loudness metering generally, Dolby Media Meter 2, Nugen VizLM, Waves WLM, and Steinberg SLM-128 (free to Nuendo and Cubase users) are all very good.
I have yet to experiment with those plugins and decide on my favorite tools. I happen to have the Waves WLM so will give that a try first, and plan to compare with the demo version of Nugen VizLM and see if I want to buy. I will update this article with feedback from my experience when ready.
Wwise and FMOD now also support BS.1770 metering, which is extremely convenient for metering directly within the audio engine.
In Fabric, there are Volume Meter and Loudness Meter Components which allow you to meter one specific Group Component. You could for instance apply those to a Master Group Component to monitor signals of the overall game.
However, I think that despite using these tools within the audio engines, it is worth measuring the direct output of your game directly from your DAW with the help of a mastering plugin. I see this as a way to ‘double-check’, I’m a big fan of making sure everything works as it is meant to, and listening to the absolute final end result of the product seems like a valid way to do this.
Finally, I unfortunately don’t have the luxury of working in a fully calibrated and controlled studio environment. If you are in a similar position as me, I’d strongly recommend considering renting a studio space towards the final stages of the game production to perform some more in depth mixing and metering.
I hope this was useful even though this info is based mostly on research rather than pure experience. I will most definitely revisit this topic once my remaining questions are answered 🙂