flac dev - Jan 2007 - Decoding Type=Independent

On 1/2/07, Josh Coalson <xflac@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;
};

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

Martin

--- MVallevand <mvallevand@gmail.com> wrote:
> On 1/2/07, Josh Coalson <xflac@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.

Josh


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

On 1/2/07, Josh Coalson <xflac@yahoo.com> wrote:
> 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.
Thanks, this is much clearer now.  I was wondering why it sounded so good.
> 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.
Thanks again, the target platform is powerpc (405).  I doubt if I have
the expertise with FLAC to find anything but I will have a look.

Martin

On 1/2/07, Josh Coalson <xflac@yahoo.com> wrote:
> 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.
Turns out here's nothing wrong with the libFLAC.   I use usleep() to
yield cpu in the write callback and with a smaller blocksize in my
INDEPENDENT sample file, I think I was targeting the wrong issue,  and
I kept making it worse by adding printf's.

I now just have to figure out the correct mix of usleep() and samples read,

The explanation was still very helpful and thanks a lot.

Martin