For testing a small issue with shorten and foo_clienc I've encoded a wav file to shorten with %s %d and then - %d (with "Encoder requires accurate length" checked) and finally - %d (without "Encoder requires accurate length" checked).

The - %d (without "Encoder requires accurate length" checked) file are destroyed in the way that length are given as 3:22:53 and birate as 14 kbps. The two other encodes shows the correct info, length 3:03 and bitrate 990 kbps. So obviously, if one want to encode shorten files with foo_clienc using pipe one should have "Encoder requires accurate length" checked.

However, something about the wav header are destroyed or something, there must be some difference between the dysfunctional file and one of the correct ones (even if both play fine), but a bitcompare between them says:

I guess it's not the de facto files that are compared then, but the decoded PCM data (as it says "No differences in decoded data found"), which I guess will be the identical... Well, it's useful to know which data are being compared....

Yes, the component compares decoded PCM data. Otherwise it would be quite useless for comparing - for example - a Shorten and a Wavpack file. Shorten stores a WAV header in every .shn file (in encoded form) at the beginning of the encoding processes. That's why it needs the "Encoder requires accurate length" option enabled.

Thanks! That clears the issue. Using bitcompare to search for errors in files will then only be useful for those errors that will occur in the decoded PCM stream...