- From: Jean-Marc Valin <jmvalin@mozilla.com>
- Date: Thu, 02 May 2013 16:28:38 -0400
- To: Frederick Umminger <frederick.umminger@gmail.com>
- CC: "public-audio@w3.org" <public-audio@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/2013 03:17 AM, Frederick Umminger wrote: > Soft-clipping will add distortion to the sound whereas a good > compressor/limiter will not. Well, it depends on the amount of clipping that goes on. Also, clipping is unavoidable even with a compressor, so it's probably a good idea to to it smoothly anyway. Compressors also have their own artefacts, especially full-band ones. For example, if there's a low frequency burst, it'll modulate any high frequencies present in the signal. So for large excursions, compressors may be unavoidable, but it we can avoid those, soft-clipping may be a better option. One important advantage of (soft-)clipping is that when there are no overflows, it does not cause any artefact at all. > Head room is often the best way to prevent clipping,but it can > conflict with a desire to maximize the loudness. Without an > enforced standard for head room there is an inevitable creep > towards 0 dB FS. With regards to this, perhaps the Web Audio API > should somehow incorporate the proposed game console loudness > standard ( http://gameaudiopodcast.com/ASWG-R001.pdf ), which is > based on proven television loudness standards, I'm not sure how > this could be enforced though, other than through dynamics > processing within the browser. Well, I would say that at least having a standard level would go a long way. That's actually what I've been trying to specify for WebRTC audio: http://tools.ietf.org/html/draft-ietf-rtcweb-audio-01#section-4 Of course, being able to actively enforce it (e.g. running some level control on any signal that exceeds the limit) might be even better. For example, there could be a -20 dB "maximum average level", above which a slow-acting AGC would trigger to maintain the average at no more than -20 dB. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRgsx2AAoJEJ6/8sItn9q9QMcH/1t1NImwzM7gT9J1PC+xUsSh S9Ei9+3H95bceCNEzGNBZvFFGzgGT3J0thaPgcPNTOYPEImCYQO0DhDRXLaayTHt 7PtuuVjCLRJGDMQxWePPrAALJhtokaSqx3/QfJQTQEfYRf5mowiwCgGahFcFqfcx OPJvonzbRgSTlxgVq14cU1Dk8kNnoMCfYrEOyu/yHbZEtaPgAGenOXJTPE/is3PY W1Yz5eQfo1fh4VVqOZLyva2wEW9q6suAS7fk200DaLytdY7LYc3MCOTnZ8GFO7bg p2Fbb/LkkhgG8t9l3UfC5Txu/6nBXwarmaoBmMcB9JPqevRmiQCvns9uaNyUFDE= =XOEn -----END PGP SIGNATURE-----
Received on Thursday, 2 May 2013 20:29:07 UTC