Programme level

Programme level refers to the signal level that an audio source is transmitted or recorded at, and is important in audio if listeners of Compact Discs (CDs), radio and television are to get the best experience, without excessive noise in quiet periods or distortion of loud sounds. Programme level is often measured using a peak programme meter or a VU meter.

The level of an audio signal is among the most basic of measurements, and yet widespread misunderstanding and disagreement about programme levels has become arguably the greatest single obstacle to high quality sound reproduction.

How it works

Live sound covers an enormous range of levels, but this is not something that can be demonstrated with a conventional sound level meter. Sound level meters respond quite slowly, even on a "fast" setting: they use a root mean square (RMS) rectifier which by definition must take a slow running average of the square of the input voltage. Music is complex, and constantly varying, with brief peaks originating from many sources including the initial impact of sticks on cymbals and drums. A loud band might measure 100 dB SPL on a sound level meter, yet have peaks reaching 130 dB SPL or higher.

A recording system must handle these peaks; they can be measured using a peak responding meter with an integration time of 0.5 ms or less (not a standard IEC type PPM which has a longer integration time).

The sound level meter is useless for properly assessing noise levels, since the commonly used A-weighting is based on equal-loudness contours for pure tones, and is not valid for the random noise.

The subjective loudness of noise is best measured using a noise-meter to the ITU-R 468 noise weighting standard. The chart below shows, on this basis, the real range of live music, and then the level capabilities of various stages in the audio chain, from microphone to loudspeaker.

Analysing programme levels

This chart is based on the assumption that what goes in should come out—true high-fidelity—and so an Alignment Level (AL) corresponding to 100 dB SPL has been assumed throughout. Any lower level would imply severe clipping at the first stage; the master recording. Top quality microphones do not present a problem; most will handle 130 dB SPL without severe distortion, and a few manage more than 140 dB SPL.

The master recording process, using current 24-bit techniques, offers around 99 dB of "true" dynamic range (based on the ITU-R 468 noise weighting standard); identical to the dynamic range of a good studio microphone, though very few recordings will use just one microphone, and so the noise on most recordings is likely to be the sum of several microphones after mixing, and probably at least 6 dB worse than shown.

gollark: It could record locally and upload later, though.
gollark: This person apparently reverse-engineered it statically, not at runtime, but it *can* probably detect if you're trying to reverse-engineer it a bit while running.
gollark: > > App behavior changes slightly if they know you're trying to figure out what they're doing> this sentence makes no sense to me, "if they know"? he's dissecting the code as per his own statement, thus looking at rows of text in various format. the app isn't running - so how can it change? does the app have self-awareness? this sounds like something out of a bad sci-fi movie from the 90's.It's totally possible for applications to detect and resist being debugged a bit.
gollark: > this is standard programming dogma, detailed logging takes a lot of space and typically you enable logging on the fly on clients to catch errors. this is literally cookie cutter "how to build apps 101", and not scary. or, phrased differently, is it scary if all of that logging was always on? obviously not as it's agreed upon and detailed in TikTok's privacy policy (really), so why is it scary that there's an on and off switch?This is them saying that remotely configurable logging is fine and normal; I don't think them being able to arbitrarily gather more data is good.
gollark: > on the topic of setting up a proxy server - it's a very standard practice to transcode and buffer media via a server, they have simply reversed the roles here by having server and client on the client, which makes sense as transcoding is very intensive CPU-wise, which means they have distributed that power requirement to the end user's devices instead of having to have servers capable of transcoding millions of videos.Transcoding media locally is not the same as having some sort of locally running *server* to do it.

See also

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.