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.

[googlebot]

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.

This post has been edited by googlebot: Jan 3 2011, 18:43

[MichaelW]

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.

edit: omission

This post has been edited by MichaelW: Jan 3 2011, 23:16

[googlebot]

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.

[Robertina]

With foobar2000 1.1.1 and flac encoder 1.2.1b:

• Source file = wav 32-bit (floating-point)
• Output file format = flac
• Output bit depth = either "32-bit" or "Auto"

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.

[Axon]

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.)

EDIT: LOL Robertina!

This post has been edited by Axon: Jan 4 2011, 01:21

[saratoga]

With foobar2000 1.1.1 and flac encoder 1.2.1b:

• Source file = wav 32-bit (floating-point)
• Output file format = flac
• Output bit depth = either "32-bit" or "Auto"

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.

[Robertina]

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

Yes.

This "floating-point" in round brackets only should indicate that I used both a 32-bit and a 32-bit floating point file for my test.

[Robertina]

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:

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?

foobar2000 v1.1.1, WavPack encoder v4.60.1

[saratoga]

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.

[Robertina]

Thank you for your clarification, saratoga.

----------------------------------------

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.

[Porcus]

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).

[Porcus]

encoder/decoder internals

Then, arrgh, decoder bugs: http://www.hydrogenaudio.org/forums/index....showtopic=84101

[googlebot]

I stand corrected by practice, it seems.

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.

Then, arrgh, decoder bugs: http://www.hydrogenaudio.org/forums/index....showtopic=84101

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.

This post has been edited by googlebot: Jan 4 2011, 11:17

[Robertina]

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.

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.

[lvqcl]

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?

FLAC doesn't convert 32-bit input to 24-bit. Foobar2000 does this.

BTW, WavPack has -p switch: "practical float storage (also affects 32-bit integers, no longer technically lossless)".

[googlebot]

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.

Edit: lvqcl has already provided the answer.

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.

This post has been edited by googlebot: Jan 4 2011, 12:56

[2Bdecided]

Floating point is only approximate

It's a digital file. In which way is a copy of that file "approximate"? What do you think the words "copy" and "lossless" mean in the context of binary data?

Cheers,
David.

[Robertina]

Thank you for your full answer , googlebot.

FLAC doesn't convert 32-bit input to 24-bit. Foobar2000 does this.

Edit: lvqcl has already provided the answer.

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?

This post has been edited by Robertina: Jan 4 2011, 15:35

[lvqcl]

f32.wav: 32-bit floating point.

CODE

f32.wav: ERROR: unsupported format type 3

i32.wav: 32-bit integer

CODE

i32.wav: WARNING: legacy WAVE file has format type 1 but bits-per-sample=32
i32.wav: ERROR: unsupported bits-per-sample 32

i32w.wav: 32-bit integer, waveformatextensible

CODE

i32w.wav: ERROR: unsupported bits-per-sample 32

[lvqcl]

By the way, WavPack accepts 32-bit integer files, but foobar2000 converts 32-bit integers to 32-bit floats. So it isn't possible to losslessly pack 32-bit int WAVs with foobar2000.

[Robertina]

By the way, WavPack accepts 32-bit integer files, but foobar2000 converts 32-bit integers to 32-bit floats.

You are right, lvqcl.

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").

[lvqcl]

That's probably because foobar2000 converts everything to 32-bit float during decoding. So Binary Comparator compares 32-bit float data with 32-bit float data.

This post has been edited by lvqcl: Jan 4 2011, 17:16

[Robertina]

I am not really happy with what I have learned in this thread so far...

The devil in the detail is hardly ever mentioned

It seems so, indeed.

[googlebot]

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.