Originally posted by spoon
I have updated the dBpowerAMP Codec to Flac 1.0.3 and is fully compatible with Ogg Tags.

You are welcome to try the new codec here:

http://forum.dbpoweramp.com/showthread.php?threadid=601

For use with either dBpowerAMP Audio Player, or dBpowerAMP Music Converter.

Originally posted by Garf
Does it work on non-x86 systems now?

-- 
GCP

Originally posted by Frank Klemm


Last time I check flac there were some serious FPU issues which 
depends on precision of FPU implementation:

    bits = 1 + (int) floor ( log(value) / log(2) )

This do not works on machines where log(2) is rounded in the oppositite direction
or division is made by reciprocal multiplication and rounding is done in the
right direction.

It do not work on Cray Supercomputers. 
It works with 80 bit IEEE. 64 bit IEEE I haven't tested.

This type of bugs are so wellknown that skiming through the source code
is enough to detect it.

Originally posted by bryant

I have not looked at the FLAC code at all so I don't know where this came from, but it doesn't necessarily mean that the code isn't portable to another floating-point implementation. 

This would only be a problem if it was required that the operation be performed identically in the encoder and decoder.

For example, if this statement was calculating some bit count in the encoder that was then literally transmitted in the datastream, and that the decoder simply read this value and acted on it, there would be no portability problem. 

It would just mean that the encoder would generate different datastreams on different computers but that both would be playable by any decoder. Not an ideal scenario, but not a showstopper either.

int bits ( unsigned __int32 value )

{

    static unsigned char table [256] = {

        0,1,2,2,3,3,3,3,....

        .....,8

    };



    if ( value < 0x0000100) return table[value];

    if ( value < 0x0010000) return table[value >>  8] +  8;

    if ( value < 0x1000000) return table[value >> 16] + 16;

    return table[value >> 24] + 24;

}

Originally posted by Frank Klemm


Last time I check flac there were some serious FPU issues which 
depends on precision of FPU implementation:

    bits = 1 + (int) floor ( log(value) / log(2) )

This do not works on machines where log(2) is rounded in the oppositite direction
or division is made by reciprocal multiplication and rounding is done in the
right direction.

It do not work on Cray Supercomputers. 
It works with 80 bit IEEE. 64 bit IEEE I haven't tested.

This type of bugs are so wellknown that skiming through the source code
is enough to detect it.

Originally posted by jcoalson

Things like this do not affect libFLAC and this is why:

There are no floating point values in a FLAC stream.  In the libFLAC encoder, floating point is used in the analysis stage 1) when constructing a filter, but the kernel is quantized before transmission; 2) in a few places to estimate the energy in the residual signal, where small errors are not important.  The decoder doesn't use floating point at all and nothing in it is sensitive to the FP implementation of the encoder's host.

Aside from pipes on Windows in 1.0.2, now fixed, someone has yet to point out any places in the code that cause libFLAC or flac to "not work" on any architecture that you would expect it to.  I'm not saying that there aren't some exotic architectures that may have problems, but libFLAC is running in a lot of places (x86, sparc, PPC, Alpha, ARM) and there are no bug reports like that.

Josh