Skip to content

A malformed WAV reports "No matches found" with no disclosure that it could not be parsed #312

Description

@sectoramen

A WAV whose chunk layout the extractor cannot walk yields zero findings and says nothing about it, so an unreadable file is indistinguishable from a clean one.

Reproduction

Two fixtures, identical except for RIFF chunk padding. Both carry the same value in an INFO/ICMT comment:

fixture data chunk findings stderr
correctly padded even length 1 (SSN, conf 100)
unpadded length 1, no pad byte 0 nothing; stdout says No matches found.

RIFF requires each chunk to be padded to an even length. WAVExtractor.parseChunks walks chunk headers sequentially (internal/preprocessors/meta-extractors/meta-extract-audiolib/wav-extractor.go:74), so an unpadded odd-length chunk leaves the reader at an odd offset and the next chunk ID read is misaligned. The LIST/INFO chunk that holds the metadata is then never found.

Why it matters

The extraction failure is silent. The run prints No matches found. and exits 0, which is the same output a genuinely clean audio file produces, so an operator has nothing to distinguish "this file has no metadata" from "this file could not be read".

This is the same class as #294 (corrupt PDF) and #301, both of which were fixed by setting ExtractionWarning so the disclosure survives FileRouters combine step. The fix here is the same shape: when chunk walking terminates early or the declared sizes do not add up, record a payload-free ExtractionWarning saying audio metadata was not read, rather than returning an empty result.

Severity is lower than the PDF cases because a real-world WAV written by real software is RIFF-compliant, so this needs a malformed or truncated file to trigger. It is still a silent coverage gap, and a truncated download is an ordinary way to get one.

Note on provenance

Found while investigating #306. I initially mistook this for "audio metadata is never extracted at all" — it is not; parseListChunk/parseInfoField handle IART, ICMT and friends, and a correct fixture is detected. The zero-finding result came entirely from my malformed fixture, which is exactly the confusion a disclosure would have prevented.

Values shown are from synthetic fixtures.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions