W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: DynamicsCompressorNode

From: Frederick Umminger <frederick.umminger@gmail.com>
Date: Fri, 3 May 2013 00:24:16 -0700
Message-ID: <CAPJnUh_okYjhJOysgnRJv7o0BkSyXqvmQf=6Cr=zjuy5upF8yA@mail.gmail.com>
To: Jean-Marc Valin <jmvalin@mozilla.com>
Cc: Chris Rogers <crogers@google.com>, "public-audio@w3.org" <public-audio@w3.org>
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




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-----
>
Received on Friday, 3 May 2013 07:24:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC