Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument / verified-clean

Audio File Size Estimator

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: VERIFIED_CLEANLifecycle: verified-clean

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area
Audio, Music, Photography & Color
Tranche
tranche-3
Evidence ID
t3-013
Ledger rows
1

No ledger note is attached.

Review findings

The formulas are standard under the stated assumptions, but the spec needs an explicit MB/GB convention, a clear distinction between raw PCM payload size and complete WAV file size, and required-input behavior when lossy bitrate is absent. The existing lossy honest label is appropriate but should also mention variable bitrate and container overhead.

Formula and scope findings

  • The PCM formula is correct for raw PCM payload bytes when sample rate is in samples/second, bit depth is in bits/sample, channels is a count, and duration is in seconds; it does not include WAV headers, metadata, padding, or other container overhead.
  • The lossy formula is correct as a constant-bitrate estimate when bitrate is in bits/second, but it is not exact for variable-bitrate codecs and omits codec/container overhead.
  • The output units MB/GB are ambiguous because the specification does not state whether they mean decimal MB/GB or binary MiB/GiB.

Unit assumptions

  • sampleRate is samples per second, such as 44100 or 48000 Hz.
  • bitDepth is bits per sample per channel; dividing by 8 converts it to bytes per sample.
  • channels is a dimensionless positive channel count.
  • seconds is duration in seconds.
  • bitrate is bits per second; a value such as 128 kbps must be converted to 128000 bits/second before applying the formula.
  • Test outputs distinguish decimal MB (1 MB = 1000000 bytes) from binary MiB (1 MiB = 1048576 bytes).

Boundary hardening

Recorded hazards

  • A lossy estimate cannot be computed when bitrate is omitted; the interface must require bitrate for lossy mode or clearly report missing input.
  • Reject or clearly handle nonpositive sample rates, bit depths, channel counts, and negative durations; zero duration should produce zero bytes.
  • Validate that bitrate is positive for lossy mode and that kbps-to-bits-per-second conversion is applied exactly once.
  • Very long durations or large sample rates can exceed JavaScript safe integer precision if calculations are not guarded or performed with suitable numeric handling.
  • A WAV file's actual size can exceed the PCM payload estimate because of headers, metadata, padding, and container structure.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "mode": "PCM/WAV payload",
    "sample_rate_hz": 44100,
    "bit_depth_bits": 16,
    "channels": 2,
    "duration_seconds": 180
  },
  "expected_outputs": {
    "payload_bytes": 31752000,
    "payload_MB_decimal": 31.752,
    "payload_MiB": 30.2810668945
  },
  "working": "16 / 8 = 2 bytes/sample. 44100 samples/s × 2 bytes/sample × 2 channels = 176400 bytes/s. 176400 × 180 s = 31752000 bytes. 31752000 / 1000000 = 31.752 MB. 31752000 / 1048576 = 30.2810668945 MiB."
}

Related workflows

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • VERIFIED_LEDGER.json · VERIFIED_CLEAN
  • evidence-tranche3/tranche3-results.json