Lemon Agent for Audio

You already know how to work in Ableton Live. The useful role for an agent is not “make this warmer.” It is to inspect an exported file, compare it with a reference, and give you measurements and listening questions you can act on in the DAW.

The agent handles repeatable checks. Your ears and taste make the mix.

Audit your next bounce

Export a WAV from Ableton, choose one reference track, and put both in a small review folder. Keep the previous bounce instead of overwriting it.

bounce-review/
  mix-v03.wav
  reference.wav
  brief.md

In brief.md, state the destination, what you changed, and what you are unsure about. Then give the folder to a file-capable agent with this job:

Audit mix-v03.wav against reference.wav. Do not edit or overwrite either
audio file. Use available deterministic tools before making listening
claims. Measure file format, channels, sample rate, duration, integrated
loudness, loudness range, true peak, silence, and broad spectral balance.
If a check cannot be run, mark it "not measured" rather than guessing.

Write bounce-audit.md with: (1) a measurement table for both files,
(2) any failed export gates, (3) no more than three differences worth
listening for, each tied to a measurement, and (4) no more than three
specific experiments to try in Ableton. Separate facts from judgment.
Do not claim a mix problem from a number alone.

The artifact is bounce-audit.md: a receipt you can compare with the next export. Return to Ableton, make the changes you agree with, export mix-v04.wav, and A/B the two versions. That is the loop.

Starter tools

These are building blocks, not a required stack. Install only what your agent can use in your own environment.

FFmpeg

FFmpeg inspects formats, channels, duration, peaks, silence, and loudness without opening a DAW.

brew install ffmpeg

librosa and pyloudnorm

librosa provides time- and frequency-domain analysis in Python. pyloudnorm provides BS.1770 loudness measurement.

python -m pip install librosa pyloudnorm

The operating pattern

• Files first. Takes, renders, notes, and measurements live together where an agent can inspect them. The Ableton project remains the source for your creative decisions.
• Checks before ears. Catch clipping, silence, wrong duration, and wrong export format before spending attention on the mix.
• Claims carry receipts. “The low end is crowded” needs a measurement and a listening test. Descriptions without either are vibes.
• New exports, never destructive edits. Keep the path from raw take to current bounce visible.

What ships next

Everything above works today with public tools. The packaged version is deliberately narrower: one user, one measurement pass, one receipt.

Who it is for first

A producer who exports a bounce from a DAW and wants to know whether the file itself is sound before it leaves the machine — sent to a label, uploaded, or dropped into a set. Not mastering engineers, not sample-pack QA at scale. One person, one export, one question: is there anything wrong with this file that I would rather not discover later?

The one workflow

The studio version runs on smpl, a pipe-based audio toolchain that passes NDJSON frames between stages. The first packaged pass is a single pipe:

smpl read mix-v03.wav | smpl describe-all | smpl view

describe-all aggregates the light analysis tier in one pass: loudness, spectral shape, technical QC, defect markers, and a mel spectrogram. view renders those frames as a readable report and keeps the frames on stdout for anything downstream. No model download, no account, no hosted state.

In: the exported bounce (mix-v03.wav) and a brief.md naming the destination and its loudness target.

Out: the frame stream — features carrying units, defect markers with timestamps, a spectrogram image — and bounce-audit.md, the receipt that stays beside the bounce so the next export has something to be compared against.

The instrument

audio-bounce-audit, an installable skill authored in this repo. It conducts the practice around that pipe: the versioned review folder, the brief, the gates, the receipt, and the return to the DAW. It uses smpl when smpl is on the path and falls back to the FFmpeg measurements above when it is not, marking anything it could not measure as not measured.

It will not restate smpl’s flag surface. The smpl repository already ships a smpl-audit skill for driving the toolchain itself, and this page links to it rather than copying it.

The judgment artifact

Reused, not invented: smpl’s QC gate set. qc.clipping.detected fires on a true peak at or above −0.1 dBTP. qc.dc_offset_dbfs and qc.snr_db report offset and noise in named units. qc.lossy.confidence scores whether a WAV was once an MP3, using a detector that requires a plausible codec cutoff, a steep slope across it, and a dead shelf above it before it will claim anything. Every key, unit, and namespace is published in smpl’s feature-key registry, so a number in the report traces back to a definition.

What is still missing is smaller than a failure list: a one-page bounce gate table mapping six checks — export format and duration, integrated loudness against the stated destination, true peak, clipping, DC offset, lossy origin — to the exact feature key, unit, threshold, and the reason that threshold exists. That table is what this craft owes. There is no Audio Failure List planned; these measurements already carry their own evidence, and a list invented to match a template would not.

The worked example

Two files published with smpl’s own documentation: bright.wav, an airy texture, and lossy.wav, the same texture after a 64 kbps MP3 round trip back to WAV.

curl -LO https://algonormative.github.io/smpl/assets/bright.wav
curl -LO https://algonormative.github.io/smpl/assets/lossy.wav

smpl read bright.wav | smpl qc | smpl spectrogram --kind mel | smpl view > /dev/null
smpl read lossy.wav  | smpl qc | smpl spectrogram --kind mel | smpl view > /dev/null

Expect bright.wav to report a cutoff near 22 kHz with qc.lossy.confidence at 0.0, and lossy.wav to report a cutoff near 16.5 kHz with confidence around 0.86. Same texture, same length, one failed gate. You know the ground truth before you run it, which is the point: the example shows the check catching something real instead of describing a file you cannot verify. The spectrogram shows the encoder ceiling before the number does.

Who owns what

Three sites touch this material, and each owns one layer:

• lemon-agent.dev/audio documents the practice: folder discipline, gates, receipts, the loop back into the DAW, and the skill that conducts it.
• smpl documents the tool: install, subcommands, the wire protocol, the feature-key registry. This page links to that reference and never restates it. A flag documented in two places goes stale in one of them.
• lemon.audio documents the play: toys, drops, the flasher, the command-line studio, finished work in a weirder register.

Practice here, tool there, play at lemon.audio. When a page here needs a tool detail, it links.

The implementation work — an unlisted instrument page, the skill, the gate table, and the worked example — is tracked in the house’s task queue. This page stays out of primary navigation until someone outside the house runs the audit on a bounce of their own and reports what it missed.

Watch out

• The unproven meter. Test a new probe on a known file before trusting its first surprising result.
• The ungated bounce. “Sounds fine here” is not an export check.
• Selection by memory. A/B candidates against the reference before committing.
• Optimizing a metric. Loudness, clarity, and spectral balance are constraints and clues, not goals by themselves.