Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Is FLAC sample a signed or unsigned integer. (Read 3358 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is FLAC sample a signed or unsigned integer.

A basic question I'm afraid! Wikipedia https://en.wikipedia.org/wiki/FLAC says
Quote
FLAC supports only integer samples, not floating-point (signed/unsigned?). It can handle any PCM bit resolution from 4 to 32 bits per sample, any sampling rate from 1 Hz to 65,535 Hz in 1 Hz increments or from 10 Hz to 655,350 Hz in 10 Hz increments, and any number of channels from 1 to 8.
It doesn't say whether these integers are signed or unsigned though, and I can't find the information anywhere else. Is there a choice, if not which is it?

Re: Is FLAC sample a signed or unsigned integer.

Reply #1
Flac samples are unsigned, FWIW.  The significance of being unsigned is that a bits per sample of n represents a sample in the range zero to 2^(n-1).  That almost misses the point of how Flac samples are actually represented, since they are a sequence of bits independent of any particular hardware representation of integers.  They are stored as 4-32 bit (in practice only up to 24 bit in any current implementation) unsigned integer "words" stored in big-endian format.  An encoder can of course represent Flac samples any way it chooses internally, including as signed integers of a sufficient size.

Re: Is FLAC sample a signed or unsigned integer.

Reply #2
A basic question I'm afraid! Wikipedia https://en.wikipedia.org/wiki/FLAC says
Quote
FLAC supports only integer samples, not floating-point (signed/unsigned?). It can handle any PCM bit resolution from 4 to 32 bits per sample, any sampling rate from 1 Hz to 65,535 Hz in 1 Hz increments or from 10 Hz to 655,350 Hz in 10 Hz increments, and any number of channels from 1 to 8.
It doesn't say whether these integers are signed or unsigned though, and I can't find the information anywhere else. Is there a choice, if not which is it?

This question doesn't make sense. What are you actually trying to do?

Re: Is FLAC sample a signed or unsigned integer.

Reply #3
The output is signed or unsigned depending on whether the input was signed or unsigned. In other words the output is identical to the input, whatever that was.

Re: Is FLAC sample a signed or unsigned integer.

Reply #4
I've concluded that so long as they are both integers (they are), it doesn't matter, as it's just a number so could be converted without loss from one to the other.

Re: Is FLAC sample a signed or unsigned integer.

Reply #5
FLAC compressed 16-bit integers losslessly, so it doesn't matter whether they are signed or unsigned, you'll get the same values out that you put in (which has been said). However, the quality of the compression (i.e., the ratio) will suffer greatly is the wrong interpretation is used.

In other words, 16-bit audio in a WAV file is signed, and FLAC knows this and compresses as though the values 0 and -1 are very close together (and they are very close together in an analog signal). However, if you converted that to unsigned by adding 0x8000 then those two values become 0x8000 and 0x7FFF which are the furthest two values apart (opposite rails). The lossless compression ratio is going to be terrible. And it wouldn't sound so good either, but it would still be lossless.

Re: Is FLAC sample a signed or unsigned integer.

Reply #6
I'm interested in this question as well as I'm now computing checksums for my ALAC files and want to know out of curiosity how the FLAC's internal checksums are computed.

Looking at the source code of flac, one can see what unsigned and/or big endian data are preprocessed into signed and little endian data before the actual encoding. This is true for 8,16,24 bit data https://github.com/xiph/flac/blob/27c615706cedd252a206dd77e3910dfa395dcc49/src/flac/encode.c#L2398