1986cf97d7a04d8b425d9c61fe6b52b3 flac-1.1.3-devel-win.zipde9771830c6b879632ce50ce0052b830 flac-1.1.3-linux-i386.tar.gzad00df28be05eaa773854cf5da31f208 flac-1.1.3-osx-ppc.tar.gz9badf34f5f717426babd2d9da4715aa4 flac-1.1.3-win.zipb084603948b60ee338e0c29978cc580c flac-1.1.3.tar.gz
b5229a913b2c860fcd879bdacb6a9b797bd44e0d flac-1.1.3-devel-win.zipe8ad3debe240eb329d8a186e8066e08681679c62 flac-1.1.3-linux-i386.tar.gz3c0e10dba0da045364b0cc23c3694a201a2d87c0 flac-1.1.3-osx-ppc.tar.gz3f048d915c95e4c9478e9e7249bc508a66245247 flac-1.1.3-win.zipe19c92bebe536b69dd14d54de76c1f626b83b295 flac-1.1.3.tar.gz
Oh wow, everyone except the English?
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 18.104.22.168 released ?
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).
The encoder chooses suitable defaults in the absence of any -A options; any -A option specified replaces the default(s).
I am surprised that this major update did not receive at least 1.2 status!
So that workaround will always use "tukey(0,5)", even when the encoder would have chosen a different apodization function? That's bad.
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.
LANG=C LC_ALL=C flac -5V ...
Quote from: dv1989 on 02 December, 2006, 08:44:59 AMI 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
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 beCode: [Select]LANG=C LC_ALL=C flac -5V ...Josh
By the way, that FAQ states 4KB as default padding, I thought it was increased to 8KB?
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