Almost 6 years after the prior release, the new FLAC devs at Xiph.org (http://www.xiph.org/), headed by Erik de Castro Lopo, have released a new version. Excerpts from the changelog (http://xiph.org/flac/changelog.html):
- Supports RF64+Sony Wave64
- Can ignore timestamp/permissions from infile
- Allow MM:SS:FF/.SS times in non-CDDA cuesheets
- Fixed ReplayGain on stdin
- Appropriate channel masks for 6.1/7.1 input
- Analyse gain of 56–192 kHz files
- Handle UTF-8 filenames on Windows
- Support input files > 2/4 GB
- Command-line tools can now use wildcards
Home: http://xiph.org/flac/ (http://xiph.org/flac/)
Compiles: see post #7 (http://hydrogenaudio.org/forums/?showtopic=101082#entry835601) onwards
Changelog is updated, but download links go to old FLAC 1.2.1 version
Which links, where? If you mean on either http://xiph.org/flac/ (http://xiph.org/flac/) or the no longer updated http://flac.sourceforge.net/ (http://flac.sourceforge.net/), probably the developers simply have not yet compiled official binaries. Perhaps some reader here has done this for his/her personal usage and platform and might be willing to share the results.
As per the penultimate item on the bulleted list of changes, the sources are now maintained using git at Xiph, not SourceForge. The relevant link: https://git.xiph.org/?p=flac.git;a=tree (https://git.xiph.org/?p=flac.git;a=tree) Download all files at once by clicking on the link entitled “snapshot”.
Finally, moving to Validated News! Congratulations to everyone who helped to bring FLAC back from its cryosleep.
FWIW, Arch Linux already has i686 (https://www.archlinux.org/packages/extra/i686/flac/) and x86_64 (https://www.archlinux.org/packages/extra/x86_64/flac/) binaries.
Changelog is updated, but download links go to old FLAC 1.2.1 version
Yeah, this is more of a developers release. There are no big changes, (edit: besides the UTF-8 support in Windows of course, thank Case for that) it's been made easier to compile libFLAC. There's no real need to upgrade for end users, except if you want to encode RF64, W64 or 7- or 8-channel files. (edit: or if you want to encode files with non-latin characters in the filenames) There's a checked and tested Windows binary shipped with the new FLAC frontend (http://flacfrontend.sourceforge.net/) however, if you're curious. On other platforms you'll have to compile it yourself for now I guess.
The official download location for the source tarballs is at http://downloads.xiph.org/releases/flac/ (http://downloads.xiph.org/releases/flac/) (that is linked from the “download” page, and 1.3.0 is there).
Further to my earlier comments about the availability of compiled binaries and packages of the source, see the posts starting here in the thread about prereleases of 1.3.0:
http://hydrogenaudio.org/forums/?showtopic...125#entry835436 (http://hydrogenaudio.org/forums/?showtopic=99757&st=125#entry835436)
Replies directed specifically at previous posts within that thread should probably go there. However, if they have significant relevance to the final version as a whole, posting them here might be more prudent.
Other posts about the final release of 1.3.0 should be kept in this thread, in the hope that discussions about it can be easily located by readers, rather than being fragmented across various locations.
There was a Windows binary ready even here right away: http://www.saunalahti.fi/~cse/temp/ (http://www.saunalahti.fi/~cse/temp/)
You would expect it here http://www.flac.com/ (http://www.flac.com/)
assuming everything compiles OK, I'll post a set of binaries at Rarewares later today and post here when they're available.
I don't know much about programming and don't know much about all these binary versions, I just know they are all different (MD5 etc.).
How is the official 1.2.1b build compiled? Is it possible to have a 1.3.0 built the same way of the official one? I just want to make sure it will work with everything.
I am currently use this one: http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip (http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip)
Thanks.
How is the official 1.2.1b build compiled? Is it possible to have a 1.3.0 built the same way of the official one? I just want to make sure it will work with everything.
Old official FLAC was compiled with Visual Studio 6.0. It made small binaries as it could dynamically link against msvcrt.dll that came with Windows since Windows 2000. I don't think anyone has the compiler in use anymore.
I am currently use this one: http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip (http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip)
That version is compiled with MSVC 2012 Update 2 using the Windows XP toolset and static linking. It works on Windows XP and newer and doesn't require any additional dlls.
I noticed that FLAC compile from Case was added into foobar2000 free encoder pack (http://www.foobar2000.org/encoderpack).
What about the issue (problem) regarding FLAC and file sizes greater than 2GB . . . has this been addressed?
Yes, not sure why it was left out of the changelog. Another problem size was 4 GB. Both issues are solved and I have tested over 20 GB FLAC files succesfully. Such large FLAC actually revealed bugs in foobar2000 that are fixed in latest versions.
Confirmed as well on Linux x86_64 with a 5GB FLAC file.
AFAIK 2GB problem was related to MSVC:
libFLAC uses the C stdlib for file i/o. even on my XP box with VS 2005, microsoft's stdlib implementation is still limited to 2 GB (i.e. no 64-bit off_t).
I'm reluctant to add win-specific calls to libFLAC just because MS is intentionally sabotaging portability. every other build of flac works with large files.
Good point about the fixes for large input files and the curious fact of these being omitted from the changelog. I have added those and some other things to the list of changes in the OP, alongside a couple of new links that are useful to have in the same place for quick access.
Yes, not sure why it was left out of the changelog. Another problem size was 4 GB. Both issues are solved and I have tested over 20 GB FLAC files succesfully. Such large FLAC actually revealed bugs in foobar2000 that are fixed in latest versions.
So I assume continuously streaming flac will now also work?
32 and 64 bit compiles are at Rarewares now - ICL 12.1 compiles.
Crash.
Do these ICL 12.1 compiles require a SSE2 cpu by any chance?
Crash.
Do these ICL 12.1 compiles require a SSE2 cpu by any chance?
The Intel 12.1 compiler defaults to arch SSE2. Therefore, my guess is the answer to your question is yes.
I tested these compiles on my Intel Core2. A CD image (44.1/16/stereo, 53min 50sec) was encoded with -8 setting.
Encoding time (smaller is better):
Case 76.2 s
ktf 77.0 s
john33 32bit 79.6 s
lamedude SSE 32bit 79.5 s
john33 64bit 77.6 s
lamedude SSE 64bit 76.6 s
Case: flac built by Case using MSVC 2012 (see post #12 in this thread)
john33: flac built by john33 using ICC 12.1 (see post #20 in this thread)
ktf: flac built by ktf using MinGW (see post #134 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99757&view=findpost&p=835599))
lamedude: flac built by lamedude using MSVC 2012 (see post #132 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99757&view=findpost&p=835471))
And for FLAC -5:
Case 21.0 s
ktf 23.2 s
john33 32bit 21.2 s
lamedude SSE 32bit 21.1 s
john33 64bit 26.3 s
lamedude SSE 64bit 25.3 s
32 and 64 bit compiles are at Rarewares now - ICL 12.1 compiles.
Thank you very much, John
I can confirm that the 64-bit encoder is slower than the 32-bit version. Running Win 8 Pro, i5 2500k, using foobar2000 1.2.6 as a front-end, 32-bit averages around 245x real-time, while 64-bit is around 222x.
While VS12 is a big improvement I never expected it to beat the mighty ICC. AVX didn't make much of a difference compared to SSE2 (hopefully AVX2 will) so that doesn't save it. My quick test shows the assembly provides 50% and 10% speedup in -5 and -8, respectively, so the 64bit version has a big handicap in the faster settings.
Here's VC12 binaries (http://daman6009.home.comcast.net/flac.zip) (including SSE1 for CoRoNe).
I compared john33's 32-Bit and 64-Bit binaries and I always get faster results with the 64-Bit.
I tested -0 -5 and -8.
Maybe it depends on the system setup.
I have an i5-3570K, z77 chipset, and 2x4GB DDR 800MHz (8-8-8-24). Not overclocked.
I compared john33's 32-Bit and 64-Bit binaries and I always get faster results with the 64-Bit.
I tested -0 -5 and -8.
Maybe it depends on the system setup.
I have an i5-3570K, z77 chipset, and 2x4GB DDR 800MHz (8-8-8-24). Not overclocked.
I confirm it. 64-bit is 15% faster.
Phenom x4 965, 8gb
What about that one? I created a 4,4GB dummy album for benchmark on a ramdrive and applied RG scanning with metaflac. There is some real speed increase around 20%.
core i5@4,4
Case 1:18
32bit ICL 1:16
64bit ICL 1:02
x64 builds seem faster to me...
Also find it a bit odd the ICL non x64 build seems to pull slightly ahead of the others on an AMD cpu (could just be john's magic)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Songs: 25
Size: 767 MB (804 807 162 bytes)
Duration: 1:16:02.351 (201 199 665 samples)
Encoded from wav to flac -8 using foobar as front-end (win7)
CPU: AMD FX-8320 @ 4.0
RAM: DC 1866 @ 10-11-10-30
Builds in order of seconds (real-time speed):
lamedude x64 - 15.480 (294.66x)
john33 ICL x64 - 15.975 (285.53x)
john33 ICL - 16.875 (270.31x)
Case - 17.312 (263.48x)
minGW - 17.399 (262.17x)
lamedude SSE2 - 17.907 (254.73x)
lamedude SSE1 - 18.572 (245.61x)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have just updated the FLAC 1.3.0 compiles based upon the ICL 13.0 compiler. On my development system (a 3770k system), these are about 10% faster than the ICL 12.1 compiles were. Other peoples experiences would be interesting.
I have just updated the FLAC 1.3.0 compiles based upon the ICL 13.0 compiler. On my development system (a 3770k system), these are about 10% faster than the ICL 12.1 compiles were. Other peoples experiences would be interesting.
Cheers Here are the results of the updated binaries, using foobar2000 as a front-end. The same WAV file was encoded thrice:
32-bitTotal encoding time: 0:13.766, 253.82x realtime
…
Total encoding time: 0:13.859, 252.12x realtime
…
Total encoding time: 0:13.719, 254.69x realtime
64-bitTotal encoding time: 0:16.141, 216.48x realtime
…
Total encoding time: 0:16.828, 207.64x realtime
…
Total encoding time: 0:16.047, 217.74x realtime
Weird! Nonetheless, it's heartening to see others are getting better results, more in line with what can be expected.
Thanks for the new compiles, John. You're a legend, and your work is deeply appreciated
Avira is giving me a virus alert when unzipping john33's new 32-bit ICL 13.0 bundle (for two out of three binaries). No alerts on the 64-bit bundle.
Obviously, it could be a false positive, I just wanted to mention it.
EDIT: Avira Free Antivirus version 13.0.0.3640 with definition files up-to-date as of June 2.
I run Avast Free on all my systems so I'd be very surprised if it was anything other than a false positive, but thanks for the notification.
@Compact Dick - It's strange how the encoding times seem to vary so much on different systems. On my system, as referred to above, there is virtually no time difference between the 32 and 64 bit compiles. I have a 6 core Bulldozer system that I'll try and see how they compare, relatively.
Edit: FWIW, on the AMD system the 32 bit compile is about 15% faster!
FWIW, both compiles run slower on my x86_64 Arch Linux system (with Wine) than the native build.
Edit: on a Core i7 mobile CPU.
anything to increase the speed and efficiency? No?
Hmm weird... using the same settings as my previous (http://www.hydrogenaudio.org/forums/index.php?showtopic=101082&view=findpost&p=835919) post:
ICL13 x64 - 14.871 (306.73x)
ICL13 - 15.985 (285.36x)
They seem to be a bit faster, though it's a different day, some background process may have been hogging the CPU yesterday.
Those who were reporting a slower x64 build, were you using win8 or win7?
anything to increase the speed and efficiency? No?
Nope, just the newer compiler. Otherwise, exactly the same compiler settings.
Those who were reporting a slower x64 build, were you using win8 or win7?
Windows 8 Pro.
Thanks for all of the work.
Dumb question: is there any benefit to me transcoding all my CD rips in 16/44.1k FLAC from 1.2.1 V8 to 1.3.0?
I doubt it. As ktf indicated earlier, most of the changes affect specific use-cases: chances are that if they were relevant to your collection, you would already know that you needed the new version. AFAIK, beyond the fixes and additions specified in the changelog, very little has changed on the level of the format itself. I suspect recompression would yield little or perhaps even no benefits.
For it to be worth your time to re-encode everything, the new version would have to offer a pronounced increase in compression. In reality, it seems to be a refresh as the new maintainers deal with some old issues and add some new features, rather than delving deeply into the encoding process itself. And, to be honest, FLAC has never seemed to be targeted directly at maximal compression or users who worry about it, preferring to reach acceptable compression and then focus on other things. Time will tell whether this trend continues, but were I to be presumptuous, I would predict that it will.
db1989 is correct; his allowances are generous, in fact.
If I remember correctly from the prereleases, re-encoded (1.2.1 -> 1.3.0preX) files differ in size by a handful of bytes, likely just due to changed strings (1 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99757&view=findpost&p=826349)). Aside from developer-side improvements, and handling unicode characters on the Windows command line, the main libFLAC improvement was in the decoding speed (2 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99757&view=findpost&p=827208)). Compression is not affected at all.
Thanks for the advice. I didn't expect any compression improvements, nor do I really need them. I was more concerned about file format updates that made the files more robust, enabled features, etc., and I don't see any that apply to the way I use FLAC. I suppose I'll roll 1.3.0 for future encodes and let the 1.2.1 files alone. I didn't have any problems with FLAC as it was, and its all good to see it continue to evolve.
Aside from developer-side improvements, and handling unicode characters on the Windows command line, the main libFLAC improvement was in the decoding speed (2 (http://www.hydrogenaudio.org/forums/index.php?showtopic=99757&view=findpost&p=827208)). Compression is not affected at all.
A noteworthy change that might be relevant to certain types of user, but for some reason was not included in the official changelog, is the fix enabling encoding of source files >2 GB and >4 GB under Windows. Anyway, thanks for posting some sources!
I have just updated the FLAC 1.3.0 compiles based upon the ICL 13.0 compiler.
Works like a charm, even on older Windows versions, thanks for that
From the few tests I've done the ICL 13 build is as fast as Ktf's GCC build.
Something else worth noting and not mentioned in the changelog are that support for expanding wildcards on Windows has been added to both flac.exe and metaflac.exe. This is particularly nice for using metaflac to add both track and album ReplayGain to an album. Previously, to use metaflac to calculate album gain, you had to enumerate each track's filename on the command line.
C:\>metaflac --add-replay-gain "D:\Music\J.J. Cale\Troubador\*.flac"
Question:
For programs that work with the library (DLL) rather than the front-end encoder (EXE), are any of the updates relevant?
Programs like eac3to and Illustrate's dBpoweramp use a DLL to convert to FLAC.
Would any of these benefit from the recent updates or would the DLL's already be working without the bugfixes present in 1.3.0?
from the horse's mouth (spoon on the dbpoweramp forums)
Actually none of the changes would change dBpoweramps implementation (as the changes are to flac.exe and we use the library direct)...
Thank you for clearing that up!
Something else worth noting and not mentioned in the changelog are that support for expanding wildcards on Windows has been added to both flac.exe and metaflac.exe.
Good point indeed! I just added it to the list in the OP. It seems Hydrogenaudio could compile a superior changelog at this rate.
I tested these compiles on my Intel Core2. A CD image (44.1/16/stereo, 53min 50sec) was encoded with -8 setting.
Encoding time (smaller is better):
Case 76.2 s
ktf 77.0 s
john33 32bit 79.6 s
lamedude SSE 32bit 79.5 s
john33 64bit 77.6 s
lamedude SSE 64bit 76.6 s
Case: flac built by Case using MSVC 2012 (see post #12 in this thread)
john33: flac built by john33 using ICC 12.1 (see post #20 in this thread)
ktf: flac built by ktf using MinGW (see post #134 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99757&view=findpost&p=835599))
lamedude: flac built by lamedude using MSVC 2012 (see post #132 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=99757&view=findpost&p=835471))
Can you try these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin.tar.lzma) (built with i686-w64-mingw32-gcc-4.8.1 and yasm)? Also these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3.tar.lzma) (same, but with -O3 optimizations) and these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3-march=core2.tar.lzma) (same, but with -O3 optimizations and -march=core2)
Also these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3.tar.lzma) (same, but with -O3 optimizations) and these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3-march=core2.tar.lzma) (same, but with -O3 optimizations and -march=core2)
These builds require a libogg-0.dll with an InterlockedCompareExchange@12 procedure, which I can't find.
Also these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3.tar.lzma) (same, but with -O3 optimizations) and these (http://lrn.no-ip.info/other/flac-1.3.0-1-mingw32-staticbin-O3-march=core2.tar.lzma) (same, but with -O3 optimizations and -march=core2)
These builds require a libogg-0.dll with an InterlockedCompareExchange@12 procedure, which I can't find.
Good catch! I've updated both tarballs, should be fine now.
Small test performed on a computer running XP Pro with an 'old' Core2Duo E6750 and encoding at both -8 and -6 compressions a pop/rock album rip of 453 MB WAV, 44min 53s:
Rarewares' ICL13 -8: 1:01.281
Rarewares' ICL13 -6: 0:16.484
KTF's -8: 1:00.918
KTF's -6: 0:18.562
LRN's generic -8: 0:57.875
LRN's generic -6: 0:17.500
LRN's Core2 -8: 0:57.688
LRN's Core2 -6: 0:17.672
Here are my results, they're very interesting indeed.
Phenom II X6 1055 running Windows 8 64 bit. Not currently overclocked, so rest of spec is insignificant.
I took a 3:22 long 24 bit 96kHz 5 channel file and encoded it with the ICL 13.0 32 bit and 64 bit binaries. I conducted 3 runs with each encoder.
- 32 bit
- 11.38x realtime
- 11.36x realtime
- 11.34x realtime
- 64 bit
- 15.49x realtime
- 15.53x realtime
- 15.40x realtime
It seems that, at least on my system with high res files, the 64 bit binary is much faster.
Could people with AMD CPU try these patched* flac versions and compare them with vanila ICL13 from rare-wares? I wonder if Intel still plays dirty and slows down execution on AMD, but I no longer have an AMD CPU to check myself.
flac-1.3-icl_patch.7z (http://www47.zippyshare.com/v/11066746/file.html)
* removes the code dispatcher check for GenuineIntel
Is it possible to compile x86-64 version of FLAC with assembler optimizations?
I tested 32-bit and 64-bit compiles from rarewares and 64-bit compile is slower for -3, -4, -5 and -6 encoding modes. I think that's because 64-bit version doesn't have ASM optimized functions...
OTOH, it's relatively easy to rewrite FLAC__lpc_compute_autocorrelation_asm_ia32_sse_lag_N functions with intrinsics, and maybe this will be enough to restore encoding speed.
My (experimental) FLAC compile made with Intel Composer XE 2013; several asm functions were rewritten with intrinsics (SSE/SSE2/SSSE3/SSE4.1).
Anyone wants to test it?
[removed]
Why don't you guys add 1.3.0 binaries here http://sourceforge.net/projects/flac/files/flac-win/ (http://sourceforge.net/projects/flac/files/flac-win/)? Case's binaries (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=101082&view=findpost&p=835631) perhaps (since they also are the ones in the foobar2000 Free Encoder Pack (http://www.foobar2000.org/encoderpack))?
See this post, it's about the binaries: http://lists.xiph.org/pipermail/flac-dev/2...uly/004274.html (http://lists.xiph.org/pipermail/flac-dev/2013-July/004274.html)
Furthermore, FLAC is (slowly) being moved away from sourceforge.
See this post, it's about the binaries: http://lists.xiph.org/pipermail/flac-dev/2...uly/004274.html (http://lists.xiph.org/pipermail/flac-dev/2013-July/004274.html)
Furthermore, FLAC is (slowly) being moved away from sourceforge.
And it takes months to upload a binary to the website?
Good observation
I ended up using john33's compile from rarewares.org, and never looked at the subject again. But the official website still has the 1.2.1 windows binaries as the latest.
http://www.rarewares.org/lossless.php (http://www.rarewares.org/lossless.php)
I used Case's one since day one, that wasn't my point.
Everything is so slow around open source projects, it takes months to do every little thing. IMO this is still one reason open source projects in general can't compete with big companies. If Apple changes iTunes albums to ALAC every other compressed lossless codec is done.
Everything is so slow around open source projects, it takes months to do every little thing.
As you say "everything," one counterexample suffices to falsify your point: look at Firefox (an open source project) security updates. Several times, they released an update which fixed a zero-day exploit in less than a week's time.
IMO this is still one reason open source projects in general can't compete with big companies.
Baseless claim. Many big company (e.g., Apple, Intel, IBM, Oracle) extensively rely on open-source projects. E.g., a shitload of major components of OS X are open source (including the kernel, apache, bash, man, perl, rsync, vim, ...)
If Apple changes iTunes albums to ALAC every other compressed lossless codec is done.
This is just silly. First, it doesn't really belong in a thread with the topic FLAC 1.3.0. Second, what's the value of this claim without providing any rationale for it?
---
EDIT: Moderation, please consider binning my post. Couldn't resist replying...
the lack of official mp3 command line encoders doesn't seem to be doing the format much harm.
the lack of official mp3 command line encoders doesn't seem to be doing the format much harm.
Right I just hope for a brighter future of FLAC.
I really love FLAC! I'm so glad it's still going strong now that it's had some increased direct hardware support from companies such as SanDisk Sansa (makers of the great sounding Clip, Clip+, and ClipZip media players with EQ). And with Linux support it's still going strong too. Thanks to everyone here for helping propel it forward!
Eventually the hardware manufacturers will include 24-bit support as 24-bit becomes more Native to chips. Those are my predictions anyway. I read that it happened with some Desktop computer motherboards, so maybe with other hardware too!
See this post, it's about the binaries: http://lists.xiph.org/pipermail/flac-dev/2...uly/004274.html (http://lists.xiph.org/pipermail/flac-dev/2013-July/004274.html)
Furthermore, FLAC is (slowly) being moved away from sourceforge.
And it takes months to upload a binary to the website?
It's indeed a shame that the official FLAC download page (https://www.xiph.org/flac/download.html) still lists 1.2.1 as the most recent binary. Especially considering so much effort was put into 1.3.0
There has been some discussion on the list about the binaries for the various platforms and that they want to compile them internally. That way they don't have to rely on externally compiled binaries where they can't really vouch for quality and security (There has been no shortage of volunteers to compile an official binary! (http://lists.xiph.org/pipermail/flac-dev/2013-July/004278.html)).
As considerable work has been done towards version 1.3.1 in the last few months (https://git.xiph.org/?p=flac.git;a=shortlog) (particularly a lot of code clean up and speed improvements) I wouldn't be surprised if they are waiting for that to go to release and launch official binaries at the same time.
I used Case's one since day one, that wasn't my point.
Everything is so slow around open source projects, it takes months to do every little thing. IMO this is still one reason open source projects in general can't compete with big companies. If Apple changes iTunes albums to ALAC every other compressed lossless codec is done.
Everything so slow around closed source projects which have reached perfection. IMO this is still one reason closed source projects can't compete with open source software on super computers and webservers. Strangely even though AAC is currently used by Apple, MP3 still hasn't died and used by all other digital music distribution companies. And LAME is still being actively developed. And then we have ... Opus which beats all other lossy audio codecs - each one of them.
Sarcasm aside, do you have anything valuable to say other than your groundless opinion?
Opus which beats all other lossy audio codecs - each one of them.
Since you're on the subject, you may want to "ground" this opinion, too.
Getting official binaries out is actually a pain in the ass, particularly if you have to support multiple platforms and want one trusted person to compile them all for security reasons. My guess the delay is them trying to find someone with a Mac and an up to date toolchain
As considerable work has been done towards version 1.3.1 in the last few months (https://git.xiph.org/?p=flac.git;a=shortlog) (particularly a lot of code clean up and speed improvements) I wouldn't be surprised if they are waiting for that to go to release and launch official binaries at the same time.
Nice, I had no idea they are working on a new version.
Getting official binaries out is actually a pain in the ass, particularly if you have to support multiple platforms and want one trusted person to compile them all for security reasons. My guess the delay is them trying to find someone with a Mac and an up to date toolchain
Xiph has already confirmed they have a Mac and can compile the OS X build themselves. If they need input, tips or best practices in compiling using the OS X toolchain they can rely on the mailinglist where a number of people have been building FLAC binaries for OS X for years.
I doubt technical reasons are to blame for the wait, I expect they are just waiting for 1.3.1 to kill two birds with one stone. A lot of changes for various build systems have landed after the release of 1.3.0 so they might as well wait until 1.3.1 is ready for release.
I can only be thankful there's still active development of this great codec, no matter how long it takes to upload new binaries. So, thanks to everyone who contributes.
I can only be thankful there's still active development of this great codec, no matter how long it takes to upload new binaries. So, thanks to everyone who contributes.
True.
Now need a oggenc that read one of these big flac files.
Wolf
I'm not sure what you mean Wolf.
--ignorelength doesn't work?
I'm not sure what you mean Wolf.
--ignorelength doesn't work?
idk, using ubuntu 12.04 so flac 1.3.1 has not been down ported to my system yet.
Wolf
idk, using ubuntu 12.04 so flac 1.3.1 has not been down ported to my system yet.
Wolf
1.3.1 is NOT out yet, read the comments back.
I'm late to the party, but anyways... didn't find any newer info about FLAC 1.3.0 builds for Windows, so I tested all the ones mentioned here.
system: i7-3770, 16gb ram, win8pro-x64
test method: flac.exe -8 input.flac -o output.flac
_________________________________________
input: bytes file MD5 fb2k verification MD5
flac 1.2.1, 3h22m, 44.1kHz/16bit/2ch 1,708,858,410 1092139DA14A43C016F614A1A070598C FC2B730F57920D49D4E41604FE14A623
_________________________________________
results: time ratio bytes file MD5 fb2k verification MD5 flac.exe MD5
1.3.0-case-x32 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4ADD826644D303B57D220F866C67292B
1.3.0-case-x32-fb2k 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4ADD826644D303B57D220F866C67292B
1.3.0-flacfrontend21-x32 2:49 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 8C4AE54CE1B243904CEAB30575534FB3
1.3.0-john33-x32 2:52 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 C31C314E8C1E8DC62EE0CDBE048C6112
1.3.0-john33-x64 2:38 0.998 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 29546F37C3EB364155FADD43EC570DED
1.3.0-lamedude-sse1-x32 2:53 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 F08E20ADF2042919CA3BF8305E36CFF6
1.3.0-lamedude-sse2-x32 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 6C52EEA53F27CFEC697632194AA4D5D5
1.3.0-lamedude-x64 2:58 0.998 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 174360529CEBF9371B41019D46F1FDC4
1.3.0-lrn-mingw32-x32 3:18 0.998 1,705,098,763 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E87DC0158474E662637886797F36C0DA
1.3.0-lrn-mingw32-o2-x32 2:52 0.998 1,705,098,763 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E0D5DAE8EF9BA49D0822901FE5D114A6
1.3.0-lrn-mingw32-o2-core2-x32 2:45 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4D650372DBDB65DCC76E34DBAA42FB8F
1.3.0-wcd-x32 4:00 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E5639F8BABD64836B85B4DB119279A7B
1.2.1-official-x32 3:12 0.998 1,705,099,033 2BA84F8B1B5514BE4BED536F341875C7 FC2B730F57920D49D4E41604FE14A623 16344C45643E41544A5C1C926A109C9F
1.2.1b-official-x32 3:15 0.998 1,705,099,033 2BA84F8B1B5514BE4BED536F341875C7 FC2B730F57920D49D4E41604FE14A623 B8396749F374C9F48CBE3B16C5333D49
Bug? Using the -p option results in much larger files than without p (up to 2% larger!). This doesn't seem to happen when I use a blocksize of 512. I haven't tested it on many input files yet, so it might be limited to my input files -- more testing is needed.
Bug? Using the -p option results in much larger files than without p (up to 2% larger!). This doesn't seem to happen when I use a blocksize of 512. I haven't tested it on many input files yet, so it might be limited to my input files -- more testing is needed.
Are you seeing this in 1.3.0 but not in older versions?
Noob question:
So if FLAC is itself updated, do these changes affect old FLAC files or only FLAC files made with the new version?
Noob question:
So if FLAC is itself updated, do these changes affect old FLAC files or only FLAC files made with the new version?
Only those created with the new version or older files you reencode with the new version.
How do you think they would affect older files unless you did something to them?
Noob question:
So if FLAC is itself updated, do these changes affect old FLAC files or only FLAC files made with the new version?
Only those created with the new version or older files you reencode with the new version.
How do you think they would affect older files unless you did something to them?
No idea. Hence the "noob question".
FLAC git 3194829 (https://git.xiph.org/?p=flac.git;a=commit;h=31948291a230685ee12af88c35d53a671e0d968f) win32 and x64 compiles:
win32 (http://www.mediafire.com/download/fl2xnsglsjpmssv/flac-git-3194829-win32.zip), x64 (http://www.mediafire.com/download/cjcg1a1d12o7nah/flac-git-3194829-x64.zip)
Built using MSVC 2013 Update 3 RC using the Windows XP toolset (v120_xp)
I decided to use the latest FLAC git instead of 1.3.0 due to various Windows/MSVC support improvements.
You can browse FLAC's git repository and view all the changes since 1.3.0 here: https://git.xiph.org/?p=flac.git;a=summary (https://git.xiph.org/?p=flac.git;a=summary)
Holy Moly! Just browsed the flac-dev Archives and seems like our fellow member "lvqcl" feels in love with the flac code He is running amok with improvements. Impressive!
quick test
comp. level 8
Intel Q9400 o/c (3.2Ghz)
44100Hz 16Bit sample
~ 54.24x > flac 1.3.0 32bit (john33 icl13)
~ 54.24x > flac 1.3.0 64bit (john33 icl13)
~ 72.85x > flac (latest git) 32bit (GrieverV msvc2013u3rc)
~ 84.39x > flac (latest git) 64bit (GrieverV msvc2013u3rc)
48000Hz 24Bit sample
~ 27.85x > flac 1.3.0 32bit (john33 icl13)
~ 44.65x > flac 1.3.0 64bit (john33 icl13)
~ 50.22x > flac (latest git) 32bit (GrieverV msvc2013u3rc)
~ 52.43x > flac (latest git) 64bit (GrieverV msvc2013u3rc)
nice improvements.
nice improvements.
Indeed!
I only just downloaded them. I have not had the time to do any tests or setup my converters to use the git builds.
Nice to see development is continuing. So many nice improvements just looking at the git logs.
Some basic benchmarks using PowerShell Measure-Command:
Command: flac.exe -8
CPU: AMD A6-5400K@4.0GHz
CD Image: 44.1/16/Stereo, 57:48
GrieverV git 3194829 64bit: ~32.98s
GrieverV git 3194829 32bit: ~44.70s
john33 1.3.0 64bit: ~63.30s
john33 1.3.0 32bit: ~64.33s
Case 1.3.0 32bit: ~66.13s
I hope they start thinking about tagging a release soon because these improvements are definitely worth it.
Great to see some new code here. I was considering FLAC to be "finished" to some extend, as in there is pretty much no room for further improvements.
Definitely glad to see someone take up the work.
I wonder when packagers start pushing builds into upstream, so my Fedora and Debian releases see them.
I wonder when packagers start pushing builds into upstream, so my Fedora and Debian releases see them.
Ubuntu Trusty (14.04) packages Flac 1.3.0, so I bet it's in Sid at the very least. I don't know about Fedora, though.
Interesting.
The speed of encoding for the new alpha x64 build is now on par with FLACUDA/FLACCL.
foobar2000's converter w/ 8 threads:
FLACCL -6
FLAC (x64 alpha build) -8
Ivy Bridge quad-core i7, HD4000 graphics.
Interesting.
The speed of encoding for the new alpha x64 build is now on par with FLACUDA/FLACCL.
That depends very much on the ratio CPU-speed/GPU-speed of course.
On the flac-dev mailinglist itself, some performance checks have been posted as well.
http://www.audiograaf.nl/misc_stuff/FLAC-p...nux-GCC-4.8.pdf (http://www.audiograaf.nl/misc_stuff/FLAC-performance-test-Linux-GCC-4.8.pdf) (system specs here: http://lists.xiph.org/pipermail/flac-dev/2...ly/004889.html (http://lists.xiph.org/pipermail/flac-dev/2014-July/004889.html))
This shows speedups around 60%
74 minutes album, flac -8, on a mobile Core i7 CPU @ 2.2 GHz:
99.81 seconds with 1.3.0, 52.69 seconds with git. That's insane
Can't edit my post #79 (http://www.hydrogenaud.io/forums/index.php?showtopic=101082&view=findpost&p=865196) above (some mod please delete it), so here's the updated list... yowzer.
system: i7-3770, 16gb ram, win8pro-x64
test method: flac.exe -8 input.flac -o output.flac
flac 1.3.0 binaries: http://www.hydrogenaudio.org/forums/index.php?showtopic=101082
________________________________________________________________________________
input: bytes file MD5 fb2k verification MD5
flac 1.2.1, 3h22m, 44.1kHz/16bit/2ch 1,708,858,410 1092139DA14A43C016F614A1A070598C FC2B730F57920D49D4E41604FE14A623
________________________________________________________________________________
results: time ratio bytes file MD5 fb2k verification MD5 flac.exe MD5
1.3.0-case-x32 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4ADD826644D303B57D220F866C67292B
1.3.0-case-x32-fb2k 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4ADD826644D303B57D220F866C67292B
1.3.0-flacfrontend21-x32 2:49 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 8C4AE54CE1B243904CEAB30575534FB3
1.3.0-flac-git-3194829-x32 1:57 0.988 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 3B67802CC3D2BD4572B9466763BF2E21
1.3.0-flac-git-3194829-x64 1:53 0.988 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 27924BE6762C8CEC06CE811DF0513ECA
1.3.0-john33-x32 2:52 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 C31C314E8C1E8DC62EE0CDBE048C6112
1.3.0-john33-x64 2:38 0.998 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 29546F37C3EB364155FADD43EC570DED
1.3.0-lamedude-sse1-x32 2:53 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 F08E20ADF2042919CA3BF8305E36CFF6
1.3.0-lamedude-sse2-x32 2:47 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 6C52EEA53F27CFEC697632194AA4D5D5
1.3.0-lamedude-x64 2:58 0.998 1,705,098,763 49D7D89FAD8335F339915F7FED0C1265 FC2B730F57920D49D4E41604FE14A623 174360529CEBF9371B41019D46F1FDC4
1.3.0-lrn-mingw32-x32 3:18 0.998 1,705,098,763 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E87DC0158474E662637886797F36C0DA
1.3.0-lrn-mingw32-o2-x32 2:52 0.998 1,705,098,763 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E0D5DAE8EF9BA49D0822901FE5D114A6
1.3.0-lrn-mingw32-o2-core2-x32 2:45 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 4D650372DBDB65DCC76E34DBAA42FB8F
1.3.0-wcd-x32 4:00 0.998 1,705,099,033 9BE9ABC5283909DC0F08A822F0B8FF46 FC2B730F57920D49D4E41604FE14A623 E5639F8BABD64836B85B4DB119279A7B
1.2.1-official-x32 3:12 0.998 1,705,099,033 2BA84F8B1B5514BE4BED536F341875C7 FC2B730F57920D49D4E41604FE14A623 16344C45643E41544A5C1C926A109C9F
1.2.1b-official-x32 3:15 0.998 1,705,099,033 2BA84F8B1B5514BE4BED536F341875C7 FC2B730F57920D49D4E41604FE14A623 B8396749F374C9F48CBE3B16C5333D49
john33-x64 compile of 1.3.0 still has the fastet RG scanning with metaflac. No science but 5GB scanned in 1.06min against 1.12min with git x64.
I hope they start thinking about tagging a release soon because these improvements are definitely worth it.
They are thinking of a 1.3.1: "This fix alone is worth a new release so its time to work towards one. (http://lists.xiph.org/pipermail/flac-dev/2014-June/004761.html)"
It would probably be useful if people gave this Git a good grilling and report any issues here or on the mailing list.
Hello guys,
Could you please test this one (http://aiz.free.fr/flac-git-7251201-win32.zip), it looks pretty good for a win32 compile.
-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-
Configuration summary :
FLAC version : ........................ 1.3.0
Host CPU : ............................ i686
Host Vendor : ......................... pc
Host OS : ............................. mingw32
Compiler is GCC : ..................... yes
GCC version : ......................... 4.9.0
Compiler is Clang : ................... no
SSE optimizations : ................... yes
Asm optimizations : ................... yes
Ogg/FLAC support : .................... no
Quick test:
Command: flac.exe -8
CPU: Intel e7200@2.86GHz
CD Image: 44.1/16/Stereo, 58:44
GrieverV git 3194829 64bit: ~50.20s
GrieverV git 3194829 32bit: ~57.68s
john33 1.3.0 32bit: ~83.97s
AiZ git 7251201 32bit: ~51.05s
Thanks,
AiZ
I hope they start thinking about tagging a release soon because these improvements are definitely worth it.
They are thinking of a 1.3.1: "This fix alone is worth a new release so its time to work towards one. (http://lists.xiph.org/pipermail/flac-dev/2014-June/004761.html)"
It would probably be useful if people gave this Git a good grilling and report any issues here or on the mailing list.
That's awesome news! I'm not sure how I missed that on their mailing list.
Hello guys,
Could you please test this one (http://aiz.free.fr/flac-git-7251201-win32.zip), it looks pretty good for a win32 compile.
-snip-
Thanks,
AiZ
It's nice to see MSVC compiles are comparable to GCC and vice versa. 64bit builds would be nice to see since the 32bit is nearly the speed of the MSVC 64bit.
I'd be wary of using GCC 4.9.0. I've seen a few projects (FFmpeg, Musl) that have had some serious issues with it.
FLAC git 3194829 (https://git.xiph.org/?p=flac.git;a=commit;h=31948291a230685ee12af88c35d53a671e0d968f) win32 and x64 compiles:
win32 (http://www.mediafire.com/download/fl2xnsglsjpmssv/flac-git-3194829-win32.zip), x64 (http://www.mediafire.com/download/cjcg1a1d12o7nah/flac-git-3194829-x64.zip)
Built using MSVC 2013 Update 3 RC using the Windows XP toolset (v120_xp)
I decided to use the latest FLAC git instead of 1.3.0 due to various Windows/MSVC support improvements.
You can browse FLAC's git repository and view all the changes since 1.3.0 here: https://git.xiph.org/?p=flac.git;a=summary (https://git.xiph.org/?p=flac.git;a=summary)
I get a nice encoding speed improvement with an i5 CPU, but with an older AMD X2 4000+ it performs the same as the old 1.3.0 from last year. Is this normal?
(Always using x64 on Win7.)
FLAC git 3194829 (https://git.xiph.org/?p=flac.git;a=commit;h=31948291a230685ee12af88c35d53a671e0d968f) win32 and x64 compiles:
win32 (http://www.mediafire.com/download/fl2xnsglsjpmssv/flac-git-3194829-win32.zip), x64 (http://www.mediafire.com/download/cjcg1a1d12o7nah/flac-git-3194829-x64.zip)
Built using MSVC 2013 Update 3 RC using the Windows XP toolset (v120_xp)
I decided to use the latest FLAC git instead of 1.3.0 due to various Windows/MSVC support improvements.
You can browse FLAC's git repository and view all the changes since 1.3.0 here: https://git.xiph.org/?p=flac.git;a=summary (https://git.xiph.org/?p=flac.git;a=summary)
I get a nice encoding speed improvement with an i5 CPU, but with an older AMD X2 4000+ it performs the same as the old 1.3.0 from last year. Is this normal?
(Always using x64 on Win7.)
I'm not familiar with FLAC's codebase, but AFAICT the big gains are due to adding SSE optimizations, particularly SSE4.
You should still see a small difference between 1.3.0 and 3194829 since SSE3 support was added and I believe there were a few minor improvements.
SSE3 is a very minor improvement over SSE2 while SSE4 is a significant improvement over SSE3.
I'm not familiar with FLAC's codebase, but AFAICT the big gains are due to adding SSE optimizations, particularly SSE4.
I've seen speed improvements of >60% with an SSE2 compile (Only GCC 4.9 supports SSE 4 function multiversioning due to the introduction of some handy features for that), so I'd say these improvements are not only SSE4 related. Source: from the horse's mouth (http://lists.xiph.org/pipermail/flac-dev/2014-July/004892.html). As the mentioned AMD X2 4000+ has support for SSE3, I wonder what is causing this as well.
Still, for example a FLAC compile on the Raspberry Pi has no speed increase (might even be a very small decrease, but that's within measurement error), so all of the speedup is due to Intel x86/AMD64 related instruction sets being used more efficiently.
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).
According to http://en.wikipedia.org/wiki/SSE2#Differen...en_MMX_and_SSE2 (http://en.wikipedia.org/wiki/SSE2#Differences_between_MMX_and_SSE2) :
Although one SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: [...] and the throughput of SSE2 instructions in older x86 implementations was half that for MMX instructions. Intel addressed [...] the last problem by widening the execution engine in their Core microarchitecture in Core 2 Duo and later products.
(emphasis mine).
SSE throughput was doubled in Intel Core 2 (released in 2006) and AMD K10 (released in 2007). Older processors won't benefit much from the new SSE code.
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).
Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).
Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?
SSE2 allows you to run MMX operations on the large, 128-bit registers introduced along with SSE. (This explains only why you don't need MMX anymore when exclusively targeting platforms which support SSE2. Not sure about the SSE4.1 part.)
Hello,
After some troubles, win64 binaries (http://aiz.free.fr/flac-git-7251201-win64.zip) of latest flac.git
-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-
Configuration summary :
FLAC version : ........................ 1.3.0
Host CPU : ............................ i686
Host Vendor : ......................... pc
Host OS : ............................. mingw64
Compiler is GCC : ..................... yes
GCC version : ......................... 4.9.1
Compiler is Clang : ................... no
SSE optimizations : ................... yes
Asm optimizations : ................... yes
Ogg/FLAC support : .................... no
Quick test:
Command: flac.exe -8
CPU: Intel i5-2520M@2.5GHz
CD Image: 44.1/16/Stereo, 58:44
john33 1.3.0 32bit: ~58.21s
john33 1.3.0 64bit: ~55.44s
GrieverV git 3194829 32bit: ~43.41s
GrieverV git 3194829 64bit: ~37.13s
AiZ git 7251201 32bit: ~37.98s
AiZ git 7251201 64bit: ~34.47s
AiZ
FLAC 1.3.0 uses MMX to accelerate integer operations, and the new version uses SSE2/SSSE3/SSE4.1 (SSE4.1 - only 32-bit executable).
Interesting, why not for the 64-bit executable? Is that because of a specific difference in the architecture?
That's because SSE4.1 code isn't faster than the corresponding C code compiled for x86-64. Not sure why. Maybe SSE code is just not optimal.
It's easier to explain why SSE4.1 is faster than 32-bit code. When FLAC encodes 24-bit input files it performs:
a) int32 * int32 -> int64 multiplications
b) int64 + int64 -> int64 additions
c) int64 SHR n -> int32 shifts
d) etc.
It's easy to do them in 64-bit mode when 64-bit registers are available, but in 32-bit mode they are noticeably slower. Fortunately it's possible to perform 64-bit calculations with SSE instructions.
But the instruction for int32 * int32 -> int64 multiplication (PMULDQ) was introduced only in SSE 4.1.
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...
It should be vender_string (something like "libFLAC 1.2.1 (UTC 2007-09-17)").
As far as I know the vendor string hasn't been updated to 1.3.1pre yet as this is not an official alpha release. A few people just pulled the most recent code from Git and compiled it themselves. The vendor string shouldn't be any different between 1.3.0 and this recent Git code.
It is more likely the result of a change in compression code. Even the slightest change to the compression can make resulting audio have identical checksums while the flac files will be different.
Additionally, FLAC uses floating-point math during its analysis process. Builds using different compiler options (or different compilers!) may make slightly different encoding decisions.
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
Well, yes, of course! How else would these new versions be encoding nearly twice as fast?
While both versions produce flac files with identical md5sum, the flac files are not identical (binary compare)...
Please refer to http://xiph.org/flac/faq.html#tools__different_sizes (http://xiph.org/flac/faq.html#tools__different_sizes)
Why doesn't the same file compressed on different machines with the same options yield the same FLAC file?
It's not supposed to, and neither does it mean either encoding was bad. There are many variations between different machines or even different builds of flac on the same machine that can lead to small differences in the FLAC file, even if they have the exact same final size. This is normal.
This is applicable too for different FLAC versions.
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
Well, yes, of course! How else would these new versions be encoding nearly twice as fast?
Well, somehow I was under the impression that the SSE optimisations alone were responsible for that, my bad...
Anyway, a new version number should be considered then.
Anyway, a new version number should be considered then.
which would happen with official versions (as noted a few posts up) but as this is all against non-official versions taken straight from git, not everything has been changed like version numbers reported by the compiles, etc.
Is it safe to use the faster git builds or just stick with the official build for now?
Is it safe to use the faster git builds or just stick with the official build for now?
Checksum matches so, they are safe probably like any other build. 1.3.1 should be released soon anyway.
But it was tested less thoroughly than regular 1.3.0. What's worse, it still writes "reference libFLAC 1.3.0 20130526" to FLAC files, so it's not possible to easily find all FLAC files that were made with this version.
But it was tested less thoroughly than regular 1.3.0. What's worse, it still writes "reference libFLAC 1.3.0 20130526" to FLAC files, so it's not possible to easily find all FLAC files that were made with this version.
Yes, it would probably be a good idea to start naming anything after a release "1.3.0post" in git until an official "1.3.1pre" comes out to prevent these sort of issues. It would allow people to test git versions (a good thing) without creating flac files with untested versions that are indistinguishable from a release version (a bad thing).
Has there been changes (between the source code used for john33's compilation of flac 1.3.0 and AiZ's git version) to the flac encoding engine?
If your question is "Does FLAC 1.3.0git compress files any more efficiently than 1.3.0?" the answer appears to be no. Recompressing a 1.3.0 file results in a ratio of "1.000" according to the console output. The resulting files aren't binary-identical due to differing compilers or SSE code, but you won't gain any disk space.
AFAIK, the last version of FLAC to improve compression was 1.2.x.
The resulting files aren't binary-identical due to differing compilers or SSE code, but you won't gain any disk space.
The audio stream is binary-identical though and that's what's important. Don't confuse the two, audio stream and file with metadata and everything else.
FLAC built from git sources should make files that are bit-identical to 64-bit flac 1.3.0.
IOW:
For modes -0 ... -7: 64bit git = 32bit git = 64bit 1.3.0 = 32bit 1.3.0
For mode -8: 64bit git = 32bit git = 64bit 1.3.0 ≠ 32bit 1.3.0
(Usually. It depends on CPU and (as Octocontrabass mentioned) a compiler)
I try to increase encoding speed slightly further. Please test the attached versions (with 16-bit input files).
Also please write your CPU model name (e.g.: Intel Core i7-950).
[removed]
My speed results on Intel Core i7-4771 for encoding my test file with compression level 8:
flacA : 149.19x realtime speed
flacB : 177.15x realtime speed
flacC : 155.81x realtime speed
flacD : 186.40x realtime speed
Edit: For reference FLAC 1.3.0 runs at 91.06x realtime speed.
Intel i7 M640.
Times were taken with 7Bench's timer.exe:
timer {flac} --best test.wav
exe Global time (s) xRealtime
---------------------------------------
1.3.0 20.808 50.028
A 11.305 92.083
B 9.834 110.936
C 10.476 99.369
D 8.828 117.920
Reference 1.3.0 is current 64-bit ICL 13.0 compile from Rarewares.
Intel Q9400 @3.2Ghz
comp. level 8
86.64x AiZ git7251201 64bit
81.47x flacA
76.18x flacB
84.41x flacC
81.06x flacD
Two systems, both Win7 64. 7bench timer, --best, global time (seconds).
Intel i5-750
------------
flacA 43.339
flacB 36.779
flacC 40.015
flacD 33.449
1.3.0-icl 74.049
git-3194829 44.244
git-7251201 38.931
AMD X2 4000+
------------
flacA 135.314
flacB 113.209
flacC 134.394
flacD 112.054
1.3.0-icl 139.167
git-3194829 131.929
git-7251201 129.526
(Earlier I said there was no improvement with the first git encoder on AMD. Sorry, I was testing in a different way, so the difference wasn't evident.)
Intel i7 4970K, Windows 8.1 x64
exe Global time (s) xRealtime
---------------------------------------
1.3.0 6.701 100.134
A 4.148 161.764
B 3.580 187.430
C 3.996 167.918
D 3.430 195.627
i7 3770K
flacA 21.56 s 128.10x
flacB 18.38 s 150.27x
flacC 19.88 s 138.93x
flacD 16.58 s 166.58x
flac 1.3.0 x64 Rarewares ICL13 36.79 s 75.07x
flac-git-7251201-win64 (AiZ, post #106) 19.81 s 139.49x
P.S. oops, compression level 8
Thank you all.
So, flac_D is ~20% faster than flac_C on Core i and Athlon X2. But on Core2 it's 4% slower.
Anyone with Bulldozer/Piledriver?
c2d e6850, flac -8
flac 1.3.0 8.159
flacA 6.398
flacB 6.014
flacC 5.936
flacD 6.017
Congratulations, these are quite dramatic speed improvements over v1.2.1. Is there a chance you could add additional compression levels, i.e. like FLACCL which offers additional compression up to level 11? Now that would be terrific.
These are are quite impressive speed improvements!
I think it would be interesting to see if there are known compression improvements that were previously ruled out because of their detrimental effect on speed. If some of the current speed improvements could be traded against some compression improvements you'd have the best of both worlds. 1.3.1 would still be quicker than 1.3.0 but also compress better.
>Anyone with Bulldozer/Piledriver?
Yes - AMD A6-6400K
=== flacA -8 -f test.wav ===
Execution time: 3.972 s / 95.9x
=== flacB -8 -f test.wav ===
Execution time: 3.641 s / 101.4x
=== flacC -8 -f test.wav ===
Execution time: 3.756 s / 98.2x
=== flacD -8 -f test.wav ===
Execution time: 3.449 s / 107.0x
=== flac (Rarewares ICL 32bit) -8 -f test.wav ===
Execution time: 6.988 s / 52.8x
Since the results for core2 were different than the rest, I decided to test on mine:
Mobile Core 2 Duo 1.5GHz (T5250). 667MHz DDR2 , Windows 7 x64.
Measured with measure-command of windows powershell
CD image length 1:13:50 (4430 sec), flac -8 -f file.wav
flaca TotalSeconds : 153,9725606 28.771x
flacb TotalSeconds : 152,377362 29.072x
flacc TotalSeconds : 153,347153 28.888x
flacd TotalSeconds : 152,9806216 28.958x
flac 1.2.1 TotalSeconds : 197,4928717 22.431x
Not sure if this will make it better or worse for the decision.
I try to increase encoding speed slightly further. Please test the attached versions (with 16-bit input files).
Also please write your CPU model name (e.g.: Intel Core i7-950).
lvqcl, please, can you compile and upload 64-bit test executables?
Anyone with Bulldozer/Piledriver?
FX-8350, SSD > SSD, Album duration 56:06.733:
FLAC 1.3.0
52.21, 52.15, 52.09, 52.54, 52.18: 52.23 seconds, 64.46x.
FLACA
31.26, 31.31, 31.11, 31.09, 31.32: 31.21 seconds, 107.87x.
FLACB
29.14, 28.68, 29.06, 28.98, 29.00: 28.97 seconds, 116.21x.
FLACC
29.75, 29.92, 29.86, 30.00, 29.88: 29.88 seconds, 112.68x.
FLACD
27.65, 27.62, 27.55, 27.60, 27.59: 27.60 seconds, 121.98x.
There are speed improvements for decoding too. Post #93 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=869606)
Decoding speed is four times more faster than encoding (-8) but speed optimization make sense there too as in case like FLAC to FLAC, FLAC to MP3 or similar encoding.
Some results for decoding of FLAC -8 files:
i7 3770k
flac 1.3.0 x64 Rarewares ICL13 - 516.25x
flacD - 643.81x
flac-git-7251201-win64 (AiZ, post #106) - 673.64x
Thanks all!
They should show the same behavior (if 32-bit flac_D is fastest then 64-bit flac_D will be faster among other 64-bit versions). But... here they are.
FX-8350, SSD > SSD, Album length 56:06.733:
FLAC64_a
28.50, 27.89, 27.68, 27.58, 27.62, 27.85 seconds, 120,89x.
FLAC64_b
24.90, 26.03, 25.07, 25.09, 24.99, 25.02 seconds, 134.56x.
FLAC64_c
26.47, 26.24, 26.13, 26.34, 26.40, 26.32 seconds, 127.92x.
FLAC64_d
23.79, 23.73, 23.67, 23.77, 23.73, 23.74 seconds, 141.82x.
Intel Pentium G2130, 4GB RAM, Intel 330 SSD, Windows 7 64bit
44.1KHz/16bit stereo .wav file. Length: 1:11:17
Exec. Time(s) Speed x realtime
====================================
flacA 40.2 106.4x
flacB 34.2 125.1x
flacC 36.7 116.5x
flacD 30.8 138.9x
flac64_a 37 115.6x
flac64_b 31.2 137.1x
flac64_c 34.2 125.1x
flac64_d 28.8 148.5x
AMD Phenom II X4 970, level8, single thread in foobar.
==== 32-bit ====
flacA 87x
flacB 102x
flacC 87x
flacD 106x
==== 64-bit ====
flacA 93x
flacB 113x
flacC 94x
flacD 114x
For reference, libflac 1.2.1 at same settings = 55x
How do you guys take your measurements? I just picked the average of the values foobar showed while encoding.
How do you guys take your measurements? I just picked the average of the values foobar showed while encoding.
I use http://www.gammadyne.com/cmdline.htm#timer (http://www.gammadyne.com/cmdline.htm#timer) and a very simple batch file
timer
flac.exe -8 -f file.wav
timer /s
The timer executable outputs the total time taken for the commands between the two times its called. Divide the source wave time with the running time and you get the speed multiplier. I repeat the process 2 or 3 times until encoding times are stabilized (primed CPU caches etc) for each executable. I keep the batch file open in notepad+ and change which executable I want to run quickly.
I use timer32/timer64 from 7benchmark: http://sourceforge.net/projects/sevenmax/files/7-Benchmark/ (http://sourceforge.net/projects/sevenmax/files/7-Benchmark/)
Intel Q9400 @3.2Ghz
comp. level 8
same sample
86.67x flac64A
87.11x flac64B
90.48x flac64C
87.59x flac64D
Ok, here is what it looks like when timed with timer64 (took 3 attempts -> averaged). File is 7:35,293 -> 455,293 seconds. AMD Phenom II X4 970, as above.
32bit:
flac 1.2.1 9,094s 50,1x
flacA 5,504s 82,7x
flacB 4,543s 100,2x
flacC 5,526s 82,4x
flacD 4,557s 99,9x
64bit:
flacA 5,054s 90,1x
flacB 4,150s 109,7x
flacC 5,064s 89,9x
flacD 4,154s 109,6x
I'm liking build B, though build D is only marginally slower. I also ran a comparison on a folder containing 5:54:53 of music between flac 1.2.1, flacD and flaccl (nVidia 260GTX), running them at 4 threads via foobar
flac 1.2.1 2:15 157,7x
flaccl 1:18 272,9x
flacD x64 1:10 304,2x
That's.... impressive!
Now if only we could cut some of that speed and make it compress as good as TAK does...
edit: formatting
I'm liking build B, though build D is only marginally slower.
I think it's just a measurement error.
Speaking of measurement errors... I noticed with the 7bench timer it's better to look at process time instead of global time, since the latter is much more affected by other processes running on the computer at the same time. At least on my old system (AMD X2 4000+) it can skew the results, even if I leave it alone when running.
And I confirm an overall improvement with the 64bit builds.
Interesting. Benching same file with same settings today takes me half a second longer. Have repeated it a few times now, so not a caching issue.
For me, process time and global time seem to keep the hierarchy. But I'm not doing anything except playing music while benching, so I guess I have nothing to influence the times.
Also, the values fluctuate between D being faster:
64bit:
flacA 5,478s 83,1x
flacB 4,515s 100,8x
flacC 5,447s 83,6x
flacD 4,395s 103,6x
and them being nearly same speed:
64bit:
flacB 4,546s 100,1x
flacD 4,536s 100,3x
Speaking of measurement errors... I noticed with the 7bench timer it's better to look at process time instead of global time
Good point. In *nix environments, there's the time command for this purpose (i.e., you can run something like "time ./a.out").
I googled for a Windows equivalent. It seems there isn't one. A few people on stackoverflow and such suggested using a command that's only available in the powershell (which i don't have on my system.)
i7 4930K, Windows 8.1 x64
Encoder Global time (s) xRealtime
--------------------------------------------
v1.2.1 x32 7.403 100.346
Flac_A x32 4.156 177.333
Flac_B x32 3.590 205.292
Flac_C x32 3.893 189.314
Flac_D x32 3.226 228.456
Flac_A x64 3.830 192.428
Flac_B x64 3.320 221.987
Flac_C x64 3.556 207.255
Flac_D x64 3.040 242.434
I'm liking build B, though build D is only marginally slower. I also ran a comparison on a folder containing 5:54:53 of music between flac 1.2.1, flacD and flaccl (nVidia 260GTX), running them at 4 threads via foobar
flac 1.2.1 2:15 157,7x
flaccl 1:18 272,9x
flacD x64 1:10 304,2x
That's.... impressive!
Now if only we could cut some of that speed and make it compress as good as TAK does...
edit: formatting
What compression level did You set for flaccl? flaccl -6 compresses as good as FLAC -8. And flaccl -6 still should be faster than flaccl -8
I think speed comparison should be done with settings that produce a same compression ratio.
My rationale for that comparison was "max compression while staying subset compatible". Besides, that one is only true for my old GPU, it's not to be interpreted as flaccl being slower than libflac.
Though if flaccl compresses better, how does it manage to stay within the subset? I think changing the presets of libflac (or adding a "max" one) so that it matches flaccl is worth a thought.
CD Image: 44.1/16/Stereo, 1h:15m:48s
CPU: Core i5 3210M @ 2.50GHz
flac-1.2.1b (-8) 96.1s 47.33x
flac-1.3.0-icl(john33) (-8) 82.9s 54.86x
flac-git-7251201-win32(AiZ) (-8) 45.6s 99.74x
flacA_x32 (-8) 45.5s 99.96x
flacB_x32 (-8) 38.9s 116.92x
flacC_x32 (-8) 41.8s 108.80x
flacD_x32 (-8) 35.0s 129.94x
BUT, to put that into perspective:
wavpack_4.70.0 (hhx) 65.2s 69.75x
wavpack_4.70.0 ( ) 22.1s 205.79x! (same size as flac)
Takc_2.3.0 (pMax) 95.0s 47.87x
Takc_2.3.0 (p0e) 10.7s 425.05x! (same size as flac)
According to my tests, compression ratio of wavpack (@default settings) is closer to flac -5 than to flac -8. And flac -5 encoding speed (on your CPU) will probably be around 300x.
Intel Core2 6600 @ 2.40 GHz
Measured with timer64 on a RAMdisk
16bit/44.1kHz 3:40:10.093 (582565116 samples)
flacA 76.206 173.34x
flacB 75.956 173.92x
flacC 76.112 173.56x
flacD 75.925 173.99x
flac64_A 74.006 178.50x
flac64_B 72.836 181.67x
flac64_C 74.022 178.47x
flac64_D 72.618 181.91x
Though if flaccl compresses better, how does it manage to stay within the subset? I think changing the presets of libflac (or adding a "max" one) so that it matches flaccl is worth a thought.
FLACCL -6 is similar to FLAC -8
FLACCL -8 is similar to FLAC -8 + very slow settings which have very slight impact on compression. Settings are: flac -8 -A tukey(0.5) -A flattop. Compression gain is very small, less than 1% ( ~0.11%)
Hi guys,
I know I'm a bit late to the party, but here are my results for the 8 binaries for setting -0 through -8 for both encoding as well as decoding. The scripts are very similar to the lossless codec comparison (http://www.audiograaf.nl/downloads.html) I did some time ago, these results are from a AMD A4-3400 with Windows 7.
(http://www.audiograaf.nl/misc_stuff/lvqcl-test-enc.png)
(http://www.audiograaf.nl/misc_stuff/lvqcl-test-dec.png)
I think the small differences for the 32-bit compiles considering decoding are within measurement error. For each 'row', the topmost is -0, the lowest is -8
Bug? Using the -p option results in much larger files than without p (up to 2% larger!). This doesn't seem to happen when I use a blocksize of 512. I haven't tested it on many input files yet, so it might be limited to my input files -- more testing is needed.
This has just been fixed in git: http://git.xiph.org/?p=flac.git;a=commit;h...ad99baa1ca24c49 (http://git.xiph.org/?p=flac.git;a=commit;h=27846708fe6271e5e3965a4bbad99baa1ca24c49)
Anybody have AMD Athlon CPU? Athlon, AthlonXP, Athlon64... Please test encoding speed of the attached encoders, for both -8 and -5 presets.
[removed]
Same sample as my other ones, on an athlon XP 2400+, running a clean winXP SP3
32bit -5:
flac 1.2.1 8,468s 53,8x
flac32_a 7,562s 60,2x
flac32_n 7,218s 63,1x
flac32_s 7,281s 62,5x
32bit -8:
flac 1.2.1 21,437s 21,2x
flac32_a 18,234s 24,9x
flac32_n 17,609s 25,9x
flac32_s 18,187s 25,0x
Does anyone use such a system for everyday use? I just reactivated me ol' faithful to test it as doing anything else on it is pretty much impossible...
Good to see the decoding speed improving a little too. Years ago we used libflac for decoding in rockbox, but we switched to ffmpeg because their decode was an order of magnitude faster. It something like doubled battery life on ARM devices playing FLAC files. Improving the decoder would probably help various other portable devices that use the official source.
so, which one is the fastest ?
also, the flac quality has something to be with the speed ?
Same sample as my other ones, on an athlon XP 2400+, running a clean winXP SP3
Thanks!
Does anyone use such a system for everyday use?
[offtopic] Some even want to run Google Chrome (https://plus.google.com/+ToddVierling/posts/EDw83Qnkxzh) on them [/offtopic]
CD Image: 44.1/16/Stereo, 40m:48s
CPU: AMD Athlon XP 3200+ @ 2.20GHz
flac-1.2.1b (-5) 26.9s 91.00x 202MB
flac32_a (-5) 23.5s 104.17x 202MB
flac32_n (-5) 21.7s 112.81x 201MB
flac32_s (-5) 23.2s 105.52x 202MB
flac-1.2.1b (-8) 92.8s 26.38x 198MB
flac32_a (-8) 76.8s 31.88x 198MB
flac32_n (-8) 73.8s 33.17x 197MB
flac32_s (-8) 76.5s 32.00x 198MB
wavpack_4.70.0 ( ) 23.8s 102.86x 201MB
wavpack_4.70.0 (h) 33.3s 73.51x 196MB
wavpack_4.70.0 (hhx) 85.6s 28.60x 190MB
Takc_2.3.0 (p0) 8.4s 291.43x 204MB
Takc_2.3.0 (p0e) 12.7s 192.76x 188MB
Takc_2.3.0 (pMax) 159s 15.40x 174MB
Athlon64 X2 4000+, Win7
encoder (-8) process time (s) ~realtime (x)
----------------------------------------------------
flac32_a 116.797 35.6
flac32_n 112.149 37.1
flac32_s 116.017 35.9
flacA 130.728 31.8
flacB 109.341 38.0
flacC 130.666 31.8
flacD 108.685 38.3
encoder (-5) process time (s) ~realtime (x)
----------------------------------------------------
flac32_a 37.674 110.4
flac32_n 34.772 119.6
flac32_s 37.767 110.1
flacA 42.213 98.5
flacB 40.045 103.9
flacC 42.026 99.0
flacD 40.092 101.7
(timer64 [flac] [-8/-5] image.wav -f)
(image.wav 16/44.1, t = 4160s)
flac32_n uses 3DNow, while flac32_s uses SSE. FLAC prefers SSE over 3dNow, so I thought that flac32_s will be faster.
But for Athlons XP and Athlons 64 it's actually slower. That was unexpected.
Not sure about Phenoms though... maybe SSE is faster for them.
Here are another 3 encoders: one uses 3DNow, another uses SSE, and the 3rd uses new code for SSE (hopefully faster).
CD Image: 44.1/16/Stereo, 40m:48s
CPU: AMD Athlon XP 3200+ @ 2.20GHz
flac_3dnow (-5) 23.1s 105.97x
flac_oldsse (-5) 23.1s 105.97x
flac_newsse (-5) 22.0s 111.27x
flac_3dnow (-8) 76.1s 32.17x
flac_oldsse (-8) 76.1s 32.17x
flac_newsse (-8) 74.3s 32.95x
flac_newsse.exe is faster, but flac_3dnow.exe is slower than flac32_n.exe.
flac_newsse.exe is faster, but flac_3dnow.exe is slower than flac32_n.exe.
That's because I uploaded wrong flac_3dnow.exe file, sorry.
Athlon64 X2 4000+
encoder (-5) process time (s) ~realtime (x)
----------------------------------------------------
flac_3dnow_v2 37.081 112.2
flac_oldsse 40.544 102.6
flac_newsse 37.128 112.0
encoder (-8) process time (s) ~realtime (x)
----------------------------------------------------
flac_3dnow_v2 105.784 39.3
flac_oldsse 109.965 37.8
flac_newsse 105.659 39.4
(Side note: is there a simple way to format/align these columns? Pasting from Notepad works just partly.)
3dnow and newsse are the fastest I've seen so far on AMD, with the exception of flac32_n, which is the fastest at compression -5 (I double checked).
32bit athlon XP2400+, -5:
flac 1.2.1 8,468s 53,8x
flac32_3dnow 7,203s 63,2x
flac32_sse_old 7,578s 60,1x
flac32_sse_new 7,312s 62,3x
32bit athlon XP2400+, -8:
flac 1.2.1 21,437s 21,2x
flac32_3dnow 17,484s 26,0x
flac32_sse_old 18,031s 25,3x
flac32_sse_new 17,609s 25,9x
Ran three times, one time 3dnow needed half a second less on -5 preset, but i wrote it off as measurement error. Others stayed within a +/-100ms margin
CD Image: 44.1/16/Stereo, 40m:48s
CPU: AMD Athlon XP 3200+ @ 2.20GHz
flac_3dnow_v2 (-5) 21.2s 115.47x
flac_oldsse (-5) 23.1s 105.97x
flac_newsse (-5) 22.0s 111.27x
flac_3dnow_v2 (-8) 74.2s 32.99x
flac_oldsse (-8) 76.1s 32.17x
flac_newsse (-8) 74.3s 32.95x
All similar results I see.
Encoding speed on Intel Core i7-950
flac -5:
old sse: 294.1x
new sse: 314.8x (+7%)
flac -8:
old sse: 125.0x
new sse: 128.4x (+2.7%)
Encoding speed on Intel Core i7-950
flac -5:
old sse: 294.1x
new sse: 314.8x (+7%)
flac -8:
old sse: 125.0x
new sse: 128.4x (+2.7%)
my results different
Intel Q9400 @3.2Ghz
comp. level 8
same sample
81.47x flac_oldsse
78.74x flac_newsse
Was it an expected behaviour that the 3dnow_v2.exe could run on an intel core2? i.e. does this concrete version already have branches depending on cpu? the time was comparable to flacD.
Said that, one strange thing happened: In my inital test, all flacx encodes were between 152 and 153 seconds. When i ran flacd again after testing 3dnow, i obtained 149 seconds. So, this deviates more than the different between the runs of the codecs. Maybe the hard drive had more influence in the test than what I expected. Cache should not play a role, since i'm taking about a 700+ MB .wav, and this laptop has only 2GB of RAM.
Was it an expected behaviour that the 3dnow_v2.exe could run on an intel core2? i.e. does this concrete version already have branches depending on cpu? the time was comparable to flacD.
If 3dnow is not available then '3dnow_v2' should be equal to 'oldsse'.
Didn't realize the AMD test set had valid tests for Intel too. On i7-4771:
flac -5 -s -c image.wav >nul:
oldsse 425.86x realtime
newsse 454.76x realtime
flac -8 -s -c image.wav >nul:
oldsse 176.06x realtime
newsse 177.82x realtime
Too late for the game?
Where can I download flacABCD?
They have been removed, as the tests were concluded and the relevant patch merged
Is flac_newsse now the fastest version for Intel i5-4670 cpu?
How about x32 vs x64?
I still have the files from the tests, but since lvqcl removed them I have to assume he might not want them available here.
For me on Intel (i5-750) the fastest was flac64_d.
And 64bit was faster than 32bit.
I have to assume he might not want them available here.
Those binaries should only ever be used for testing purposes. If you want a faster binary, *please* be patient and wait for the upcoming release, of which the source code will have been thoroughly tested.
Yes, I totally understand.
Just wish that I won't miss the party again.
Yes, I totally understand.
Just wish that I won't miss the party again.
You don't have to be sad. Maybe you did miss that one http://www.hydrogenaud.io/forums/index.php?showtopic=106545 (http://www.hydrogenaud.io/forums/index.php?showtopic=106545)
Many things you can benchmark till no sun shines. The forthcoming flac will be a real improvement.
Bench different apodizers, search methods, speed against compression, bring in flake and flacCL....
32- and 64-bit exe files built from the current code (15 Oct 2014):
Just wondering, is there a date/amount of new extras the code has to accumulate to warrant a new version?
Just wondering, is there a date/amount of new extras the code has to accumulate to warrant a new version?
18 Jun 2014: http://lists.xiph.org/pipermail/flac-dev/2...une/004761.html (http://lists.xiph.org/pipermail/flac-dev/2014-June/004761.html)
32- and 64-bit exe files built from the current code (15 Oct 2014):
Pink Floyd - Discovery Box Set (14 albums), converting with foobar2000 1.3.4 on i7-2700k
FLAC 1.3.0 (Case): Total encoding time: 3:36.563, 201.33x realtime
FLAC (flac-e0fbe71.exe, lvqcl) x64: Total encoding time: 1:24.969, 513.15x realtime
Wow, thanks very much for the patches and for integrating all the improvements, now let's wait for an official 1.3.1 release.
Encoded all my Benassi CDs (3.11gb), on a laptop with SSD and i7-4700MQ, using Foobar.
1.3.0 john33 64bit: x255
git lvqcl 64bit: x630
Stunned.
damn you all and your fancy cpu instructions.
on a single core athlon64 i get a 4% increase (assuming the result is repeatable - i only tested one album)
flac 1.3.0 foobar2000 encoder pack level 8: Total encoding time: 2:09.781, 23.91x realtime
flac lvqcl level 8: Total encoding time: 2:04.625, 24.90x realtime
damn you all and your fancy cpu instructions.
Indeed
3:23:55 of .tak files over gigabit LAN -> flac using foobar2000 with 4 threads:
flac-1.3.0: ~147,4x - 1:23
flac-git: ~254,9x - 0:48
CPU: Phenom II X4 970
edit: same set of files, but this time wav (ramdisk) -> flac (ramdisk)
flac-1.3.0: ~167,6x - 1:13
flac-git: ~339,9x - 0:36
Here's my poor music playing little fanless SSD-equipped Atom at full steam:
flac.exe -f -8 The_Gathering-Echoes_Keep_Growing_-Edit-.wav
7.4x realtime (50.3 sec) with flac 1.2.1
8.4x realtime (44.6 sec) with http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip (http://www.saunalahti.fi/~cse/temp/flac-1.3.0-win32.zip)
and a mighty
14.6x realtime (25.6 sec) with flac-e0fbe71.exe.7z
First and last repeated for sanity checking. Fairly stable.
flac.exe -t The_Gathering-Echoes_Keep_Growing_-Edit-.flac
Quite unstable results likely due to background processes, tested a handful of time each and reporting best results: respectively,
5.9 sec, 5.0 and 3.7 sec.
Stop whining over yer > 20x realtime figures!
Kindly,
the fourth Yorkshireman
However it uses much more RAM than before.
For instance, when encoding a 453 MB file using FLAC -6 with Flac-e0fbe71 by lvqcl then Timer32 reports:
Virtual Memory = 15 MB
Physical Memory = 12 MB
Whilst Flac 1.3.0 versions by Case, by LRN and by Rarewares are all reporting:
Virtual Memory = 4 MB
Physical Memory = 2 MB
However it uses much more RAM than before.
Yes, that is correct. That is only the case with Windows though. It is an added buffer to reduce disk fragmentation.
See these thread for more information
http://lists.xiph.org/pipermail/flac-dev/2...ber/005081.html (http://lists.xiph.org/pipermail/flac-dev/2014-September/005081.html)
http://lists.xiph.org/pipermail/flac-dev/2...ber/005094.html (http://lists.xiph.org/pipermail/flac-dev/2014-September/005094.html)
Does the git version already include re-tuned presets/new apodization functions? I'm seeing a minimal increase in filesize at -8
Does the git version already include re-tuned presets/new apodization functions?
No, it does not. I sent the patch for inclusion only yesterday.
edit: to be more specific, it does include the apodization functions, but they aren't used by default yet.
I see. I wonder why my 2GB set of wav files encoded with the git version are 3862 byte bigger than with 1.3.0 though. Not like it's a huge discrepancy
I see. I wonder why my 2GB set of wav files encoded with the git version are 3862 byte bigger than with 1.3.0 though.
Probably the metadata written is slightly different or http://xiph.org/flac/faq.html#tools__different_sizes (http://xiph.org/flac/faq.html#tools__different_sizes)
I see. I wonder why my 2GB set of wav files encoded with the git version are 3862 byte bigger than with 1.3.0 though.
Probably the metadata written is slightly different or http://xiph.org/flac/faq.html#tools__different_sizes (http://xiph.org/flac/faq.html#tools__different_sizes)
I tried the old John33 64bit and lvqcl's 64bit compiles with my old frontend that writes own metadata and 30 cds came out exactly in the same size.
Again i am really impressed what you did to the code lvqcl alone from looking over the mailing list. A place in the flac Hall Of Fame is well deserved.
Just thinking aloud:
For those of us who are a bit reluctant to using experimental builds for encodings meant to last forever: I assume there would be security added by decoding for verification with a different build? (Protecting against the case where new code makes "same" errors on encoding and decoding.) Is that necessary? Feasible?
Just thinking aloud:
For those of us who are a bit reluctant to using experimental builds for encodings meant to last forever: I assume there would be security added by decoding for verification with a different build? (Protecting against the case where new code makes "same" errors on encoding and decoding.) Is that necessary? Feasible?
FLAC stores the MD5 hash of the original stream in its STREAMINFO block, so a broken encoder will manifest as a file that passes all the frame checksum verifications but has an MD5 mismatch at the end. It should be easy enough to check the unlikely event of the decoder miscalculating the MD5 hash by piping its raw PCM output to an external md5sum program and comparing it to the contents of STREAMINFO.
FLAC stores the MD5 hash of the original stream in its STREAMINFO block, so a broken encoder will manifest as a file that passes all the frame checksum verifications but has an MD5 mismatch at the end.
Not if the error is implementing the wrong algorithm. For both encoding and decoding. Then it will consistently decode
its own files to the original signal even though it by specification should mean something else.
Suppose you "encode" your language to contemporary American English, not knowing that you were supposed to encode to some older specification of British English. You translate "homosexual" to "gay", and when you translate it back, it will be ... "homosexual". Fine, it verifies! But now you send your encoded file to someone who uses the Reference Decoder, to which "gay" means "happy". There is no way you can detect that error from within your own algorithm, because you have - effectively - written a perfectly working encoder-decoder for
a different codec.
Not if the error is implementing the wrong algorithm. For both encoding and decoding. Then it will consistently decode its own files to the original signal even though it by specification should mean something else.
Since the specification hasn't changed in some time, just verify your files encoded by 1.3.0 against an earlier FLAC version such as 1.2.1.
Is that necessary?
The encoder and decoder share quite some code, for example, calculating the residual from the LP coefficients is done with the same functions for both encoding and decoding. If something is wrong with these functions, encoding and decoding will indeed make the same error. For this reason, during the testing period for FLAC 1.3.0, I ran the test suite with FLAC as an encoder and ffmpeg and older versions of FLAC as a decoder. This had the added benefit of catching some cornercases in which the ffmpeg decoder didn't work properly.
If you want to do this yourself to verify your build, change the file test_streams.sh in the directory test. There is a subroutine called test_file().
echo -n "decode..."
cmd="run_flac --silent --force --endian=little --sign=signed --decode --force-raw-format --output-name=$name.cmp $name.flac"
You can change that run_flac command to use a different binary or even ffmpeg.
In general, I would just disencourage using unstable code in production.
Thanks for enlightening!
Tuffy: that was my point exactly.
What would be the fastest available Windows compile of flac.exe for FLAC file testing (flac.exe -t) purposes? This would be run on a 64-bit Windows system.
What would be the fastest available Windows compile of flac.exe for FLAC file testing (flac.exe -t) purposes? This would be run on a 64-bit Windows system.
http://www.hydrogenaud.io/forums/index.php...st&p=877721 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=877721)
If you want to test the new presets with improved compression you should get a fresh build as the patch for that only just landed.
https://git.xiph.org/?p=flac.git;a=commit;h...a0e1270b850b0a9 (https://git.xiph.org/?p=flac.git;a=commit;h=02891daa7a88bf963fab6511aa0e1270b850b0a9)
If you want to test the new presets with improved compression you should get a fresh build as the patch for that only just landed.
https://git.xiph.org/?p=flac.git;a=commit;h...a0e1270b850b0a9 (https://git.xiph.org/?p=flac.git;a=commit;h=02891daa7a88bf963fab6511aa0e1270b850b0a9)
lvqcl, can you make a new build with the last git? Your last one was perfect. Thanks.
Not quite the latest git (I changed its vendor string, etc), but... here it is.
Not quite the latest git (I changed its vendor string, etc), but... here it is.
Thanks but I'll skip the alpha-pre tag I have OCD for these kind of things, I know your last build is not the "reference libFLAC 1.3.0 20130526" but you forgot to change it and it's FAST so I am going to keep that one for now. All my files have that string, I will wait for the new "reference libFLAC 1.3.1 ...".
Maybe if you do something like "libFLAC-git date" ...maybe.
32- and 64-bit exe files built from the current code (15 Oct 2014):
http://www.hydrogenaud.io/forums/index.php...ost&id=8051 (http://www.hydrogenaud.io/forums/index.php?act=attach&type=post&id=8051)
I seem to be getting a lot of errors reported when I use the above 32 bit and 64 bit versions. Has anyone else encountered error reports? For example, see my recent post in the uploads section:
[On another matter, I seem to be getting errors on some flac downloads. The error manifested itself in the decoded waveform for 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_17.flac by way of silence for a short segment of about 21mS commencing 1.834mS into the file. Probably an error at my end. I am querying this at post #211 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=881350) of the FLAC 1.3.0 has been released thread.]
The error reported as follows (this is copied from the command prompt window for two files that were checked using a 32-bit pc running Windows 7):-
C:\newflac>flac -t *.flac
flac 1.3.0, Copyright © 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundati
on
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_17
.flac: *** Got error code 2:FLAC__STREAM_DECODER_ERROR_STATUS_FRAME_CRC_MISMATCH
15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_17
.flac: ERROR while decoding data
state = FLAC__STREAM_DECODER_READ_FRAME
15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_2.
flac: *** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
*** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_2.
flac: ERROR while decoding data
state = FLAC__STREAM_DECODER_READ_FRAME
Perhaps flac.exe accesses some library that on my PCs is out of date. Or is it a self-contained executable?
Which CPU do you have? It's possible that new optimizations have a bug somewhere but it's also possible your CPU or memory has a fault causing miscalculations. lvqcl's compiles work fine for those files here. The flac.exe binary has no extra dll dependencies.
Also no problem here with decoding these Haydn files (tried 32-bit version @ Intel Core2 Quad Q9500).
@eahm:
I will wait for the new "reference libFLAC 1.3.1 ...
The binaries supplied by lvqcl (flac-new-20141115.7z) report this vendor string: "libFLAC 1.3.1 (UTC 2014-11-15)"
The error reported as follows (this is copied from the command prompt window for two files that were checked using a 32-bit pc running Windows 7):-
[...]
Perhaps flac.exe accesses some library that on my PCs is out of date. Or is it a self-contained executable?
This flac.exe is indeed self-contained. Can you check the MD5 of the files?
7fc463c74ccbe471ed3d307ec23a2e0c 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_2.flac
0415967ee313fc202c53ac652834983b 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_6.flac
e891c704fa107a0f7f4ef412d10c0a63 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_17.flac
If these check out, there might be a serious bug somewhere that we didn't notice yet.
edit: oh, and by the way, if you repeat the process of testing, do the same errors pop up in the same place every time you run it?
Can you check the MD5 of the files?
7fc463c74ccbe471ed3d307ec23a2e0c 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_2.flac
0415967ee313fc202c53ac652834983b 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_6.flac
e891c704fa107a0f7f4ef412d10c0a63 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_17.flac
The MD5s were very different. The files had been downloaded with a 64 bit pc. I then downloaded again, this time using a 32 bit pc, and the MD5s were as you have shown them, ktf, above. These files checked out ok using flac.exe -t on both the 32 bit and 64 bit pcs.
So I am sorry to have raised this issue.
There must be some integrity issue with how my 64 bit pc downloads files. (It's odd though as I do not ordinarily seem to have a problem with file downloads using that pc.)
Thanks to everyone for their advice! Much appreciated.
Could it be that you are running faulty hardware (like bad RAM or something)?
There must be some integrity issue with how my 64 bit pc downloads files. (It's odd though as I do not ordinarily seem to have a problem with file downloads using that pc.)
Highly likely you have a RAM stick going bad. Especially if the checksums change every few times you calculate them. I had this behavior and it simply started happening out of nowhere, so even if you don't usually have problems like these, try running some memory diagnostic (the windows built-in one should do the trick, or there is also memtest86+ (http://www.memtest.org/))
Highly likely you have a RAM stick going bad. Especially if the checksums change every few times you calculate them. I had this behavior and it simply started happening out of nowhere, so even if you don't usually have problems like these, try running some memory diagnostic (the windows built-in one should do the trick, or there is also memtest86+ (http://www.memtest.org/))
I ran the Windows memory tool on my 64-bit pc. It reported no error.
The MD5 checksums stay constant. For the three files I downloaded using my 64-bit Windows 7 pc [which uses a wi-fi connection to my router] the MD5 ckecksums are:
9b71e529534bf27cea1652eb45053f10 ...2.flac
c8c3910c5b64f94e2b66b31f68a61d3c ...6.flac
47d81d2ce9a1e966bd52b232e42a903e ...17.flac
These files all report errors when I run the flac.exe test. They all load into an audio editor, such as Audacity, but examination can reveal corruption (e.g. the patch of silence in the last file, 15_Haydn__String_Quartet_In_D__Op__76__No__5_-_Finale_-_Presto___cues_section_
17.flac).
On the other hand, for the three files I downloaded using my 32-bit Windows 7 pc [which uses an ethernet connection to my router] the MD5 checksums are as supplied by ktf above. And flac.exe (on either pc) reports all three files as ok.
So the error appears to have occurred at the time of the file downloads. A bit of a mystery, but I think I'll use my 32-bit pc for critical downloads in the future.
Cheers.
P.S. I tried a download of the three files again a moment ago with my 64-bit pc. The first file, ...2.flac, was fine, but the other two had totally new MD5's! I think I'll run the RAM check a few more times on separate occasions, in case there's an intermittent issue with the RAM.
Whether your PC is 64-bit or 32-bit makes no difference to downloading files.
P.S. I tried a download of the three files again a moment ago with my 64-bit pc. The first file, ...2.flac, was fine, but the other two had totally new MD5's! I think I'll run the RAM check a few more times on separate occasions, in case there's an intermittent issue with the RAM.
I would:
- check the file system!
- try different RAM-testing software.
- download to a different physical drive as well, and see if you can reproduce that. I've had Windows writing file segments all over the place due to errors in the file system.
- download to a different computer, and "download" from that one to the potential troublemaker. Use your browser?
I would likely also have run the files through a binary diff tool to see if they differ "at random" or somewhere specific. But frankly I have no clue what information to extract from that :-o
I would likely also have run the files through a binary diff tool to see if they differ "at random" or somewhere specific. But frankly I have no clue what information to extract from that :-o
Single-bit errors can most easily be attributed to bad RAM. Large blocks of bad data with lengths that are a power-of-two multiple of 512 are filesystem corruption, though you can't rule out bad RAM as the cause. Insertions, deletions, and large block differences that aren't a multiple of 512 are most likely to be a network issue.
where do you put this version of 64bit flac?
The only x64 binary that I am aware has been posted so far is here: http://www.hydrogenaud.io/forums/index.php...st&p=835471 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=99757&view=findpost&p=835471)
If I could figure out how to compile (win7 x64), I'd build a GCC x64 FLAC version.
One that doesn't depend on VC dll's.
It'd also be nice to see benchmarks for x64 GCC as well.
The only x64 binary that I am aware has been posted so far is here: http://www.hydrogenaud.io/forums/index.php...st&p=835471 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=99757&view=findpost&p=835471)
Am I missing something? Didn't lvqcl just post both 32 and 64-bit binaries on November 14th?
http://www.hydrogenaud.io/forums/index.php...st&p=880786 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=880786)
Not quite the latest git (I changed its vendor string, etc), but... here it is.
Am I missing something? Didn't lvqcl just post both 32 and 64-bit binaries on November 14th?
http://www.hydrogenaud.io/forums/index.php...st&p=880786 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=880786)
I wasn't sure if those were GCC or MSVC, but running them through Dependancy Walker reveals they are MSVC (and require the MSVC runtime to be installed).
(http://i.imgur.com/g5yh21t.png)
If it is linked to MSVCRT.dll then it's likely built with MinGW GCC (Recent MSVC runtimes are named differently such as MSVCR120.dll).
If it is linked to MSVCRT.dll then it's likely built with MinGW GCC (Recent MSVC runtimes are named differently such as MSVCR120.dll).
That's good to know. Time to play with some test encodees.
These (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=877721) files were built with GCC 4.9.1 and these (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=880786) were built with GCC 4.9.2.
(MSYS/MinGW-w64/GCC (http://xhmikosr.1f0.de/tools/msys/))
The official release of FLAC 1.3.1 is near and a pre-release for testing is now available (you can find the preliminary version of the changelog here (https://git.xiph.org/?p=flac.git;a=blob_plain;f=doc/html/changelog.html;h=ee9735b67db4e1fd4238dd2883c1fe75fd9ff793;hb=288edbb3a16b3b857508e2f70d0fb43091f2858f)).
It would be very useful if people could test this on various platforms and in various configurations, Windows in particular.
Hi all,
As people may have seen there's a pre-release here:
http://downloads.xiph.org/releases/flac/beta/ (http://downloads.xiph.org/releases/flac/beta/)
Specifically:
flac-1.3.1pre1.tar.xz : The source code
flac-1.3.1pre1-win.zip : Windows 32 and 64 bit binaries
Please test.
I'm particularly interested in hearing about the windows binaries
which were cross compiled from Linux to Windows. Unfortunately
there is a bug in Wine which prevents me from running either of
the testsuites. Maybe someone on windows could grab the source
and the binaries, build from source, copy the binaries into the
built flac tree and then run the tests.
Cheers,
Erik
For the curious, the binaries supplied at http://downloads.xiph.org/releases/flac/be...3.1pre1-win.zip (http://downloads.xiph.org/releases/flac/beta/flac-1.3.1pre1-win.zip) seem to have been built with GCC 4.9.1.
edit: Here's a graph comparing (http://www.audiograaf.nl/misc_stuff/compareFLAC1.3.1pre1.pdf) FLAC 1.2.1, FLAC 1.3.0 and FLAC 1.3.1pre1, compiled with GCC 4.9. The used CPU doesn't benefit from the SSE4.1 or AVX2 improvements, so newer CPUs might see an even larger encoding speed increase.
Thanks for the pre1 release. I've never thought about asking for flac but I guess I'll ask here, is there a way to delete or not write at all the "Tool" tag?
edit:
By "Tool" tag I mean this: "reference libFLAC 1.3.0 20130526". Leave it empty, write nothing when converting or remove it after the conversion.
is there a way to delete or not write at all the "Tool" tag?
Do you mean the vendor string? It's part of the vorbiscomment specification (and it's mandatory), so simply removing the VORBIS_COMMENT block will do, but you won't have any tags. If you add tags again, the vendor string is added again, but it is set to the vendor string of the tool you used to add tags to the file.
metaflac --remove --block-type=VORBIS_COMMENT file.flac
If you mean something else with tool tag, please explain.
ktf, thanks for that, I've modified my post to explain better what I'm looking for.
Here's a test I just ran testing (flac.exe -t) a set of about 150 files. To me, any increases in encoding speed and fractions of a percentage increases in compression are totally meaningless. On the other hand, if I want to test upwards of 40,000 files, decoding speed is important.
This test includes lvqcl's two sets of compiles linked above.
Version (Compiler) Time (sec) Speed vs realtime
--------------------------------------------- ---------- -----------------
1.2.1b 32-bit 119.13 329x
Xiph 1.3.0 32-bit 113.45 345x
Xiph 1.3.0 64-bit 103.45 379x
lvqcl 1.3.1 2014-11-15 32-bit (GCC 4.9.1) 80.83 485x
lvqcl 1.3.1 2014-11-15 64-bit (GCC 4.9.1) 76.16 515x
lvqcl 1.3.1 2014-11-15 32-bit (GCC 4.9.2) 80.56 487x
lvqcl 1.3.1 2014-11-15 64-bit (GCC 4.9.2) 75.56 519x
Xiph 1.3.1 pre1 32-bit (GCC 4.9.1) 81.55 481x
Xiph 1.3.1 pre1 64-bit (GCC 4.9.1) 77.23 507x
Here's a test I just ran testing (flac.exe -t) a set of about 150 files.
Are they 16-bit, 24-bit or both?
They were all 2 channel 16/44.1. I have some 24/96 files that I can also test with.
I've compiled 32-bit and 64-bit libFLAC with VS2013, and i'm reencoding my whole library via PowerShell Audio. Will try both versions. May take a few hours...
There is no point in building with NASM anymore, right? Just checking... the README still mentions it.
With the beta flac.exe linked in Maurits's post, I get the following on an AMD Phenom II X4 970 @3.5GHz:
Set 1: a few albums (wav 44.1kHz 16bit): 2:33:09, 1 630 978 738 bytes
flac 1.2.1 lv8 0:51 (180x) 809 645 691 (49,64%) [+/- 0MB]
flac 1.3.1 lv8 0:24 (383x) 807 720 851 (49,52%) [- 1,8MB]
flac 1.3.1 lv8e 1:27 (106x) 805 230 363 (49,37%) [- 4,2MB]
tak 2.3.0 p4m 1:28 (104x) 755 009 174 (46,29%) [-52,1MB]
Set 2: hires album (wav 48kHz 24bit): 1:13:58, 1 280 307 724 bytes
flac 1.2.1 lv8 1:04 ( 69x) 918 175 228 (71,71%) [+/- 0MB]
flac 1.3.1 lv8 0:26 (171x) 916 311 947 (71,56%) [- 1,8MB]
flac 1.3.1 lv8e 2:02 ( 36x) 915 515 373 (71,50%) [- 2,5MB]
tak 2.3.0 p4m 0:54 ( 82x) 893 934 332 (69,82%) [-23,1MB]
Set 3: hires album (wav 96kHz 24bit): 0:53:48, 1 863 301 258 bytes
flac 1.2.1 lv8 1:29 (36x) 1 222 429 935 (65,60%) [+/- 0MB]
flac 1.3.1 lv8 0:33 (98x) 1 216 111 317 (65,26%) [- 6,0MB]
flac 1.3.1 lv8e 2:50 (19x) 1 204 972 348 (64,66%) [-16,6MB]
tak 2.3.0 p4m 1:06 (49x) 1 168 977 920 (62,73%) [-51,0MB]
This is using foobar with 4x encoding threads from and to a RAMdisk. TAK simply for (personal) reference.
Great job on that encoding speed boost! It doesn't seem to matter whether you're encoding a "normal" or a hires album with flac anymore.
8e is not really worth it compared to TAK though - too slow and too little gain. Leaving the -e parameter out of the lv 8 preference was a solid decision.
And FLAC 1.3.1 has been released. See the corresponding news item (http://www.hydrogenaud.io/forums/index.php?showtopic=107611) I just posted in News Submissions.
New version works great! I also appreciate the improved build experience under visual studio.