Yes with the 'Power Pack' full GUI tag editing, or if you install my Audio Player you get tag editing in the Music Collection.

Alot of the code I grabed from my Ogg implementation, it was quite similar, so no real hardships there. It could be made much easier with such simple calls:

SetTag(Filename, Element, Data)

and the same for get tag, for setting a tag element that already exists - you need to search through all existing tag values to find the right on - something that always catches me out (I ended up with duplicate values for awhile)>

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.

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.

WavPack is entirely integer based, BTW, except when it calculates the compression ratio for display.

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.

It is not portable and it do not work properly.

QUOTE

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

I would NEVER use a format not requiring that.

QUOTE

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.

Nonsense!
If you miss to store the MSB, you can't reconstruct the value right.

1./log(2) as IEEE-754 is rounded down, so the result is slightly too low.
You can't distinguish the value from 0 (000).

QUOTE

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.

Wrong. Using the brain or some tests will show this perfectly. I tested both methods.

It is not working and it is not portable. You can't decode files encoded on a Cray even on a Cray (fsuj01.rz.uni-jena.de).
And log() is extremly slow compared to all other solutions (250 clocks on P4). Best would be a table based solution:

CODE

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;

}

Fast, portable, easy to read.
I sent this solution twice to jcoalson. He isn't interested in portable code.

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.

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.

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

Sorry, tested. You're right. Flac works on the Cray now.

It remains the hint that log() is slow on Pentium III and extremly slow on Pentium 4
CPUs (Cray I haven't test). They need several hundreds of clocks for computation. Computation
by basic instructions is now much faster than using these prebuilt instructions.
Also very slow are sin, cos, exp, ...
See FLAC__fixed_compute_best_predictor() in fixed.c

Highly unpredictable jumps are also slow (16...22 clocks on Pentium 4).
See FLAC__bitmath_silog2() in bitmath.c
Use table based methods.

'unsigned' as type is not allowed in C99 anymore.
Use 'unsigned int'.

Another wish for long term archiving software is that at least one implementation
in portable ISO-C do exist. Portable in the meaning 'Portable', not 'a lot of scripts
around it which try to discover the system like Columbus America'. It's a pain
to translate this on a 10 year old computer (take a 386+8 MB+Zortech C++)
or in 10 years (hardware not available now). automake/autoconf/libtool
have a very small time window where they work and tracking down why a
script+source ball do not work is not something I wish my enemies.