After 18 months of development, FLAC 1.3.1 has been released. The trigger for this release was a heap overflow found by the Google Security Team.
Changes- Huge encoding speedup for i386 and x86_64 (up to 250% for 24-bit)
- Slightly improved compression of compression levels 6, 7 and 8
- Fixed CVE-2014-9028 (heap write overflow) and CVE-2014-8962
- Output buffer has been added to Windows to mitigate fragmentation
- Various build system improvements and bug fixes
For the complete changelog, see http://xiph.org/flac/changelog.html (http://xiph.org/flac/changelog.html)
The source is available here (http://downloads.xiph.org/releases/flac/flac-1.3.1.tar.xz), official Windows binaries are supplied here (http://downloads.xiph.org/releases/flac/flac-1.3.1-win.zip).
Don't forget to mention the added decoding efficiency improvements for all bit depths. Particularly 24 bit on IA32.
The website still points to the 1.2.1b binary. (Navigate to http://xiph.org/flac/download.html (http://xiph.org/flac/download.html), then click the link named "FLAC for Windows (command-line tools only)."
I do notice that the 1.3.1 binary has just been added to the sourceforge page, but it still defaults to 1.2.1 ("Looking for the latest version? Download flac-1.2.1b.exe (2.7 MB)."
ktf thanks!
audiophool, give them some time
I'd be very interested to see an encoding speed comparison between 1.3.0 and 1.3.1 with one of the new Haswell based CPUs. They can make full use of the AVX2 improvements in the new version, many older CPUs only benefit from AVX1 or older SSE instruction sets.
Thank You very much for speed and compression improvements to all involved people.
Until now FLACCL was faster on my setup (strong CPU and week GPU) comparing to FLAC 1.3.0.
But now 1.3.1 is faster. Sticking with it.
is there plans for a patch/build to support old systems (xp sp3 barton 3000+) too?
is there plans for a patch/build to support old systems (xp sp3 barton 3000+) too?
Why, doesn't it work on that system?
Excellent work - thanks to all of the developers involved!
@ktf: i believe the cpu is missing a feature and the build relies on that? when trying to encode in foobar or flacdrop a grey error console showed up.
btw: the official 1.3.0 also did not work but i found a mingw version that did the trick.
@ktf: i believe the cpu is missing a feature and the build relies on that?
AFAIK the build is build for i686, so at least MMX but no requirements for SSE. What error do you get? For 1.3.0, there have never been official binaries.
I benchmarked the official 1.3.1 (32bit) compile from xiph.org with other flac compiles I collected during its "evolution":
Encoder Options Process time FLAC file size
---------------------------------------------------------------------------------------
flac 1.3.0 -8 77.548 sec 292.407.249 bytes
flac 1.3.1 -8 56.831 sec 292.127.317 bytes
flac-git-7251201 (AiZ) -l 12 -b 4096 -m -e -r 6 50.887 sec 292.407.763 bytes
flac 1.3.1 -l 12 -b 4096 -m -e -r 6 52.572 sec 292.407.763 bytes
WAV file size = 663.678.612 bytes
CPU used: Intel Core 2 Quad Q9500 @ 2.8 GHz
AiZ's post: http://www.hydrogenaud.io/forums/index.php...st&p=869644 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=869644)
Although GCC 4.9.0 was used for AiZ's compile, it is faster (~ 3% on my CPU) than the GCC compiles of 1.3.1.
@AiZ: Would you mind to provide "your" 1.3.1?
Can I do a static build (flac & metaflac) on wheezy? If so, how?
Use
make LDFLAGS='-static'
to make a static build
Use
make LDFLAGS='-static'
to make a static build
thanks (that did the trick).
Interesting, my own VS2013 compile is about 10 seconds slower than the official (gcc-compiled?) on the same set of 1.51GB of wav files.
I actually expected the opposite considering gcc is not "native" to windows.
I followed the readme instructions, so nasm.exe was used. How can I control which instruction sets are used, or does it try to automatically use all possible optimizations? I'm on an AMD Phenom II CPU.
I actually expected the opposite considering gcc is not "native" to windows.
FLAC doesn't use libraries for much of its work. The real work is done directly, so there isn't much difference between a native compiler and a non-native one.
I followed the readme instructions, so nasm.exe was used. How can I control which instruction sets are used, or does it try to automatically use all possible optimizations? I'm on an AMD Phenom II CPU.
This release uses function multiversioning, which is supported by GCC starting with release 4.9. IIRC, MSVC2013 supports it too, so it should indeed automatically check the CPU whether it supports the optimizations.
@ktf: maybe this is already helpful to you - cant test anymore (link broken), but i am pretty sure that it was even your 1.3.0 build that works on the barton cpu: http://www.hydrogenaud.io/forums/index.php...st&p=835599 (http://www.hydrogenaud.io/forums/index.php?showtopic=99757&view=findpost&p=835599)
regarding the specific error, i'll report back.
There's a line in configure.ac:
XIPH_ADD_CFLAGS([-msse2])
which means that SSE2 is required.
Here is a build that doesn't need SSE2: (see post #39)
thats it, is working now, although very slow compared to the 1.3.0 build, thank you. would be interresting to see a sse1 version, as the cpu is capable of that instruction.
Really?
a) This build is able to use SSE/AVX-accelerated routines when possible.
b) Remember that -6, -7 and -8 presets were re-tuned. For example, -6 was very close to -5. Now it is noticeably slower but compresses better.
Or you can old presets by using the following settings:
old preset equivalent settings
-6 -l 8 -b 4096 -m -r 6
-7 -l 8 -b 4096 -m -e -r 6
-8 -l 12 -b 4096 -m -e -r 6
I do notice that the 1.3.1 binary has just been added to the sourceforge page, but it still defaults to 1.2.1 ("Looking for the latest version? Download flac-1.2.1b.exe (2.7 MB)."
This has just been fixed
It might also be worth pointing out that John33 has new Windows builds of 1.3.1 compiled with ICL 14 over at Rarewares (http://www.rarewares.org/lossless.php)
I've been using rarewares build for a while now, mostly because of the lack of official 1.3.0 builds for windows.
Now the question is, which one is faster / more efficient?
The Rarewares ICL x64 build is actually slower than the (official) GCC x64 build on my Haswell machine. Roughly 5% difference.
me7, I can replicate the speed difference; I'm admittedly rather surprised. Usually the ICL builds eke out at least a small bump.
How do you bench the encoding speed? I found no command for that..
Really?
a) This build is able to use SSE/AVX-accelerated routines when possible.
b) Remember that -6, -7 and -8 presets were re-tuned. For example, -6 was very close to -5. Now it is noticeably slower but compresses better.
Or you can old presets by using the following settings:
old preset equivalent settings
-6 -l 8 -b 4096 -m -r 6
-7 -l 8 -b 4096 -m -e -r 6
-8 -l 12 -b 4096 -m -e -r 6
yes, it is quite a difference. encoding speed at -6 is 82x (1.3.0) to 50x (1.3.1).
regarding the ''strict'' sse2 requirement in the official build: would it have broken optimizations to just ask for sse1 (like in your build)?
yes, it is quite a difference. encoding speed at -6 is 82x (1.3.0) to 50x (1.3.1).
As I wrote, just use "-l 8 -b 4096 -m -r 6" instead of "-6" if you want the speed of the old preset.
My own ICL 14 compile is doing even worse than the one from Rare..
In addition I get the warning "warning #10121: overriding '/QxCORE-AVX2' with '/archAVX'"for libFLAC_static when I compile it with "/QxCORE-AVX2".
It only goes away if I chose "/QxCORE-AVX", which doesn't make that much sense to me.
And yes, my Haswell i4600u is capable of AVX2.
Measured with a stop watch:
3.822.698.948 Bytes 16 bit Wav
Sourceforge version : 01:31.4
Own Vc120 compile : 01:35.8
Own ICL 14 compile : 01:55.6
As I wrote, just use "-l 8 -b 4096 -m -r 6" instead of "-6" if you want the speed of the old preset.
sure, just wanted to show old/new standard switch in contrast it is on par when using this preset, so thank you.
C2D, nvidia GT640, testing a 13min CDDA-WAV using flac --best/-8:
1.3.0 32bit icl: 16.8sec
1.3.0 64bit icl: 16.7sec
1.3.1 32bit icl: 13.5sec
1.3.1 32bit: 13sec
1.3.1 64bit icl: 12.3sec
1.3.1 64bit: 12sec
FLACCL: 5.9sec
Nice speedbump.
Going to post my findings, but not going to bore you with exact numbers, because I don't think this thread was meant for benchmark details.
I used the default compression level (-5) and window's powershell measure-command
Comparing rarewares 1.3.0 I had, with the rarewares for 1.3.1 and the official binaries, I can conclude the following:
* For rarewares 1.3.0, the 64 bit binary used to be slower than the 32 bit.
* For rarewares 1.3.1, the 64 bit binary is now faster. To a lesser degree than above.
* The 64 bit official binary is slightly faster than the official 32-bit, but this diff was smaller than the cases above.
Overall the official binaries are the fastest. And the rarewares 1.3.1 are an improvement over 1.3.0
Hardware: http://valid.canardpc.com/jnf5fx (http://valid.canardpc.com/jnf5fx)
Hello,
@AiZ: Would you mind to provide "your" 1.3.1?
Unfortunately, "my" compile and the official one output the same numbers, git-7251201 remains the fastest.
To get the execution time, I use timer64 from Igor Pavlov (7-zip/7-bench).
git-7251201 (-l 12 -b 4096 -m -e -r 6)
Commit = 3924 KB = 4 MB
Work Set = 3324 KB = 4 MB
Kernel Time = 1.996 = 3%
User Time = 46.035 = 92%
Process Time = 48.032 = 96%
Global Time = 49.955 = 100%
official/my compile 1.3.1 (-l 12 -b 4096 -m -e -r 6)
Commit = 14152 KB = 14 MB
Work Set = 13624 KB = 14 MB
Kernel Time = 0.904 = 1%
User Time = 49.561 = 96%
Process Time = 50.466 = 98%
Global Time = 51.375 = 100%
On my now ageing architecture (C2D e7200, like yours), I don't know if the small performance drop and the bigger working set could be related...
AiZ
Curious speed results you see there. On my Core i7 the official 64-bit binary is 57% faster than your old git build (235.9596x realtime speed vs 150.1619x).
The increase you see in the working set size comes from output buffering. It writes less often to the disk so it should only help with speed.
@AiZ: Would you mind to provide "your" 1.3.1?
Unfortunately, "my" compile and the official one output the same numbers, git-7251201 remains the fastest.
That probably has to do with this patch: http://lists.xiph.org/pipermail/flac-dev/2...ust/004987.html (http://lists.xiph.org/pipermail/flac-dev/2014-August/004987.html)
Sorry guys, this was the trade-off. I myself am stuck with a C2D as well.
One can open lpc_intrin_sse.c, find "#if 1" line and replace it with "#if 0", then compile flac.exe.
P.S. I suspect that old Intel CPUs (older than Core i 'Nehalem') suffer from slow unaligned loads. But I'm not an expert.
How do you bench the encoding speed? I found no command for that..
Timer32.exe or Timer64.exe from http://sourceforge.net/projects/sevenmax/files/7-Benchmark/ (http://sourceforge.net/projects/sevenmax/files/7-Benchmark/)
One can open lpc_intrin_sse.c, find "#if 1" line and replace it with "#if 0", then compile flac.exe.
So I did it myself and tested on Intel Core2. For -5 preset, the difference is 8% (encodig time is 16.4 seconds vs 15.2 sec). For the
old -8 preset, the difference is 4% (48.2 sec vs 46.4 sec). But for the
new -8 preset, the difference is 24% (54.8 sec vs 44.2 sec)! Oops. This is not funny.
Maybe FLAC should have both old and new versions and choose the appropriate ones.
I built both the original FLAC 1.3.1 and the modified code with the same compiler (MinGW-w64/GCC 4.9.2) and attached them to this post, so you can test their encoding speed.
Hi,
With modified lpc_intrin_sse.c, 1.3.1 performance is on par with git-7251201 one (C2D architecture).
Thanks,
AiZ
It would be interesting to see what version is faster on other AMD and Intel processors.
I built both the original FLAC 1.3.1 and the modified code with the same compiler (MinGW-w64/GCC 4.9.2) and attached them to this post, so you can test their encoding speed.
system: athlon64 3200+, 896mb ram, XP SP3
image.wav, 73 mins, 16/44.1.
timer32 flac -8 image.wav
image.wav: wrote 440373786 bytes, ratio=0.569 (indentical for both builds)
flac-1.3.1-win-for_older_intel_CPUs.zip
Kernel Time = 1.812 = 1%
User Time = 132.328 = 93%
Process Time = 134.140 = 95% Virtual Memory = 14 MB
Global Time = 140.906 = 100% Physical Memory = 12 MB
flac-1.3.1-win.zip
Kernel Time = 2.140 = 1%
User Time = 107.250 = 89%
Process Time = 109.390 = 91% Virtual Memory = 14 MB
Global Time = 119.859 = 100% Physical Memory = 12 MB
that build for older intel cpus is around 17.5% slower for me.
Thanks. But I think that it makes more sense to compare process times, in this case the difference is 22.6%.
oops, it's lucky i posted the numbers in full.
some tests on my AMD FX-6300 Win7 x64 SP1 using Measure-Command on 750MB wav.
tested with -8 setting
1.3.1 x32 from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 40
Milliseconds : 56
1.3.1 x32 no-sse2 from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 41
Milliseconds : 983
1.3.1 x64 from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 31
Milliseconds : 518
1.3.1 x32 for older intel from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 42
Milliseconds : 898
1.3.1 x32 for older intel from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 45
Milliseconds : 301
1.3.1 x64 for older intel from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)
Seconds : 37
Milliseconds : 88
1.3.1 x32 official
Seconds : 40
Milliseconds : 451
1.3.1 x64 official
Seconds : 31
Milliseconds : 535
1.3.1 x32 rarewares
Seconds : 37
Milliseconds : 70
1.3.1 x64 rarewares
Seconds : 33
Milliseconds : 70
1.3.1 x32 my own VS2012 build (full optim)
Seconds : 33
Milliseconds : 691
1.3.1 x64 my own VS2012 build (full optim)
Seconds : 32
Milliseconds : 400
my own vs2012 is still the best for x32 no my PC. it's suspiciously faster.
flac --best, 13min CDDA-WAV, Process Time in seconds, three runs, percentage calculated with the second values
Core 2 Duo E6850:
flac_older_64: 10.623 10.670 10.857 ( -8.5% to flac_64)
flac_older_32: 11.247 11.341 11.388 (-10.5% to flac_32)
flac_older_32_nosse: 11.466 11.559 11.559 (-10.1% to flac_32_nosse)
flac_64: 11.590 11.653 11.684
flac_32: 12.636 12.667 12.698
flac_32_nosse: 12.729 12.854 12.916
Core i5 1st-gen ULV:
flac_64: 13.416 13.572 13.587
flac_32: 14.055 14.289 14.414
flac_32_nosse: 14.994 15.319 15.662
flac_older_64: 15.475 15.553 15.631 (+14.6% to flac_64)
flac_older_32: 16.177 16.224 16.754 (+13.5% to flac_32)
flac_older_32_nosse: 17.035 17.300 17.300 (+12.9% to flac_32_nosse)
Intel C2Q Q9400 @3200
16bit 44100hz sample level -8
flac 1.3.1 official 64bit : 71.83x
flac 1.3.1 lvqcl 64 bit : 73.13x
flac 1.3.1 lvqcl 64 bit (old intel) : 90.00x
i'm stick with old intel
Thx for the timer64, any ideas why I can't compile libFLAC_static.lib with QxAVX2 ?
Foobar has been updated to version 1.3.6 (http://www.foobar2000.org/download), the only change is that it now uses FLAC 1.3.1.
XLD has been updated to version 20141129 (http://tmkk.undo.jp/xld/index_e.html) and now uses FLAC 1.3.1.
just for the record (addition to my previous post)
1.3.0 x32 rarewares
Minutes : 1
Seconds : 15
Milliseconds : 118
and the result file is bigger.
huge improvement i'd say. thanks to all who was involved!
Would be nice to update James Chapmans Audiotester he offers at vuplayer since it benefits of faster decoding.
I made some test by converting Classical music files from flac 1.3.0 to 1.3.1, using -8 preset. Generally the files created by 1.3.1 are just slightly smaller (I get values of 0.998 0.999, 1.000) but every now and then the file size created by 1.3.1 is bigger! (1.000, 1.002, but sometimes as high as 1.004, 1.005).
I'm on Linux I use my own compile, using GCC 4.8.
flac on the command line gives the following warning:
FAILURE: Compression failed (ratio 1,000, should be < 1.0).
This happens for some files for one or more of the following reasons:
* Recompressing an existing FLAC from a higher to a lower compression setting.
* Insufficient input data (eg, very short files, < 10000 frames).
* The audio data is not compressable (eg a full range white noise signal).
In my case neither of the above is true.
I'm recompressing from preset 8 to preset 8
The files are not very short
The audio data is compressable
I made some test by converting Classical music files from flac 1.3.0 to 1.3.1, using -8 preset. Generally the files created by 1.3.1 are just slightly smaller (I get values of 0.998 0.999, 1.000) but every now and then the file size created by 1.3.1 is bigger! (1.000, 1.002, but sometimes as high as 1.004, 1.005).
I'm on Linux I use my own compile, using GCC 4.8.
Remember that -e (--exhaustive-model-search) was removed from the new presets, in exchange for functions that are both faster and "typically" yield better compression, but of course will not cover ALL the scenarios. If you re-enable the option (eg: -8e). I'm pretty sure you should ALWAYS get equal or better compression than before, but you'll lose all the speed benefits.
You can take that even further (-8ep) and you will get slightly better compression, but considerably slower performance. There are even more options that would make flac even slower, for very small gains in compression. (Discussed here http://www.hydrogenaud.io/forums/index.php...t&p=875580) (http://www.hydrogenaud.io/forums/index.php?showtopic=106545&view=findpost&p=875580))
Hello,
@lvqcl, for the fun...
Pentium M 740@1.73GHz, SSE2
Official
Kernel Time = 1.796 = 1%
User Time = 137.718 = 90%
Process Time = 139.515 = 91% Virtual Memory = 14 MB
Global Time = 152.703 = 100% Physical Memory = 12 MB
GCC
Kernel Time = 1.937 = 1%
User Time = 137.687 = 88%
Process Time = 139.625 = 90% Virtual Memory = 14 MB
Global Time = 154.875 = 100% Physical Memory = 15 MB
OldCPU
Kernel Time = 1.734 = 1%
User Time = 138.343 = 89%
Process Time = 140.078 = 90% Virtual Memory = 14 MB
Global Time = 154.531 = 100% Physical Memory = 15 MB
Pentium 4 520@2.8GHz, SSE3
Official
Kernel Time = 1.531 = 1%
User Time = 99.765 = 87%
Process Time = 101.296 = 88% Virtual Memory = 14 MB
Global Time = 113.843 = 100% Physical Memory = 12 MB
GCC
Kernel Time = 1.812 = 1%
User Time = 99.640 = 85%
Process Time = 101.453 = 87% Virtual Memory = 14 MB
Global Time = 116.265 = 100% Physical Memory = 12 MB
OldCPU
Kernel Time = 2.062 = 1%
User Time = 98.843 = 85%
Process Time = 100.906 = 86% Virtual Memory = 14 MB
Global Time = 116.125 = 100% Physical Memory = 12 MB
Bye,
AiZ
Today I had a lot of spare CPU and a plenty of time so I decided to reencode my music collection with latest flac 1.3.1.
I thought it might be interesting to share the result.
The collection consists of 8248 songs from 674 CDs (and a handful of Vinyl rips). It spans most genres but the bulk should be leaning towards rock, pop, blues and experimental music.
I run Fedora 20 (linux) for x86-64 and used the following command to perform the reencoding:
"find DIRECTORY -name '*.flac' -print0 | xargs -0 flac -8f"
Previously almost all files were encoded with flac 1.2.1 (20070917) and option "-8". The rest were encoded with earlier flac-versions or with flac 1.3.0.
I used the script made by "tuffy" in the following post to measure the size before and after:
http://www.hydrogenaud.io/forums/index.php...st&p=811058 (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=97125&view=findpost&p=811058)
Before:
$ ./musicsize.py DIRECTORY/
metadata length : 104224827
total frames length : 188823150502
uncompressed length : 327231818538
compression : 57.70%
After:
$ ./musicsize.py DIRECTORY/
metadata length : 104708391
total frames length : 188428672021
uncompressed length : 327231818538
compression : 57.58%
Best Ratio: 0.889 (Kate Miccuci - Walking in Los Angeles)
Worst Ratio: 1.073 (Vladimir Vysotsky - Горизонт)
Median Ratio: 0.998
Average Ratio: 0.9977935
The ratios was calculated over the ratios reported by the flac-command after encoding was done.
The only noteworthy thing I can see from a brief looking through the results with worse ratio is that most seems to come from spoked word (interview CDs and tracks with only people speaking).
One file showed a IO_ERROR due to flac having trouble with the long filename (fixed after shortening the name and rerunning flac manually on it).
Overall a ~400MB size reduction of the whole library and I am quite happy with the results.
Thanks for the new release!
Besides all of the wonderful looking new benchmark numbers, I'd like to add that I converted 334GB of flac music over from 1.3.0 to 1.3.1.
I've got a pretty bad processor so it took about 7 hours, but I saved 940MB from the conversion. Average kbps dropped by 2kbps.
I love it when upgrading versions shows that much!
Besides all of the wonderful looking new benchmark numbers, I'd like to add that I converted 334GB of flac music over from 1.3.0 to 1.3.1.
I've got a pretty bad processor so it took about 7 hours, but I saved 940MB from the conversion. Average kbps dropped by 2kbps.
I love it when upgrading versions shows that much!
You probably did some research before doing it so, what's the easiest/fastest way and does your procedure delete the old version? When I did ALAC to FLAC with dBpoweramp while ago ALAC was deleted automatically after the new FLAC verification was done.
Besides all of the wonderful looking new benchmark numbers, I'd like to add that I converted 334GB of flac music over from 1.3.0 to 1.3.1.
I've got a pretty bad processor so it took about 7 hours, but I saved 940MB from the conversion. Average kbps dropped by 2kbps.
I love it when upgrading versions shows that much!
You probably did some research before doing it so, what's the easiest/fastest way and does your procedure delete the old version? When I did ALAC to FLAC with dBpoweramp while ago ALAC was deleted automatically after the new FLAC verification was done.
I simplified the procedure back when I was converting from 1.2.1 to 1.3.0. I simply used foobar to convert my entire flac library to another drive / folder while retaining the exact folder hierarchy that it was in before. Then I used FreeFileSync to do a time/size difference replace on my original music. It replaces all of the music but leaves all of the existing art and extras behind. I decided on this method just in case something went wrong, given the huge amount of music. Though, I've never had an issue arise never hurts to be cautious.
My conversion:
http://www.zageron.com/img/20141201063025404.png (http://www.zageron.com/img/20141201063025404.png)
Here's an update with lvqcl's compiles (32bit):
Encoder Options Process time FLAC file size
---------------------------------------------------------------------------------------
flac 1.3.0 -8 77.548 sec 292.407.249 bytes
flac 1.3.1 (xiph) -8 56.831 sec 292.127.317 bytes
flac-git-7251201 (AiZ) -l 12 -b 4096 -m -e -r 6 50.887 sec 292.407.763 bytes
flac 1.3.1 (xiph) -l 12 -b 4096 -m -e -r 6 52.572 sec 292.407.763 bytes
flac 1.3.1 (lvqcl) -8 56.659 sec 292.127.317 bytes
flac 1.3.1_core2 (lvqcl) -8 45.084 sec 292.127.317 bytes
flac 1.3.1 (lvqcl) -l 12 -b 4096 -m -e -r 6 53.055 sec 292.407.763 bytes
flac 1.3.1_core2 (lvqcl) -l 12 -b 4096 -m -e -r 6 50.856 sec 292.407.763 bytes
AiZ's post: http://www.hydrogenaud.io/forums/index.php?s=&showtopic=101082&view=findpost&p=869644
lvqcl's post: http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856
WAV file size = 663.678.612 bytes (15 files)
CPU used: Intel Core 2 Quad Q9500 @ 2.8 GHz
So lvqcl's version for "older intel cpus" is on-par with AiZ's version when the old -8 settings are used. That could be expected.
But two things really surprised me:
a) The "older intel cpu" version is ~25% faster than the standard compile and ~72% faster than 1.3.0. Excellent!
b) The "older intel cpu" verison is faster with new -8 settings while standard compile is faster with old -8 settings.
Thanks everyone who made this new versions possible.
I've updated to Foobar2000 Vn 1.3.6 and the new encoder pack.
Conversions to FLAC work wonderfully well, but the General, Tool in Foobar2000 reports reference libFLAC 1.3.0 20130526 for a newly converted file.
This is not what I expected to see, is it correct?
Besides all of the wonderful looking new benchmark numbers, I'd like to add that I converted 334GB of flac music over from 1.3.0 to 1.3.1.
I've got a pretty bad processor so it took about 7 hours, but I saved 940MB from the conversion. Average kbps dropped by 2kbps.
Insane economic decisions by people in this thread. 1 GB of storage costs like 5 cents. So you took the time (and the cost of seven hours of electricity for powering your computer) for 5 cents. Oh well.
Tool in Foobar2000 reports reference libFLAC 1.3.0 20130526 for a newly converted file.
that's not right. i've just downloaded the latest encoder pack myself and it reports
reference libFLAC 1.3.1 20141125 on a newly encoded file. perhaps your converter settings reference the path to an older version??
Insane economic decisions by people in this thread.
i'm sure the real reason is that people want the latest and greatest version reported in the tool section if they use a media player that show it.
Tool in Foobar2000 reports reference libFLAC 1.3.0 20130526 for a newly converted file.
that's not right. i've just downloaded the latest encoder pack myself and it reports reference libFLAC 1.3.1 20141125 on a newly encoded file. perhaps your converter settings reference the path to an older version??
Insane economic decisions by people in this thread.
i'm sure the real reason is that people want the latest and greatest version reported in the tool section if they use a media player that show it.
Thanks so much for your assistance Marc. Replacement of all instances of FLAC.exe on my system with the latest & greatest version fixed it of course!
Also (from olden days) I have in Tools/Converter/Additional Command Line paths, an entry showing the path to FLAC.exe. Is that necessary with the latest version of Foobar2000 please?
For the record, results for Core i7 950 (Nehalem architecture):
encoding time for -8 preset, for 44.1/16/stereo WAV:
"newer intel" vs. "older intel":
32 bit: 33.8 sec vs 39.0 sec;
64 bit: 30.2 sec vs 37.2 sec;
32 bit "no_SSE2": 35.8 sec vs 41.0 sec.
@lvqcl, for the fun...
The results are so close that it's a bit suspicious... Are you sure that there's no other flac.exe somewhere in the PATH (or in the same directory with timer.exe) ?
Hello,
I've downloaded archives again, checked that all flac.exe are different, there's no other flac.exe in the path, etc.: results are the same, I've just added Rarewares icl 1.3.0 & 1.3.1 compiles to compare.
Pentium M
flac -l 12 -b 4096 -m -e -r 6
1.3.1 official
Kernel Time = 1.968 = 1%
User Time = 137.500 = 89%
Process Time = 139.468 = 90% Virtual Memory = 14 MB
Global Time = 153.468 = 100% Physical Memory = 12 MB
1.3.1 GCC
Kernel Time = 2.203 = 1%
User Time = 137.203 = 89%
Process Time = 139.406 = 90% Virtual Memory = 14 MB
Global Time = 153.750 = 100% Physical Memory = 15 MB
1.3.1 GCC-nosse2
Kernel Time = 1.828 = 1%
User Time = 137.296 = 89%
Process Time = 139.125 = 90% Virtual Memory = 14 MB
Global Time = 152.921 = 100% Physical Memory = 15 MB
1.3.1 OldCPU
Kernel Time = 1.703 = 1%
User Time = 138.359 = 89%
Process Time = 140.062 = 90% Virtual Memory = 14 MB
Global Time = 154.437 = 100% Physical Memory = 15 MB
1.3.1 OldCPU-nosse2
Kernel Time = 2.078 = 1%
User Time = 137.890 = 89%
Process Time = 139.968 = 91% Virtual Memory = 14 MB
Global Time = 153.609 = 100% Physical Memory = 15 MB
1.3.0 rarewares
Kernel Time = 3.734 = 2%
User Time = 151.484 = 95%
Process Time = 155.218 = 97% Virtual Memory = 4 MB
Global Time = 159.062 = 100% Physical Memory = 2 MB
1.3.1 rarewares
Kernel Time = 2.046 = 1%
User Time = 139.343 = 89%
Process Time = 141.390 = 90% Virtual Memory = 14 MB
Global Time = 155.750 = 100% Physical Memory = 15 MB
Pentium 4
flac -l 12 -b 4096 -m -e -r 6
1.3.1 official
Kernel Time = 2.046 = 1%
User Time = 99.656 = 85%
Process Time = 101.703 = 86% Virtual Memory = 14 MB
Global Time = 116.937 = 100% Physical Memory = 12 MB
1.3.1 GCC
Kernel Time = 1.812 = 1%
User Time = 99.812 = 86%
Process Time = 101.625 = 88% Virtual Memory = 14 MB
Global Time = 115.437 = 100% Physical Memory = 12 MB
1.3.1 GCC-nosse2
Kernel Time = 1.828 = 1%
User Time = 98.015 = 85%
Process Time = 99.843 = 87% Virtual Memory = 14 MB
Global Time = 114.031 = 100% Physical Memory = 15 MB
1.3.1 OldCPU
Kernel Time = 2.078 = 1%
User Time = 99.218 = 88%
Process Time = 101.296 = 89% Virtual Memory = 14 MB
Global Time = 112.718 = 100% Physical Memory = 15 MB
1.3.1 OldCPU-nosse2
Kernel Time = 1.781 = 1%
User Time = 97.609 = 86%
Process Time = 99.390 = 88% Virtual Memory = 14 MB
Global Time = 112.875 = 100% Physical Memory = 15 MB
1.3.0 rarewares
Kernel Time = 5.359 = 3%
User Time = 130.796 = 83%
Process Time = 136.156 = 86% Virtual Memory = 4 MB
Global Time = 156.671 = 100% Physical Memory = 5 MB
1.3.1 rarewares
Kernel Time = 1.578 = 1%
User Time = 104.734 = 85%
Process Time = 106.312 = 86% Virtual Memory = 14 MB
Global Time = 122.453 = 100% Physical Memory = 15 MB
AiZ
my quick test, single album
# FLAC, quick test
## machine
CPU~Single core Intel Pentium 4 CPU (-HT-) clocked at 3192.032 Mhz Kernel~3.2.0-4-amd64 x86_64
## zz_ward, single album
### flac 1.2.1 -8 (wheezy repo)
done in 0:01:18
size 276.4 MiB
### flac 1.3.1 -8 (static compile)
done in 0:01:13
size 275.0 MiB
### flac 1.3.1 -8 (static compile),(parallel --gnu flac -8 {} ::: "$@")
done in 0:01:08
size 275.0 MiB
### ape 3.99 insane (multimedia repo)
done in 0:06:46
size 254.5 MiB
### wavpack 4.60 -xh (wheezy repo)
done in 0:01:03
size 273,0 MiB
### wavpack 4.60 -xhh (wheezy repo)
done in 0:01:18
size 268,0 MiB
notes:
- monkeys-audio version is ancient
- wavpack is old
Just a minor cosmetic note:
When encoding a file, the first line of the text-output is longer than 80 characters, which results in wrapping:
flac 1.3.1, Copyright (C) 2000-2009 Josh Coalson, 2011-2014 Xiph.Org Foundatio
n
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.
flac on the command line gives the following warning:
FAILURE: Compression failed (ratio 1,000, should be < 1.0).
This happens for some files for one or more of the following reasons:
* Recompressing an existing FLAC from a higher to a lower compression setting.
* Insufficient input data (eg, very short files, < 10000 frames).
* The audio data is not compressable (eg a full range white noise signal).
In my case neither of the above is true.
I'm recompressing from preset 8 to preset 8
The files are not very short
The audio data is compressable
I'm also getting this error message and nothing seems to be wrong with the source file for me as well. However, the converted file is smaller than the original one but it's still listed as 1.3.0 by foobar and has the same MD5 checksum as the original....?!?
flac on the command line gives the following warning:
FAILURE: Compression failed (ratio 1,000, should be < 1.0).
This happens for some files for one or more of the following reasons:
* Recompressing an existing FLAC from a higher to a lower compression setting.
* Insufficient input data (eg, very short files, < 10000 frames).
* The audio data is not compressable (eg a full range white noise signal).
In my case neither of the above is true.
I'm recompressing from preset 8 to preset 8
The files are not very short
The audio data is compressable
I'm also getting this error message and nothing seems to be wrong with the source file for me as well. However, the converted file is smaller than the original one but it's still listed as 1.3.0 by foobar and has the same MD5 checksum as the original....?!?
I assume that because it failed, it reverted to the original file and discarded the changes. Maybe the verify flag was on?
In any case, read post 54 ( http://www.hydrogenaud.io/forums/index.php...st&p=882953 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882953) )
I assume that because it failed, it reverted to the original file and discarded the changes. Maybe the verify flag was on?
In any case, read post 54 ( http://www.hydrogenaud.io/forums/index.php...st&p=882953 (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882953) )
Thanks for the reply Makaki. The script which I use converts files with the -v option so the file probably couldn't be compressed anymore and was thus reverted to 1.3.0
However, it's still strange that the reverted file is a bit smaller than the original as both are 1.3.0 with the same compression level. I guess that this has something to do with rewriting the headers as the MD5 checksum has remained identical.
However, it's still strange that the reverted file is a bit smaller than the original as both are 1.3.0 with the same compression level. I guess that this has something to do with rewriting the headers as the MD5 checksum has remained identical.
Padding I guess? If you remove a picture using a tagger, then I assume it does not rewrite the file - rather, it leaves empty space. Rewriting the file with same data but without the empty space ... try to compress them using 7z or zip or something, and see if it evens out the difference.
I did some testing, using an Intel Core i5-4460, here are my results:
CLI encoder: flac.exe
Destination file: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\Alice In Chains - Would.flac
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Users\*\Desktop\flac-1.3.1-git-7251201-win32\flac.exe" -s --ignore-chunk-sizes -8 - -o "Alice In Chains - Would.flac"
Working folder: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:05.257, 122.78x realtime
wav-cdda: 108 MB
flac: 74.4 MB
----------------------------------------------------------------------------------------------------
CLI encoder: flac.exe
Destination file: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\Alice In Chains - Would.flac
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Users\*\Desktop\flac-1.3.1-win-for_older_intel_CPUs\flac.exe" -s --ignore-chunk-sizes -8 - -o "Alice In Chains - Would.flac"
Working folder: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:04.087, 157.93x realtime
wav-cdda: 108 MB
flac: 74.3 MB
----------------------------------------------------------------------------------------------------
CLI encoder: flac.exe
Destination file: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\Alice In Chains - Would.flac
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Users\*\Desktop\flac-1.3.1-win-lvqcl\flac.exe" -s --ignore-chunk-sizes -8 - -o "Alice In Chains - Would.flac"
Working folder: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:03.244, 198.97x realtime
wav-cdda: 108 MB
flac: 74.3 MB
----------------------------------------------------------------------------------------------------
CLI encoder: flac.exe
Destination file: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\Alice In Chains - Would.flac
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Users\*\Desktop\flac-1.3.1-x64-icl-rarewares\flac.exe" -s --ignore-chunk-sizes -8 - -o "Alice In Chains - Would.flac"
Working folder: G:\MP3\CD-Backup\Alice In Chains - 1992 - Would [COL 668328 2]\
Encoder process still running, waiting...
Encoder process terminated cleanly.
Track converted successfully.
Total encoding time: 0:03.464, 186.33x realtime
wav-cdda: 108 MB
flac: 74.3 MB
flac on the command line gives the following warning:
FAILURE: Compression failed (ratio 1,000, should be < 1.0).
This happens for some files for one or more of the following reasons:
* Recompressing an existing FLAC from a higher to a lower compression setting.
* Insufficient input data (eg, very short files, < 10000 frames).
* The audio data is not compressable (eg a full range white noise signal).
I'm also getting this error message and nothing seems to be wrong with the source file for me as well. However, the converted file is smaller than the original one but it's still listed as 1.3.0 by foobar and has the same MD5 checksum as the original....?!?
I assume that because it failed, it reverted to the original file and discarded the changes. Maybe the verify flag was on?
First I also thought that conversion failed. But it did not. The resulting (bigger than 1.3.0) file had vendor string 1.3.1. (I did the conversion on Linux on the command line.)
What failed is not conversion but compression. 1.3.1 produced a bigger file than the older flac I transcoded.
It also happened that when converting my collection from 1.2.1 to 1.3.0, some files became bigger. But flac 1.3.0 did not gave such a message. This must be a new feature of 1.3.1.
flac on the command line gives the following warning:
FAILURE: Compression failed (ratio 1,000, should be < 1.0).
This happens for some files for one or more of the following reasons:
* Recompressing an existing FLAC from a higher to a lower compression setting.
* Insufficient input data (eg, very short files, < 10000 frames).
* The audio data is not compressable (eg a full range white noise signal).
I'm also getting this error message and nothing seems to be wrong with the source file for me as well. However, the converted file is smaller than the original one but it's still listed as 1.3.0 by foobar and has the same MD5 checksum as the original....?!?
I assume that because it failed, it reverted to the original file and discarded the changes. Maybe the verify flag was on?
First I also thought that conversion failed. But it did not. The resulting (bigger than 1.3.0) file had vendor string 1.3.1. (I did the conversion on Linux on the command line.)
What failed is not conversion but compression. 1.3.1 produced a bigger file than the older flac I transcoded.
It also happened that when converting my collection from 1.2.1 to 1.3.0, some files became bigger. But flac 1.3.0 did not gave such a message. This must be a new feature of 1.3.1.
Maybe the error message is a bit misleading by using the word FAILURE because it's actually something like WARNING: COULD NOT PRODUCE SMALLER FILE WITH THE USED SETTINGS. The word failure makes me think that there's a chance of data loss.
The commit http://git.xiph.org/?p=flac.git;a=commit;h=e9d805dd4374 (http://git.xiph.org/?p=flac.git;a=commit;h=e9d805dd4374)
changed the that calculate autocorrelation. However, the new code
worked slightly (about 4%) slower on Core 2, but with the new
presets the speed decrease can reach ~25%.
This patch enables both old and new functions and chooses between
them at runtime.
https://git.xiph.org/?p=flac.git;a=commitdi...bf4e63f49647e69 (https://git.xiph.org/?p=flac.git;a=commitdiff;h=ac0b4b4cab42fdd5c010bac85bf4e63f49647e69)
Awesome.
Thanks Eric and lvqcl for getting the best for both worlds...
@lvqcl: Would you mind to share your windows binaries with the latest patch again?
@lvqcl: Would you mind to share your windows binaries with the latest patch again?
Do you mean these (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=882856)?
Hello,
git-e78accd (http://aiz.free.fr/flac-git-e78accd.zip) binaries (win32 & win64).
AiZ
@tuNk77: No, this (http://www.hydrogenaud.io/forums/index.php?showtopic=107611&view=findpost&p=883570) one with the runtime decision for old/new intel cpu...
@AiZ: thanks for the compile:
Encoder Options Process time FLAC file size
---------------------------------------------------------------------------------------
flac 1.3.1_core2 (lvqcl) -8 45.084 sec 292.127.317 bytes
flac 1.3.1_core2 (lvqcl) -l 12 -b 4096 -m -e -r 6 50.856 sec 292.407.763 bytes
flac 1.3.1_git-e78accd -8 45.115 sec 292.091.184 bytes
flac 1.3.1_git-e78accd -l 12 -b 4096 -m -e -r 6 50.559 sec 292.397.538 bytes
So, same process times as lvqcl's "old intel" compile, but (a little surprising) slightly smaller flac files.
git-e78accd (http://aiz.free.fr/flac-git-e78accd.zip) binaries (win32 & win64).
Which commit is that? I can't find a commit e78accd?
So, same process times as lvqcl's "old intel" compile, but (a little surprising) slightly smaller flac files.
I don't know which commit AiZ compiled from, but it is probably due to this patch: http://git.xiph.org/?p=flac.git;a=commit;h...e29b5969d04be97 (http://git.xiph.org/?p=flac.git;a=commit;h=c97e057ee57d552a3ccad2d12e29b5969d04be97)
git-e78accd (http://aiz.free.fr/flac-git-e78accd.zip) binaries (win32 & win64).
Which commit is that? I can't find a commit e78accd?
https://git.xiph.org/?p=flac.git;a=commit;h...6b0f05e4a3cef96 (https://git.xiph.org/?p=flac.git;a=commit;h=eb753ae5b4e79429c8f6abf1d6b0f05e4a3cef96)
First eight characters of the tree-string.
From git log:
Improve LPC order guess
The recent compression preset retuning improved upon most material
but it the few tracks that show regression are usually classical
music. This patch improves compression by improving the LPC order
guess, of which classical music benefits most.
Improvement is 0.007% on average but up to 0.1%. I haven't seen
regressions for any of my test samples.
That would explain the smaller FLAC files...
Hey guys,
I recently discovered this forum which I have found to be an excellent source of information for setting up & using EAC with FLAC for CD archives.
Is there any reason I should (or shouldn't) replace the bundled version of FLAC in Exact Audio Copy V1.0b3 (FLAC 1.2.1) with FLAC 1.3.1? Thanks.
Bartier
You definitely should replace it with the newer version. The new version has fixed various bugs (though the worst ones were related to mono and 24-bit sources, not relevant to CD), it creates smaller encodes and it does it faster.
Thanks, Case. Is there any downside at all to upgrading? Is there a possibility that files encoded with the new version can't be read by certain players?
Thanks, Case. Is there any downside at all to upgrading? Is there a possibility that files encoded with the new version can't be read by certain players?
Since the file specification hasn't changed, all files produced by the new encoder will work the same as ones from the previous version. So there really isn't any downside.
Thanks, Case. Is there any downside at all to upgrading? Is there a possibility that files encoded with the new version can't be read by certain players?
Since the file specification hasn't changed, all files produced by the new encoder will work the same as ones from the previous version. So there really isn't any downside.
Hopefully this remains to be true: http://lists.xiph.org/pipermail/flac-dev/2...ber/005370.html (http://lists.xiph.org/pipermail/flac-dev/2014-December/005370.html)
Hopefully this remains to be true: http://lists.xiph.org/pipermail/flac-dev/2...ber/005370.html (http://lists.xiph.org/pipermail/flac-dev/2014-December/005370.html)
That's the other way round, so no need to panic: this can be fixed.
From git log:
Improve LPC order guess
The recent compression preset retuning improved upon most material
but it the few tracks that show regression are usually classical
music. This patch improves compression by improving the LPC order
guess, of which classical music benefits most.
Improvement is 0.007% on average but up to 0.1%. I haven't seen
regressions for any of my test samples.
That would explain the smaller FLAC files...
When transcoding my (mostly Classical music) files from 1.3.0 to 1.3.1, several files became indeed bigger, I even encountered albums where most files and the overall size became bigger.
Now I checked with this git version. The files, which 1.3.1 made bigger did not revert to their 1.3.0 size, some files, however, and mostly files which were small (5-6 MiB and even smaller) became smaller: 0,999 and even 0,998.
[..]
Now I checked with this git version. The files, which 1.3.1 made bigger did not revert to their 1.3.0 size, some files, however, and mostly files which were small (5-6 MiB and even smaller) became smaller: 0,999 and even 0,998.
Do you mean with this git version they are smaller than they were with 1.3.0?
I cant get flac 1.3.1 to work with EAC in copy and test mode, version 1.3.0 and 1.2.1 works perfectly... any clue?
I'm using the same command line as always:
-8 -V -T "ARTIST=%artist%"
[...]
I just end up with the .wav files, the compression window shows for 1 sec before shutting down.
I cant get flac 1.3.1 to work with EAC in copy and test mode...
Just tried it with no problem. Is that really your complete commandline? You at least need a %source% at the end.
Ahh, no it was not complete command line BUT no %source% i see now. Can't remember removing it though ^^ Do I also need -o %dest% after %source%? Thanks for the help!
Do you mean with this git version they are smaller than they were with 1.3.0?
No. I mean they are smaller with this git version than with 1.3.1
Does anyone here know where to find deb files for Ubuntu 14.04?
You can search in this site : askubuntu.com. I once found it there.
You can search in this site : askubuntu.com. I once found it there.
Most of the time, I use a bash script to convert my audio files. In this script, I am now using wine to call flac. That works great, so I guess I'll be using that for the time being.
Thanks, Case. Is there any downside at all to upgrading? Is there a possibility that files encoded with the new version can't be read by certain players?
Since the file specification hasn't changed, all files produced by the new encoder will work the same as ones from the previous version. So there really isn't any downside.
Hopefully this remains to be true: http://lists.xiph.org/pipermail/flac-dev/2...ber/005370.html (http://lists.xiph.org/pipermail/flac-dev/2014-December/005370.html)
Aaand fixed! A patch to fix this has been merged in git
Thanks, Case. Is there any downside at all to upgrading? Is there a possibility that files encoded with the new version can't be read by certain players?
Since the file specification hasn't changed, all files produced by the new encoder will work the same as ones from the previous version. So there really isn't any downside.
Hopefully this remains to be true: http://lists.xiph.org/pipermail/flac-dev/2...ber/005370.html (http://lists.xiph.org/pipermail/flac-dev/2014-December/005370.html)
Aaand fixed! A patch to fix this has been merged in git
will there be an updated official flac version including this fix and the patches below in the near future?
https://git.xiph.org/?p=flac.git;a=commitdi...bf4e63f49647e69 (https://git.xiph.org/?p=flac.git;a=commitdiff;h=ac0b4b4cab42fdd5c010bac85bf4e63f49647e69)
http://git.xiph.org/?p=flac.git;a=commit;h...e29b5969d04be97 (http://git.xiph.org/?p=flac.git;a=commit;h=c97e057ee57d552a3ccad2d12e29b5969d04be97)
I would expect so, but it's hard to tell. There was one particular security fix which I think warrants a new release: http://sourceforge.net/p/flac/bugs/425/ (http://sourceforge.net/p/flac/bugs/425/)
But then again, I've been surprised in the past about the releases
oh cool!!!
Got http://aiz.free.fr/flac-git-e78accd.zip (http://aiz.free.fr/flac-git-e78accd.zip) -> "flac.exe" 750'094 2014-12-08 17:15 only ...
1.3.1 x32 for older intel from http://www.hydrogenaud.io/forums/index.php...st&p=882856 (http://www.hydrogenaud.io/forums/index.php...st&p=882856)
Seconds : 42 Milliseconds : 898
Can't find the attach ... has it been deleted ?
Hello,
git-bc1f15db (http://aiz.free.fr/flac-git-bc1f15db.zip) binaries (win32 & win64).
AiZ
Hello @AiZ, do you have a compile of the lastest commit of flac and/or libflac?
flac-fdc1ccf built with MinGW/GCC and Intel Compiler:
edit: Attachment removed by request (newer version available).
flac-fdc1ccf built with MinGW/GCC and Intel Compiler:
Do you know what has changed since to 1.3.1?
Mostly bugfixes. Maybe it'll also work slightly faster.
flac-fdc1ccf built with MinGW/GCC and Intel Compiler:
flac-fdc1ccf.7z
Looks like the GCC build (32 bits SSE2) needs the MSVC 2010 runtime (Msvcr100.dll).
Is it expected ?
No, it's my GCC was configured this way some time ago and I forget to revert the changes.
Here are the fixed executables:
Here are the fixed executables:
flac-fdc1ccf_v2.7z
Thanks :)
This GCC build now works without the need of any MSVC runtime.
However, the I just noticed the ICC build doesn't run on Windows XP.
Déjà vu: https://hydrogenaud.io/index.php?topic=109766.msg906816#msg906816
https://hydrogenaud.io/index.php/topic,111777.msg921585.html#msg921585
Thanks :)
This GCC build now works without the need of any MSVC runtime.
Actually it still requires msvcrt.dll, but this DLL is shipped with Windows, and there's no need to install additional runtimes.
However, the I just noticed the ICC build doesn't run on Windows XP.
Yes, they were built with default settings (Vista and SSE2 are required, IIRC).
Yes, they were built with default settings (Vista and SSE2 are required, IIRC).
Well, it's just a flag to turn on in the compiler:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
http://www.msfn.org/board/topic/172970-why-not-a-valid-win32-application-xp-programs/
Overwriting 06000000 with 05000100 at 150H and 158H makes it running on XP ;)
WinXP is completely outdated today, no need to support it. Vista+ is OK.
i wonder how john33 is doing? hope he is fine and his great compiles on rarewares is not yet history.
would be great to see a sign of life, maybe even updated vorbis and flac compiles over there ;)
No, it's my GCC was configured this way some time ago and I forget to revert the changes.
Here are the fixed executables:
Thank you very much lvqcl.
Is there an automated nightly builder for flac anywhere?