Systematize Pre-Release Checks for Sound-Playing Apps with Waveform Rendering and Agents

The 6/26 update let Antigravity render audio files. Drawing on years of shipping sound in healing apps, here is a design that folds loudness, clipping, length, and silence checks into an agent verification loop, with the actual scripts.

Antigravity³⁷⁶audio assetspre-release checksindie development²⁰ quality gate³

✦ Premium Article

Run a healing app long enough and "sound" climbs into the surprising top ranks of reasons a star gets docked. "I used it before bed and it was suddenly loud," "I thought it was silent, then it played a few seconds in" — these quietly erode ratings more than functional bugs do.

Audio assets don't announce themselves with a compile error the way code does. Verifying every one by ear becomes unrealistic as the track count grows. With the 6/26 update, Antigravity can render audio files as waveforms inside the IDE, opening a path to offload part of this "ear work" to eyes and scripts. As someone who has shipped sound in indie apps, here is a design that systematizes pre-release audio checks as a verification loop.

Where audio assets actually cause accidents

First, let's make concrete which defects break the reader's experience. A vague "quality check" hands an agent a vague result.

Across my operations, the ones most likely to draw complaints and low ratings were four: loudness varying between tracks, peaks clipping into distortion, unnatural silence or an abrupt onset at the start, and loop material whose tail and head don't join smoothly.

Most of these are visible in the waveform. Put differently, if you reduce them to things a waveform can show, you can give the agent a footing for judgment.

Kill the machine-decidable parts first

Before sending anything to ears or an agent, automate what a number can decide. Skip this and reviews drown in subjective back-and-forth. I always run a light gate built on ffprobe and ffmpeg's loudnorm analysis before publishing.

#!/usr/bin/env bash
# audio-gate.sh — machine-judge audio assets before release
# usage: ./audio-gate.sh assets/sounds/*.wav
set -euo pipefail
 
# distribution targets (tune to your app)
TARGET_LUFS=-16      # a mobile playback ballpark
MAX_TP=-1.0          # true-peak ceiling dBTP
MIN_SEC=1.0          # reject material that's too short
MAX_HEAD_SILENCE=0.3 # allowed head-silence seconds
 
for f in "$@"; do
  dur=$(ffprobe -v error -show_entries format=duration -of csv=p=0 "$f")
  stats=$(ffmpeg -i "$f" -af loudnorm=I=$TARGET_LUFS:TP=$MAX_TP:print_format=json -f null - 2>&1 \
          | sed -n '/{/,/}/p')
  lufs=$(echo "$stats" | python3 -c "import sys,json;print(json.load(sys.stdin)['input_i'])")
  tp=$(echo "$stats" | python3 -c "import sys,json;print(json.load(sys.stdin)['input_tp'])")
  head_sil=$(ffmpeg -i "$f" -af silencedetect=noise=-50dB:d=0.1 -f null - 2>&1 \
             | grep -m1 "silence_end" | grep -oE "[0-9.]+" | head -1 || echo 0)
 
  status="OK"
  awk "BEGIN{exit !($dur < $MIN_SEC)}" && status="TOO_SHORT"
  awk "BEGIN{exit !($tp > $MAX_TP)}" && status="CLIPPING"
  awk "BEGIN{exit !($head_sil > $MAX_HEAD_SILENCE)}" && status="HEAD_SILENCE"
  printf "%-28s dur=%.1fs LUFS=%s TP=%s headSil=%ss -> %s\n" \
    "$(basename "$f")" "$dur" "$lufs" "$tp" "$head_sil" "$status"
done

Just running this surfaces, in one list, problems that are hard to catch without A/B listening: "one track is 6 dB louder," "the tail is clipping." When I swapped an AdMob reward sound, this stage caught a true-peak overage and I fixed it before release.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A verification script that machine-judges loudness, clipping, and head silence with ffprobe and loudnorm

✦A procedure for having an agent review with 'eyes instead of ears' using waveform rendering

✦How to place a pre-release gate so you don't lose stars to volume complaints after launch

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Have the agent review "with its eyes" via waveform rendering

Machines can only reject what a threshold expresses. Feel-leaning judgments — "the loop seam feels off," "the fade is unnatural" — survive numbers alone. This is where waveform rendering helps.

Opening an audio file in Antigravity renders its waveform, so you can ask the agent to review while referencing it. The idea is to give it a visible signal — the waveform — as a stand-in for ears.

## Audio review request (instruction template for the agent)
Target: look at the waveform of assets/sounds/loop_rain.wav and check:
1. Whether the last 200ms and first 200ms have similar amplitude (loop-seam step)
2. Whether fade in/out is linear, with no abrupt onset
3. Whether there is any clipping (waveform pinned to the top/bottom) throughout
Output: if there are issues, bullet "location (sec) / symptom / recommended fix."
If none, reply only "pass."

The key is not to ask the agent vaguely for "good / bad." Translate the checks into observable waveform features and the answers turn specific. Define the loop seam as "the amplitude difference between tail and head" and the agent will point to that step from the waveform.

Make it a two-stage verification loop

Machine judgment and waveform review each miss things alone. I make this two-stage sequence my default pre-release procedure.

Stage	Owner	Catches	Cost
Stage 1	audio-gate.sh (machine)	loudness variance, clipping, length, head silence	nearly free, seconds
Stage 2	agent (waveform review)	seams, fades, subjective oddness	few tokens, tens of seconds

Order matters. Clearing the machine-rejectable items first shrinks what Stage 2 shows the agent, making review cheaper and sharper. Trying to make the agent listen to everything from the start hurts both tokens and judgment precision.

Wire it into scheduled, unattended tasks

I add material gradually through nightly scheduled runs. Folding the audio gate into this unattended pipeline sifts additions automatically.

# scheduled-task: pre-gate on audio asset additions
steps:
  - run: ./audio-gate.sh assets/sounds/new/*.wav | tee audio_report.txt
  - gate: grep -qE "TOO_SHORT|CLIPPING|HEAD_SILENCE" audio_report.txt && exit 1 || true
  - agent_review:
      prompt_file: prompts/audio_waveform_review.md
      only_if: stage-1 pass  # only machine-passed files go to waveform review

In unattended operation, the safe stance is: anything failing the machine gate never advances to commit. Let a marginal asset through while no one is listening and you tend to learn about it only when the low rating arrives.

What to automate, and what to keep for your own ears

Honestly, I keep the final call for my own ears. Healing sounds especially can meet every threshold yet feel "somehow unsettling," a region that neither numbers nor waveforms show well.

The aim of automation is to clear all the obvious accidents before they reach the ear, leaving only the assets that deserve my attention. Volume, clipping, and length to the machine; seams and fades to the agent's waveform review; the final texture to me. Since adopting this split, I have almost stopped losing stars to volume issues after release.

Running a sound-playing app solo, these unglamorous checks quietly protect the rating. If you are raising an app that has sound too, I hope this helps you build your own system.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.