DEV Community: Bastien Sulyan

Decoding Small and Low-Contrast QR Codes on HTML5 Canvas

Bastien Sulyan — Sat, 24 Oct 2026 11:37:38 +0000

When building the Sunasty Web QR Scanner and its companion open-source Chrome extension sunasty-qr-scanner, we noticed a recurring failure mode with standard JavaScript QR decoders like jsQR: passing a full-resolution desktop screenshot (e.g. 2560×1440 on a HiDPI display) containing a small 140×140 QR code in one corner frequently returns null.

1. Why Single-Pass Full-Frame Scans Fail

Pure JavaScript QR decoders locate finder patterns (the nested 1:1:3:1:1 square ratios) after converting the RGBA buffer into a binary bit matrix. When the QR code occupies less than 2% of the frame area:

Downscaling the full viewport blurs high-version QR modules beyond the Nyquist limit.
Keeping native resolution increases the adaptive threshold block size relative to the modules, merging adjacent dark dots.
Translucent overlays reduce luminance contrast below detection margins.

2. Multi-Scale Overlapping Grid Pipeline

To achieve fast recognition on normal images while recovering small codes on dense screenshots, we run a cascaded pipeline:

Pass 1 (Normalized Full Frame): Scan full image capped at 1024 px. Succeeds in ~8 ms for typical images.
Pass 2 (Native Resolution): If source exceeds 1024 px, scan at native 1:1 resolution.
Pass 3 (Overlapping 3x3 Spatial Grid): Divide image into 9 overlapping regions (each covering 48% width/height, stepped at 0%, 26%, 52%). The 22% overlap ensures any code straddling a boundary remains wholly inside at least one tile.
Pass 4 (Luminance Binarization): Apply a hard luminance threshold at $Y = 128$ ($Y = 0.299R + 0.587G + 0.114B$) to rescue washed-out graphics.

export function decodeQrMultiScale(sourceCanvas, jsQR) {
  const ctx = sourceCanvas.getContext('2d', { willReadFrequently: true });
  const { width, height } = sourceCanvas;

  // Pass 1: Direct scan
  const fullData = ctx.getImageData(0, 0, width, height);
  const directHit = jsQR(fullData.data, width, height, {
    inversionAttempts: 'attemptBoth'
  });
  if (directHit && directHit.data) return directHit.data;

  // Pass 2: Overlapping 3x3 sub-regions for small QR codes
  const tileCanvas = document.createElement('canvas');
  const tileCtx = tileCanvas.getContext('2d', { willReadFrequently: true });
  const offsets = [0, 0.26, 0.52];
  const span = 0.48;

  for (const ox of offsets) {
    for (const oy of offsets) {
      const sx = Math.floor(width * ox);
      const sy = Math.floor(height * oy);
      const sw = Math.floor(width * span);
      const sh = Math.floor(height * span);

      tileCanvas.width = Math.min(1200, Math.round(sw * 1.5));
      tileCanvas.height = Math.min(1200, Math.round(sh * 1.5));
      tileCtx.imageSmoothingEnabled = false;
      tileCtx.drawImage(sourceCanvas, sx, sy, sw, sh, 0, 0, tileCanvas.width, tileCanvas.height);

      const tileImg = tileCtx.getImageData(0, 0, tileCanvas.width, tileCanvas.height);
      const hit = jsQR(tileImg.data, tileCanvas.width, tileCanvas.height, {
        inversionAttempts: 'attemptBoth'
      });
      if (hit && hit.data) return hit.data;
    }
  }

  return null;
}

3. Client-Side RFC 6238 TOTP Generation (Web Crypto API)

When decoding otpauth://totp/... setup QR codes, computing 2FA codes locally prevents transmitting authentication secrets across the network. Using the W3C Web Cryptography API (crypto.subtle):

export async function generateTotp(secretBase32, timestampMs = Date.now(), period = 30, digits = 6) {
  const keyBytes = decodeBase32(secretBase32);
  const counter = Math.floor(timestampMs / 1000 / period);
  const counterBuffer = new ArrayBuffer(8);
  const counterView = new DataView(counterBuffer);
  counterView.setBigUint64(0, BigInt(counter));

  const cryptoKey = await crypto.subtle.importKey(
    'raw',
    keyBytes,
    { name: 'HMAC', hash: 'SHA-1' },
    false,
    ['sign']
  );

  const signature = await crypto.subtle.sign('HMAC', cryptoKey, counterBuffer);
  const sigBytes = new Uint8Array(signature);
  const offset = sigBytes[sigBytes.length - 1] & 0x0f;
  const binary =
    ((sigBytes[offset] & 0x7f) << 24) |
    ((sigBytes[offset + 1] & 0xff) << 16) |
    ((sigBytes[offset + 2] & 0xff) << 8) |
    (sigBytes[offset + 3] & 0xff);

  const otp = binary % (10 ** digits);
  return String(otp).padStart(digits, '0');
}

Interactive demonstration and tools available on Sunasty.

Processing PDF Files in the Browser Without a Backend

Bastien Sulyan — Sat, 24 Oct 2026 11:22:01 +0000

Most web applications still handle PDF manipulation by uploading the user's file to a remote server, invoking Ghostscript or QPDF in a container, and streaming the result back. For contracts, tax filings, medical records, or identity documents, that round-trip introduces unnecessary storage liability and network latency.

When building the browser-side PDF tools on Sunasty, the goal was to execute every operation—merging, page reordering, stream compression, deskewing, and metadata removal—inside the user's tab using Web Workers, ArrayBuffer transfers, and WebAssembly.

1. Zero-Copy Buffer Transfer to Web Workers

Parsing an 80 MB scanned PDF on the main UI thread will freeze scrolling and input events for several seconds. When a user selects a file via an <input type="file"> or drag-and-drop target, reading it as an ArrayBuffer and passing it in the transfer list of Worker.postMessage moves ownership of the memory block in constant time without duplicating bytes in RAM:

// Main thread: transfer the underlying ArrayBuffer to the PDF worker
async function dispatchPdfTask(file, operation, options = {}) {
  const buffer = await file.arrayBuffer();
  const worker = new Worker(new URL('./pdf-worker.js', import.meta.url), {
    type: 'module'
  });

  return new Promise((resolve, reject) => {
    worker.onmessage = (event) => {
      worker.terminate();
      if (event.data.error) {
        reject(new Error(event.data.error));
      } else {
        resolve(new Blob([event.data.outputBuffer], { type: 'application/pdf' }));
      }
    };
    worker.onerror = (err) => {
      worker.terminate();
      reject(err);
    };

    // Passing [buffer] in the second argument detaches it from the main thread
    worker.postMessage({ operation, buffer, options }, [buffer]);
  });
}

2. Merging Object Graphs Without Corrupting Cross-References

A PDF file is a directed graph of numbered indirect objects (obj ... endobj) indexed by a cross-reference table (xref) or cross-reference stream at the tail of the file. Concatenating two PDFs requires copying the page tree nodes (/Type /Page) and their transitive dependencies (fonts, form XObjects, color spaces, content streams) into a target document and assigning fresh object IDs so references do not collide.

In the Sunasty PDF Merger, we iterate over each source file inside the Worker, copy the requested page indices into a unified document catalog, and serialize with object streams enabled (useObjectStreams: true) so repeated structural dictionaries are compressed together:

import { PDFDocument } from 'pdf-lib';

export async function mergePdfBuffers(sourceBuffers) {
  const mergedPdf = await PDFDocument.create();

  for (const buffer of sourceBuffers) {
    const sourceDoc = await PDFDocument.load(buffer, {
      ignoreEncryption: false,
      updateMetadata: false
    });
    const pageIndices = sourceDoc.getPageIndices();
    const copiedPages = await mergedPdf.copyPages(sourceDoc, pageIndices);
    for (const page of copiedPages) {
      mergedPdf.addPage(page);
    }
  }

  const bytes = await mergedPdf.save({ useObjectStreams: true });
  return bytes.buffer;
}

3. Inspecting and Purging `/Info` and XMP Metadata

PDF files store provenance in two distinct structures:

The Trailer /Info Dictionary: Legacy key-value strings such as /Author, /Creator, /Producer, /CreationDate, and /ModDate.
The Catalog /Metadata Stream: An uncompressed or Flate-encoded XML packet following the Adobe XMP specification (<x:xmpmeta>), which often retains the original Author name, operating system, and document history even after a user clears the standard properties dialog.

When sanitizing a document—for example in the Sunasty PDF Metadata Remover—modifying only the /Info dictionary leaves the XMP stream intact. Both references must be cleared:

import { PDFDocument, PDFName } from 'pdf-lib';

export async function stripPdfMetadata(inputBuffer) {
  const pdfDoc = await PDFDocument.load(inputBuffer, { updateMetadata: false });

  // 1. Clear standard Info dictionary keys
  pdfDoc.setTitle('');
  pdfDoc.setAuthor('');
  pdfDoc.setSubject('');
  pdfDoc.setKeywords([]);
  pdfDoc.setProducer('');
  pdfDoc.setCreator('');

  // 2. Delete the XMP /Metadata stream reference from the document Catalog
  const catalog = pdfDoc.catalog;
  if (catalog.has(PDFName.of('Metadata'))) {
    catalog.delete(PDFName.of('Metadata'));
  }

  // 3. Remove custom non-standard keys from the Info dictionary
  const infoRef = pdfDoc.context.trailerInfo.Info;
  if (infoRef) {
    const infoDict = pdfDoc.context.lookup(infoRef);
    if (infoDict && typeof infoDict.keys === 'function') {
      for (const key of infoDict.keys()) {
        infoDict.delete(key);
      }
    }
  }

  return (await pdfDoc.save({ useObjectStreams: true })).buffer;
}

4. Client-Side Compression and Image Downsampling

High-resolution RGB images embedded as raw Flate streams instead of baseline JPEG (/DCTDecode) are the most common cause of bloat.

In the Sunasty PDF Compressor, we apply two techniques:

Structural & Stream Recompression: Parsing indirect objects, removing unreferenced orphan objects, and packing non-stream objects into compressed /ObjStm containers.
Raster Downsampling (150 DPI / 200 DPI): Rendering each page at a controlled scale onto an OffscreenCanvas, encoding to progressive JPEG at quality 0.75, and rebuilding a clean PDF container.

Interactive demonstration and tools available on Sunasty.

Perceptual Color Systems in JavaScript: OKLCH Conversion and WCAG 2.1 Contrast Auto-Fix

Bastien Sulyan — Sat, 24 Oct 2026 11:21:58 +0000

Design systems built on cylindrical hsl(h, s, l) math consistently run into the same perceptual flaw: human vision does not perceive equal lightness across hues. In HSL, pure yellow (hsl(60, 100%, 50%), #FFFF00) and pure blue (hsl(240, 100%, 50%), #0000FF) both report a lightness of 50%. Yet their WCAG 2.1 relative luminances are 0.9278 and 0.0722 respectively—meaning white text is illegible on yellow (1.07:1) while passing AAA on blue (8.59:1).

Below is the mathematical implementation for converting sRGB colors into Björn Ottosson's perceptual OKLCH color space, evaluating WCAG 2.1 luminance contrast, and automatically solving for the nearest accessible foreground lightness—all in zero-dependency JavaScript.

(If you want to drop these functions directly into a Node.js or browser project, the open-source package sunasty-color-math and the online Sunasty Color Picker implement the full pipeline client-side.)

1. Transforming sRGB to Perceptual OKLCH

Converting an 8-bit sRGB triplet $(R, G, B \in [0, 255])$ into oklch(L C h) requires four deterministic steps:

Electro-Optical Transfer Function (EOTF): Undo sRGB gamma compression to obtain linear-light RGB channels in $[0, 1]$.
LMS Cone Response Matrix: Map linear sRGB into approximate human cone responses $(l, m, s)$.
Cube-Root Non-Linearity: Apply $\sqrt[3]{x}$ to model perceptual lightness compression, then project into Oklab $(L, a, b)$.
Polar Coordinate Conversion: Convert Cartesian $(a, b)$ into Chroma $C = \sqrt{a^2 + b^2}$ and Hue angle $h = \text{atan2}(b, a) \cdot \frac{180}{\pi}$.

function srgbChannelToLinear(c) {
  const v = Math.max(0, Math.min(255, c)) / 255;
  return v <= 0.04045 ? v / 12.92 : ((v + 0.055) / 1.055) ** 2.4;
}

export function rgbToOklch(r, g, b) {
  const lr = srgbChannelToLinear(r);
  const lg = srgbChannelToLinear(g);
  const lb = srgbChannelToLinear(b);

  const l = 0.4122214708 * lr + 0.5363325363 * lg + 0.0514459929 * lb;
  const m = 0.2119034982 * lr + 0.6806995451 * lg + 0.1073969566 * lb;
  const s = 0.0883024619 * lr + 0.2817188376 * lg + 0.6299787005 * lb;

  const l_ = Math.cbrt(l);
  const m_ = Math.cbrt(m);
  const s_ = Math.cbrt(s);

  const L = 0.2104542553 * l_ + 0.793617785 * m_ - 0.0040720468 * s_;
  const a = 1.9779984951 * l_ - 2.428592205 * m_ + 0.4505937099 * s_;
  const bVal = 0.0259040371 * l_ + 0.7827717662 * m_ - 0.808675766 * s_;

  const C = Math.sqrt(a * a + bVal * bVal);
  let h = (Math.atan2(bVal, a) * 180) / Math.PI;
  if (h < 0) h += 360;

  return {
    L: Number(Math.max(0, Math.min(1, L)).toFixed(2)),
    C: Number(C.toFixed(2)),
    h: C < 0.004 ? 0 : Math.round(h),
  };
}

When you rotate the hue $h$ in oklch(L C h) while holding $L$ constant (for example, L = 0.62), every generated badge or chart series maintains uniform perceived brightness.

2. Computing WCAG 2.1 Contrast Ratios and Automatic AA Lightness Adjustment

Under WCAG 2.1 Success Criterion 1.4.3, normal body text requires a luminance contrast ratio of at least 4.5:1, while large text (18pt+ or 14pt+ bold) and UI graphics (including QR codes and icons) require at least 3.0:1:

$$\text{Contrast Ratio} = \frac{L_{\text{lighter}} + 0.05}{L_{\text{darker}} + 0.05}$$

where relative luminance $Y$ is weighted by the CIE 1931 photopic luminosity function:

$$Y = 0.2126 \cdot R_{\text{lin}} + 0.7152 \cdot G_{\text{lin}} + 0.0722 \cdot B_{\text{lin}}$$

When a designer picks a muted brand accent—such as Slate 400 (#94A3B8) on a white surface (#FFFFFF), which yields 2.56:1—we can automatically compute the closest accessible shade that preserves the original hue and saturation while meeting 4.5:1:

export function relativeLuminance(r, g, b) {
  return (
    0.2126 * srgbChannelToLinear(r) +
    0.7152 * srgbChannelToLinear(g) +
    0.0722 * srgbChannelToLinear(b)
  );
}

export function computeContrastRatio(fgRgb, bgRgb) {
  const lum1 = relativeLuminance(fgRgb.r, fgRgb.g, fgRgb.b);
  const lum2 = relativeLuminance(bgRgb.r, bgRgb.g, bgRgb.b);
  const brightest = Math.max(lum1, lum2);
  const darkest = Math.min(lum1, lum2);
  const rawRatio = (brightest + 0.05) / (darkest + 0.05);

  return {
    ratio: Number(rawRatio.toFixed(2)),
    aaNormal: rawRatio >= 4.5,
    aaLarge: rawRatio >= 3.0,
    aaaNormal: rawRatio >= 7.0,
  };
}

By stepping lightness downward when the background luminance exceeds 0.18 (or upward on dark surfaces), autoFixContrastForAA('#94A3B8', '#FFFFFF', 4.5) converges in under 50 iterations to #596B82 (4.56:1), preserving the cool slate hue (215deg).

3. Practical Verification Across UI Components and Scannable Graphics

Color math does not stop at CSS custom properties; it directly impacts visual regression testing and optical decoding:

Interactive Token Inspection: Use the Sunasty Color Picker (or the open-source Chromium MV3 extension) to sample any viewport pixel, inspect its HEX, HSL, OKLCH, and nearest Tailwind CSS token, and run one-click WCAG AA auto-fixes.
Visual Regression Auditing: When migrating a legacy HSL palette to perceptual OKLCH tokens or compressing UI assets, verify pixel-level deltas side-by-side in the Sunasty Image Compare split-view inspector.
Optical Contrast for QR Matrices: Custom-branded QR codes frequently fail to scan on mobile cameras when designers style the foreground modules with low-contrast pastels. Maintaining at least a 3.0:1 luminance ratio (and testing low-contrast binarization against the Sunasty QR Scanner) ensures reliable decoding across both hardware laser scanners and browser camera feeds.

Inspecting and Stripping EXIF GPS and C2PA Content Credentials in the Browser

Bastien Sulyan — Sat, 24 Oct 2026 11:13:58 +0000

Every image captured on a modern smartphone or mirrorless camera carries structured binary metadata alongside its compressed pixel stream. While camera settings like aperture and focal length are benign, embedded GPS IFDs (latitude, longitude, altitude, and UTC timestamp) and cryptographic provenance manifests (C2PA / JUMBF) reveal exact physical locations, device serial numbers, and editing software chains.

Uploading sensitive photographs to server-side "metadata remover" websites defeats the purpose of privacy sanitization: the remote server receives the unredacted file before stripping it. Below is a byte-level guide to inspecting and stripping EXIF and C2PA metadata entirely inside the browser using ArrayBuffer and DataView.

1. Anatomy of JPEG `APP1` (EXIF) and JUMBF (`C2PA`) Segments

In a baseline or progressive JPEG stream, data is organized into marker segments beginning with 0xFF:

0xFFD8 (SOI): Start of Image.
0xFFE1 (APP1): Carries the Exif\0\0 header followed by a TIFF header (0x4949 for little-endian or 0x4D4D for big-endian) and linked Image File Directories (IFDs), or an XMP packet (http://ns.adobe.com/xap/1.0/).
0xFFEB (APP11): Carries JPEG Universal Metadata Box Format (JUMBF, ISO/IEC 19566-5) boxes, which store C2PA (Coalition for Content Provenance and Authenticity) manifests, claim signatures, and asset hashes.
0xFFDA (SOS): Start of Scan (compressed entropy-coded image data follows).

Parsing JPEG Marker Segments in JavaScript

Because all JPEG segment lengths (except SOI, EOI, and RSTn) are stored as big-endian 16-bit unsigned integers immediately following the 2-byte marker, you can enumerate every metadata segment in a few dozen lines of JavaScript without decoding a single pixel:

export function listJpegSegments(arrayBuffer) {
  const view = new DataView(arrayBuffer);
  if (view.byteLength < 4 || view.getUint16(0, false) !== 0xffd8) {
    throw new Error('Not a valid JPEG stream');
  }

  const segments = [];
  let offset = 2;

  while (offset + 4 <= view.byteLength) {
    if (view.getUint8(offset) !== 0xff) break;
    const marker = view.getUint16(offset, false);

    // Standalone markers without length payload
    if (marker === 0xffd9 || marker === 0xffda) {
      segments.push({ marker: marker.toString(16), offset, length: 0 });
      break;
    }

    const segLength = view.getUint16(offset + 2, false);
    if (segLength < 2 || offset + 2 + segLength > view.byteLength) break;

    let signature = '';
    const sigLen = Math.min(12, segLength - 2);
    for (let i = 0; i < sigLen; i++) {
      const ch = view.getUint8(offset + 4 + i);
      signature += ch >= 32 && ch <= 126 ? String.fromCharCode(ch) : '.';
    }

    segments.push({
      marker: `0x${marker.toString(16).toUpperCase()}`,
      offset,
      length: segLength + 2,
      signature,
    });

    offset += 2 + segLength;
  }

  return segments;
}

2. Inspecting EXIF GPS Coordinates and C2PA Provenance Claims

Inside an APP1 segment starting with Exif\0\0, tag 0x8825 in IFD0 points to the GPS Info IFD. That sub-IFD stores coordinates as arrays of three RATIONAL values (degrees, minutes, seconds, each composed of two 32-bit unsigned integers numerator / denominator):

0x0001 (GPSLatitudeRef): 'N' or 'S'
0x0002 (GPSLatitude): [degNum/degDen, minNum/minDen, secNum/secDen]
0x0003 (GPSLongitudeRef): 'E' or 'W'
0x0004 (GPSLongitude): [degNum/degDen, minNum/minDen, secNum/secDen]

To inspect these tags—along with camera shutter counts, lens serials, and ICC profiles—without uploading the photo, open it in the Sunasty EXIF Metadata Reader.

Verifying C2PA Content Credentials

Meanwhile, cameras from Leica, Sony, Nikon, and Canon, as well as generative AI pipelines and editing tools (Adobe Photoshop, OpenAI, Google), attach cryptographic C2PA manifests inside JUMBF superboxes (c2pa UUID d8fec3d6-1b0e-483c-9297-5828877ec481). A C2PA manifest contains:

Assertions (c2pa.actions, stds.schema-org.CreativeWork, c2pa.hash.data).
Claim (c2pa.claim): Links assertions via SHA-256 digests.
COSE Signature (c2pa.signature): An X.509 certificate chain signing the claim structure.

You can inspect the full JUMBF box hierarchy, signer certificate details, and action history of any JPEG, PNG, WebP, or AVIF image locally using the Sunasty C2PA Content Credentials Reader.

3. Stripping Metadata Losslessly in Browser Memory

There are two ways to strip metadata in a browser environment:

Canvas Re-encoding (canvas.toBlob): Drawing an image onto an HTML5 <canvas> and exporting it discards APP1 and APP11 segments automatically, but it re-quantizes DCT coefficients (causing generational quality loss on JPEG files).
Lossless Binary Segment Filtering: Slicing out APP1 (0xFFE1), APP2, APP11 (0xFFEB), and COM (0xFFFE) segments while preserving SOI, DQT (quantization tables), DHT (Huffman tables), SOF0 (frame header), and the compressed SOS bitstream produces a byte-identical image payload with zero recompression loss:

export function stripJpegMetadataLossless(arrayBuffer) {
  const src = new Uint8Array(arrayBuffer);
  const view = new DataView(arrayBuffer);
  if (view.getUint16(0, false) !== 0xffd8) {
    throw new Error('Invalid JPEG SOI');
  }

  const chunks = [src.subarray(0, 2)]; // Keep 0xFFD8 (SOI)
  let offset = 2;

  while (offset + 4 <= view.byteLength) {
    if (view.getUint8(offset) !== 0xff) {
      chunks.push(src.subarray(offset));
      break;
    }

    const marker = view.getUint16(offset, false);
    // Once we hit Start of Scan (0xFFDA), copy the rest of the entropy stream verbatim
    if (marker === 0xffda) {
      chunks.push(src.subarray(offset));
      break;
    }

    const segLength = view.getUint16(offset + 2, false);
    const totalLen = 2 + segLength;

    // Strip APP1..APP15 (0xFFE1..0xFFEF) and COM (0xFFFE), keep APP0 (JFIF) and DQT/DHT/SOF
    const isMetadataApp = marker >= 0xffe1 && marker <= 0xffef;
    const isComment = marker === 0xfffe;

    if (!isMetadataApp && !isComment) {
      chunks.push(src.subarray(offset, offset + totalLen));
    }

    offset += totalLen;
  }

  const totalBytes = chunks.reduce((acc, c) => acc + c.byteLength, 0);
  const out = new Uint8Array(totalBytes);
  let pos = 0;
  for (const chunk of chunks) {
    out.set(chunk, pos);
    pos += chunk.byteLength;
  }
  return out.buffer;
}

Notice one subtle consequence of C2PA: if an image contains a signed C2PA manifest and you strip or modify the APP1 EXIF block, the C2PA hard-binding data hash (c2pa.hash.data) will fail verification unless the APP11 JUMBF manifest is also removed.

For a complete step-by-step walkthrough across JPEG, PNG (eXIf and iTXt chunks), WebP, and HEIC files, read our guide on how to remove EXIF and GPS data from photos and our architectural audit of the privacy risks of server-side online file tools.

How to Clean Up Podcast and Remote Interview Audio Directly in the Browser

Bastien Sulyan — Sat, 24 Oct 2026 11:12:53 +0000

Remote interviews recorded over WebRTC, Zoom, or Riverside frequently suffer from three compounding acoustic problems: low-frequency HVAC rumble below 80 Hz, broadband room reverberation mixed into the vocal band, and uneven dialogue pacing between speakers. Moving raw multi-gigabyte video recordings through cloud upload queues to fix these issues introduces latency and exposes unreleased recordings to third-party storage buckets.

This guide walks through a deterministic, client-side signal processing workflow to demux video containers, isolate vocal stems, and adjust playback cadence directly in browser memory.

1. Demuxing Video Containers Without Re-Encoding Loss

Many remote recording platforms export multi-track or composite .mp4 and .mkv files where the audio stream is already encoded as AAC (mp4a.40.2) or Opus at 48 kHz. Uploading a 1.5 GB .mp4 file to a remote server just to strip the video track wastes bandwidth.

When preparing an interview for editing or ASR transcription, the first step is extracting the audio stream locally:

Stream extraction vs. transcoding: If your downstream DAW accepts .m4a, you only need to demux the moov and mdat atoms. If your podcast host or transcription pipeline requires constant-bitrate MP3 (libmp3lame), transcoding at 192 kbps stereo (or 96 kbps mono for single-voice speech) reduces file size by over 85% compared to the source video container.
Sample rate consistency: Keep speech tracks at 48,000 Hz or 44,100 Hz. Avoid arbitrary resampling steps between 44.1 kHz and 48 kHz, which introduce aliasing artifacts near the upper sibilance band (6 kHz to 9 kHz).

You can perform this extraction locally in WebAssembly using the Sunasty MP4 to MP3 Converter, which reads the container directly from the local File handle without transmitting media bytes over the network.

2. High-Pass Filtering and Vocal Stem Isolation

Once you have the raw audio buffer, speech intelligibility depends on separating direct vocal energy (fundamental frequencies between 85 Hz and 255 Hz, plus formants up to 4 kHz) from stationary background noise and bleed.

Filtering Sub-Vocal Rumble with Web Audio `BiquadFilterNode`

Before applying any spectral separation, a second-order Butterworth high-pass filter at 80 Hz ($Q = 0.7071$) removes microphone stand vibrations, plosives, and air-conditioning hum without thinning out chest resonance:

async function applyHighPassFilter(audioBuffer, cutoffHz = 80) {
  const offlineCtx = new OfflineAudioContext(
    audioBuffer.numberOfChannels,
    audioBuffer.length,
    audioBuffer.sampleRate
  );

  const source = offlineCtx.createBufferSource();
  source.buffer = audioBuffer;

  const highPass = offlineCtx.createBiquadFilter();
  highPass.type = 'highpass';
  highPass.frequency.setValueAtTime(cutoffHz, 0);
  highPass.Q.setValueAtTime(Math.SQRT1_2, 0);

  source.connect(highPass);
  highPass.connect(offlineCtx.destination);
  source.start(0);

  return offlineCtx.startRendering();
}

Spectral Vocal Isolation

When a remote guest records in an untreated room with background music, fan noise, or crosstalk, standard gate plugins often clip word tails (creating choppy decay). Time-frequency masking via Short-Time Fourier Transform (STFT) separates the harmonic vocal stem from the non-vocal residual accompaniment.

For tracks with noticeable background bleed or ambient beds, running the recording through the client-side Sunasty Vocal Remover isolates the center-channel vocal stem from the ambient bed entirely on-device. A complete breakdown of EQ cut points, de-essing thresholds, and LUFS loudness targets (-16 LUFS for stereo podcasts, -19 LUFS for mono) is documented in our technical reference on cleaning audio for podcasts.

3. Time-Stretching and Cadence Adjustment Without Pitch Distortion

During editorial review or pre-transcription auditing, producers often need to tighten slow delivery (for example, speeding a segment up to 1.10x or 1.15x) or slow down dense technical terminology (0.85x) to verify phonetic accuracy.

Naive resampling changes playback duration by altering the sample clock, which shifts pitch proportionally ($\Delta f = f_0 \cdot r$, producing the classic chipmunk effect). Phase vocoder and WSOLA (Waveform Similarity Overlap-Add) algorithms decouple tempo from pitch by slicing the time-domain signal into overlapping Hann-windowed frames (typically 20 ms to 30 ms for speech) and realigning phase coherence at the target synthesis hop size:

function createHannWindow(frameSize) {
  const win = new Float32Array(frameSize);
  for (let n = 0; n < frameSize; n++) {
    win[n] = 0.5 * (1 - Math.cos((2 * Math.PI * n) / (frameSize - 1)));
  }
  return win;
}

For speech signals, WSOLA preserves transient crispness on consonants (p, t, k) better than large-window FFT phase vocoders, which can introduce phase smearing ("phasiness") around sibilants. To adjust track tempo with pitch lock enabled and export the resulting waveform directly in the browser, use the Sunasty Audio Speed & Pitch Changer.

Summary Checklist for Browser-Based Podcast Post-Production

Stage	Target Parameter	Purpose
Container Demux	48 kHz PCM / 192 kbps MP3	Strip video track without cloud upload
High-Pass Filter	80 Hz, $Q = 0.707$	Eliminate plosives and HVAC rumble
Stem Isolation	STFT vocal stem extraction	Suppress ambient bleed and background beds
Tempo Normalization	1.05x–1.15x WSOLA pitch-locked	Tighten pacing without formant shift
Loudness Target	-16 LUFS integrated, -1.0 dBTP	Consistent playback across podcast directories