This server lets you check loudness compliance of media files and list supported broadcast standards.
check_loudness: Analyze a media file (any format ffmpeg reads) against EBU R 128, ATSC A/85, or BS.1770. Returns a verdict (pass/fail/measured) with per-metric details (integrated loudness, loudness range, true peak), failure descriptions, and exact remediation (e.g., gain correction with ffmpeg command). Supports optional audio stream selection and detailed mode (max momentary/short-term loudness).
list_standards: Retrieve all supported standards with targets, tolerances, and official citations.
A loudness compliance verdict, not raw meter output. loudcheck measures
a media file with ffmpeg and answers the question that actually matters —
does this file pass the spec? — against formal published standards:
Agents start here → SKILL.md — when to call this, worked examples, MUST/MUST NOTs. Family contract: FAMILY.md.
EBU R 128 (European broadcast: −23.0 LUFS ±0.5 LU, max −1 dBTP)
ATSC A/85 (US television: −24 LKFS ±2 dB, true peak below −2 dBTP)
BS.1770 (measure-only: BS.1770 defines no compliance target, so this
mode returns verdict measured with the numbers and no judgment)
$ loudcheck master.wav --standard EBU_R128
FAIL — EBU R 128
✗ integrated -19.4 LUFS (target -23.0 ±0.5, delta +3.6)
✓ true peak -16.3 dBTP (max -1.0)
· LRA 0.0 LU (informational)
→ apply -3.6 LU gain to reach -23.0 LUFS (e.g. ffmpeg -af volume=-3.6dB, or loudnorm I=-23)Ships as a CLI and an MCP tool over one engine, so agents and humans get the identical verdict.
An agent (or an engineer) can run ffmpeg's ebur128 filter and get numbers.
What it can't get from a shell is the verdict — that requires knowing the
standard's target, tolerance, and gating, and interpreting integrated
loudness vs. LRA vs. true peak against them. Loudness is one of the most
common causes of delivery rejection, and the gap is not measurement — it's
the standards-aware answer. That's the whole tool.
Related MCP server: ffmpeg-mcp
Requires Python 3.10+ and ffmpeg 5.0+ on PATH.
uvx loudcheck file.wav # zero-install run (requires ffmpeg >= 5.0 on PATH)
pip install loudcheck # CLI
pip install "loudcheck[mcp]" # + MCP serverFrom a clone: pip install -e ".[mcp,dev]".
loudcheck file.wav # EBU R128 by default
loudcheck file.mp4 --standard ATSC_A85 # first audio stream of a video
loudcheck file.wav --json # full structured verdict
loudcheck file.wav --standard BS_1770 # measurement only, no gates
loudcheck file.mov --all-streams # verdict every audio track
loudcheck file.mov --stream 1 # a specific audio track
loudcheck file.wav --detailed # + max momentary / short-term
loudcheck masters/ --standard EBU_R128 # batch a directory -> table
loudcheck a.wav b.wav c.wav # batch multiple files
loudcheck --schema # print the tool definitionBatch mode prints one line per file (plus remediation for fails) and a
summary; --json in batch emits an array. Exit code is 1 if any file
fails.
Exit codes carry the verdict: 0 = pass, 1 = fail (non-compliant),
2 = error (missing file, no audio stream, no ffmpeg). Gate a delivery on
the exit code alone.
--json is the full contract: overall verdict, per-metric
measured/target/tolerance/delta/pass with the spec citation attached to
every gated metric, failures in plain English, and remediation with the
exact correction — a fail 2.3 LU over target tells you to apply
−2.3 LU gain and hands you the ffmpeg incantation. This tool never applies
the fix (measurement and verdict only); the agent one-shots it with
loudnorm using the delta provided.
MCP: register loudcheck-mcp (stdio; or loudcheck --mcp, or
python -m loudcheck.mcp_server). Zero-install:
uvx --from 'loudcheck[mcp]' loudcheck --mcp. Tools:
check_loudness(path, standard) → same JSON as the CLI, and
list_standards() → the catalog with citations. Verified against
mcp==1.28.1.
tool.json at the repo root describes the surface machine-readably —
or fetch it live from any install with loudcheck --schema (the file ships
inside the package; a test keeps the two copies in sync).
ffmpeg version is part of the contract: every verdict includes
measurement_context.ffmpeg_version. Minimum supported: 5.0. Developed and
verified against 8.1.
Only formal, stable standards live in this repo; per-platform delivery templates (Netflix, DPP, Apple TV+, Amazon, broadcaster specs) never do. Platform specs change unilaterally and cover far more than loudness — the moment they enter, this stops being a near-zero-maintenance community tool and becomes a yearly-maintenance product. If a PR adds a target that a platform can change on its own, it belongs in a separate template layer built on top of this primitive, not here.
Contributions of additional formal standards (e.g. a plain ITU-R BS.1770
mode) are welcome: a standard is pure data in
loudcheck/standards.py — targets, tolerances, and
citations. No code changes required.
One ffmpeg pass with loudnorm=print_format=json (analysis mode) yields
integrated loudness, loudness range, true peak (oversampled dBTP per
BS.1770), and the gating threshold. The test suite cross-checks loudnorm's
reading against ffmpeg's independent ebur128 implementation — the two must
agree within 1 LU for CI to pass, so an ffmpeg release that changes filter
behavior is caught by the suite, not by users.
pytest generates calibrated test tones on the fly (no binaries in the
repo): per BS.1770's calibration statement, a mono 997 Hz sine at 0 dBFS
reads −3.01 LKFS, so tones are generated at exact known loudness — compliant,
too loud, too quiet, and true-peak-hot — and every verdict must match its
known expectation.
Loudness correction (use ffmpeg loudnorm with the delta this tool gives
you) · full-file QC (codec/colour/cadence) · real-time monitoring · GUIs ·
platform delivery templates (see guardrail).
MIT
Loudness compliance verdict for a media file against a formal published standard. Measures integrated loudness, loudness range, and true peak (via ffmpeg), then evaluates them against the named standard's targets and tolerances.
Args: path: media file to check (any format ffmpeg can read). standard: EBU_R128 (broadcast, -23 LUFS), ATSC_A85 (US TV, -24 LKFS), or BS_1770 (measurement only — verdict "measured", no gates). stream: zero-based audio stream index for multi-track files. detailed: also report max momentary / max short-term loudness (one extra ffmpeg pass).
Returns: dict with: verdict (pass|fail|measured), per-metric measured/target/delta and pass booleans, failures (plain-English causes), remediation (exact corrections, e.g. "apply -2.3 LU gain"), and measurement_context (ffmpeg version, stream info).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| stream | No | ||
| detailed | No | ||
| standard | No | EBU_R128 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears behavioral transparency. It discloses the use of ffmpeg, the three metrics, the effect of the 'detailed' flag (extra ffmpeg pass), and the 'standard' parameter's behavior (e.g., BS_1770 yields 'measured' verdict). It also describes the return dict including failures and remediation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long but well-structured with a summary and Args block. It front-loads the purpose and every sentence adds value. Minor redundancy in the return description could be trimmed, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and no output schema, but the description fully covers parameter semantics and provides a detailed return value description (dict with verdict, metrics, failures, remediation, context). It is complete for a compliance checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, which it does excellently. It explains each parameter: 'path' is any format ffmpeg can read, 'standard' has detailed values with explanations, 'stream' is zero-based index, and 'detailed' is boolean for extra pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Loudness compliance verdict for a media file against a formal published standard' with specific metrics (integrated loudness, loudness range, true peak) and distinguishes from sibling tool 'list_standards' which likely lists standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly gives usage context by listing standards with their applications (e.g., 'EBU_R128 (broadcast, -23 LUFS)'), but does not explicitly state when to use this tool versus alternatives like 'list_standards'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the standards this tool can verdict against, with their targets, tolerances, and spec citations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose authentication needs, side effects, or performance impacts. However, as a read-only list with no parameters, it is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, perfectly front-loaded with the action and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the purpose and output details adequately, though it does not mention pagination or format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds context about the content of the output (targets, tolerances, spec citations), which is meaningful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists standards with details like targets, tolerances, and spec citations. It uses a specific verb 'list' and resource 'standards', distinguishing it from the sibling 'check_loudness'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a preliminary step before using 'check_loudness', but no explicit guidance on when to use or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have clearly distinct purposes: one checks loudness against a standard, the other lists available standards. No overlap in functionality.
Both tool names follow a consistent verb_noun pattern: check_loudness and list_standards. The naming is predictable and clear.
With only 2 tools, the server is on the low end of the typical range. While the tools cover the core functionality, a batch processing tool or a tool to preview raw measurements would round out the set.
The server covers the main use case of loudness checking and provides standards listing. Minor gaps exist, such as batch processing or the ability to update standards, but the core workflow is complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Run FFmpeg and FFprobe in the cloud: convert, compress, trim and analyze video and audio.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Privacy-first audio intelligence: BPM, key, waveform. Audio never stored. Pay per second.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chaoz23/loudcheck'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
