Help - Search - Members - Calendar
Full Version: LPC coefficients quantization in FLAC
Hydrogenaudio Forums > Lossless Audio Compression > FLAC
audio_geek
hi,
Can someone tell me how the prediction coefficients are quantized in FLAC....
I want to know whether it uses vector quantization and transmit a codebook index or scalar quantization ??
If vector quantization, then it will be nice if u could tell me some specifications of the vector quantization...
SebastianG
QUOTE(audio_geek @ Oct 3 2005, 01:31 PM)
hi,
Can someone tell me how the prediction coefficients are quantized in FLAC....
I want to know whether it uses vector quantization and transmit a codebook index or scalar quantization ??
If vector quantization, then it will be nice if u could tell me some specifications of the vector quantization...
*



I'm pretty sure they're linearly scalar-quantized. BTW: This is documented here.

Sebi
jcoalson
correct.
audio_geek
QUOTE
I'm pretty sure they're linearly scalar-quantized.

Does it mean that if we implement some vector quantization algorithm, the compression is going to increase....??? I am not questioning the complexity.... it may go up.

rompel
QUOTE(audio_geek @ Oct 3 2005, 01:41 PM)
QUOTE
I'm pretty sure they're linearly scalar-quantized.

Does it mean that if we implement some vector quantization algorithm, the compression is going to increase....??? I am not questioning the complexity.... it may go up.
*

Perhaps. But not by a whole lot. Assuming 16-bit input, flac -8 uses at most 0.20% of the input file size for the LPC coefficients (and typically less--0.13% on a non-representative sample of 25 songs). I'm no expert on VQ, but I'd be surprised if using VQ could save even half that. That's a pretty small savings to justify breaking backward compatibility.
audio_geek
QUOTE
(audio_geek @ Oct 3 2005, 01:41 PM)
QUOTE

QUOTE

I'm pretty sure they're linearly scalar-quantized.

Does it mean that if we implement some vector quantization algorithm, the compression is going to increase....??? I am not questioning the complexity.... it may go up.
*

Perhaps. But not by a whole lot. Assuming 16-bit input, flac -8 uses at most 0.20% of the input file size for the LPC coefficients (and typically less--0.13% on a non-representative sample of 25 songs).

This is really good information i was seeking...
How can I exactly know about how much bandwidth is taken by the residuals and how much by the LPC coefficients in the final bit stream ??
And I want to try diffrent kind of LPC quantization and see how the residual bandwidth varies... Please suggest me how to do it.
jcoalson
it probably won't get you much. I did an experiment where the residual was calculated from a 32-bit float kernel (i.e. no quantization), while still transmitting the quantized coefficients. (of course this file would not decode but it was meant to find the limit for transmitting the kernel.) size improved less than 0.1% in all cases.

FLAC uses low order (<=32) filters so optimizing the size of the kernel doesn't help much. and the simple quantization scheme it uses is already very close in error to unquantized kernels.

you can calculate the # of bits used for the kernel by running 'flac --analyze' on a file, then for each subframe calculate 4+5+order*qlp_coeff_precision, and add up for all subframes. see http://flac.sourceforge.net/format.html#subframe_lpc

Josh

edit: to get the total residual size is more complicated, you have to subtract off the frame header size, frame footer size, subframe headers, and metadata, all calculated from the analyze output.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.