All project guidesRunnable project · 8 lifecycle stages

Audio: from waveforms to an edge sound classifier

Build a sound-event system that preserves timing, handles silence and measures the full signal-processing path.

A complete CPU waveform-to-inference harness is runnable: trained spectral classifier, full fresh-process recovery, fixed evaluation, calibrated precision and complete exported artifacts. PCM WAV ingestion is available; natural-recording quality and target-edge performance remain unmeasured.

Where to put your code

Write your code in: projects/audio-harness/my_model.py (copy projects/audio-harness/starter/model.py first: cp projects/audio-harness/starter/model.py projects/audio-harness/my_model.py).

Verify stages: python3 projects/audio-harness/tests/check.py --stage all --impl projects/audio-harness/my_model.py

What you’re working toward

Classify short sound events from fixed windows and explain what happens with silence, noise and a changed recording source.

Before you start

Shared foundations, neural-network training, explicit recovery and deployment contracts. The project supplies a connected waveform/STFT tutorial and lifecycle exercise.

How to use this guide

Follow one stage at a time. Read the linked lesson, predict a result, run its companion, then adapt the contract to your project. Keep your observed output and explain a failure before moving on.

Use the linked project stages to connect these building blocks. Its reference checks establish the declared CPU fixture; real-data quality and target-device measurements need separate evidence.

Make the figures explain the model

Inspect the actual held-out error as waveform and spectrogram with a shared seconds axis. Color is log(1 + window-normalized power), not probability. Read confusion by true-class rows and predicted-class columns, and explain the high-tone/background error.

For every figure, name the axes, units, dataset and configuration. Explain one visible pattern with actual values, connect it to the mechanism, and state a conclusion the figure cannot support.

Stage 1 / 8

Define the data contract

Begin with what one example means. Keep stable IDs and split before fitting normalization, tokenization or augmentation. A small synthetic fixture makes bugs visible; a separate documented dataset is needed to study generalization.

Record sample rate, channel count, clip duration and amplitude convention. Split by speaker, recording session or source as appropriate before making overlapping windows.

Keep as evidence

A split manifest, provenance/license note, preprocessing version and an example inspection.

A check worth passing

Assert that train and held-out IDs are disjoint. Change one preprocessing setting and make the contract check reject the old artifact.

Practice in project stage 1

Available preparation

Stage 2 / 8

Build a transparent baseline

First build a model small enough to inspect. Predict intermediate shapes and check a forward pass using a separate calculation. Your baseline provides a reference for every later optimization.

First compare an energy or simple feature baseline with a small spectrogram classifier. Specify window size, hop, frequency bins and log floor. Test silence without producing nonfinite values.

Keep as evidence

A shape diagram, baseline configuration and an independently checked forward pass.

A check worth passing

Test a singleton batch and a changed batch size. Reject malformed targets before broadcasting can silently change the objective.

Practice in project stages 1, 2

Available preparation

Stage 3 / 8

Make each update explainable

Record whether a reported loss belongs to the parameters before or after an update. Keep validation outside the training transition and save the configuration with the random seed. A falling loss shows fitting; it is verified separately from usefulness on new examples.

Keep window labels and valid-frame masks aligned. Apply noise or gain augmentation only in training, and verify that padding does not become a class cue.

Keep as evidence

Training and validation curves, a parameter-gradient check and a record of one failed run.

A check worth passing

Overfit a tiny batch, compare one gradient with an independent finite difference and replay the same seed.

Practice in project stage 2

Available preparation

Stage 4 / 8

Prove that training can resume

Weights alone cannot reconstruct an interrupted experiment. Save optimizer memory, random state, completed step and input iterator position together with the data and package contract. Compare the next several updates after restore.

Save clip/window position and augmentation state. After restore, compare clip IDs, crop offsets and feature arrays before comparing losses.

Keep as evidence

A checkpoint manifest and uninterrupted-versus-restored sample IDs, losses and state.

A check worth passing

Interrupt at a known boundary. Restore into a fresh process and compare several subsequent batches; reject a changed dataset or optimizer configuration.

Practice in project stage 2

Available preparation

Stage 5 / 8

Measure quality and inspect errors

Freeze evaluation inputs before tuning. Aggregate sums and counts instead of averaging unequal batch means. Show representative failures alongside a metric so a reader can see what the model gets wrong.

Measure per-class recall and false positives on a fixed silence/background set. Aggregate at the intended unit—window or clip—and state how window decisions become a clip decision.

Keep as evidence

A baseline comparison, counts, error examples and a written interpretation of each figure.

A check worth passing

Evaluate one set as a whole and in uneven batches. Confirm that evaluation changes neither parameters nor optimizer state.

Practice in project stage 2

Available preparation

Stage 6 / 8

Choose weights, activations and accumulation separately

Start from a float32 reference. Weight storage, activation computation, accumulation and optimizer memory are separate decisions. Integer quantization also needs scales, zero-point policy, calibration data and runtime support. A smaller file is not evidence of faster inference.

Calibrate across quiet and loud representative signals. Compare feature-extraction precision separately from model precision; inspect clipping and rare-event recall.

Keep as evidence

A table of precision policies, artifact bytes, measured quality change and target-runtime latency.

A check worth passing

Calibrate on training or calibration data, keep final evaluation separate, and report unsupported kernels explicitly. Compare the same examples across policies.

Practice in project stage 3

Available preparation

Stage 7 / 8

Verify the deployment boundary

Package preprocessing with the trained computation. Check exported outputs on fixed normal and boundary inputs before serving them. Framework conversion and copying weights between model definitions need explicit shape, layout and dtype contracts.

Package resampling and spectrogram settings with weights. Compare features and logits stage by stage to locate a mismatch; an exported model alone does not define microphone input behavior. Use the weight-conversion project to audit an actual PyTorch/Flax dense–normalization–activation architecture. Extend its layerwise checks for this modality rather than assuming that its MLP mapping covers all operators.

Keep as evidence

A versioned artifact with signatures, preprocessing assets and source-versus-runtime parity results.

A check worth passing

Load in a fresh process. Test singleton and supported changed shapes, malformed input and a deliberately mismatched preprocessing version.

Practice in project stage 3

Available preparation

Stage 8 / 8

Measure inference and rehearse failure

Define the workload before timing it: input sizes, batching, concurrency and device. Warm up, synchronize device work and distinguish startup from steady execution. Test a failed load and a rollback to the last verified artifact.

Measure capture-window delay, preprocessing and inference. Use a stated hop size and real-time factor definition; verify dropped-window and missing-device behavior on actual hardware.

Keep as evidence

A workload report with latency units, throughput denominator, memory observations and a recovery/rollback note.

A check worth passing

Repeat the benchmark with a stated number of runs. On edge hardware, include preprocessing and transfer time and record the actual device; desktop proxies remain labeled proxies.

Practice in project stage 4

Available preparation

Write a precision policy, not just a dtype

Record weights, activations, accumulation, optimizer state and any inference cache separately. Keep a float32 reference and compare the same held-out examples before choosing a lower-precision artifact.

For every supported policy keep artifact size, task quality, output error, latency and the actual device. Record unsupported policies as unsupported.

Cross-framework work begins with parity

Use the existing Keras/JAX and TensorFlow conversion labs as preparation. A model definition, a saved checkpoint and an inference artifact have different contracts. Moving weights does not automatically move optimizer state, preprocessing or training behavior.

PyTorch, Keras, TensorFlow and JAX interoperability is tested per model and operation set. A successful tiny example is verified separately from that every model can round-trip between them.

Grow the harness after the small version works

Share run configuration, metrics, checkpoint metadata and artifact packaging. Keep modality-specific preprocessing, objectives and decoding behind explicit interfaces. Extend one working image system first, then text, audio and paired retrieval.

MaxText is an advanced reference for language-model training and supported multimodal workflows. Study its configuration, input pipeline, checkpointing, sharding and precision choices. Pin a release or commit in a separate compatible environment before adapting code; the course CPU environment does not validate a MaxText installation.

Carry engineering evidence across the lifecycle

Use the engineering-release project after the modality harness. Track the same data, preprocessing, model and evaluation identity from experiment through service.

MLflow tracking and Docker are concrete tools; MLOps, LLMOps and ModelOps describe responsibilities around them. Read the linked operations lessons before treating a registry alias or a passing local check as a deployed system.

References and next steps

Open the connected harness

Open the preparation project

Open the preparation project

Planned extensions

These project specifications build on this track. Their workspaces and checks are not available yet.