IPB

Welcome Guest ( Log In | Register )

5 Pages V   1 2 3 > »   
Reply to this topicStart new topic
FLAC 1.1.3 released
jcoalson
post Dec 2 2006, 07:20
Post #1


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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
Go to the top of the page
+Quote Post
jcoalson
post Dec 2 2006, 07:49
Post #2


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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
Go to the top of the page
+Quote Post
Klyith
post Dec 2 2006, 08:33
Post #3





Group: Members (Donating)
Posts: 352
Joined: 10-July 04
From: Albany NY USA
Member No.: 15259



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.
Go to the top of the page
+Quote Post
Fandango
post Dec 2 2006, 12:33
Post #4





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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? mad.gif

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

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

This post has been edited by Fandango: Dec 2 2006, 12:34
Go to the top of the page
+Quote Post
molnart
post Dec 2 2006, 12:39
Post #5





Group: Members
Posts: 322
Joined: 25-March 06
From: Slovakia
Member No.: 28819



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 ? huh.gif


--------------------
www.last.fm/user/molnart
Go to the top of the page
+Quote Post
Fandango
post Dec 2 2006, 12:51
Post #6





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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. ohmy.gif
Go to the top of the page
+Quote Post
Emanuel
post Dec 2 2006, 13:00
Post #7





Group: Members
Posts: 284
Joined: 13-January 02
From: Sthlm, Sweden
Member No.: 999



QUOTE (Fandango @ Dec 2 2006, 12:51) *
Oh wow, everyone except the English?

Basically, yes...


--------------------
http://forum.studio.se (in Swedish)
Go to the top of the page
+Quote Post
goodnews
post Dec 2 2006, 14:10
Post #8





Group: Banned
Posts: 232
Joined: 20-January 06
Member No.: 27228



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 ? huh.gif

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?
Go to the top of the page
+Quote Post
Fandango
post Dec 2 2006, 14:28
Post #9





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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 (<- laugh.gif, coming from the guy who started it).
Go to the top of the page
+Quote Post
goodnews
post Dec 2 2006, 14:36
Post #10





Group: Banned
Posts: 232
Joined: 20-January 06
Member No.: 27228



QUOTE (Fandango @ Dec 2 2006, 06: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 (<- laugh.gif, 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...

This post has been edited by goodnews: Dec 2 2006, 14:38
Go to the top of the page
+Quote Post
me7
post Dec 2 2006, 14:42
Post #11





Group: Members
Posts: 177
Joined: 23-August 06
Member No.: 34375



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

This post has been edited by me7: Dec 2 2006, 15:08
Go to the top of the page
+Quote Post
db1989
post Dec 2 2006, 14:44
Post #12





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



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

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!
Go to the top of the page
+Quote Post
me7
post Dec 2 2006, 15:07
Post #13





Group: Members
Posts: 177
Joined: 23-August 06
Member No.: 34375



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?
Go to the top of the page
+Quote Post
db1989
post Dec 2 2006, 15:09
Post #14





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



There is surely a better way to fix the problem?
Go to the top of the page
+Quote Post
Fandango
post Dec 2 2006, 15:13
Post #15





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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.
Go to the top of the page
+Quote Post
Maurits
post Dec 2 2006, 16:27
Post #16





Group: Members
Posts: 370
Joined: 30-September 05
From: London, Europe
Member No.: 24805



QUOTE (dv1989 @ Dec 2 2006, 13:44) *
I am surprised that this major update did not receive at least 1.2 status! wink.gif

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'. biggrin.gif

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

This post has been edited by Maurits: Dec 2 2006, 16:27
Go to the top of the page
+Quote Post
Synthetic Soul
post Dec 2 2006, 17:24
Post #17





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



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

This post has been edited by Synthetic Soul: Dec 2 2006, 17:32


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
tev777
post Dec 2 2006, 18:09
Post #18





Group: Members
Posts: 181
Joined: 10-October 03
From: Florida, USA
Member No.: 9235



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


--------------------
--
Eric
Go to the top of the page
+Quote Post
jcoalson
post Dec 2 2006, 18:37
Post #19


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



QUOTE (Klyith @ Dec 2 2006, 02: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.

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! wink.gif

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
Go to the top of the page
+Quote Post
Maurits
post Dec 2 2006, 18:58
Post #20





Group: Members
Posts: 370
Joined: 30-September 05
From: London, Europe
Member No.: 24805



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! wink.gif

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?
Go to the top of the page
+Quote Post
Fandango
post Dec 2 2006, 19:19
Post #21





Group: Members
Posts: 1548
Joined: 13-August 03
Member No.: 8353



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.
Go to the top of the page
+Quote Post
skelly831
post Dec 2 2006, 19:47
Post #22





Group: Members (Donating)
Posts: 782
Joined: 11-April 05
From: México
Member No.: 21361



Great news, thanks for the update! smile.gif


--------------------
we was young an' full of beans
Go to the top of the page
+Quote Post
iGold
post Dec 2 2006, 20:28
Post #23





Group: Members
Posts: 139
Joined: 23-December 05
Member No.: 26599



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.
Go to the top of the page
+Quote Post
jcoalson
post Dec 2 2006, 20:36
Post #24


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



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.
Go to the top of the page
+Quote Post
hellokeith
post Dec 2 2006, 21:14
Post #25





Group: Members
Posts: 288
Joined: 14-August 06
Member No.: 34027



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 ?
Go to the top of the page
+Quote Post

5 Pages V   1 2 3 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 22nd July 2014 - 23:55