Skip to main content
Topic: FLAC v1.3.2 Final (Read 29823 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.3.2 Final

Reply #50
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.

Re: FLAC v1.3.2 Final

Reply #51
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.



Re: FLAC v1.3.2 Final

Reply #54
@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?

Re: FLAC v1.3.2 Final

Reply #55
@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

Re: FLAC v1.3.2 Final

Reply #56
Is there a way you can compile a build with the last two fixes as well, from 6 and 8 days ago? Thanks.

Re: FLAC v1.3.2 Final

Reply #57
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.

Re: FLAC v1.3.2 Final

Reply #58
Perfect, thank you, damn me that I never learned how to program or follow coding stuff.

Re: FLAC v1.3.2 Final

Reply #59
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

Re: FLAC v1.3.2 Final

Reply #60
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 and 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, no to re-encoding your existing FLAC music files.
Every night with my star friends / We eat caviar and drink champagne
Sniffing in the VIP area / We talk about Frank Sinatra
Do you know Frank Sinatra? / He's dead

Re: FLAC v1.3.2 Final

Reply #61
Very helpful indeed.  Thanks Maurits :)

Re: FLAC v1.3.2 Final

Reply #62
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 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.



Re: FLAC v1.3.2 Final

Reply #65
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).
Code: [Select]
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

Re: FLAC v1.3.2 Final

Reply #66
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:
Code: [Select]
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.

Re: FLAC v1.3.2 Final

Reply #67
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 reports that file is truncated. Link to corrupted flac file

Re: FLAC v1.3.2 Final

Reply #68
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 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).

 

 
SimplePortal 1.0.0 RC1 © 2008-2018