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


Re: FLAC v1.3.3

Reply #2
Thanks NR  :D

Re: FLAC v1.3.3

Reply #3
In case anyone's wondering, this release does not contain any improvements in compression (or at least not at --best), so there's no utility in re-encoding your existing 1.3.x files.

I am, however, pleased that it should no longer spam my console output when I specify -f --no-error-on-compression-fail.


Re: FLAC v1.3.3

Reply #4
I did a VS 2017 compile done from the source of the official 1.3.3 Xiph release.
I don't do these things often atm. It would be nice someone can check it.
It should be a bit faster against a GCC version.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.3.3

Reply #5
I did a VS 2017 compile done from the source of the official 1.3.3 Xiph release.
I don't do these things often atm. It would be nice someone can check it.
It should be a bit faster against a GCC version.
Works OK on Windows 7 32 bit and core i3 3245. Indeed a bit faster than build from NetRanger - ~156x vs ~148x

Re: FLAC v1.3.3

Reply #6
Wombat's build is indeed a bit faster compared to NetRanger's build.
Same file encoded at level 8
Wombat's build: 174,91x
NetRanger's build: 156.85x

BTW, using x64

Re: FLAC v1.3.3

Reply #7
Thanks for testing how it works in w32 and x64!
This compile i only did because i see no sign of official 1.3.3 Windows binaries and some may also like these.
In no way i want to compete with Netranger and his nice effort to always deliver recent GIT builds. Cheers!
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: FLAC v1.3.3

Reply #8
Can I know what's the difference between NR binaries and those at Rarewarez? The latter seem be bigger.

Re: FLAC v1.3.3

Reply #9
Made with different compliers.  John33 use ICL for his compiles.

Re: FLAC v1.3.3

Reply #10
Is there going to be an official FLAC 1.3.3 version that gets released on the official site?



Re: FLAC v1.3.3

Reply #13
'erikd' haven't pushed it yet on Github.
https://github.com/xiph/flac/pull/119
Thanks for the info.
The compiled versions report as libFLAC 1.3.3 20190804 and one day later as libFLAC 1.3.4 20190805
I wonder why 1.3.4 didn't make it to any official xiph page yet?

https://github.com/xiph/flac/issues/111#issuecomment-521431000

Re: FLAC v1.3.3

Reply #14
Quote
Verion 1.3.3 was borked because the version number in CMakeLists.txt did
not get updated.
So, Erik cares about typo in CMakeLists.txt, but he doesn't care about fact that offical site still hosts 32-bit binary of 1.3.2 for windows with bug (that was fixed in git more than 2 years ago) that prevents encoding  on 32-bit system if size of source PCM stream is larger than 4GB?

Re: FLAC v1.3.3

Reply #15
Erik has already made it quite clear that he couldn't care any less about proprietary ("dead") operating systems.

Re: FLAC v1.3.3

Reply #16
BTW, FLAС still needs --channel-map=none to encode some non-standard channels configurations (e.g. 4.1) and still --channel-map=none is not documented.

Re: FLAC v1.3.3

Reply #17
I discovered some 24-bit WAV files that are NOT decoded properly after encoding-decoding using the flac 1.3.3 Windows 64-bit binaries at rarewares. Specifically the fmt chunk is messed up and does not contain the correct information. Unfortunately they are wav files I cannot release to the public. Flac 1.3.2 from xiph works correctly.

Re: FLAC v1.3.3

Reply #18
More specifically, the original wav header looks like this:

Code: [Select]
52 49 46 46 86 8C 80 02 57 41 56 45    RIFF†Œ€.WAVE

But after encoding and decoding with flac 1.3.3 it looks like this:

Code: [Select]
52 49 46 46 9E 8C 80 02 57 41 56 45    RIFFžŒ€.WAVE

The fmt chunk in the original wav is:

Code: [Select]
66 6D 74 20 10 00 00 00 01 00 02 00    fmt ........

but in the encoded/decoded wav it's:

Code: [Select]
66 6D 74 20 28 00 00 00 FE FF 02 00    fmt (...þÿ..

It looks like flac is "fixing" the wav file to be a correct 24-bit PCM file with the 0xFFFE flag, but I don't know if "fixing" files is appropriate or not.

Re: FLAC v1.3.3

Reply #19
I believe this was intentional.
IIRC, FLAC is not storing the "fmt" header itself, but reconstructs it instead, and in this commit from 2017, it was modified to use WAVEFORMATEXTENSIBLE for bits different than 8 or 16

https://git.xiph.org/?p=flac.git;a=commit;h=bb750734287a4079ca3de9ff85c71cc62160ac46

So it all depends on what kind of compatibility do you need when decoding a flac file.

 

Re: FLAC v1.3.3

Reply #20
I wouldn't have even noticed except that when batch converting some files I was double checking the conversion by running a SHA256 sum on the original wav and comparing it against a SHA256 sum on the decoded flac file. I don't mind if flac is going to fix files, but it will make it more difficult to make sure decoded PCM is bit-for-bit identical to the original. I'm not the type who can just "trust" that it is. I suppose I can just compare the data chunk, but that's a lot more difficult from a batch file than comparing the entire file.



Re: FLAC v1.3.3

Reply #23
You can compile libFLAC_dynamic.dll? Thanks


 
SimplePortal 1.0.0 RC1 © 2008-2019