Audio Processing Pipeline for Podcasts – YAML & SQL Triggers on Supabase

Podcasting is booming, but producing broadcast‑quality audio is a complex process. Recording raw audio often includes background noise, inconsistent loudness, and the wrong format. Professional podcasts need:

• Consistent loudness — EBU R128 loudness normalization (target -16 LUFS for podcasts)
• Noise reduction — remove background hum, hiss, and room tone
• Format conversion — WAV/FLAC to MP3 for distribution
• Metadata — title, artist, album, artwork
• Waveform visualization — for podcast players and social media

This guide shows you how to build a fully automated podcast audio processing pipeline using a declarative YAML template and a transpiler that generates the complete SQL migration. The pipeline turns a raw recording into a broadcast‑ready podcast episode — all driven by PostgreSQL triggers and pgmq.

The Gap: From Raw Audio to Podcast-Ready

Most podcasters record audio in high‑quality formats (WAV, FLAC) and then manually process it: normalize loudness, remove noise, convert to MP3, add metadata, and create a waveform image. This is time‑consuming and inconsistent.

What if the pipeline could be fully automated — triggered by the upload itself, processing in the background, and delivering a complete podcast episode ready for distribution? And what if you could define that pipeline in a declarative YAML file that you can version, share, and reuse?

This guide shows you exactly how to build that pipeline.

Architecture Overview

The pipeline consists of:

• Supabase Storage — dedicated buckets for each processing stage: audio-uploads, audio-temp-1, audio-temp-2, and audio-processed (final).
• PostgreSQL triggers — one trigger per step. Each fires on INSERT into storage.objects when a file appears in a specific bucket.
• pgmq — message queue for job processing (uses the existing render queue).
• ffmpeglab-runner — executes FFmpeg commands for audio processing.
• pg_notify — real‑time status updates.
• YAML transpiler — reads the pipeline definition and generates the SQL migration + SVG graph.

Important: This pipeline uses the existing render and logpiece tables from the FFmpegLab server. It does not create new tables — it only adds the pipeline components.

What the Pipeline Delivers

Prerequisites

• A Supabase project (cloud or self‑hosted).
• ffmpeglab-server and ffmpeglab-runner deployed (see setup guide).
• The render and logpiece tables must already exist (created by the FFmpegLab server migrations).
• Access to your Supabase database (psql or the Supabase SQL Editor).
• Deno installed to run the transpiler.

The YAML‑Driven Approach

While you can write the SQL directly, the recommended way is to use the YAML transpiler. This gives you:

• Declarative pipeline definition – define steps, triggers, and buckets in clean YAML.
• Automatic SQL generation – the transpiler produces the exact PostgreSQL migration.
• Visual pipeline graph – generate an SVG diagram of your pipeline with --svg.
• Reusable templates – share and version your pipeline definitions.

The transpiler is a single TypeScript file that reads your YAML and generates the SQL migration. It runs with Deno and has zero external dependencies (except yaml for parsing).

The YAML Template

Create a file called audio-pipeline.yaml with the following content. It defines the buckets, RLS policies, and each processing step in sequence. The runId section configures how the per‑run ID is generated — in this case, deterministically from the input file name.

name: "Audio Processing Pipeline"
pipelineId: "audio-pipeline"
runId:
  mode: "deterministic"
  template: "{baseFilename}"
description: "Sequential audio processing: extract → normalize → waveform"
version: "1.0.0"

editor:
  compressionLevel: 23
  preset: "medium"
  aspectRatio: "16:9"
  framerate: 30
  opacity: 1.0

storage:
  output_bucket: "audio-processed"
  buckets:
    - name: "audio-uploads"
      public: false
      allowed_mime_types:
        - "audio/mpeg"
        - "audio/wav"
        - "audio/flac"
        - "video/mp4"
    - name: "audio-temp-1"
      public: false
      allowed_mime_types:
        - "audio/wav"
    - name: "audio-processed"
      public: true
      allowed_mime_types:
        - "audio/mpeg"
        - "image/png"

  rls_policies:
    - name: "Users can upload to their own audio folders"
      operation: "INSERT"
      role: "authenticated"
      condition: |
        (bucket_id IN ('audio-uploads', 'audio-temp-1', 'audio-processed')) AND
        (storage.foldername(name))[1] = auth.uid()::text

steps:
  - id: "extract_audio"
    trigger:
      name: "handle_extract_audio"
      event: "INSERT"
      table: "storage.objects"
      condition: |
        NEW.bucket_id = 'audio-uploads' AND
        NEW.name NOT LIKE '%.emptyFolderPlaceholder'
    command: -i $MEDIA_1 -ac 1 -ar 16000 -vn -f wav -y $OUTPUT_PATH
    inputs: ["INPUT_FILE"]
    outputs: ["OUTPUT_FILE"]
    output_path: "{{userId}}/{{pipelineId}}/{{runId}}/temp/{{baseFilename}}.wav"
    editor:
      output: "wav"
      preset: "fast"
      selectedCode: "custom"
      width: 0
      height: 0
      length: 0
      compressionLevel: 0
    next_bucket: "audio-temp-1"
    keep: false

  - id: "normalize_loudness"
    trigger:
      name: "handle_normalize_audio"
      event: "INSERT"
      table: "storage.objects"
      condition: |
        NEW.bucket_id = 'audio-temp-1' AND
        NEW.name NOT LIKE '%.emptyFolderPlaceholder'
    command: -i $MEDIA_1 -af loudnorm=I=-16:LRA=11:TP=-1.5 -c:a libmp3lame -b:a 192k -f mp3 -y $OUTPUT_PATH
    inputs: ["INPUT_FILE"]
    outputs: ["OUTPUT_FILE"]
    output_path: "{{userId}}/{{pipelineId}}/{{runId}}/podcast/{{baseFilename}}.mp3"
    editor:
      output: "mp3"
      preset: "medium"
      selectedCode: "custom"
      compressionLevel: 23
    next_bucket: "audio-processed"
    keep: true

  - id: "generate_waveform"
    trigger:
      name: "handle_waveform"
      event: "INSERT"
      table: "storage.objects"
      condition: |
        NEW.bucket_id = 'audio-processed' AND
        NEW.name LIKE '%.mp3' AND
        NEW.name NOT LIKE '%.emptyFolderPlaceholder'
    command: -i $MEDIA_1 -filter_complex showwavespic=s=1200x200:colors=#FC6D26 -frames:v 1 -f image2 -y $OUTPUT_PATH
    inputs: ["INPUT_FILE"]
    outputs: ["OUTPUT_FILE"]
    output_path: "{{userId}}/{{pipelineId}}/{{runId}}/waveforms/{{baseFilename}}.png"
    editor:
      output: "png"
      preset: "medium"
      selectedCode: "custom"
      width: 1200
      height: 200
    next_bucket: "audio-processed"
    keep: true

render:
  project_name: "audio-processing"
  status: "queued"
  public: false

The keep: true flag on the last step tells the transpiler to send the output directly to the final bucket (audio-processed). Intermediate steps use next_bucket to pass the result to the next step's trigger. The runId is computed deterministically from the input file name (using mode: "deterministic" and template: "{baseFilename}"). This ensures all steps in the sequential pipeline compute the same run ID, grouping all outputs for a single upload under one folder.

Running the Transpiler

Download the transpiler and the SVG generator:

Run the transpiler to generate the migration files:

Add the --svg flag to also generate a visual graph of your pipeline:

The output will be:

Apply the migration to your Supabase database:

Visualising the Pipeline

The generated SVG gives you a clear overview of your pipeline. Steps marked with KEEP are green – their outputs are permanently stored in the final bucket. Edges are labelled with the bucket they use for data flow.

In the graph above, the steps run sequentially. The first step extracts audio and passes it to the second, which normalizes and passes to the third. The final step produces a waveform image and both the MP3 and PNG are stored in audio-processed. All steps share the same runId, so all outputs are grouped under {userId}/audio-pipeline/{runId}/.

Processing Logic Explained

When a file is uploaded to audio-uploads/{userId}/, the pipeline:

1. Step 1 (extract_audio) — converts the file to WAV and uploads it to audio-temp-1.
2. Step 2 (normalize_loudness) — applies loudness normalization and noise reduction, converts to MP3 with metadata, and uploads to audio-processed (final bucket).
3. Step 3 (generate_waveform) — triggers on the MP3 uploaded to audio-processed, generates a waveform image, and uploads it to the same bucket.

Each step's trigger condition matches the bucket that receives the previous step's output. The keep flag on the last two steps ensures the artifacts are permanently stored. Since runId is computed deterministically from the input file name, all steps get the same runId, grouping everything together.

Exact FFmpeg Commands

The YAML steps define the following FFmpeg commands using placeholders:

• $MEDIA_1 — The path to the downloaded input file (resolved by the runner).
• $OUTPUT_PATH — The temporary path for the output file (resolved by the runner).

1. Extract Audio (Step 1)

2. Normalize Loudness (Step 2)

3. Generate Waveform (Step 3)

Configure ffmpeglab-runner

The runner needs to be configured to poll the render queue and execute the provided FFmpeg commands. The transpiler uses the existing render queue.

Monitor the Pipeline

You can monitor the pipeline using SQL queries and notifications.

Customising the Pipeline

Add Metadata to the MP3

Modify the command in the normalize_loudness step to include metadata tags:

Adjust Loudness Target

Change the I parameter in loudnorm:

• -18 — for music (more dynamic)
• -16 — for podcasts (recommended)
• -14 — for loud podcasts

Add Noise Reduction

Add the afftdn filter to the command:

Change Waveform Size or Color

Frequently Asked Questions (FAQ)

Final Word

You now have a fully automated podcast audio processing pipeline defined in YAML and generated via a transpiler. With PostgreSQL triggers, pgmq, and Supabase Storage, you get:

• Professional loudness normalization — EBU R128 compliant
• Noise reduction — clean, clear audio
• MP3 conversion — with ID3v2 metadata
• Waveform visualization — for podcast players
• Video support — extract audio from videos
• Real‑time notifications — know when processing is complete
• Full observability — monitoring views and logs
• Declarative YAML — version‑controlled, reusable pipeline definitions
• Per‑run grouping via deterministic runId – all outputs for one upload stay together.

The pipeline is production‑ready, scalable, and configurable. It uses the existing render and logpiece tables from the FFmpegLab server, so there are no table conflicts — just pure, automated audio processing.