FLAC 1.3.2 released - 1 Jan 2017
Code improvements and hardening and many minor bug fixes. See the changelog for more information.
https://xiph.org/flac/changelog.html
https://xiph.org/flac/download.html
Seems like there are zero speed (except for "old Intel CPUs")/compression improvements.
No Windows build yet.
No Windows build yet.
There is :)
http://downloads.xiph.org/releases/flac/flac-1.3.2-win.zip
Seems like there are zero speed (except for "old Intel CPUs")/compression improvements.
Almost all the people who tested it during the pre-release phase reported small compression improvements. That will be down to that changed LPC order guess that is mentioned in the changelog.
Not yet! File not found ...
Looks like it's on the Xiph downloads page:
http://downloads.xiph.org/releases/flac/
Not yet! File not found ...
DL works for me too. But here is a mirror for you: https://mega.nz/#!O8Q1BZzQ!mwf6kYjdhlT0BcIuZ3Pk_rIFLJEtvyNtC7diH-r8Rik
(Just repacked to 7z to save bytes)
You can download from SourceForge.
Sources: https://sourceforge.net/projects/flac/files/flac-src/flac-1.3.2.tar.xz/download
Windows binaries: https://sourceforge.net/projects/flac/files/flac-win/flac-1.3.2-win.zip/download
There have been issues with some of the mirrors apparently but more should be updated by now: http://downloads.xiph.org/releases/flac/
To whom it may concern: I did some benchmarking with the official xiph build of flac v1.3.2.
- CPU: i5-2400 @ 3.1 GHz
- SSD: Samsung 850 EVO 250 GB
- OS: Windows 8.1 64 bit
- Compression: -8
(the timing was done with "timer64.exe", v14 by Igor Pavlov)
flac132_x86_xiph:
Kernel Time = 2.078 = 2%
User Time = 75.515 = 95%
Process Time = 77.593 = 98% Virtual Memory = 14 MB
Global Time = 78.839 = 100% Physical Memory = 14 MB
1.167.279.038 Bytes in 40 files
flac132_x64_xiph:
Kernel Time = 2.171 = 3%
User Time = 65.437 = 95%
Process Time = 67.609 = 98% Virtual Memory = 14 MB
Global Time = 68.857 = 100% Physical Memory = 13 MB
1.167.279.038 Bytes in 40 files
flac131_x64_xiph:
Kernel Time = 2.203 = 3%
User Time = 67.515 = 95%
Process Time = 69.718 = 98% Virtual Memory = 14 MB
Global Time = 70.808 = 100% Physical Memory = 13 MB
1.167.334.662 Bytes in 40 files
flac131_x64_icl:
Kernel Time = 2.187 = 3%
User Time = 68.156 = 95%
Process Time = 70.343 = 98% Virtual Memory = 14 MB
Global Time = 71.690 = 100% Physical Memory = 13 MB
1.167.334.662 Bytes in 40 files
flac131_x64-git-bc1f15db (AiZ):
Kernel Time = 2.281 = 3%
User Time = 67.171 = 95%
Process Time = 69.453 = 98% Virtual Memory = 14 MB
Global Time = 70.667 = 100% Physical Memory = 13 MB
1.167.279.038 Bytes in 40 files
Bottom line: In my test, although performed on an ancient CPU, Xiph's 64 bit build was the fastest encoder. And additionally saved some bytes ;) .
32 bit binary is significantly slower.
I've added tests of different other flac 1.3.1 binaries (collected in this (https://hydrogenaud.io/index.php/topic,107611.0.html) thread).
N.B. AiZ's binary was the fastest on my Core2 CPU...
Big thanks to the team (Eric, lvqcl, et al.)
.sundance.
[..]
In my test, although performed on an ancient CPU, Xiph's 64 bit build was the fastest encoder. And additionally saved some bytes ;) .
[..]
Thanks, that is interesting. I knew there had been some improvements that could benefit 64 bit performance but I hadn't expected the difference to be that big.
FLAC v1.3.2
Built on Jan 23 2017, GCC 6.3.0
commit : 0c741d59489c718d1e0f86ce51646da42e87a860 (2017-01-22)
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
https://github.com/xiph/flac
[..]
In my test, although performed on an ancient CPU, Xiph's 64 bit build was the fastest encoder. And additionally saved some bytes ;) .
[..]
Thanks, that is interesting. I knew there had been some improvements that could benefit 64 bit performance but I hadn't expected the difference to be that big.
FLAC uses some of the SS(S)E intrinsics, which benefit from having more vector registers in 64 bit mode IIRC.
@NetRanger:
Just ran my little test suite with your binary. No idea if it's got anything to do with the UPX compression used, but it performed significantly worse than xiph's official release:
24.01.2017:
flac-1.3.2_2017-01-22_x86_x64-gcc630 (upx):
Kernel Time = 2.203 = 2%
User Time = 79.296 = 95%
Process Time = 81.500 = 98% Virtual Memory = 15 MB
Global Time = 82.754 = 100% Physical Memory = 16 MB
flac132_x64_xiph:
Kernel Time = 2.359 = 3%
User Time = 65.187 = 94%
Process Time = 67.546 = 97% Virtual Memory = 14 MB
Global Time = 68.956 = 100% Physical Memory = 13 MB
.sundance.
@sundance :
Don't have a clue either. The Xiph binaries haven't been updated since the official release of v1.3.2. Don't know with what the Xiph's binaries have been compiled through.
Working on making a new set of FLAC binaries since there been a couple of updates on the source. Im using the 'media-autobuild_suite' for my compilation needs, Im a noob when it comes to setting up a compilation environment, so i use something finished instead. ;)
FLAC v1.3.2
Built on Jan 24, 2017, GCC 6.3.0
commit : 33f093ae2f9d850dfa4dc3e7b60fba282731f894 (2017-01-23)
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
https://github.com/xiph/flac
the icl compiles from rarewares (always) used to be the fastet for me. i dont know that much about compiling, so i wonder if this is true in general, or just a strange incident?
official build
Total encoding time: 0:05.886, 368.36x realtime
netranger gcc build
Total encoding time: 0:06.634, 326.83x realtime
How many flac 1.3.2 versions will come out this year?
I don't see much on the mailing list that suggest we need new compiles. Seems like several people change compiling behaviour but nothing worthwhile when you have a working 1.3.2 official compile.
In somewhat FLAC related news, Firefox 51 now supports FLAC. See https://www.mozilla.org/en-US/firefox/51.0/releasenotes/
How many flac 1.3.2 versions will come out this year?
There won't be any more 1.3.2 versions, all you're seeing is people making their own compiles of 1.3.2 for a variety of reasons.
There has been talk of a quick release of 1.3.3 to fix a few small bugs but that, if that even happens, will not be anything worth holding out for. It wouldn't amount to any notable differences to end users, only for some developers.
I encountered problem when using flac encoder 1.3.2 But 1.3.1 works OK. 1.3.2 cannot encode w64 file which is 24 bit, 96 kHz, 6 channels. Encoder gives out error "got partial sample". I tried official 1.3.2 windows 32 bit compile from xiph.org and also compile from foobar2000 free encoder pack. Results are the same. I also created ticket on sourceforge - https://sourceforge.net/p/flac/bugs/453
Unfortunately sample file is very big (4.11 GB), because i cannot reproduce problem with small files.
Sample: w64 - https://drive.google.com/open?id=0B5sV6iTkjJSsNHJHVjE3RG5TMFU (https://drive.google.com/open?id=0B5sV6iTkjJSsNHJHVjE3RG5TMFU), and same file compressed with wavpack - https://drive.google.com/open?id=0B5sV6iTkjJSsbWRCWGRZcG9zWkk (https://drive.google.com/open?id=0B5sV6iTkjJSsbWRCWGRZcG9zWkk)
BE CAREFUL, FILE CONTAINS WHITE NOISE!
Thanks for reporting before they release the next version. While waiting for that you can download a fixed 1.3.2 from the attachment.
While waiting for that you can download a fixed 1.3.2 from the attachment.
Thanks. Fix confirmed. Free encoded pack probably also should be updated/changed.
I think Free Encoder Pack can wait for the next official release, which I have understood isn't far away. The bug shouldn't affect use with foobar's converter since WAV format can't feed the encoder 64-bit numbers that triggered the problem.
The bug shouldn't affect use with foobar's converter since WAV format can't feed the encoder 64-bit numbers that triggered the problem.
But actually i first encountered problem with this file when tried to convert it with foobar2000. Now i tested it one more time in foobar's converter with flac from encoder pack to be sure. Yes, problem exists in foobar2000 converter with flac from encoder pack, but not with your fixed version. Difference is that problem appears closer to the end of file, not in beginning, when using foobar's converter.
1 out of 1 tracks converted with major problems.
Source: "C:\Windows\System32\d;\music\noise.w64"
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "G:\noise.flac"
Additional information:
Encoder stream format: 96000Hz / 6ch / 24bps
Command line: "D:\0__CODECS\LOSSLESS\FLAC\flac-1.3.2 NO SSE2\flac.exe" -s --channel-map=none --ignore-chunk-sizes -8 -V - -o "noise.flac"
Working folder: G:\
Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters
That changes things. I'll give Peter a new version and hopefully he can update the pack soon.
Would be nice to see up-to-date FLAC libraries (libflac.dll - e.g. for use in eac3to) on RareWares as well.
FLAC compiles updated on Rarewares to latest GIT 1.3.2. These are probably no faster than the official release but do incorporate all the updates subsequent to the release, of which there have been many. :)
FLAC compiles updated on Rarewares to latest GIT 1.3.2.
Thanks! :)
FLAC v1.3.2-Git-2017-03-16
Built on Mar 17, 2017, GCC 6.3.0
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-03-20
Built on Mar 22, 2017, GCC 6.3.0
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-04-08
Built on Apr 08, 2017, GCC 6.3.0
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
Thanks for compiling new builds NetRanger, do you see any speed difference when converting between yours and the Intel compiles?
@eahm - Don't really bother about speed when i encode audio, so i haven't looked into it.
FLAC v1.3.2-Git-2017-04-09
Built on Apr 10, 2017, GCC 6.3.0
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
Maybe a stupid question, but how do we know unofficial git builds does not "break" something?
When there aren't a new stable release with a version number; can we be sure no corruption or errors occure?
In other words: Are these binaries considered beta/ test, or "daily driver"?
Maybe a stupid question, but how do we know unofficial git builds does not "break" something?
encoding options:
-V, --verify Verify a correct encoding by decoding the output in parallel and comparing to the original
...At least for the encoded bits.
For those that want another option, here are 64-bit windows binaries, etc. from the 9 April 2017 source:
https://40th.com/jb/flac_gpl/files/
or build your own from what's there.
Maybe a stupid question, but how do we know unofficial git builds does not "break" something?
You don't know that short of testing each build yourself.
In other words: Are these binaries considered beta/ test, or "daily driver"?
They're just unofficial binaries people post online. They're not considered anything.
Maybe a stupid question, but how do we know unofficial git builds does not "break" something?
encoding options:
-V, --verify Verify a correct encoding by decoding the output in parallel and comparing to the original
Although I doubt that the following will ever be an issue, then this is in principle not a safe way to test an application. Suppose somewhere in the code the encoding is done wrong (think of "1 000 000" by mistake being encoded as "ten" rather than "million") and the code is recycled for the decoding: the "ten" is decoded to "1 000 000" and the verify option gives thumbs up.
I would be very surprised to see anything like that in the official FLAC source. (On the other hand, I suppose anything of that kind could happen to a DIY port by created by an endianness-ignorant idiot like myself, but I digress.) But there is a reason that one writes software test suites independently.
Of course --verify guards against a helluvalot of other thinkable errors, some of which are not even related to the application itself.
For those that want another option, here are 64-bit windows binaries, etc. from the 9 April 2017 source:
https://40th.com/jb/flac_gpl/files/
I can't download 20170409_xiph_flac_bin_winx64.zip, I got this error message:
403 Forbidden
You don't have permission to access /jb/flac_gpl/files/20170409_xiph_flac_bin_winx64.zip on this server.
No problem with the other files though.
FLAC v1.3.2-Git-2017-04-16
Built on Apr 18, 2017, GCC 6.3.0
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-04-19
Built on Apr 20, 2017, GCC 6.3.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-05-03
Built on May 06, 2017, GCC 6.3.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-05-27
Built on May 27, 2017, GCC 6.3.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-06-11
Built on June 18, 2017, GCC 6.3.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
As most of the recent posts are not about FLAC 1.3.2 at all but rather about the latest GIT version, wouldn't it be a good idea to create a new topic specifically about the latest GIT builds?
Perhaps an admin could split it off so old posts are kept?
FLAC v1.3.2-Git-2017-07-01
Built on July 05, 2017, GCC 7.1.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2017-07-19
Built on July 22, 2017, GCC 7.1.0
32 & 64-bit Windows Binaries
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
I remember this was asked in the past but I'm not sure where at this point, will FLAC ever support 8+ channels? I am asking for the ATMOS audio tracks, are the extra channels over 7.1 different channels or just extra information from these channels? Thanks.
I remember this was asked in the past but I'm not sure where at this point, will FLAC ever support 8+ channels?
I think the limit is 8, however for practical purposes, I think if you wanted to encode some ridiculous number of channels you'd probably just encode them as independent channel pairs inside a container.
I am asking for the ATMOS audio tracks, are the extra channels over 7.1 different channels or just extra information from these channels? Thanks.
https://en.wikipedia.org/wiki/Dolby_Atmos#Home_theater_implementation_details_-_differences_from_commercial_installations
FLAC v1.3.2 (Git 2017-12-04)
Built on January 14, 2018, GCC 7.2.0
Latest commit : a0027fa
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
https://github.com/xiph/flac
@NetRanger thanks for the updated build, the two dates mean the build has all the updates up to 2017-12-04 or 2018-01-14?
@NetRanger thanks for the updated build, the two dates mean the build has all the updates up to 2017-12-04 or 2018-01-14?
It has all the updates up to 2017-12-04 and is built/compiled 2018-01-14
Is there a way you can compile a build with the last two fixes as well, from 6 and 8 days ago? Thanks.
Is there a way you can compile a build with the last two fixes as well, from 6 and 8 days ago? Thanks.
They're included. Have a look here
https://github.com/xiph/flac/commits/master
Seems like that dates is different on Github & Xiph.org's flac.git. I took the dates from Github flac.git
Im using media-autobuild_suite for my compilation needs. Will have a look 2morrow to see what repository the script uses to get the source from.
Perfect, thank you, damn me that I never learned how to program or follow coding stuff.
Hi all
Sorry to butt in with a simple question... How important is it to update to the latest version of FLAC? When I rip CDs, I still rip to version 1.2.1. What's the downside to this? Should I look to change it and keep up with the times or am I ok as I am? If changing, what will the benefits be? And should I be thinking about changing my existing FLACs to a more recent version (if that's even possible)?
Cheers
Hi all
Sorry to butt in with a simple question... How important is it to update to the latest version of FLAC? When I rip CDs, I still rip to version 1.2.1. What's the downside to this? Should I look to change it and keep up with the times or am I ok as I am? If changing, what will the benefits be? And should I be thinking about changing my existing FLACs to a more recent version (if that's even possible)?
Cheers
The effect on the resulting files will not be very big. There is no difference to audio quality as all FLAC files made by any FLAC version are lossless. One thing you might see is a difference in size, files encoded with newer version could be slightly smaller as modern FLAC encoders are slightly more efficient. Encoding with newer versions is faster too.
If you are on Windows I would say there is a good reason to update as there are two security issue with FLAC encoders older than 1.3.1 (CVE-2014-9028 (https://www.cvedetails.com/cve/CVE-2014-9028/) and CVE-2014-8962 (https://www.cvedetails.com/cve/CVE-2014-8962/) if you're interested in that sort of stuff).
As for your last question, there is no real reason to encode your existing FLAC files to a new version. It would be a lot of hassle and time while at best you would regain a few percent in storage space.
In short, yes to updating your FLAC encoder to the latest version (https://xiph.org/flac/download.html), no to re-encoding your existing FLAC music files.
Very helpful indeed. Thanks Maurits :)
If changing, what will the benefits be? And should I be thinking about changing my existing FLACs to a more recent version (if that's even possible)?
Re-encoding is possible and should be lossless. But beware that the FLAC frontend, which is a tool that I guess people would employ, has eaten several of my files (https://hydrogenaud.io/index.php/topic,99803.msg921798.html#msg921798) even if I asked it to verify. My paranoia and my backup drive saved those, though.
Also, I do unfortunately have a couple of corrupted FLAC files. Re-encoding produces a "technically valid" FLAC file "with the corrupted content", and I do not want them to show up as OK, so I did not re-encode those.
That were the caveats I think.
As for "benefits", my reason was cosmetic: when highlighting a bunch of files in my media player (foobar2000), it would show as "Tool" a bunch of different "reference libFLAC" versions before and in between the lossies, which made that view harder to read. I did of course not transcode the lossies, but I could and did get all the different "reference libFLAC" versions (from 1.1.4 and up) down to a single one.
Saving space? Likely not enough to bother. Unless you encoded at say "-0" (some do, often by misunderstanding encoding speed vs decoding speed), or had a habit of embedding enormous picture files, which you later have deleted (I do not think many applications can "reclaim" such wasted space?) or your hard drive is so full that you really want to squeeze out that last drop.
FLAC v1.3.2 (Git 2018-01-08)
Built on January 17, 2018, GCC 7.2.0
Latest commit included : a0027fa
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
NOTE :
This is a recompile i made to be on the safe side. This should have the same contents as my previous post above.
FLAC v1.3.2 (Git 2018-02-10)
Built on February 11, 2018, GCC 7.3.0
Latest commit included : 45f7d41
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
I'm using 20180209__flac-HEAD-45f7d41.tar.gz and this CreateFile code (bottom) is called by grabbag__file_are_same(infilename, outfilename), resulting in the create-always of the files being compared, even if neither exist. In this case, the output.flac is being written, and so cannot be later created (sharing violation/EACCESS) when the output file is created. My compiler _MSC_VER is 1912. The #else case uses the passed in dwCreationDisposition (e.g., OPEN_EXISTING).
HANDLE WINAPI flac_internal_CreateFile_utf8(...){
#if _MSC_VER > 1900 && WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
...
handle = CreateFile2(wname, dwDesiredAccess, dwShareMode, CREATE_ALWAYS, NULL);
#else
...
Also, it needs to return handle for that #if _MSC_VER > 1900 case:
...\windows_unicode_filenames.c(220): warning C4716: 'flac_internal_CreateFile_utf8': must return a value
For those that want another option, here are 64-bit windows binaries, etc. from the 9 April 2017 source:
https://40th.com/jb/flac_gpl/files/
I can't download 20170409_xiph_flac_bin_winx64.zip, I got this error message:
403 Forbidden
You don't have permission to access /jb/flac_gpl/files/20170409_xiph_flac_bin_winx64.zip on this server.
No problem with the other files though.
Took a while to look for this problem (but only a minute to find it once I did; it was the first place I looked-ha)
https://github.com/xiph/flac/commit/94a61241b02064c7d9fe508f72a742f2a90b8492
(may as well mention this new one
https://github.com/xiph/flac/commit/972454edf8ac5773955a63d97f83970267093613#commitcomment-27806056
which is not a nice one).
The packages are at the same place as before, but only flac2112.exe and metaflac.exe. The complete set of (older/) 32-bits are there, though.
It seems that flac.exe -t is unable to detect some kinds of corruption in flac files without md5 checksum. I have file for which flac.exe only complains about missing md5 checksum, while foobar2000 with foo_verifier reports "Reported length is inaccurate" and Audiotester (http://www.vuplayer.com/other.php) reports that file is truncated. Link to corrupted flac file (https://www.dropbox.com/s/9mjk4ez98lom6bs/corrupted.flac?dl=1)
If changing, what will the benefits be? And should I be thinking about changing my existing FLACs to a more recent version (if that's even possible)?
Re-encoding is possible and should be lossless. But beware that the FLAC frontend, which is a tool that I guess people would employ, has eaten several of my files (https://hydrogenaud.io/index.php/topic,99803.msg921798.html#msg921798) even if I asked it to verify. My paranoia and my backup drive saved those, though.
Also, I do unfortunately have a couple of corrupted FLAC files. Re-encoding produces a "technically valid" FLAC file "with the corrupted content", and I do not want them to show up as OK, so I did not re-encode those.
That were the caveats I think.
As for "benefits", my reason was cosmetic: when highlighting a bunch of files in my media player (foobar2000), it would show as "Tool" a bunch of different "reference libFLAC" versions before and in between the lossies, which made that view harder to read. I did of course not transcode the lossies, but I could and did get all the different "reference libFLAC" versions (from 1.1.4 and up) down to a single one.
Saving space? Likely not enough to bother. Unless you encoded at say "-0" (some do, often by misunderstanding encoding speed vs decoding speed), or had a habit of embedding enormous picture files, which you later have deleted (I do not think many applications can "reclaim" such wasted space?) or your hard drive is so full that you really want to squeeze out that last drop.
Why would you even sort or group by "tool"? (Isn't "format" enough?)
re. corruption: Isn't there a switch which will abort encoding if a corrupted file is encountered? (--no-decode-through-errors, --warnings-as-errors)
re. wasted space: foobar2000 has the ability to remove extra padding from FLAC files. It's also easy to implement yourself if you want, FLAC file format is quite simple and reasonable (on the outer level, without looking into the actual compression of audio data — which is enough here).
FLAC v1.3.2 (Git 2018-04-08)
Built on April 11, 2018, GCC 7.3.0
Latest commit included : 98deaf1
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git 2018-04-30)
Built on May 03, 2018, GCC 7.3.0
Latest commit included : 2817eca
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
NetRanger: your builds are appreciated, thanks and please keep posting them.
FLAC v1.3.2 (Git 2018-05-06)
Built on May 09, 2018, GCC 7.3.0
Latest commit included : 85fca3c
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git 2018-05-23)
Built on May 28, 2018, GCC 7.3.0
Latest commit included : 01eb197
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git 2018-06-10)
Built on June 14, 2018, GCC 7.3.0
Latest commit included : 452a447
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
Thanks for the build again, why is sox.exe included too now?
Thanks for the build again, why is sox.exe included too now?
A little mistake when adding the files to the archive....... ;) :D
FLAC v1.3.2 (Git 2018-08-20)
Built on August 13, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)
Latest commit included : cdb030c
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
Hmm, I'm kinda wondering, if FLAC will ever be expanded beyond 8 channels. I was looking into shoe-horning more channels into FLAC, breaking the spec, but I've only seen projects that gave up.
Hmm, I'm kinda wondering, if FLAC will ever be expanded beyond 8 channels. I was looking into shoe-horning more channels into FLAC, breaking the spec, but I've only seen projects that gave up.
FLAC in Matroska?
FLAC in Matroska?
Good call. I'll check it out if it works for me. Would be nice if more hardware supported Matrsoska, though.
FLAC v1.3.2 (Git 2018-08-25)
Built on August 27, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)
Latest commit included : 0897458
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC in Matroska?
Good call. I'll check it out if it works for me. Would be nice if more hardware supported Matrsoska, though.
Would be quite a scenario if your hardware does support FLAC and does support > 8 channels, but not Matroska ...
ffmpeg has experimental support for FLAC-in-mp4, but I don't know if anything would play it.
If WavPack is an option, then I see a list of 18 channels at http://www.wavpack.com/wavpack_doc.html
Should maybe the Lossless comparison wiki article be updated with channel limitations?
https://wiki.hydrogenaud.io/index.php?title=Lossless_comparison
Would be quite a scenario if your hardware does support FLAC and does support > 8 channels, but not Matroska ...
ffmpeg has experimental support for FLAC-in-mp4, but I don't know if anything would play it.
If WavPack is an option, then I see a list of 18 channels at http://www.wavpack.com/wavpack_doc.html
Management decision, so to say. I use FLAC to save the panadapter section of my ham radio receiver. Using FLAC makes it relatively easy, because I can handle it like any other sound file in things like Audacity, and I can still use the 655MHz bandpass FLAC allows to encode the entirety of my 10MHz window maximum of baseband. Why the >8 Channels I hear you ask? Because I'm using up to 20 of these windows side-by-side (20 receivers). Putting them all into one file (as they're recorded simultaneously), is just more convenient.
Management decision, so to say. I use FLAC to save the panadapter section of my ham radio receiver. Using FLAC makes it relatively easy, because I can handle it like any other sound file in things like Audacity, and I can still use the 655MHz bandpass FLAC allows to encode the entirety of my 10MHz window maximum of baseband. Why the >8 Channels I hear you ask? Because I'm using up to 20 of these windows side-by-side (20 receivers). Putting them all into one file (as they're recorded simultaneously), is just more convenient.
Huh, now you made me read specs ... So FLAC has max 8 channels (so obviously not intended for multitrack recording, hm? To the level where they could not afford even a full byte?). Good news is that you can set the number of samples to zero for "unknown", since then you are not bound by the less-than-an-hour 2^36 samples for 20 MHz sampling rate.
WavPack on the other hand provides for custom sampling rates and 256 channels - but is not supported by Audacity. According to https://wiki.audacityteam.org/wiki/FFmpeg_integration#table , Audacity can read WavPack by way of ffmpeg - but not write. IDK whether that is an ffmpeg limitation, but the ffmpeg doc says it only supports WavPack encoding at 32-bits integer, and that was maybe not what you wanted.
But same source claims Audacity can read & write .mka by way of ffmpeg, so why not try your luck at FLAC ...
@Porcus Yeah, I thought I'd use MPEG-4 ALS, too, but it seems that there's very little software support. MPEG-4 SLS is a similar problem, also it seems the specs aren't fully determined.
I was looking into WavPack, too. 1Hz - 16.777MHz sampling rate, 256 channels.
The more obscure formates, like True Audio are a lot better: 0 (DC) - 4GHz sampling rate, up to 65535 channels (same specs as MPEG-4 ALS). Unfortunatelly, those formats are also not the best when it comes to software support. I mainly handle them in command line, too, as in this case latency isn't really much of an issue, etc. For Recording I use either FFmpeg or SoX.
One other thing I forgot to mention in my previous post:
I prefer command line programs doing one thing but doing that rather convenient. I know FFmpeg is fully featured and everything, combines everything into one thing, nice, etc. but tbh. I prefer having a flac, opusenc, or an mkvmerge.
SoX is almost always my go-to solution, when something has to be rigged up there and then. I found myself numerous times having to fix something up, so it "just records" or "just converts" something. Having something "just stream" a video, I did that a couple times with FFmpeg. Some things I can only do with FFmpeg, short of using libavf and libavcodec in my own program.
FLAC v1.3.2 (Git 2018-09-02)
Built on September 16, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)
Latest commit included : faafa4c
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git 2018-09-19)
Built on September 21, 2018, GCC 7.3.0(32bit)/8.2.0(64bit)
Latest commit included : 421961f
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git-2019-02-01)
Built on February 04, 2019, GCC 7.4.0(32bit)/8.2.1(64bit)
Latest commit included : cc15b74
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2 (Git-2019-03-07)
Built on March 10, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : 12ec86c
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
To whom it may concern - https://github.com/xiph/flac/issues/100
Remove Visual Studio project files
Once the CMake build system has been merged (#97) it should be possible to remove the VS project files. Posting this idea here so that people can comment.
The VS project files will not be done until after the next release, which will contain both the CMake build system and the existing VS project files.
VS2017 and later has integrated CMake support in the IDE so you don't need to install CMake nor you don't need to run it manually. You just open the folder from the IDE instead of the MSBuild solution file.
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
Nevertheless, it doesn't mean CMake is abstracted away from the IDE.
Usually you want to pass some build options to cmake or something, but they are not configurable as in the ordinary Visual Studio project settings, so you have to know CMake to some extent, and you have to look for the available options in the project (by digging CMakeLists.txt in the project tree).
FLAC v1.3.2 (Git-2019-03-07)
Built on March 10, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : 12ec86c
But there is some benefit using this build? I only noticed now...I'm using FLAC 1.3.2 released - 1 Jan 2017 from xiph site. Release from xiph.org it's a good choice anyway compared to FLAC v1.3.2 (Git-2019-03-07)?
But there is some benefit using this build? I only noticed now...I'm using FLAC 1.3.2 released - 1 Jan 2017 from xiph site. Release from xiph.org it's a good choice anyway compared to FLAC v1.3.2 (Git-2019-03-07)?
32 bit windows build from 1 Jan 2017 has bug: it can't encode if source wav(w64) file is bigger than 4 GB. It was fixed later in git. Also current git version contains fastCRC patch that slightly increases encoding speed.
VS2017 and later has integrated CMake support in the IDE so you don't need to install CMake nor you don't need to run it manually. You just open the folder from the IDE instead of the MSBuild solution file.
https://docs.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?view=vs-2019
Apparently useless for the one use case I have in a different project, namely integrating a project into a non-CMake solution tree.
FLAC v1.3.2 (Git-2019-05-04)
Built on May 04, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : 95a9423
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
Thanks NR :D
FLAC v1.3.2 (Git-2019-05-04)
Built on May 04, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : 95a9423
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
You thought about posting any Clang builds?
FLAC v1.3.2 (Git-2019-05-04)
Built on May 04, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : 95a9423
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
You thought about posting any Clang builds?
Im using 'media-autobuild_suite' for all my compiling needs and there's no clang in that suite so..........
But there is some benefit using this build? I only noticed now...I'm using FLAC 1.3.2 released - 1 Jan 2017 from xiph site. Release from xiph.org it's a good choice anyway compared to FLAC v1.3.2 (Git-2019-03-07)?
32 bit windows build from 1 Jan 2017 has bug: it can't encode if source wav(w64) file is bigger than 4 GB. It was fixed later in git. Also current git version contains fastCRC patch that slightly increases encoding speed.
I'm on windows 64bit and obviously using 1.3.2 win64 version. So my last question is: is it safe stay with currently version or is better switch to
@NetRanger version?
If you need to ask you should stick with the current official version.
FLAC v1.3.2 (Git-2019-05-12)
Built on May 12, 2019, GCC 7.4.0(32bit)/8.3.0(64bit)
Latest commit included : e4b94e3
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
If you need to ask you should stick with the current official version.
I got it! Thanks korth! ;)
FLAC v1.3.2-Git-2019-05-28
Built on May 30, 2019, GCC 9.1.0
Latest commit included : 77e234a
https://xiph.org/flac/
https://git.xiph.org/?p=flac.git;a=summary
https://github.com/xiph/flac/commits/master (mirror)
FLAC v1.3.2-Git-2019-05-31
Built on June 01, 2019, GCC 9.1.0
Latest commit included : cd03042
https://xiph.org/flac/
https://github.com/xiph/flac/commits/master
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2019-07-15
Built on July 16, 2019, GCC 9.1.0
Latest commit included : deb21bc
https://xiph.org/flac/
https://github.com/xiph/flac/commits/master
https://git.xiph.org/?p=flac.git;a=summary
FLAC v1.3.2-Git-2019-07-16
Built on July 18, 2019, GCC 9.1.0
Latest commit included : fcabd81
https://xiph.org/flac/
https://github.com/xiph/flac/commits/master
https://git.xiph.org/?p=flac.git;a=summary
1.3.3 is around as rc3 meanwhile http://lists.xiph.org/pipermail/flac-dev/2019-July/006411.html
I have been testing NetRangers builds for some time. But Exact Audio Copy displays an error message from time to time.
(https://i.imgur.com/rD54jEu.png)
I have not had any issues with the latest build from rarewares (flac-1.3.2-git-20181116-x64.zip).
What could the issue be?
I'm on win 7 x64, using Exact Audio Copy 1.3 and FLAC-1.3.2-Git-2019-07-16_Win_GCC910.7z. Using -8 -V %source% -o %dest% as compression option
If you try and re encode the same track that is throwing the error does it work?
1.3.3 is around as rc3 meanwhile http://lists.xiph.org/pipermail/flac-dev/2019-July/006411.html
That's great news :)
I have been testing NetRangers builds for some time. But Exact Audio Copy displays an error message from time to time.
<snip>
Never ran into any enconing issues with my compiles. That's the first time i recall seeing any issue been brought up
Im on Win 7 x64 & Win 10 x64.
If you try and re encode the same track that is throwing the error does it work?
Yes, it does. I told EAC to compress wav, no problem, using FLAC-1.3.2-Git-2019-07-16_Win_GCC910.7z
Could it be some instability with your system? overheating maybe.
No problems with heat, CPU is about 30 Celsius at ideal. And bout 47 Celsius at full load on the hottest core.
I haven't had a BSOD or system freeze in a long time, I think it was about two years ago when I had a BSOD the last time, caused by some bad USB3 drivers, but that was fixed with newer drivers.
Maybe the antivirus could be the one causing trouble, I don't know for sure.
I ran memtest over night earlier this year, no problems found.
Anyway, I'll stick to the rarewares build for now.
Thank you for your reply :)
Version 1.3.3 master :D
https://git.xiph.org/?p=flac.git;a=summary
Win x86 & x64 builds up @ rw:
Compiles updated to the 1.3.3 release. Intel-19 - 32 and 64 bit compiles for Windows.
http://rarewares.org/