IPB

Welcome Guest ( Log In | Register )

4 Pages V  < 1 2 3 4 >  
Reply to this topicStart new topic
FLAC 1.3.0 has been released, the most popular lossless audio codec
lamedude
post May 31 2013, 09:30
Post #26





Group: Members
Posts: 13
Joined: 2-January 12
Member No.: 96171



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).
Go to the top of the page
+Quote Post
Makaki
post Jun 1 2013, 22:35
Post #27





Group: Members
Posts: 52
Joined: 20-May 13
Member No.: 108227



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.
Go to the top of the page
+Quote Post
obla4ko
post Jun 1 2013, 23:27
Post #28





Group: Members
Posts: 2
Joined: 28-December 05
Member No.: 26705



QUOTE (Makaki @ Jun 2 2013, 01:35) *
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
Go to the top of the page
+Quote Post
Wombat
post Jun 2 2013, 01:53
Post #29





Group: Members
Posts: 951
Joined: 7-October 01
Member No.: 235



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
Go to the top of the page
+Quote Post
Seren
post Jun 2 2013, 02:39
Post #30





Group: Members
Posts: 48
Joined: 1-November 12
Member No.: 104244



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) blink.gif

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This post has been edited by Seren: Jun 2 2013, 02:56
Go to the top of the page
+Quote Post
john33
post Jun 2 2013, 10:51
Post #31


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3736
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Compact Dick
post Jun 2 2013, 12:55
Post #32





Group: Members
Posts: 157
Joined: 6-April 02
Member No.: 1707



QUOTE (john33 @ Jun 2 2013, 09:51) *
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. smile.gif

Cheers smile.gif Here are the results of the updated binaries, using foobar2000 as a front-end. The same WAV file was encoded thrice:

32-bit
CODE
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
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 smile.gif
Go to the top of the page
+Quote Post
aztec_mystic
post Jun 2 2013, 13:01
Post #33





Group: Members
Posts: 93
Joined: 28-March 13
Member No.: 107425



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.

This post has been edited by aztec_mystic: Jun 2 2013, 13:03
Go to the top of the page
+Quote Post
john33
post Jun 2 2013, 13:30
Post #34


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3736
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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

@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!

This post has been edited by john33: Jun 2 2013, 14:01


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
skamp
post Jun 2 2013, 13:39
Post #35





Group: Developer
Posts: 1344
Joined: 4-May 04
From: France
Member No.: 13875



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.

This post has been edited by skamp: Jun 2 2013, 13:53


--------------------
caudec.net
Go to the top of the page
+Quote Post
hidn
post Jun 2 2013, 21:16
Post #36





Group: Members
Posts: 53
Joined: 17-April 08
Member No.: 52847



anything to increase the speed and efficiency? No?
Go to the top of the page
+Quote Post
Seren
post Jun 2 2013, 21:41
Post #37





Group: Members
Posts: 48
Joined: 1-November 12
Member No.: 104244



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?
Go to the top of the page
+Quote Post
john33
post Jun 2 2013, 22:03
Post #38


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3736
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (hidn @ Jun 2 2013, 21:16) *
anything to increase the speed and efficiency? No?

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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Compact Dick
post Jun 2 2013, 22:10
Post #39





Group: Members
Posts: 157
Joined: 6-April 02
Member No.: 1707



QUOTE (Seren @ Jun 2 2013, 20:41) *
Those who were reporting a slower x64 build, were you using win8 or win7?

Windows 8 Pro.
Go to the top of the page
+Quote Post
DigitalMan
post Jun 5 2013, 03:03
Post #40





Group: Members
Posts: 481
Joined: 27-March 02
From: California, USA
Member No.: 1631



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?

This post has been edited by DigitalMan: Jun 5 2013, 03:05


--------------------
Was that a 1 or a 0?
Go to the top of the page
+Quote Post
db1989
post Jun 5 2013, 03:26
Post #41





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



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.
Go to the top of the page
+Quote Post
Heliologue
post Jun 5 2013, 16:59
Post #42





Group: Members
Posts: 100
Joined: 17-September 06
Member No.: 35303



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.
Go to the top of the page
+Quote Post
DigitalMan
post Jun 5 2013, 22:56
Post #43





Group: Members
Posts: 481
Joined: 27-March 02
From: California, USA
Member No.: 1631



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?
Go to the top of the page
+Quote Post
db1989
post Jun 5 2013, 23:05
Post #44





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



QUOTE (Heliologue @ Jun 5 2013, 16:59) *
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!
Go to the top of the page
+Quote Post
Brazil2
post Jun 7 2013, 13:01
Post #45





Group: Members
Posts: 121
Joined: 9-May 10
Member No.: 80499



QUOTE (john33 @ Jun 2 2013, 11:51) *
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 smile.gif
From the few tests I've done the ICL 13 build is as fast as Ktf's GCC build.
Go to the top of the page
+Quote Post
JJZolx
post Jun 11 2013, 19:13
Post #46





Group: Members
Posts: 379
Joined: 26-November 04
Member No.: 18345



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"

Go to the top of the page
+Quote Post
Sparktank
post Jun 13 2013, 03:57
Post #47





Group: Members
Posts: 16
Joined: 31-July 12
Member No.: 101901



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?
Go to the top of the page
+Quote Post
marc2003
post Jun 13 2013, 07:43
Post #48





Group: Members
Posts: 4337
Joined: 27-January 05
From: England
Member No.: 19379



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)...




Go to the top of the page
+Quote Post
Sparktank
post Jun 13 2013, 07:56
Post #49





Group: Members
Posts: 16
Joined: 31-July 12
Member No.: 101901



Thank you for clearing that up!


--------------------
I like to use "[i]HD audio[/i]" in PaulStretch. "HD audio", lol.
Go to the top of the page
+Quote Post
db1989
post Jun 13 2013, 08:03
Post #50





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



QUOTE (JJZolx @ Jun 11 2013, 19:13) *
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. biggrin.gif
Go to the top of the page
+Quote Post

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

 



RSS Lo-Fi Version Time is now: 25th April 2014 - 02:35