Oleksiy-Yakovenko
commented
9 years ago Comment #1 originally posted by Alexey-Yakovenko on 2014-11-23T16:16:09.000Z:
The WAVE extensible header should also strictly be used for any file which has more than 16 bits per sample or more than 2 channels, but is only used in the converter for files containing float samples. I haven't found a player that refuses to play these files with the short header, but haven't done much testing with multiple channels. Deadbeef plays them OK :)
wtermini
Original issue 1237 created by Alexey-Yakovenko on 2014-11-23T15:12:49.000Z:
The RIFF WAV header constructed by the converter appears to be in native-endian format. It should always be in little-endian format. Does anyone have a big-endian machine that can look at this? I can't imagine it would work well. Big-endian RIFF files are theoretically possible, but should have a magic word of FFIR or RIFX. I don't think WAV headers can be big-endian ever.
The file length placed in the RIFF header is an approximation when a pipe is used, since it is calculated in advance rather than being an actual file size. It is often wrong for Flac files because their playitems don't contain an endsample except from cuesheets (should they, it looks easy?), but also for output through DSP where samplerate changes can cause rounding errors. This doesn't cause problems for any encoders I've tested with, but they have to be set to ignore header sizes anyway. With a temporary file, the chunk size is written in after completion and is exact, but the RIFF file size is still left as an approximation which means RIFF WAV output files are sometimes technically invalid, although I haven't found a player that refuses to play them. Some tools do report header problems.
When encoding through a pipe, four spurious bytes are written to the pipe at the end of the audio data. This is because the converter tries to fill in the correct chunk size in the temporary file, but seeking in a pipe fails and the bytes are just appended. I imagine this data will be discarded in most cases since it won't form a complete sample (Flac warns about this extra data if it is given the chunk size and the --ignore-chunk-size parameter is not set), but for 8 bit or mono it would look like a sample and since the chunk size is zero the encoder cannot know it is garbage.