Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC 1.3.0 has been released (Read 190675 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC 1.3.0 has been released

Reply #25 –
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 (including SSE1 for CoRoNe).

FLAC 1.3.0 has been released

Reply #26 –
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.

FLAC 1.3.0 has been released

Reply #27 –
Quote from: Makaki on
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

FLAC 1.3.0 has been released

Reply #28 –
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
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

FLAC 1.3.0 has been released

Reply #29 –
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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FLAC 1.3.0 has been released

Reply #30 –
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.

FLAC 1.3.0 has been released

Reply #31 –
Quote from: john33 on
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-bit
Code: [Select]
Total 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-bit
Code: [Select]
Total 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

FLAC 1.3.0 has been released

Reply #32 –
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.

FLAC 1.3.0 has been released

Reply #33 –
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!

FLAC 1.3.0 has been released

Reply #34 –
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.

FLAC 1.3.0 has been released

Reply #35 –
anything to increase the speed and efficiency? No?

FLAC 1.3.0 has been released

Reply #36 –
Hmm weird... using the same settings as my previous 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?

FLAC 1.3.0 has been released

Reply #37 –
Quote from: hidn on
anything to increase the speed and efficiency? No?

Nope, just the newer compiler.  Otherwise, exactly the same compiler settings.

FLAC 1.3.0 has been released

Reply #39 –
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?
Was that a 1 or a 0?

FLAC 1.3.0 has been released

Reply #40 –
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.

FLAC 1.3.0 has been released

Reply #41 –
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).  Aside from developer-side improvements, and handling unicode characters on the Windows command line, the main libFLAC improvement was in the decoding speed (2).  Compression is not affected at all.

FLAC 1.3.0 has been released

Reply #42 –
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.
Was that a 1 or a 0?
 

FLAC 1.3.0 has been released

Reply #43 –
Quote from: Heliologue on
Aside from developer-side improvements, and handling unicode characters on the Windows command line, the main libFLAC improvement was in the decoding speed (2).  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!

FLAC 1.3.0 has been released

Reply #44 –
Quote from: john33 on
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.

FLAC 1.3.0 has been released

Reply #45 –
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"

FLAC 1.3.0 has been released

Reply #46 –
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?
I like to use "HD audio" in PaulStretch. "HD audio", lol.

FLAC 1.3.0 has been released

Reply #47 –
from the horse's mouth (spoon on the dbpoweramp forums)

Quote
Actually none of the changes would change dBpoweramps implementation (as the changes are to flac.exe and we use the library direct)...




FLAC 1.3.0 has been released

Reply #48 –
Thank you for clearing that up!
I like to use "HD audio" in PaulStretch. "HD audio", lol.

FLAC 1.3.0 has been released

Reply #49 –
Quote from: JJZolx on
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.