[Flac-dev] Decoding Type=Independent

Josh Coalson xflac at yahoo.com
Tue Jan 2 13:23:26 PST 2007

--- MVallevand <mvallevand at gmail.com> wrote:
> On 1/2/07, Josh Coalson <xflac at yahoo.com> wrote:
> > I'm not sure I understand... I think the INDEPENDENT you are
> referring
> > to means the interchannel decorrelation method.  this stage is
> before
> > and independent of LPC analysis.
> Correct.
> > I'm not sure why "independent" frames would not decode correctly
> > though.  more info on exactly how it is not working would help.
> Ignoring the fact that I am not doing anything special with the MID
> channel samples, (for now they hit the same code), I am using the
> following pseudo logic to write to the hardware PCM buffer. (I don't
> have the actual code with me but I've tried so many things this is
> close)
> for (sample= i =0;sample < blocksize; sample++ )
>    for (channel = 0; channel < channels; channel++, i++)
>        aobuf[i]= flac_decoded_data[channel][sample];
> int offset = 0;
> while ( i >0 && len >=0 ) {
>    len = write(pcm_fd,aobuf+offset, i );
>    if (len<=0)  continue;  // device busy or error
>    i -= len;
>    offset+= len;
> };

this looks ok.

> With LPC correlation it plays quite well, with Independent it is
> unlistenable.

I guess I still don't understand what you mean by "Ignoring the fact
that I am not doing anything special with the MID channel samples".
libFLAC will always give you the L/R channels to your read callback.
for M/S frames, it will convert the samples to L/R before calling
the write callback.

also, INDEPENDENT frames are just frames that are coded L/R, as
opposed to MID_SIDE frames which are M/S.  both kinds can have LPC
subframes.  (see also http://flac.sourceforge.net/format.html).
but none of this should be noticed by the client because libFLAC
in the end converts everything to uncompressed L/R samples and
passes those to the write callback.

INDEPENDENT frames can also be mixed with MID_SIDE, LEFT_SIDE,
RIGHT_SIDE frames within the same stream.  are you saying that
only the INDEPENDENT frames are coming out garbled?  in that case
I think there is just some code in libFLAC on the INDEPENDENT
code path that is not compiling they way it's supposed to on that
target, and we'd have to debug that.

otherwise it could be that it's not a problem with INDEPENDENT
coding at all.


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the Flac-dev mailing list