![]() ![]() ![]() So in conclusion and to answer Paul's question, I would standardise everything at -16LUFS with as small as tolerance as possible, preferably no more than a 2LU spread, with a maximum true peak level of -3dBTP. If you have ever worked with tools like the Sonnox Pro Codec plug-in you will find that levels above -3dBTP can still distort the codecs, so my advice is to use a true peak limiter set to -3dBTP. Again the EBU R128 program delivery specs recommend a maximum true peak of -3dBTP because lossy codecs, which are at the core of this type of content delivery, cannot handle peaks much above -3dBTP. I am also surprised about the -1dBTP limit. ![]() ![]() That said, most of this content is going to be consumed in noisy, or at best, less than ideal environments and so I would recommend that rather than drop the target loudness to accommodate the additional dynamic range that content destined for consumption on mobile devices is mixed with a relatively low loudness range, it which case the reduced headroom is not an issue. I appreciate that the higher the target loudness is the less headroom there is to support content with a good dynamic range. I would prefer a 1LU tolerance both ways so a range of -15 to -17, but if it is essential to have a wider range, and I don't think it is, then make it -14 to -18LUFS please rather than -16 to -20 LUFS. If we are going to have a range then I would suggest it is a range around -16LUFS. I agree with Paul Figgiani that -20 is getting too close to -23 which is accepted as too low for mobile devices. Why YouTube are settling on -13LUFS is baffling me and I am a little surprised that the AES document is suggesting a window of -16 to -20LUFS. The good news is we have an excellent mechanism to measure and specify loudness with the BS1770/3 standard that has been accepted worldwide. With more and more content being delivered and consumed via streaming and on line delivery services, the huge variation of loudness is having the same detrimental affect on consumers, just as we had in broadcasting before the new loudness workflows were introduced. Maybe they decided that no one else was stepping up and this issue needs resolving and so they have stepped in, so thank you AES for putting a team together and grasping this issue. It is good to see the AES producing a recommendation document but I am curious as to why the AES decided to step in. But what do I think? Thank You AES For Stepping Up Paul has posted his own thoughts on his produceNewMedia blog. Now the Audio Engineering Society (AES) has published Technical Document - AES TD1004.1.15-10 - Recommendation for Loudness of Audio Streaming and Network File Playback and community member Paul Figgiani reached out to me to ask my view on this situation and the AES document. However YouTube seem to be going for -13LUFS and Ian Shepherd has written about this on his Production Advice blog. A number of services including iTunes Radio have settled on -16LUFS and we deliver our weekly podcast to -16LUFS too. There has been a view for a long time that the broadcast standard of -23LUFS or -24LKFS would not be suitable for portable devices because there isn't enough gain in the headphone amps to deliver an acceptable volume. Consequently we still have issues with loudness when listening to streaming related content. Currently there is no standard, unlike broadcast workflows that have settled on one standard, all be it with a number of delivery specs around the world. There has been some discussion on what loudness to use for audio streaming content including iTunes Radio, Spotify, YouTube etc. ![]()
0 Comments
Leave a Reply. |