Any encoders which will 'accept but crop' too high resolution , ... so that the user will notice that not all formats are equal? Options

[Porcus]

Q: Will all (at least all widely used) 'lossless' audio encoders abort with the appropriate error message if the user tries to feed unsupported audio? Or is there any which will discard channels, downsample, crop bits or just produce nonsense?


The reason why I ask, is that this forum fairly often gets the n00b question of whether 'lossless' is indeed lossless -- and get no more than a simple 'Yes' (or 'Yes, thread closed'). The devil in the detail is hardly ever mentioned, and most users will anyway never encounter that mismatch. But if the situation is 'in the few instances where the usual answer is inadequate, the encoder will warn the users rather than eating audio information', it would certainly be A Good Thing.

[bryant]

I’d like to clarify a couple things about WavPack that were touched upon earlier.

WavPack is 100% lossless with both 32-bit integer and 32-bit floating-point audio files. For floating point this includes handling the special cases of denormals, NaNs, +/- infinities, etc. Basically, in all cases the binary data is preserved regardless of the content. In fact, one of my tests is to change the interpretation of the various data types and make sure everything still works (although, of course, the compression ratio suffers with incorrect interpretation).

As was alluded, floating-point operations (especially divide, I think) are not always guaranteed to produce the same result on all hardware (at least not by default) and this is one reason why WavPack does not use any floating-point math to compress floating-point data. Instead, the float values are converted to the largest 25-bit integers that can be represented without clipping (each block is scanned first) and compressed with the standard integer code, and then a second data stream is created to losslessly store any data that was truncated during the conversion to integers (this second stream goes in the correction file for hybrid lossless).

The -p option mentioned above discards this second stream, making the operation equivalent to 25-bit integers, although since each block is still independently coded with potentially shifted 25-bit “windows” into the floating-point data, it still retains most of the advantage of using floating-point representation. While for all practical purposes this is as good as lossless, it isn’t technically lossless, and is therefore reported as lossy (and is not the default behavior).

Regarding the original question, there actually is a situation in which WavPack will discard information and still claim lossless compression, although it’s a pretty esoteric case. If the wav file header indicates that the audio has fewer significant bits than the container (for example, 20-bit audio in 3 bytes) then only those significant bits are stored, even if the other bits are not zeros. This will show up as a decoding error only if md5 checking is enabled (because that sum is of the raw audio bytes). I don’t believe that this is an issue because all the audio specified in the wav header is losslessly stored, however it was a case that needed special attention for inclusion in WinZip because of the implicit assumptions of a file archiver.