Hydrogenaudio Forums > FLAC 1.1.3 released

Hydrogenaudio Forums > Hydrogenaudio Forum > Validated News

Pages: 1, 2, 3

jcoalson

Dec 2 2006, 00:20

FLAC 1.1.3 has been released. Almost 2 years in the making, FLAC 1.1.3 is a major release with improved compression, improved cover art and multichannel support, better recovery for corrupted files, many new features and options in the command-line tools, and several bug fixes. For developers, the decoder and encoder APIs have also been simplified and there is a new porting guide. See the changelog entry for complete details.

Josh

jcoalson

Dec 2 2006, 00:49

note there is one known bug that will affect the compression ratio for some locales but there is a workaround; see known bugs.

downloads at http://flac.sourceforge.net/download.html or http://sourceforge.net/project/showfiles.php?group_id=13478

MD5 sums:

CODE

1986cf97d7a04d8b425d9c61fe6b52b3  flac-1.1.3-devel-win.zip
de9771830c6b879632ce50ce0052b830  flac-1.1.3-linux-i386.tar.gz
ad00df28be05eaa773854cf5da31f208  flac-1.1.3-osx-ppc.tar.gz
9badf34f5f717426babd2d9da4715aa4  flac-1.1.3-win.zip
b084603948b60ee338e0c29978cc580c  flac-1.1.3.tar.gz

SHA-1 sums:

CODE

b5229a913b2c860fcd879bdacb6a9b797bd44e0d  flac-1.1.3-devel-win.zip
e8ad3debe240eb329d8a186e8066e08681679c62  flac-1.1.3-linux-i386.tar.gz
3c0e10dba0da045364b0cc23c3694a201a2d87c0  flac-1.1.3-osx-ppc.tar.gz
3f048d915c95e4c9478e9e7249bc508a66245247  flac-1.1.3-win.zip
e19c92bebe536b69dd14d54de76c1f626b83b295  flac-1.1.3.tar.gz

Klyith

Dec 2 2006, 01:33

From the changelog: "Much better recovery for corrupted files"
Is this a decoder improvement, or a change to the file stream which requires the file to be encoded with 1.1.3? The speed & compression improvements are good, but not "reencode my flacs" worthy. Error correction would be though.

Fandango

Dec 2 2006, 05:33

I think many people will never know about the workaround for the Locale bug because, seriously, who's going to read that part of the documentation?

And I don't think that only few people are affected, Germans for example, being the biggest user-base affected by this also have the "," as the decimal separator.

Hm, but I hope the difference isn't that big, but only a dozen bytes...

PS: where are the posts in which this was discovered/discussed?

molnart

Dec 2 2006, 05:39

I think every country in Europe except the UK use "," as decimal separator. At least we certainly do. And anyway if it's a "known bug" why can't be a 1.1.3.1 released ?

Fandango

Dec 2 2006, 05:51

Oh wow, everyone except the English? That kind of makes it even worse. So then the FLAC user base is literally split in half into English speaking and non-English speaking (or locale using) users now... each producing a different encode with 1.1.3... weird.

Emanuel

Dec 2 2006, 06:00

QUOTE(Fandango @ Dec 2 2006, 12:51)

Oh wow, everyone except the English?

Basically, yes...

goodnews

Dec 2 2006, 07:10

QUOTE(molnart @ Dec 2 2006, 04:39)

I think every country in Europe except the UK use "," as decimal separator. At least we certainly do. And anyway if it's a "known bug" why can't be a 1.1.3.1 released ?

I hope Josh finds a way to fix this bug in the code itself without someone having to add extra command line options, as very few except the real "die hard" audiophiles use lots of command line options. Many people use the defaults.

Does this bug only affect flac.exe for Windows or is it also in the libFLAC 1.1.3 code too?

Fandango

Dec 2 2006, 07:28

Uhm, to make things clear... is it correct that we are talking about 6 extra bytes only for the whole file? I've skimmed over the 1.1.3 beta thread and I stumbled across that number. IMHO, not enough to make a big deal out of it (<-

, coming from the guy who started it).

goodnews

Dec 2 2006, 07:36

QUOTE(Fandango @ Dec 2 2006, 06:28)

, coming from the guy who started it).

No we're talking a lot more than 6 bytes. Read the beta thread, it produces FLAC 1.1.2 like encoding rates, instead of FLAC 1.1.3 rates. Many people were quoting multi-megabyte difference in file size due to FLAC incorrectly using sub-optimal encoding rates due to their systems not using period dots but rather commans in their language by default.

Please re-release an upgrade to fix this Josh. FLAC 1.1.3a anyone? All this bug does is give this new FLAC release a "black eye" in my opinion and detracts from an otherwise great update. Too bad this wasn't caught in time to be in the release...

me7

Dec 2 2006, 07:42

No, it's more than 6 bytes. I tried to encode a few files on my german system and the compression stays the same (or almost the same) as in 1.1.2. I would say that this [-A "tukey(0,5)"] parameter is the main difference between the 1.1.2 and 1.1.3 encoder.

Edit: goodnews was faster

dv1989

Dec 2 2006, 07:44

I am surprised that this major update did not receive at least 1.2 status!

With regard to the point bug, I agree; there should be a maintenance release. It would be a shame for European users to miss out on one of the best new features of the encoder!

me7

Dec 2 2006, 08:07

What would happen if you put both versions into the encoder? Would a comma-based machine simply ignore the point-based parameter and vice versa? Or could this confuse the encoder?

Sadly I'm not into programming, but maybe someone who is could try this since flac is open-source?

dv1989

Dec 2 2006, 08:09

There is surely a better way to fix the problem?

Fandango

Dec 2 2006, 08:13

I found something which I think is a potential problem with the recommended workaround. The documentation to the affected FLAC feature (apodization) says the following:

QUOTE

The encoder chooses suitable defaults in the absence of any -A options; any -A option specified replaces the default(s).

So that workaround will always use "tukey(0,5)", even when the encoder would have chosen a different apodization function? That's bad.

Maurits

Dec 2 2006, 09:27

QUOTE(dv1989 @ Dec 2 2006, 13:44)

I am surprised that this major update did not receive at least 1.2 status!

I agree. It is called a 'Major release' but when you click on the explanation of 'Major release' you get a blurb on how last digit updates mean 'Micro updates'.

Oh well, it's not the end of world.

Synthetic Soul

Dec 2 2006, 10:24

QUOTE(Fandango @ Dec 2 2006, 14:13)

So that workaround will always use "tukey(0,5)", even when the encoder would have chosen a different apodization function? That's bad.

I don't think FLAC chooses the window depending on any criteria. It always uses tukey(0.5).

Edit: Hmm... I see you are quoting the documentation and it does give the impression that the window is chosen dynamically. I guess I must be wrong.

tev777

Dec 2 2006, 11:09

Thanks for the update, Josh. Keep up the great work.

jcoalson

Dec 2 2006, 11:37

QUOTE(Klyith @ Dec 2 2006, 02:33)

the improvement is entirely in the decoder, not due to any format changes.

QUOTE(dv1989 @ Dec 2 2006, 08:44)

I am surprised that this major update did not receive at least 1.2 status!

yes, this is a common question so I made a FAQ for it: http://flac.sourceforge.net/faq.html#api__release_versioning

as for the -A bug, I feel your pain! since this release had so much new stuff I plan on doing another one soon to correct major things that have cropped up.

I thought most people are using tools like EAC, AutoFLAC, frontend, etc where the command string is only specified once, and it is easier to do the workaround. there is another possible workaround that involves running the binary in a "C" locale. I have no idea how you do that on windows but with unix it would just be

CODE

LANG=C LC_ALL=C flac -5V ...

Josh

Maurits

Dec 2 2006, 11:58

QUOTE(jcoalson @ Dec 2 2006, 17:37)

QUOTE(dv1989 @ Dec 2 2006, 08:44)

I am surprised that this major update did not receive at least 1.2 status!

yes, this is a common question so I made a FAQ for it: http://flac.sourceforge.net/faq.html#api__release_versioning

Ah, it's clear now. Thanks!

By the way, that FAQ states 4KB as default padding, I thought it was increased to 8KB?

Fandango

Dec 2 2006, 12:19

QUOTE(jcoalson @ Dec 2 2006, 18:37)

I thought most people are using tools like EAC, AutoFLAC, frontend, etc where the command string is only specified once, and it is easier to do the workaround. there is another possible workaround that involves running the binary in a "C" locale. I have no idea how you do that on windows but with unix it would just be

CODE

LANG=C LC_ALL=C flac -5V ...

Josh

Unfortunately it's not as easy as under Unix. One workaround for Windows might be to "customize" the locale and use "." instead of "," as the decimal seperator while encoding with flac or until an update is out. I don't know of any other application where it actually matters that much.

If anyone knows whether it's possible to change the locale per application, I'd be interested to know, since I know of at least one other problem that is related to the locale setting and which bothers me.

skelly831

Dec 2 2006, 12:47

Great news, thanks for the update!

iGold

Dec 2 2006, 13:28

Is it possible to show warning if incorrect apodization function was used in command line (and was skipped by flac[.exe])? Because now I can just misspell function or parameter name (as with tukey(0.5)) and even don't know about it.

jcoalson

Dec 2 2006, 13:36

QUOTE(Maurits @ Dec 2 2006, 12:58)

By the way, that FAQ states 4KB as default padding, I thought it was increased to 8KB?

oops, fixed.

P.S. one more note to developers and package maintainers... I went around to all the open-source flac-dependent projects I could find and made patches for the api changes. if you didn't get them and need one, let me know. also if you have a closed source project and the porting guide is not clear or you need more info, let me know too.

hellokeith

Dec 2 2006, 14:14

QUOTE(jcoalson @ Dec 2 2006, 11:37)

I thought most people are using tools like EAC, AutoFLAC, frontend, etc where the command string is only specified once, and it is easier to do the workaround.
Josh

That's me.

Josh, I want the absolute best compression (ripping from CD via EAC), and I do not care about encode time. So what combination of flags do I need to set? Currently I'm using -8. It looks like now I need to specify -m --best -e ?

Mangix

Dec 2 2006, 14:27

QUOTE(hellokeith @ Dec 2 2006, 12:14)

QUOTE(jcoalson @ Dec 2 2006, 11:37)

I thought most people are using tools like EAC, AutoFLAC, frontend, etc where the command string is only specified once, and it is easier to do the workaround.
Josh

if you want the maximum compression available, then you should use a few -A functions. it increases the encode time with little to no improvement to the compression. also, you can use -A more than once.

jcoalson

Dec 2 2006, 14:38

QUOTE(hellokeith @ Dec 2 2006, 15:14)

Josh, I want the absolute best compression (ripping from CD via EAC), and I do not care about encode time. So what combination of flags do I need to set? Currently I'm using -8. It looks like now I need to specify -m --best -e ?

it's still -8 (same as --best) both of which turn on -m and -e. if you're affected by the locale bug you have to specify -A "tukey(0,5)" manually. then if you really don't care about the encoding time you can add more and different -A options but this is unlikely to ever get you more than .25% increased compression and they really slow things down.

I have some more ideas for compression improvements that I will be testing now that 1.1.3 is out.

Josh

DickxLaurent

Dec 2 2006, 23:58

Will there be a separate P4 specific build like the previous version? Or will we just have to wait and see if John33 compiles this?

ozmosis82

Dec 3 2006, 01:27

Thanks for the great work Josh. Looks like it's back to FLAC for me.

Sebastian Mares

Dec 3 2006, 01:47

1.1.2 is not affected by the locale bug, right?

goodnews

Dec 3 2006, 03:16

QUOTE(Sebastian Mares @ Dec 3 2006, 00:47)

1.1.2 is not affected by the locale bug, right?

Also FLAC 1.1.3 beta 2 was reportedly not affected by this bug... ?

Jose Hidalgo

Dec 3 2006, 03:51

Considering that a LOT of countries are affected by the -A bug (almost every country in fact !), and that this can cause IMHO potential problems with AccurateRip for instance (different file sizes, so no matches found) and lead to lots of wrong data being uploaded to AccurateRip's database, can we expect the "-A bug free version" to be available quite soon ?

Josh, what can be the estimated delay for the next bug-correcting version ? Are we talking about days ? weeks ? months ? years ?

Thanks in advance. I hope everybody will soon be able to fully enjoy all of 1.1.3's great improvements.

Sebastian Mares

Dec 3 2006, 04:12

What does AccurateRip has to do with FLAC? Nothing.

ernstblaauw

Dec 3 2006, 04:19

I will also wait for the version which fixes the localization bug. I don't know which one (',' or '.') is set at my computer, so I'll be safe and use 1.1.2 untill a bugfix is released.

Jose Hidalgo

Dec 3 2006, 04:53

QUOTE(Sebastian Mares @ Dec 3 2006, 11:12)

What does AccurateRip has to do with FLAC? Nothing.

Oops, sorry, you're totally right, I wrote that too fast.

But my question remains the same. Thanks.

Cartoon

Dec 3 2006, 04:57

An estimate of a bigfix would be appreciated. Weeks? A month? Months? Year?

Doesn't have to be that precise, but for now I will just wait for the fix (since I don't expect to encode much until after my christmas gifts

)

Egor

Dec 3 2006, 06:48

QUOTE(Synthetic Soul @ Dec 2 2006, 22:24)

You're right, currently it is always "tukey(0.5)":

QUOTE(jcoalson @ Oct 11 2006, 00:41)

QUOTE(Egor @ Oct 10 2006, 12:47)

QUOTE(options - apodization)

The encoder chooses suitable defaults in the absence of any -A options; any -A option specified replaces the default(s).

How does it choose? Is it always tukey(0.5)?

right now, yes

but it may get smarter.

Synthetic Soul

Dec 3 2006, 06:57

Thanks for the confirmation, and quotes, Egor.

I did wonder whether this referred to potential changes in the future, rather than current practise.

Case

Dec 3 2006, 07:00

I uploaded a hack-fixed version for Windows here. It treats both comma and dot with apodization functions in the same way.

ernstblaauw

Dec 3 2006, 08:56

QUOTE(Case @ Dec 3 2006, 05:00)

I uploaded a hack-fixed version for Windows here. It treats both comma and dot with apodization functions in the same way.

So it has the same behaviour as 1.1.2?

Synthetic Soul

Dec 3 2006, 13:18

QUOTE(ernstblaauw @ Dec 3 2006, 14:56)

So it has the same behaviour as 1.1.2?

No. If tukey(0.5) and tukey(0,5) are working as they should then this release will do what 1.1.3 intended to do.

Unless of course Case means that now tukey(0.5) is fubar'd as well.

Edit: Also, may I say in my best Brian Blessed voice, "Gordon's alive!".

Clemech

Dec 3 2006, 14:08

Is the new version of FLAC OK to use with FLACFrontend? I'd use the surely marvellous Foobar but it makes my tiny brain hurt.

Thanks for treating me gently!!

doubleXP

Dec 3 2006, 14:20

QUOTE(Clemech @ Dec 3 2006, 21:08)

Is the new version of FLAC OK to use with FLACFrontend?

I'm using FLACFrontend with FLAC1.1.3 and didn't encounter any problems so far.

Clemech

Dec 3 2006, 14:31

QUOTE(doubleXP @ Dec 3 2006, 15:20)

QUOTE(Clemech @ Dec 3 2006, 21:08)

Is the new version of FLAC OK to use with FLACFrontend?

I'm using FLACFrontend with FLAC1.1.3 and didn't encounter any problems so far.

Thanks - I'm sure that if something goes wrong it will be MY fault!

WaldoMonster

Dec 3 2006, 16:48

QUOTE(Case @ Dec 3 2006, 14:00)

I uploaded a hack-fixed version for Windows here. It treats both comma and dot with apodization functions in the same way.

Thanks for the fix Case.

When creating a flac file with both beta 2 and the final fixed version there is one byte difference in the file size.
I assume this is normal behavior.

lextune

Dec 3 2006, 22:06

Thanks for all your work Josh

me7

Dec 4 2006, 04:58

To clear things up: The command line fix completely solves the issue, right? Flac does not set the switch dynamically like posted before?

Synthetic Soul

Dec 4 2006, 05:16

I believe that is the idea, yes.

The easiest way to test (assuming that you use the comma as the decimal separator) is to run the following two command lines, and ensure that the results are identical :

CODE

FLAC.EXE -o one.flac source.wav
FLAC.EXE -A tukey(0,5) -o two.flac source.wav

Edit: In fact, on testing, this appears to work even if you use a full stop as the decimal separator. I assume that Case is simply replacing any occurrence of "," with "." or something:

CODE

C:\Documents and Settings\Neil\Desktop>FLAC.EXE -o one.flac source.wav && FLAC.E
XE -A tukey(0,5) -o two.flac source.wav && FLAC.EXE -A tukey(0.5) -o three.flac
source.wav

flac 1.1.3, Copyright (C) 2000,2001,2002,2003,2004,2005,2006  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

source.wav: wrote 24487047 bytes, ratio=0.723

flac 1.1.3, Copyright (C) 2000,2001,2002,2003,2004,2005,2006  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

source.wav: wrote 24487047 bytes, ratio=0.723

flac 1.1.3, Copyright (C) 2000,2001,2002,2003,2004,2005,2006  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

source.wav: wrote 24487047 bytes, ratio=0.723

Synthetic Soul

Dec 4 2006, 07:42

Discussion regarding decimal separator moved here.

jcoalson

Dec 4 2006, 12:52

first, to save time I'll say the answers by synthetic soul and doubleXP are correct.

as for when the next release will be out, please understand first that the full release cycle for flac is actually quite a lot of work, which I am hesitant to do for a bug which has such a simple workaround (adding an option). the alternative is just specific fixed binaries, and I think case's handles that nicely for windows. the fix in CVS on the trunk will be checked in probably tonight.

I don't have a schedule for 1.1.4, but the next full release will not be 2 years away again. flac releases tend to ping-pong between major releases which take a lot of time, and shorter minor releases which are mostly fixes.

Josh

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.