FLAC 1.1.3 released Options

[Mangix]

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 ?

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]

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]

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]

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

[Sebastian Mares]

1.1.2 is not affected by the locale bug, right?

[goodnews]

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]

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]

What does AccurateRip has to do with FLAC? Nothing.

[ernstblaauw]

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.

This post has been edited by ernstblaauw: Dec 3 2006, 11:20

[Jose Hidalgo]

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]

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]

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.

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

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]

Thanks for the confirmation, and quotes, Egor.

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

[Case]

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

[ernstblaauw]

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]

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

This post has been edited by Synthetic Soul: Dec 3 2006, 20:22

[Clemech]

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]

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]

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]

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]

Thanks for all your work Josh

[me7]

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]

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

This post has been edited by Synthetic Soul: Dec 4 2006, 12:22

[Synthetic Soul]

Discussion regarding decimal separator moved here.

[jcoalson]

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