Audio Level Standardization (Was Re: DynamicsCompressorNode)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The problem if we go with "let's not touch anything" is that we shift
the burden of limiting to the user. The problem is that users will be
listening to:
1) WebRTC calls with a standard level of -19 dBm0
2) Properly mastered R128 content at -23 dB LUFS
3) "Loudness war" CDs mastered up to - 4 dB FS
4) Ads that will likely aim for -4 to -10 dB FS

This means users will be forced to deal with variations up to 20 dB in
the loudness of the audio, i.e. they'll have to manually adjust their
volume knob. What this also means is that because of the presence of
3), there's a pressure to remaster content to approach the insane
levels that CDs are mixed at, with zero dynamic range. There's a way
to stop this. Broadcasters are starting to implement it and I think we
should do the same on the web.

Cheers,

	Jean-Marc

On 05/03/2013 01:32 PM, Chris Rogers wrote:
> It's up to the content authors to create content which is
> well-mastered according to any loudness standard.  The job of the
> Web Audio API is to play back the content as it's been mastered
> bit-for-bit perfectly.  In the end the AudioContext just generates
> a linear PCM stream between -1 -> +1.
> 
> Think of it this way.  If we pipe an <audio> element with a very
> well produced music track into the Web Audio API with a visualizer,
> we don't want to add any extra processing on top of that.
> 
> Chris
> 
> 
> 
> 
> 
> 
> 
> 
> On Thu, May 2, 2013 at 7:42 PM, Jean-Marc Valin
> <jmvalin@mozilla.com <mailto:jmvalin@mozilla.com>> wrote:
> 
> The idea here is just to change the way the signals are specified.
> In CD audio, you have a 16-bit values, so any instantaneous value 
> between -32768 and 32767 is valid (any value beyond that is
> clipped). The problem with specifying the maximum instantaneous
> value is that it leads to lousness war mastering where everyone is
> trying to mix as loud as possible, while destroying any sort of
> dynamic range. In that context, anyone trying to produce a good mix
> with a decent dynamic range would end up with a recording that's
> *much* lower than loudness war recordings.
> 
> What would make more sense (and what I'm proposing) is that instead
> of specifying the maximum instantaneous value, we just specify the 
> maximum *average* amplitude (e.g. RMS or weighted RMS). Anything 
> that's recorded at or below that level passes through without any
> sort of modification. Only signals that exceed that level are
> limited -- in the same was as PCM signals exceeding 32767 are
> clipped. Now, developers can still use other compression effect as
> they please, but at least we would have a way to have both uniform
> audio levels *and* make it possible to have a decent dynamic
> range.
> 
> Jean-Marc
> 
> On 05/02/2013 06:55 PM, Chris Rogers wrote:
>> I'm not a big fan of the idea of a hard-coded
>> compressor/limiter, but if there were one then I wouldn't want it
>> touching the signal at all if the signal remains below 0dBFS.
>> Sound designers/producers take great care to master their music
>> using their own mastering compressors/limiters, etc. so should
>> have the option (the default) to pass their signal through
>> cleanly without any processing at all.  In other words a
>> "straight wire".  My idea with the DynamicsCompressorNode is that
>> developers can choose to use it, especially in cases where they
>> may be mixing multiple
> sound
>> sources together, in which case it can help glue the mix
>> together.
> 
> 
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRhAY4AAoJEJ6/8sItn9q9DjgH/AlTk6e7ybNXJSGAkaWm6eY2
mmng6RTUadWEQlsc4xOvQU/sbzwNi8p5GCKvjm9lt7QK6UVT+HnWU/Izo8E8exZ1
jYjlfMhDFOWrgqAbZYGlvBroi6U3kFIzPeLqZTJBqKc0CVippb9vpTO1W3FOtwzO
9mLQz5/n1HHh9Y3HlXNztGFpotYOdo12DUZbE1LU+ml/YiSmOz2kcr1zrsMcOxer
bMvn03zqvKC00Z63D1MeizBIGLx90+2JbUFzr8/CPpxhqAsFnXnASIOWYYCZwv+G
8KKnOFJF4Vn3JvQsbRkIXKK70Ivaiyb9qGj2Yd0aKzAkurPXy8R3tfI0dCxCBl4=
=aARR
-----END PGP SIGNATURE-----

Received on Friday, 3 May 2013 18:47:49 UTC