Re: DynamicsCompressorNode

On Fri, May 3, 2013 at 12:24 AM, Frederick Umminger <
frederick.umminger@gmail.com> wrote:

> This basic idea has been adopted, and even legislated, for digital TV
> (CALM act). The digital TV
> standards are being promoted for console gaming, per the link I sent
> earlier. The relevant standards
> are EBU R128 and ATSC RP A/85. The adopted measure of loudness is ITU-R
> BS.1770. It would
> be a mistake to use any other loudness measurement or use any other
> standard average level.
>
> A result is that streaming video content is likely to be mastered
> according to these standards.
> This will lead to level mismatches between video and other web audio
> content unless the other
> web content follows the same standards, or unless the video is remastered
> to a different level.
> But, without a standard, what level would that be?
>
> Something to also consider is the health and safety aspect. If audio
> levels on web pages vary
> too much then there is a danger of users getting blasted by unexpectedly
> loud audio when they
> transition from a quiet page to a loud one.
>
> The situation is even worse if one is listening to web audio content on a
> smart TV system that
> where one can switch between web browsing, video streaming, DVD and
> Blu-ray playback, apps,
> and console gaming. There is a huge potential for annoyingly inconsistent
> audio levels.
>
> Levels could be enforced over a long-time average with a very slow-acting
> compressor/limiter.
> The result would be transparent if the time-constant is large enough.
> At some slow-enough rate the phenomenom of change-blindness should take
> place,
> where a user cannot tell that the level is changing.
>
>
> Sincerely,
>    Frederick
>

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>wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> 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/
>>
>> iQEcBAEBAgAGBQJRgyQcAAoJEJ6/8sItn9q9214IAIz/hVLrtbK7ohQ3ELGAk216
>> HBgerLiBTECtok92Wn7jJgPwXhjV/2+HS6DIRv0xU/0pX109EJNG8gLFbju4qnyb
>> wBuiGVrw1VjSk9FKqrRW7i9yurvo/k8axGEAeowYd0xUC52ZfI/dxm+u/POprOFK
>> ZO0rS7M+94sSMmHjzaApU3ZfFB1WvMgP662D6s6t+xPZDCuskx5drv1DWVplwKNS
>> EUTkpcQ6dUfgTrbNgrYa799kAggs7H/1nliQMTbcVSCrS3UFGty5fFCbLOdleCOj
>> WCB8DAnNvP0m2W6q4+taQgHsoXlWXyH6/4ucFVx8uZrAY6wGMn1bkEWPxmuY4IY=
>> =PbNb
>> -----END PGP SIGNATURE-----
>>
>
>