Hydrogenaudio Forums

Lossless Audio Compression => FLAC => Topic started by: jcoalson on 2002-07-04 09:41:03

Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-04 09:41:03
Yes, it's finally here.  See the homepage for details, but here's a summary:

- 10-15% decoder speedup
- 24-bit input support restored
- more robust plugins
- new metadata block for Vorbis-style tags
- vastly improved metadata editor
- fixed bug with pipes and Windows
- new libFLAC++, a C++ object wrapper around libFLAC
- new metadata editing interface in libFLAC and libFLAC++
- and more...

http://flac.sourceforge.net/ (http://flac.sourceforge.net/)
http://flac.sourceforge.net/news.html#20020703 (http://flac.sourceforge.net/news.html#20020703)

The new metadata interface and/or metaflac should be especially useful to frontends as they make tagging with Vorbis tags very simple.

Josh
Title: FLAC 1.0.3 Released
Post by: Garf on 2002-07-04 11:20:14
Does it work on non-x86 systems now?

--
GCP
Title: FLAC 1.0.3 Released
Post by: Sachankara on 2002-07-04 13:50:13
Very cool... I've been waiting for this some time now...  All that is missing now is a powerful tag support that can rename files on extraction in whatever way you want using the tag data...
Title: FLAC 1.0.3 Released
Post by: Ardax on 2002-07-04 16:45:41
Woo!

Congrats Josh!

/me wanders off to play with the new release...
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-04 19:05:57
Quote
Originally posted by Garf
Does it work on non-x86 systems now?

-- 
GCP


Not sure what you mean... FLAC has had solaris-sparc binary releases from the beginning and darwin-ppc since 1.0.1.  It should build almost anywhere you'd expect it to.  Somebody mentioned a problem on 64-bit Alpha's but someone else said it worked fine.  Hell, it even runs on an ARM 10 in the PhatBox.

Quote
Originally posted by Sachankara
Very cool... I've been waiting for this some time now...  All that is missing now is a powerful tag support that can rename files on extraction in whatever way you want using the tag data...


There's EasyTAG (http://easytag.sourceforge.net/) or Tag (http://www.saunalahti.fi/~cse/html/tag.html); hopefully they'll add support for Vorbis tags in FLAC.

Josh
Title: FLAC 1.0.3 Released
Post by: Garf on 2002-07-04 19:09:12
Quote
Originally posted by jcoalson

Not sure what you mean... FLAC has had solaris-sparc binary releases from the beginning and darwin-ppc since 1.0.1.  It should build almost anywhere you'd expect it to.  Somebody mentioned a problem on 64-bit Alpha's but someone else said it worked fine.  Hell, it even runs on an ARM 10 in the PhatBox.


Both Frank Klemm and Monty were complaining they couldn't get FLAC 1.0.2 to decode files on non-x86 systems.

--
GCP
Title: FLAC 1.0.3 Released
Post by: rjamorim on 2002-07-04 19:19:10
Fast compile of Flac 1.0.3 available at RareWares.

Regards;

Roberto.
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-04 19:25:43
Quote
Originally posted by Garf


Both Frank Klemm and Monty were complaining they couldn't get FLAC 1.0.2 to decode files on non-x86 systems.


Yeah, Frank routinely claims FLAC "doesn't work" but won't give any details even when I ask directly.  I haven't heard anything from Monty about it but I would give that more credibility.  There are no bug reports filed about it and people are using it routinely on all kinds of systems and have been since 1.0.  But I would welcome any specifics.

Josh
Title: FLAC 1.0.3 Released
Post by: Sachankara on 2002-07-04 19:56:30
Quote
Originally posted by jcoalson
There's EasyTAG (http://easytag.sourceforge.net/) or Tag (http://www.saunalahti.fi/~cse/html/tag.html); hopefully they'll add support for Vorbis tags in FLAC.

Josh
Well, I was thinking/hoping for native support within the executable and setting all the "output rules" via the command line... Not via an external application...
Title: FLAC 1.0.3 Released
Post by: spoon on 2002-07-04 20:37:11
Excellent Josh  I shall update the dBpowerAMP codecs in the next few days.

If I read the announcements correctly (ok haven't had chance download it yet <slap wrist>), what is the full story with tags - previously there were ID3v1 andv2, now the SDK defaults to Vorbis tags? does the SDK emigrate old tags to new tags?
Title: FLAC 1.0.3 Released
Post by: rocketsauce on 2002-07-04 21:25:37
Whenever I use the new version of the Winamp plugin to play a FLAC file I get a message saying:

ERROR: invalid/missing FLAC metadata

I then click OK and in the Winamp playlist window, instead of showing the file name, it shows:

Invalid FLAC File: ""

The file still plays.  However, I don't get the error message if I use the previous version of the plugin.

Since the files I had were encoded with FLAC 1.0.2, I tried decoding them and re-encoding (with FLAC Frontend) using the newer encoder, but I still get the same error message.  I tried this with the bundle downloaded from the FLAC website and also the versions from Rarewares.

I'm using Win98SE and Winamp 2.80.

Thanks,
Rob

BTW, rjamorim, the FLAC bundle zip (dated 2002-07-04) I downloaded from your site doesn't have the files for the frontend in it.
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-04 21:27:45
Quote
Originally posted by spoon
Excellent Josh  I shall update the dBpowerAMP codecs in the next few days.

If I read the announcements correctly (ok haven't had chance download it yet <slap wrist>), what is the full story with tags - previously there were ID3v1 andv2, now the SDK defaults to Vorbis tags? does the SDK emigrate old tags to new tags?


The API knows nothing about id3 tags except how to skip them.  The plugins support id3v1 and there are some patches in for id3v2.  So basically all id3 tagging is done with external tools and flac plays nice with them.

Vorbis tags are new and supported by the API and metaflac, but there are no command line options to set them in flac yet and the plugins don't read them yet.  But with the new metadata interface it is much easier to add support for these.

Josh
Title: FLAC 1.0.3 Released
Post by: spoon on 2002-07-04 21:33:28
Excellent, I think monkeys went the same sort of way - id3 tags then the API natively supported tags and that worked out well.

For a codec to work well it should read all 3 types, for flac files with existing id3 tags it should try to keep with them, for new files it should always use the new format. It shall be done
Title: FLAC 1.0.3 Released
Post by: Speek on 2002-07-04 22:11:13
Quote
Originally posted by rocketsauce
Whenever I use the new version of the Winamp plugin to play a FLAC file I get a message saying:

ERROR: invalid/missing FLAC metadata

I then click OK and in the Winamp playlist window, instead of showing the file name, it shows:

Invalid FLAC File: ""

The file still plays.  However, I don't get the error message if I use the previous version of the plugin.
Same problem here (Win2000 & Winamp 2.80).
Title: FLAC 1.0.3 Released
Post by: madah on 2002-07-04 22:32:21
With this new Flac 1.03 Winamp-plugin, I also get the same problems as rocketsauce & Speek did:

ERROR: invalid/missing FLAC metadata
then the file shows as Invalid FLAC File: ""
But the file plays fine and show correct length...

Win2000 & Winamp 2.80
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-04 22:42:23
Quote
Originally posted by madah
With this new Flac 1.03 Winamp-plugin, I also get the same problems as rocketsauce & Speek did:

ERROR: invalid/missing FLAC metadata

then the file shows as Invalid FLAC File: ""
But the file plays fine and show correct length...

Win2000 & Winamp 2.80


I don't have win2k but I'll try some other boxen tonight and try and reproduce it.

Josh
Title: FLAC 1.0.3 Released
Post by: john33 on 2002-07-04 22:46:57
Just to add my 2 cents, it happens on XP and Me too.
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-06 00:02:12
Quote
Originally posted by jcoalson


I don't have win2k but I'll try some other boxen tonight and try and reproduce it.


OK, I have the fix here (http://sourceforge.net/project/shownotes.php?release_id=98266).  Winamp wasn't following it's own plugin spec...

Josh
Title: FLAC 1.0.3 Released
Post by: Agent69 on 2002-07-06 03:43:41
I have noticed that FLAC is available for my home operating system, a console only NetBSD box. But what I really need is a command-line program that can play FLAC files outright; something like a flac123.

Does anyone know if anyone is working on such a beast?



Thanks!


Agent69
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-06 04:04:52
Quote
Originally posted by Agent69
I have noticed that FLAC is available for my home operating system, a console only NetBSD box. But what I really need is a command-line program that can play FLAC files outright; something like a flac123.

Does anyone know if anyone is working on such a beast?


There's a flac123 in flac-tools (http://flac-tools.sourceforge.net/) .

Josh
Title: FLAC 1.0.3 Released
Post by: Peter on 2002-07-06 08:33:10
Quote
Originally posted by jcoalson

Winamp wasn't following it's own plugin spec...

just for future reference: which part of plugin specs was it this time ?
(yes, i know how much wa2 plugin specs suck better than anyone else)
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-07 05:42:41
Quote
Originally posted by zZzZzZz

just for future reference: which part of plugin specs was it this time ?
(yes, i know how much wa2 plugin specs suck better than anyone else)


From in2.h:

Code: [Select]
void (*GetFileInfo)(char *file, char *title, int *length_in_ms); // if file == NULL, current playing is used


Winamp is sometimes calling this function for the "current playing file" case with 'file' not set to NULL, but instead pointing to an empty string (i.e. "").

Josh
Title: FLAC 1.0.3 Released
Post by: JohnV on 2002-07-07 07:28:23
Hey Josh. Do you expect to gain any better compression in the near future?
You thinking to add some better algorithms like better stereo decorrelation?
According to Florin, it increased Monkey's compression quite a bit.
http://www.monkeysaudio.com/cgi-bin/YaBB/Y...8125336&start=4 (http://www.monkeysaudio.com/cgi-bin/YaBB/YaBB.cgi?board=general&action=display&num=1018125336&start=4)
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-08 04:40:30
Quote
Originally posted by JohnV
Hey Josh. Do you expect to gain any better compression in the near future?
You thinking to add some better algorithms like better stereo decorrelation?
According to Florin, it increased Monkey's compression quite a bit.
http://www.monkeysaudio.com/cgi-bin/YaBB/Y...8125336&start=4 (http://www.monkeysaudio.com/cgi-bin/YaBB/YaBB.cgi?board=general&action=display&num=1018125336&start=4)


I think this was based on a private conversation between Matt and Florin... I can't figure out what's special about the technique they are using from just the MAC code, unless it's specific to the adaptive predictor.  FLAC already does the mid-side decorrelation.

I am open to improvements but it is not my main focus for a few reasons.  One, the more exotic the techniques, the more chance of running into patents.  Also, higher compression seems to significantly increase the decoder complexity.  WavPack is probably the only exception here; a low complexity adaptive method is still appealing.

There's only a few percent left to gain and I think now a codec's value is in the features.  But like I said, I'm open to alternatives if they fit in with the above goals.

Josh
Title: FLAC 1.0.3 Released
Post by: spoon on 2002-07-18 21:30:51
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 (http://forum.dbpoweramp.com/showthread.php?threadid=601)

For use with either dBpowerAMP Audio Player, or dBpowerAMP Music Converter.
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-19 02:13:39
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 (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
Title: FLAC 1.0.3 Released
Post by: spoon on 2002-07-19 08:15:40
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)>
Title: FLAC 1.0.3 Released
Post by: Frank Klemm on 2002-07-19 11:34:44
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.
Title: FLAC 1.0.3 Released
Post by: bryant on 2002-07-19 16:55:57
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. 
Title: FLAC 1.0.3 Released
Post by: Frank Klemm on 2002-07-19 18:12:06
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: [Select]
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.
Title: FLAC 1.0.3 Released
Post by: jcoalson on 2002-07-19 18:33:49
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
Title: FLAC 1.0.3 Released
Post by: Frank Klemm on 2002-07-19 19:44:59
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.
SimplePortal 1.0.0 RC1 © 2008-2019