How LoudCheck is engineered.

01 / ARCHITECTURE

System architecture

LoudCheck separates the web application from the computational audio-analysis service. The browser presents results; the analysis service is responsible for producing them.

02 / PROCESSING PIPELINE

Audio processing pipeline

An uploaded file is processed through defined stages. Each stage has a specific responsibility instead of placing the entire analysis inside one monolithic function.

audio_file
    │
    ▼
decode()
    │
    ▼
validate_input()
    │
    ▼
create_analysis_context()
    │
    ├── loudness analysis
    ├── true-peak analysis
    ├── dynamic analysis
    ├── frequency analysis
    └── channel / stereo analysis
    │
    ▼
derive_metrics()
    │
    ▼
classify_content()
    │
    ▼
evaluate_rules()
    │
    ▼
generate_findings()
    │
    ▼
generate_readiness()
    │
    ▼
serialize_json()

03 / MEASUREMENT ENGINE

Measurement engine

LoudCheck treats measurements as first-class software outputs. A measurement should have a defined input, algorithm, output and unit before it becomes part of a technical decision.

04 / DETERMINISTIC DESIGN

Why the core measurement layer does not require AI.

Generative AI can be useful for explanation, assistance and higher-level interpretation. It is not necessary for calculating an objective numerical property of an audio signal when that property can be defined algorithmically.

              SAME AUDIO INPUT
                       │
                       ▼
              ┌─────────────────┐
              │ Defined         │
              │ algorithm       │
              └────────┬────────┘
                       │
                       ▼
                NUMERIC RESULT
                       │
                       ▼
              ┌─────────────────┐
              │ Explicit rules  │
              └────────┬────────┘
                       │
                       ▼
                 FINDING / STATUS

05 / MEASUREMENT CONTRACTS

Every measurement has a contract.

A useful engineering pattern is to treat every metric as a contract: defined input → defined algorithm → defined output → defined unit.

06 / MULTICHANNEL PROCESSING

Channel topology is part of the input.

Audio analysis cannot always treat a multichannel signal as if it were mono. Channel count and channel role can affect the measurement algorithm.

# Convenient, but not automatically equivalent to
# a channel-aware loudness measurement.

y_mono = np.mean(y, axis=0)

loudness = meter.integrated_loudness(y_mono)

07 / RULES & FINDINGS

Rules are downstream from measurements.

A measurement should not directly become a user-facing warning. The rule engine evaluates the measurement against an explicit condition and creates a structured finding.

measurement
    │
    ▼
┌─────────────────────────┐
│ Rule evaluation         │
│                         │
│ value < threshold ?     │
│ value > threshold ?     │
│ value within range ?    │
└────────────┬────────────┘
             │
             ▼
      ┌──────────────┐
      │ Finding      │
      │ code         │
      │ severity     │
      │ message      │
      │ evidence     │
      └──────┬───────┘
             │
             ▼
       readiness engine

{
  "code": "TRUE_PEAK_HIGH",
  "severity": "high",
  "metric": "true_peak_dbtp",
  "value": -0.20,
  "unit": "dBTP",
  "rule_version": "1.0"
}

08 / READINESS ENGINE

Readiness is a derived decision.

Readiness should be generated from measurements and findings rather than calculated independently by the browser.

09 / JSON CONTRACT

Machine-readable output.

JSON provides the boundary between the analysis service and presentation clients. This allows the same analysis engine to support the current web interface and future clients without duplicating measurement logic.

{
  "analysis": {
    "engine": "LoudCheck",
    "engine_version": "1.x.x",
    "duration_seconds": 222.4,
    "sample_rate": 48000,
    "channels": 2
  },

  "measurements": {
    "integrated_lufs": -14.2,
    "lra_lu": 6.8,
    "true_peak_dbtp": -1.1,
    "rms_dbfs": -16.4,
    "plr_db": 2.2
  },

  "classification": {
    "content_type": "dense_music"
  },

  "findings": [],

  "readiness": {
    "status": "ready"
  }
}

10 / TESTING & VALIDATION

Numerical output must be tested.

Audio analysis requires more than checking whether an HTTP endpoint returns status code 200. The numerical output itself must be validated.

def test_reference_loudness():

    result = analyze("reference.wav")

    assert result.integrated_lufs >= expected_min
    assert result.integrated_lufs <= expected_max

11 / VERSIONING

Analysis must be traceable.

Audio measurements can depend on implementation details, dependencies and standards revisions. Analysis results should therefore identify the software and algorithm versions that generated them.

{
  "engine": "LoudCheck",
  "engine_version": "1.0.0",
  "loudness_standard": "ITU-R BS.1770",
  "loudness_revision": "BS.1770-5",
  "ruleset_version": "1.0.0"
}

The version shown above is an architectural example. Production reports should contain the actual algorithm and dependency versions used by the deployed analysis engine.

12 / AI BOUNDARY

AI has a place. It is not the measurement layer.

LoudCheck does not need generative AI to calculate its core measurements. This is an architectural decision, not an omission.

                         AUDIO
                           │
                           ▼
                 ┌───────────────────┐
                 │ DSP / MEASUREMENT │
                 └─────────┬─────────┘
                           │
                      AUTHORITATIVE
                           │
                           ▼
                 ┌───────────────────┐
                 │ RULES / FINDINGS  │
                 └─────────┬─────────┘
                           │
                           ▼
                       READINESS
                           │
                           ├──────────────► REPORT
                           │
                           ▼
                    OPTIONAL AI
                    EXPLANATION

13 / FUTURE ARCHITECTURE

ELTY Song Intelligence.

A future ELTY music product can extend this architecture without changing the authority of LoudCheck's measurement layer.

The long-term principle is straightforward: use deterministic signal processing when the system needs to measure the audio, and use AI where probabilistic or natural-language reasoning provides additional value.