Neatbo.

Repair WAV length fields

Patch only the RIFF and data lengths of a confirmed final PCM recording, preserving every existing sample and prefix byte.

Browser-local processingInputUnfinished classic PCM RIFF/WAVEOutputOriginal-size repaired WAV and full preservation JSONUp to 100 MiB per file · File limit: 1
  1. 1Add input
  2. 2Adjust settings
  3. 3Get your result

Tool input and files are processed in this browser without being uploaded.

Your input

Inputs are kept temporarily in this tab when switching tools. Refreshing or closing clears them; large results may need to be regenerated.

⌘ / Ctrl + Enter to run

or drag and drop them here

Files stay on this device. Your originals stay unchanged.

Up to 100 MiB per file · File limit: 1

    Options

    Complete the required options first. You can keep the defaults for the rest.

    Preparing the tool…

    Before you start

    Select an unfinished classic PCM WAV. Explicitly confirm that its first data chunk is final and that all remaining bytes are complete audio frames. Repair only the two length fields; download the original-size WAV and a complete byte-preservation report.

    How to use this tool

    1. Keep the original recording and check that it matches the stated classic PCM profile.
    2. Select it and explicitly confirm final data/EOF audio. Choose final zero padding only with evidence.
    3. Run the repair, then compare original/output lengths, PCM SHA256 and both patch spans.
    4. Download repaired.wav and the complete JSON; evaluate the recording in your intended player.

    Supported inputs and limits

    One original, at most 100 MiB. Source filename at most 512 UTF-16 units. At most 1,000 prefix chunks, including fmt; unknown prefix chunks and their padding are preserved as opaque original bytes.

    Little-endian classic RIFF/WAVE only: integer PCM tag 1, 8/16/24/32 bits, 1–8 channels, sample rate 1–384,000 Hz. One fmt before the first data chunk; fmt is exactly 16 bytes or 18 bytes with cbSize=0. Frame alignment and byte rate must match these fields.

    The final-data confirmation defaults off. This is a required user assertion, not automatic detection. Aligned trailing metadata may look like audio and cannot be distinguished here. Missing samples, wrong sample rate, empty data and incomplete frames are not repaired.

    The optional final-zero-pad assertion defaults off. Set it only when odd-length PCM has one actual final zero pad. Without that assertion, a final zero remains an audio byte; the tool does not guess whether it is a sample or padding.

    Only uint32LE at RIFF offset 4 and the real data-length field are patched. WAV length, prefix chunks, PCM and existing padding stay byte-identical. Complete JSON includes all offsets, original and output SHA256, PCM SHA256, format, frames, duration, every prefix chunk and both patch spans.

    WAV plus complete JSON must fit 102 MiB. This output guard is implied by the 100 MiB source and bounded report; an independent exact 102 MiB supported output cannot be reached. Preview shows the first 200 prefix chunks and at most 2,000 UTF-16 units per cell; complete records are in JSON.

    RIFX/RF64/BW64, extensible, float or compressed audio and malformed chunk chains are refused. No decoding, reconstruction, playback, network access or universal player/Windows compatibility guarantee. Existing names and metadata remain; this is not anonymization.

    Worked example

    Example input

    unfinished.wav: 86 bytes, two prefix chunks and six stereo 16-bit frames at 48,000 Hz; both original lengths are zero.
    Example options
    {"confirmFinalData":true,"trailingZeroPad":false}

    Example output

    RIFF length 78; data length 24; six frames / 0.000125 seconds; only the two stated fields change.

    When something does not work

    A refused run creates no downloads. Correct the explicit padding choice, unsupported format or named byte/structure issue and rerun the originals. Cancellation discards outputs; the same selected bytes can be processed in a fresh Worker.

    Frequently asked questions

    Can it tell whether aligned bytes after data are metadata?

    No. The user must confirm that the first data chunk is final and remaining bytes are complete PCM. An aligned LIST or other metadata tail can resemble sample bytes. No automatic metadata detection or recording-validity claim is made.

    Does it recover missing audio or change samples?

    No. It patches two length fields while retaining all sample, prefix and padding bytes. Missing or zeroed samples, wrong rates and incomplete frames require another recovery process.

    Why is final zero padding an explicit option?

    An 8-bit zero can be a real sample. With the option off it remains audio; with the option on, one actual final zero is treated as the pad of odd-length PCM. The input length stays unchanged.

    Documentation & further reading

    Related tools