DEV Community: schwwaaa

Build a Rust and FFmpeg Audio Mastering CLI

schwwaaa — Sun, 07 Jun 2026 01:18:13 +0000

We built mastacraf, a command-line audio mastering pipeline written in Rust and powered by FFmpeg.

The project is designed for self-produced experimental music where I do not necessarily want a tool making aesthetic decisions for me. I want something more direct:

analyze the file
apply a preset-defined processing chain
write the mastered output
generate waveform/spectrogram visuals
save a JSON report showing exactly what happened

Repo: https://github.com/schwwaaa/mastacraf
Docs: https://schwwaaa.github.io/mastacraf/
Bandcamp: https://cskonopka.bandcamp.com/album/friend

Why this exists

A lot of mastering workflows are either plugin-heavy or too opaque.

That is fine for some situations, but I wanted something local, repeatable, and inspectable.

For experimental music, the goal is not always “make this commercially loud.” A noise piece, drone, abstract electronic track, or film cue may each need different loudness targets and dynamics behavior.

mastacraf is built around presets so the tool does not decide the aesthetic. The preset defines the choice.

What it does

The current pipeline is intentionally linear:

analyze() → visualize(pre) → process() → visualize(post) → report()

For each mastered track, mastacraf can generate:

mastered/
  track/
    track_master.wav
    track_pre_spectrogram.png
    track_pre_waveform.png
    track_post_spectrogram.png
    track_post_waveform.png
    track_compare_spectrogram.png
    track_compare_waveform.png
    track_diff_spectrogram.png
    track_diff_waveform.png
    track_master_report.json

The JSON report includes the pre/post measurements, preset settings, deltas, and the exact FFmpeg filter chain.

That means the master is not just an exported file. It is reproducible.

Install

You need Rust and FFmpeg.

macOS:

brew install ffmpeg rust

Ubuntu / Debian:

sudo apt install ffmpeg
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Build:

git clone https://github.com/schwwaaa/mastacraf.git
cd mastacraf
cargo build --release

Binary:

./target/release/mastacraf

Analyze first

The most important workflow rule is:

mastacraf analyze track.wav

This prints measurements without writing mastered audio.

mastacraf measures:

integrated LUFS
true peak
loudness range
RMS
crest factor
dynamic range
DC offset
phase correlation
spectral balance
spectral centroid

Those values help decide what a preset should do.

For example:

Low or negative phase correlation is probably a mix problem.
Very high crest factor means the limiter attack should probably be slower.
If measured LRA is high, setting a low LRA target can collapse dynamics.
If the file is already near the true peak ceiling, the limiter may work harder than expected.

The point is to make mastering decisions from measurements instead of guessing.

Master a file

Basic usage:

mastacraf master track.wav

Use a preset:

mastacraf master track.wav --preset noise

Use a custom output folder:

mastacraf master track.wav --preset film --output ./deliverables/

Override loudness values:

mastacraf master track.wav --lufs -18 --true-peak -0.5

Dry run:

mastacraf master track.wav --preset mypreset --dry-run

Verbose mode:

mastacraf master track.wav --preset mypreset --verbose

Verbose mode prints the FFmpeg commands, which is useful because the tool is meant to be transparent.

Presets

Presets are TOML files.

The included presets are currently aimed at different use cases:

default  → general experimental / abstract
noise    → harsh noise / power electronics
film     → film scoring / cinematic / broadcast

A normal workflow looks like this:

mastacraf analyze track.wav
cp presets/default.toml presets/mypreset.toml
mastacraf master track.wav -p mypreset --dry-run
mastacraf master track.wav -p mypreset

A preset can control:

LUFS target
true peak ceiling
loudness range
high-pass / low-pass filtering
optional compression
limiter behavior
output format
bit depth
sample rate
visualization settings

The key design decision is that every audio-affecting setting should be visible.

No hidden processing.

FFmpeg filter chain

Internally, the processing chain is a standard FFmpeg audio filter string.

The structure is:

highpass → lowpass → compressor → limiter → loudnorm

Disabled stages are omitted.

The exact filter chain is stored in the report, so you can inspect or reproduce it later.

Example idea:

ffmpeg -i input.wav -af "<filter_chain>" -acodec pcm_s24le -ar 44100 output.wav

Rust is useful here because it gives the project a clean CLI structure around FFmpeg without needing to reimplement DSP.

Visual reports

mastacraf can generate before/after waveform and spectrogram images.

This is useful for checking whether the mastering stage changed the file in the way you expected.

For example:

Did the waveform envelope stay mostly intact?
Did the limiter only catch isolated peaks?
Did the spectrogram change uniformly, or did specific bands change?
Did loudnorm mostly apply clean gain?

The visuals are not a replacement for listening, but they are helpful review artifacts.

Why Rust + FFmpeg works well here

Rust is handling:

CLI arguments
config and preset loading
file organization
pipeline orchestration
report generation

FFmpeg is handling:

decoding
loudness analysis
filtering
limiting
visualization
output encoding

That split keeps the project small and practical.

I am not trying to build an audio engine from scratch. I am wrapping a reliable media tool in a repeatable workflow.

Future paths

The project is still early, but the structure leaves room for:

more filter stages
custom EQ presets
AI/ONNX preprocessing
matchering pre-pass workflows
demucs/source-separation inspection
Tauri desktop wrapper

The current version is deliberately focused:

analyze → process → visualize → report

That is the useful core.

Takeaway

mastacraf is not a “magic mastering” tool.

It is a repeatable mastering workflow for people who want to define their own targets and keep the process visible.

That matters for experimental music because the right answer is not always the loudest or most standardized master.

Sometimes the right answer is the one you can explain, inspect, and reproduce.

Repo: https://github.com/schwwaaa/mastacraf

Docs: https://schwwaaa.github.io/mastacraf/
Bandcamp: https://cskonopka.bandcamp.com/album/friend

Building a No-Server M3U Playlist Builder for DIY Broadcasts

schwwaaa — Fri, 05 Jun 2026 14:25:50 +0000

We built Drop Zone Ops, a client-side M3U playlist builder for DIY broadcasters who need to assemble playlists for VLC and OBS without running a server, installing an app, or editing playlist files by hand.

Repo: https://github.com/schwwaaa/drop-zone-ops
Live builder: https://schwwaaa.github.io/drop-zone-ops/

The project started from a very practical problem: .m3u playlists are simple, but building them manually gets annoying fast.

Once you start mixing local videos, remote URLs, bumpers, interstitials, commercial breaks, and longer programming blocks, a plain text playlist becomes easy to break and hard for collaborators to understand.

Drop Zone Ops turns that workflow into a small browser-based tool.

What it does

The basic workflow is:

Open the app in a browser.
Set a local base path if you are using local media.
Drop files, browse for local files, or paste remote URLs.
Reorder the playlist visually.
Tag items as content, commercial, bumper, or interstitial.
Import from CSV or JSON if needed.
Export a clean .m3u playlist.
Load it into VLC or OBS's VLC source.

The goal is not to replace OBS or become a full scheduling platform. It is meant to sit before OBS and make the preparation layer less fragile.

Local files and remote URLs

A key feature is the local base path.

If you are preparing local media, you can set a root folder path like:

/Users/yourname/Videos/content/

or on Windows:

C:\Users\yourname\Videos\content\

When local files are added, Drop Zone Ops can prefix them with that path when exporting the playlist.

Remote URLs are handled differently. HTTP and HTTPS links pass through untouched, which makes it possible to mix local media with hosted clips from places like S3, Dropbox, or another remote source.

That mixed local/remote workflow was one of the reasons I wanted the tool to exist.

Tags make the playlist easier to operate

For broadcast use, playlist items usually have roles:

content — main programming
commercial — ad spots
bumper — station IDs, intros, outros, return-from-break clips
interstitial — transitions or filler material

Drop Zone Ops lets each item carry a tag. That makes the playlist easier to scan, sort, and reason about before export.

This is small, but useful. The playlist stops being just “a list of files” and starts behaving more like a broadcast block.

CSV and JSON import

Sometimes the playlist already exists somewhere else: a spreadsheet, a planning doc, or a generated data file.

Drop Zone Ops supports CSV and JSON imports.

Example CSV:

path,name,duration,tag,group
/Users/yourname/Videos/episode-01.mp4,Episode 01,22:30,content,block-1
https://your-bucket.s3.amazonaws.com/ad.mp4,Soda Ad,0:30,commercial,ad-break-1

Example JSON:

[
  {
    "path": "/Users/yourname/Videos/episode-01.mp4",
    "name": "Episode 01",
    "duration": "22:30",
    "tag": "content",
    "group": "block-1"
  }
]

That makes the tool useful both as a manual editor and as the final step after another planning process.

Commercial injection

The larger feature is the Commercial Injection panel.

Instead of manually placing every ad, bumper, and break, you can define a commercial library and a set of rules. The injector reads the current playlist, applies the rules, previews the merged result, and updates the playlist before export.

The selection modes are intentionally simple:

random picks ads randomly from the library
sequential cycles through the library in order
specific uses exact clips from the template

This is useful for a small broadcast operation that does not need a full traffic system, but does need repeatable breaks.

For example: after every two content items, insert one or two ads and a return bumper.

The exported playlist

The final output is still just an .m3u file.

#EXTM3U
#EXTINF:1350 group-title="block-1" tvg-type="content",Episode 01
/Users/yourname/Videos/episode-01.mp4
#EXTINF:30 group-title="ad-break-1" tvg-type="commercial",Soda Ad
https://your-bucket.s3.amazonaws.com/ad.mp4
#EXTINF:8 group-title="ad-break-1" tvg-type="bumper",And We're Back
/Users/yourname/Videos/back-bumper.mp4

The point is that the user does not need to hand-maintain this format. They can work visually, then export the playlist when it is ready.

Why I kept it client-side

For this project, a no-server browser app made sense.

It keeps the workflow portable. You can open the file, build the playlist, export the result, and hand it to OBS or VLC. No backend. No login. No install step.

That also makes the tool easier to share with collaborators who just need to assemble a block and export the file.

It is not a full broadcast database or multi-user scheduler, and that is fine. It solves one specific problem: making M3U playlist creation less painful for DIY broadcast workflows.

Try it

Live project: https://schwwaaa.github.io/drop-zone-ops/
Repo: https://github.com/schwwaaa/drop-zone-ops

The README goes deeper into the full usage flow, including base paths, import formats, commercial injection templates, and OBS setup.