In the wild found a wav with 0 bits_per_sample in hound that audacity can play.
Cocalus opened this issue · comments
Someone I work with found a wav file that according to ffmpeg -i used the encoder (may have gone through other tools)
Adobe Premiere Pro CC 2017.1 (Windows)
But hound is returning that is has 0 bit samples.
audacity and ffmpeg can read it, but sox can't. soxi returns
"WAVE file fmt with padded samples is not supported yet"
It appears the extended header has wValidBitsPerSample set to zero. I'm guessing ffmpeg and audacity fall back to wBitsPerSample (16 in this case) when that happens.
It looks to be an easy enough change to hound to have such a fallback. But we've only found one example so far and I don't know if there maybe other reasons not to support that kind of fallback.
Thank you for taking the time to open an issue!
The wValidBitsPerSample field is redundant in most cases, where it is equal to wBitsPerSample, but wValidBitsPerSample can also be smaller than a multiple of 8. 0 bits per sample is silly, so it probably has a different meaning. The field in WAVEFORMATEXTENSIBLE is part of a union, but the docs don't say which value is valid in which case. It could be that Premiere interpreted the field as the wReserved field, which must be 0.
Your suggestion to fall back to the wBitsPerSample if wValidBitsPerSample is zero makes sense to me, and it could be done without breaking any files that are currently supported.
Would you be able to provide a test file for this, to confirm a fix, and to add as a regression test? It should be stripped of most audio data to keep the repository small and also to ensure there is no copyrighted audio in there. A file with ~10 samples or so would be ideal.
The original is about 177MB and I doubt I could share it, I could try to trim it but I suspect any tools I have that accept it would likely "fix" the header in the process. I can try to hexedit one of the current examples and see if it fails the same way on my end.