dbry
WAVE files rejected by 5.7 and 5.8 but accepted up to 5.6 (+ more)
For "test file" purposes, I found a few files at hifistatement.info , and it turns out that current WavPack for Windows rejects them. The change seems to have been introduced between 5.6 and 5.7.
A couple of troublesome files, Oscar Peterson on the piano:
https://www.hifistatement.info/downloads/14-09-01_peterson/Mellow_Tone_16-44.wav
https://www.hifistatement.info/downloads/14-09-01_peterson/Mellow_Tone_24-192.wav
It is beyond me to tell whether they are actually compliant.
By the way, for AIFC: Apparently, Apple's "afconvert" tool creates the types "twos" and "raw", which also ffmpeg can create. twos is self-explanatory; raw can store unsigned 8-bit, and will be created by ffmpeg if doing -codec copy from an 8-bit WAVE. WavPack rejects them. I have not succeeded at finding any documentation on them - Apple seems not to offer any documentation on AIFF anymore.
This issue was introduced in this commit.
There are many redundancies in the RIFF WAVE format chunk, and one of them is the cbSize field. It's a 2-byte field that's supposed to indicate how many bytes of stuff have been added to the end of the format chunk (to make WAVEFORMATEXTENSIBLE), including itself. The reason it's redundant is because the extra byte count is already indicated by the size of the format chunk itself (ckSize). Cool Edit used that redundancy to indicate one of their "special" data formats by simply adding two bytes to the format chunk and putting "2" in the cbSize field. For a long time the only thing I used that field for was to identify such "Adobe" files.
The reason for this breaking fix was I ran into files that had an extended header (based on the chunk size) but the cbSize field was small and so did not indicate that those fields were valid (and they apparently were not valid and I was misinterpreting the file by using them). So the change fixed that issue and I also threw in a check to make sure the cbSize field did not indicate more extra bytes than the chunk could hold (based on ckSize). And that's what's going on here. The cbSize of the 16-bit file is 64832, even though there are only 2 extra bytes in the format chunk and the cbSize field itself uses both of them.
It's an invalid file, but I guess I could just eliminate that check and allow a crazy cbSize field (the 24-bit file has 23488 there).
As for the AIFC "raw" format, that seems like something I could also accommodate. Thanks for the heads-up on these oddities!
I maybe shouldn't bother more than one channel at the time, but I initially asked at https://hydrogenaudio.org/index.php/topic,128635 and the notion that it is invalid is ... above my paygrade.
But anyway, as long as it doesn't hurt handling it.
I saw that thread on HA and would have investigated earlier had I seen WavPack mentioned. I realize now that maybe this is just a defect of WavPack, other than FLAC silently discarding the 2 "extra" bytes in these files.
Based on that discussion I have decided on a slightly different path forward for this. Thanks again.
Yeah, so FLAC does something strange to them too, although initially I tried flac and found that it did encode without any other objections than the existence of 24-bit "type 1" files.
I guess these files are "stupid" but I have more from the same source; some are this kind and others work just fine. The person(s) who run the site might possibly know what software does create such files.