Program loudness LUFS · LKFS

The integrated loudness of the whole file — one number for the entire program. It is measured to ITU-R BS.1770, including its standard gating so that silence and very quiet passages do not pull the result down.

Where a spec measures the whole mix rather than the speech in it, this is the loudness measurement it constrains. The requirement might be a target with a tolerance, a range to land inside, or a maximum level. Some specs check program loudness and dialog loudness together.

BS.1770 uses two gates. The absolute gate removes silence and very quiet material below −70 LKFS. The relative gate then removes material more than 10 dB below the average of what remains. This keeps long periods of silence or very quiet content from pulling the integrated loudness down.

Dialog loudness LKFS

The integrated loudness of the L, R and C channels, measured over the parts of the program that contain speech. DeliveryQC identifies speech using Dolby Dialogue Intelligence.

Listeners generally set their volume by the dialog, so matching programs by dialog level helps keep speech at the level they expect. Some specs target dialog for this reason; others target the whole program. Some use one or the other depending on how much speech the program contains.

The dialog measurement also leaves BS.1770’s relative gate off. Quiet speech therefore remains part of the average instead of being removed for being quiet.

If there is too little speech to produce a reliable dialog-gated measurement, the row reads Needs dialog rather than guessing. Some specs account for this by changing their target below a speech threshold — see Dialog (speech).

Program loudness range LU · LRA

How much the loudness varies across the program, measured according to EBU Tech 3342. It is a statistic, not a maximum: the spread between the 10th and 95th percentiles of short-term loudness, after quiet material has been gated out.

A wide range means the quiet passages sit a long way below the loud ones. That can work well in a cinema, but can make dialog and quieter scenes harder to follow on a phone or a television’s built-in speakers.

Specs that quote a loudness-range figure usually treat it as advice rather than a hard limit. The Result column shows which, and an advisory breach produces a warning without failing the file.

Because the measurement uses percentiles, a single gunshot or brief quiet passage has little effect. Sustained differences between scenes do.

Dialog loudness range LU

The loudness-range statistic calculated over the speech in the program rather than over the program as a whole.

Only a few specs quote a dialog loudness range, and they treat it as advice. Wide-ranging dialog can be a legibility problem in a way that wide-ranging music is not: the quieter lines may get lost.

Max short-term LUFS

The highest short-term loudness reading anywhere in the file. Short-term loudness is measured over a sliding 3 s window, according to EBU Tech 3341.

Few specs put a limit on it. The ones that do are catching something an integrated loudness figure cannot: a mix can hit its overall loudness target while still containing a passage that is very loud for a few seconds.

Max momentary LUFS

The highest momentary loudness reading in the file, measured over a sliding 400 ms window according to EBU Tech 3341. It is the shortest loudness measurement reported here and the closest thing to an instantaneous loudness level.

Momentary limits are rare in delivery specs, so this measurement is usually reported rather than checked.

Dialog (speech)

The proportion of the program that Dolby Dialogue Intelligence classified as speech, expressed as a percentage of the measurement blocks it scored.

Some specs change their loudness requirement based on this percentage, switching between a dialog target and a program target at a threshold defined by the spec. The note under the table shows which side of that threshold the file falls on.

The percentage itself is never a pass or fail. It can determine which loudness measurement the spec uses for the verdict; see the * marker.

Very short files can read slightly low because the classifier takes a few seconds to warm up. The row appears only when dialog analysis succeeds. If it does not, the loudness table indicates that instead.

Max true peak dBTP

An estimate of the highest level the waveform reaches between the stored samples, rather than just the highest sample value. DeliveryQC uses 4× oversampling for its true-peak measurement, as specified in BS.1770.

This is the peak measurement used by many modern delivery specs. A file can read exactly 0 dBFS on a conventional sample-peak meter and still exceed full scale when a converter or encoder reconstructs the waveform. That is why true-peak ceilings are normally set below full scale. The Spec column shows the limit for the selected spec.

The measurement works by oversampling, so it approaches the true inter-sample peak rather than landing on it exactly. A 4× reconstruction can read a little below the real continuous peak, and higher oversampling ratios narrow that gap without closing it.

Lossy encoding can change the decoded peaks again. They can move in either direction, and the amount cannot be predicted exactly from the source file. The headroom below full scale provides some protection against those codec-induced peak changes.

Max sample peak dBFS

The highest individual sample value in the file. This is the number shown by a conventional DAW peak meter.

It is reported because it is a familiar measurement, but many modern delivery specs constrain true peak instead. Sample peak can underestimate the actual reconstructed peak, sometimes by more than 1 dB.

Sample rate

How many times per second the audio was sampled, expressed in kHz. DeliveryQC supports 44.1 and 48 kHz files.

Video delivery specs almost always require 48 kHz. Music and podcast specs are where exceptions are more common, including requirements that accept 44.1 kHz or higher sample rates.

Bit depth

The number of bits used for each sample, and whether the samples are stored as integers or floating point. For integer PCM, bit depth determines the quantization resolution and theoretical dynamic range. It does not determine the loudness of the program.

Many delivery specs require 24-bit PCM, although some also accept 16-bit. For DeliveryQC’s integer-PCM check, a floating-point file fails regardless of its width: the requirement is for integer PCM, not simply for a certain number of bits.

Channel layout

Which channels the file contains and the order in which they are stored — from mono through the various 5.1 and 7.1 layouts, up to 7.1.4.

The order matters as much as the channel count. The same set of channels can appear in different orders across the industry; for example, SMPTE and film channel orders differ, and the LFE channel is not always in the same position. A file with the wrong order can therefore play with its channels swapped.

DeliveryQC infers a layout from the channel count and lets you correct it. Where a spec expects a particular order but the same channels are present in a different order, the row warns rather than fails. The file may be technically deliverable, but the channel order should be confirmed.

Specs delivered as one file per channel do not check channel order because the filename carries that information. In those cases, the check only verifies that the expected channels are present.

Duration

The length of the audio, shown as HH:MM:SS and calculated from the sample count and sample rate. It is the span over which the integrated loudness is measured.

Duration is reported for reference rather than checked; none of the specs covered here constrains it.

DC offset dBFS

A constant bias on a channel that shifts the waveform away from zero. DeliveryQC measures the whole-file mean of each channel and flags offsets above −50 dBFS, identifying the channel with the largest offset.

A large DC offset is usually a capture or conversion problem. It uses up headroom that should be available to the program and can cause clicks at edit points where clips with different offsets meet.

Because the measurement is averaged over the whole file, an offset affecting only part of the program can be diluted by the rest of the file. A clean result is therefore weaker evidence than a flagged one.

Channel presence

A check for non-LFE channels whose true peak never rises above a very low threshold. The threshold is low enough that a channel containing nothing but dither is still detected.

A mis-routed stem, or an empty surround or height channel, can look exactly like this. An intentionally empty channel is perfectly valid; the purpose of the check is to make sure it was empty on purpose before delivery, rather than discovering the problem afterwards.

Phase correlation

The correlation between the front L and R channels over time, from +1 (identical) through 0 (unrelated) to −1 (opposite). DeliveryQC flags sustained correlation below −0.5 rather than a momentary dip.

Strongly out-of-phase material can cancel when the mix is folded down to mono, causing parts of it to disappear on playback systems you do not control. Wide stereo material can naturally produce brief negative correlation, which is why a short excursion is not flagged.

In the tool, the correlation plot under the results shows where the problem occurs. This is usually more useful than the minimum value alone, since the minimum can include dips that were too brief to trigger a warning.

LUFS and LKFS

Two names for the same unit: absolute loudness on the BS.1770 scale. −27 LKFS and −27 LUFS represent the same loudness level.

ITU and ATSC documents generally use LKFS (Loudness, K-weighted, relative to Full Scale), while EBU documents use LUFS (Loudness Units, relative to Full Scale). The two terms refer to the same unit; the difference is terminology, not measurement method.

Dialog-gated loudness is a different measurement from program loudness. It uses speech detection to select the parts of the program included in the measurement. Depending on the standard or workflow, that measurement may be reported in LKFS or LUFS.

In DeliveryQC, dialog loudness is labelled LKFS to follow the terminology used by the standards that define the dialog-gated measurement.

LU

Loudness Units — a relative measure of the difference between two loudness values. 1 LU is 1 dB.

Loudness range and spec tolerances are expressed in LU because they describe a difference rather than an absolute level. Absolute loudness levels use LUFS or LKFS.

dBTP

Decibels relative to full scale, true peak. This is measured from the reconstructed waveform rather than the stored samples, so it can exceed 0 dBTP.

Delivery specs state their peak ceilings in dBTP rather than dBFS because the ceiling needs to apply to the reconstructed waveform, not just to the stored samples.

dBFS

Decibels relative to full scale. For integer PCM, 0 dBFS is full scale, so an integer file cannot contain samples above it. Floating-point files can, and those values are reported as measured.

DeliveryQC uses dBFS for sample peak and DC offset — measurements of the stored samples themselves.

The * marker

A row marked * is the measurement the verdict actually depends on when the spec provides more than one way to satisfy a requirement. The note under the table explains which condition selected it.

For example, a spec may use dialog loudness when the program contains enough speech to produce a valid dialog measurement, and program loudness otherwise. Both measurements are still calculated, but only the applicable one is checked. The other is reported without a pass/fail result.

The same marker is used when a spec accepts either of two measurements and one satisfies the requirement. The satisfying row is marked, while the alternative is muted rather than shown as a failure.

Pass, Warn, Fail, Needs dialog

Pass — inside the applicable limit.
Fail — outside a hard limit. The file does not meet the spec.
Warn — inside the hard limit but outside a recommended limit, or an advisory check that needs attention.
Needs dialog — the check requires a dialog-gated measurement that the file did not produce.

A Fail determines the overall badge, as does a hard check that could not be measured. Warnings never fail a file; they flag things worth checking before delivery.

A warning or failure includes the reason after the status, so tiered checks show which limit was crossed. For example, Warn · over ideal by 4.7 LKFS means the recommended target was exceeded, but the hard limit was still met.

If a hard check could not be measured, the overall badge reads INCOMPLETE rather than Pass or Fail. The file has not been cleared, but the check has not found a problem either.

N/A

A measurement that was made but is not constrained by the selected spec. There is nothing to pass or fail against.

DeliveryQC reports measurements even when the selected spec does not require them. Some of the targets are measurement standards rather than delivery specifications and therefore have no file-format requirements at all. For those, an empty File table would look like a failure to load rather than simply meaning that there was nothing to check.

silent

The meter found no program content. The reading reached the measurement floor rather than a meaningful level.

The floor is a property of the meter, not a level that can be acted on, so DeliveryQC reports silent instead of displaying the floor value.

A silent file is still evaluated against the spec. It really is below any peak ceiling, but it also does not meet a loudness target.