03 January, 2011, 11:22:07 AM

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.

The devil in the detail is hardly ever mentioned, and most users will anyway never encounter that mismatch.

There just is no devil in the detail...

I don't know what you imagine digital audio is like. Encoders don't "eat" audio information and silently leave on the plate what they don't like. Every stream has a format and every encoder a set of formats it accepts. For your case, a developer would have to intentionally convert the data before feeding it and intentionally not inform the user about it. That is very unlikely and if such bad practice is found, you should rather think about using this developer's software than thinking about whether there needs to be a disclaimer attached to all claims of losslessness.

ders don't "eat" audio information and silently leave on the plate what they don't like. Every stream has a format and every encoder a set of formats it accepts. For your case, a developer would have to intentionally convert the data before feeding it and intentionally not inform the user about it. That is very unlikely ...

Unlikely in the case of developers who are members of HA, but can't you imagine a commercial company dedicated to making life easy for consumers who might silently modify inputs their app couldn't handle to give the consumer the best possible outcome and not bother them with scary techy details? I can imagine three who might do that sort of thing (Apple, Sony and perhaps Microsoft). I have of course, not the slightest suspicion that any of them have done anything like that, but OP's question seems to be something it is worthwhile seeking reassurance on.

I agree that stuff like this is happening in the field of lossy audio and video compression. Sometimes such can indeed improve average customer experience. The same is not true for introducing loss into something labeled 'lossless'. I also don't know a case where something like this would have happened.

Due to the specifications of the flac format two identical 24-bit flac files are created, without an error message or a lead on the bit depth reduction. foobar's console reports: "Track converted successfully."

Conclusions:

Porcus posed a legitimate question.

It's the duty of the user to check which specifications are supported by the encoder he uses.

FWIW, AFAIK, neither flac.exe nor foobar2000 warns the user when encoding floating-point lossless sources to FLAC. (FLAC does not support floating point so an implicit conversion to 24-bit fixed point is necessary.)

Due to the specifications of the flac format two identical 24-bit flac files are created, without an error message or a lead on the bit depth reduction. foobar's console reports: "Track converted successfully."

Conclusions:

Porcus posed a legitimate question.

It's the duty of the user to check which specifications are supported by the encoder he uses.

Since floating point numbers are by definition approximate, I don't think theres an expectation that processing will be lossless.

Since floating point numbers are by definition approximate, I don't think theres an expectation that processing will be lossless.

saratoga,

after my post above I began to brood over your statement and I would like to apply to you for help:

If I at first convert a 32-bit floating-point WAV to a WavPack file, then convert that wv-file back to a WAV file and compare the latter with my original wav file, foobar's Binary Comparator component says:

Quote

All tracks decoded fine, no differences found.

Does that result not mean that a lossless conversion of a floating-point file can be expected or is there an error in my logic?

Does that result not mean that a lossless conversion of a floating-point file can be expected or is there an error in my logic?

Floating point is only approximate, but still very accurate (particularly if your source wavpack file is relatively low precision compared to the intermediate floating point). Depending on the CPU, precision and software it may or may not give you the same result.

Since flac files can have 24-bit maximal and hence all types of 32-bit source files (floating- and fixed-point) will lose bit depth on the conversion process, from my point of view it would be appropriate to complete at least the flac WIKI with an appropriate hint, as long as neither the encoder nor the software used as a graphical front-end show any warning.

I am glad that I didn't rely on that "lossless is lossless" statements as mentioned by Porcus when I began to convert my 32-bit audio files to a lossless format, but did my own tests where I realized this situation. So I think it was a good point, Porcus, to bring this up.

Since floating point numbers are by definition approximate, I don't think theres an expectation that processing will be lossless.

Disagree totally here. We are telling users that 'lossless' means ... well, actually, lossless. By assumption, we are talking about users who don't know the meaning of the term 'lossless audio format'. Users who cannot be expected to have even the faintest idea of the concept 'floating-point number'.

Obviously, they cannot be expected to know anything about format internals, or encoder/decoder internals, and all they are told is, yes goddammit, what part of 'lossless' did you fail to understand?, please accept as a universal truth (thread closed and STFU).

I still think that Foobar or the Flac encoder is far from behaving as it should, here, and that this rather belongs into a bug report than into the Flac Wiki. In programming there is no implicit Float->Int conversion. So an explicit conversion is happening here - this is where the information loss occurs (not in the encoder) - and the developer is not telling you about it! It's only slightly less worse in the 32 bit integer case, where the 8 LSB are probably just omitted without checking whether they are empty.

Float preservation is hard to accomplish. It's not impossible, though. Developers must just not rely on a specific hardware's float capabilities for the correctness of their program.

This is seems to be a common range offset bug (start counting from 0 instead of 1 and vice versa). While this is certainly annoying and a sign of bad QA, the same could basically happen to any WAV implementation. It is not specifically related to the math of lossless compression.

I still think that Foobar or the Flac encoder is far from behaving as it should

I think this too, but why would it be wrong to mention in the FLAC Wiki that this file format can have 24-bit max, but accepts 32-bit sources as input files and that the encoder doesn't provide a warning in that cases? I admit that I don't understand that part of your post starting with "this is where the information loss occurs (not in the encoder) - and the developer is not telling you about it!"

If the information loss doesn't occur in the encoder: whose developer do you mean then with "and the developer is not telling you about it"? I am really confused about that but I am far away from having your technical knowledge, so sorry for bothering you with that.

Quote

Float preservation is hard to accomplish. It's not impossible, though. Developers must just not rely on a specific hardware's float capabilities for the correctness of their program.

So I would like to hear Bryant's (David's) comment on this. I am using several computers (= different hardware) and converting mainly 32-bit floating-point wav files to WavPack and on all these PCs there never has been found a difference between an original source file and a WavPack file that I converted back.

I think this too, but why would it be wrong to mention in the FLAC Wiki that this file format can have 24-bit max, but accepts 32-bit sources as input files and that the encoder doesn't provide a warning in that cases?

I think this too, but why would it be wrong to mention in the FLAC Wiki that this file format can have 24-bit max, but accepts 32-bit sources as input files and that the encoder doesn't provide a warning in that cases?

You are right. That would be valuable information, until it is fixed (if ever).

I admit that I don't understand that part of your post starting with "this is where the information loss occurs (not in the encoder) - and the developer is not telling you about it!"

With "encoder" I mean the actual encoder within the code. There are additional components within a converter program, for example, file I/O, parsing, user interface, etc. All encoders can only interpret a limited set of input formats. If the format of your input doesn't match any of those, it has to be converted first. Sometimes a developer can rely on implicit conversion, for example when you feed 24-bit integer samples into an encoder that works with 64 bit integer values internally. They get just padded with zero. In the case of float and FLAC you have a completely incompatible input format, which has to be converted explicitly before being fed to the encoder. The developer must have included such functionality, else it wouldn't silently "work", but doesn't tell you about it when it happens. Since there is information loss, this is bad practice.

If the information loss doesn't occur in the encoder: whose developer do you mean then with "and the developer is not telling you about it"?

Good question. To possibilities: 1. libFLAC's API accepts float samples without throwing an exception and applies the lossy conversion internally. 2. libFLAC does not accept float samples and Foobar converts before feeding the samples to libFLAC. I'll have a look it later.

So I would like to hear Bryant's (David's) comment on this. I am using several computers (= different hardware) and converting mainly 32-bit floating-point wav files to WavPack and on all these PCs there never has been found a difference between an original source file and a WavPack file that I converted back.

In practice that's usually not an issue. A program can check for the precision of the available hardware floating point units and only use them, when they are sufficient. If not, alternative, higher precision routines are used, which are slower. Developers often can rely on libraries, which do these checks behind the scenes and can just be used transparently.

Does the flac encoder show a hint when it is controlled via command line parameters (= without the possibly influence by an additional software like foobar) if somebody tries to feed files with more than 24-bit or floating-point files?

But if I compare these two files (the source 32-bit integer wav file with the back-converted and now 32-bit floating-point wav), foobar's Binary Comparator doesn't find any differences between them ("No differences in decoded data found").

32 bit float values can safely store 24 bit int samples. Could anyone enlighten me why we should care about 32 bit int samples (besides the generality that losses should be reported for processes labeled 'lossless')? No DAC in the world can produce an equivalent analog output.