IPB

Welcome Guest ( Log In | Register )

2 Pages V  < 1 2  
Reply to this topicStart new topic
FLAC 1.0.3 Released
jcoalson
post Jul 19 2002, 02:13
Post #26


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



QUOTE
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.


Does that mean you can tag FLAC files with Vorbis comments from the GUI? If so, that's pretty cool. Any feedback about the libFLAC metadata interface then?

Josh
Go to the top of the page
+Quote Post
spoon
post Jul 19 2002, 08:15
Post #27


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



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)>


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Frank Klemm
post Jul 19 2002, 11:34
Post #28


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



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

-- 
GCP


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.


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post
bryant
post Jul 19 2002, 16:55
Post #29


WavPack Developer


Group: Developer (Donating)
Posts: 1287
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



QUOTE
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.

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. smile.gif
Go to the top of the page
+Quote Post
Frank Klemm
post Jul 19 2002, 18:12
Post #30


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



QUOTE
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. 


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.

Intel:
1 + log(8)/log(2) = 4.0000000000000000001 => 4 bits are stored (1000)

log(2) as IEEE-854 is rounded down, so the result is slightly too high.

Cray:
1 + log(8)/log(2) = 3.999999999999998 => 3 bits are stored (000)

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.


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post
jcoalson
post Jul 19 2002, 18:33
Post #31


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



QUOTE
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.


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
Go to the top of the page
+Quote Post
Frank Klemm
post Jul 19 2002, 19:44
Post #32


MPC Developer


Group: Developer
Posts: 543
Joined: 15-December 01
From: Germany
Member No.: 659



QUOTE
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


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.

For old technics test I have a
- 386SX/20
- 8 MByte RAM
- MS-DOS 3.31
- Copro
- Hercules + VGA 256 KByte
- Monochrom Monitor
- fanless (monitor is the loudest part)
- 10 Mbyte Ethernet
- ISA Soundcard
- Floppy 1.44 MB
- HD 120 Mbyte (shut down motor aber 5 minutes)
- Zortech C++, Watcom C++, GNU-C (djgpp), Turbo C++.
- CD-ROM 2x

Task is to port FLAC there. Things like "You need Automake 1.4.1" or
"On my Debian it works" is poison for compiling programs on this machine.


--------------------
-- Frank Klemm
Go to the top of the page
+Quote Post

2 Pages V  < 1 2
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th April 2014 - 13:47