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.

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.

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.

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?

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

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

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

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.

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.

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!

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

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.

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.

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.

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 ?