12bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=12
16bit.wav: wrote 2927092 bytes, ratio=0,553
20bit.wav: ERROR: legacy WAVE file has format type 1 but bits-per-sample=20
24bit.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=24
24bit.wav: wrote 5545954 bytes, ratio=0,699
Anyway, I find it questionable especially for audio-only compressors to reject a signal just because of a container that the format has no ambition of preserving. FLAC decodes writes to WAVEFORMATEXTENSIBLE when it thinks it is appropriate, but that is hardly an excuse for rejecting input container it can very well read. Settling for a warning is kinda acceptable, but erring out?!
24-bit in non-extensible WAV is non-standard but unambiguous, so FLAC reads them but throws a warning. However, 20 or 12 bit per sample WAV is non-standard and ambiguous, because there is no specification of the alignment anywhere. Are bits left-padded to byte alignment, right-padded to byte-alignment or not aligned at all?
Here's the FLAC code for handling this.
if(wFormatTag == 1) {
if(bps != 8 && bps != 16) {
if(bps == 24 || bps == 32) {
/* let these slide with a warning since they're unambiguous */
flac__utils_printf(stderr, 1, "%s: WARNING: legacy WAVE file has format type %u but bits-per-sample=%u\n", e->inbasefilename, (uint32_t)wFormatTag, bps);
if(e->treat_warnings_as_errors)
return false;
}
else {
/* @@@ we could add an option to specify left- or right-justified blocks so we knew how to set 'shift' */
flac__utils_printf(stderr, 1, "%s: ERROR: legacy WAVE file has format type %u but bits-per-sample=%u\n", e->inbasefilename, (uint32_t)wFormatTag, bps);
return false;
}
}