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

Does it work on non-x86 systems now?

--
GCP

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

Woo!

Congrats Josh!

/me wanders off to play with the new release...

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.



There's EasyTAG or Tag; hopefully they'll add support for Vorbis tags in FLAC.

Josh

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

--
GCP

Fast compile of Flac 1.0.3 available at RareWares.

Regards;

Roberto.

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

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

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?

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.

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

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

Same problem here (Win2000 & Winamp 2.80).

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

Just to add my 2 cents, it happens on XP and Me too.

OK, I have the fix here. Winamp wasn't following it's own plugin spec...

Josh

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

There's a flac123 in flac-tools .

Josh

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:



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

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

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

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

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.

It is not portable and it do not work properly.



I would NEVER use a format not requiring that.



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



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:



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

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.