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-git Releases (Code Base v1.4.x) (Read 28357 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #25 –
Quote from: ktf on
I've lifted some restrictions on channel mask recently, these changes are in this compile. Channel masks that are non-standard in FLAC should now be accepted properly, without having to resort to --channel-map=none. However, I don't have much files to test, so if anyone with such files could give it a try, that would be much appreciated.
Tested 4.1 and FL-FR-FC-BC. Files are accepted and compressed without problems.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #27 –
Hope it's not faux pas to drop MSVC builds in here, didn't seem worth making my own thread for builds that might be slower or worse since I've no idea what I'm doing anyways.

Same commit as NetRanger's previous post, built with MSVC 2022 and copious "lemme flip some of these optimization switches and see what happens"

x64 - AVX
20230211-git-3f1f82c8-x64-AVX - flac.exe and metaflac.exe only
20230211-git-3f1f82c8-x64-Shared-AVX - what you want if you just want libFLAC.dll for something else (rename it if you need to)
x86/32 - SSE2 - 20230211-git-3f1f82c8-x86-Shared-SSE2 - because I still need a 32-bit libFLAC.dll to let eac3to use...

I forgot CXX and UTILS enabled in CMake when I switched to shared builds, so both also come with FLAC++.dll, flacdiff.exe, and flactimer.exe

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #29 –
Quote from: NetRanger on
FLAC git-771eb050 20230217
Built on February 18, 2023, GCC 12.2.0
This build has much improved foreign metadata handling. When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV (which only works for WAV). Also, decoding to AIFF-C sowt and WAVE_FORMAT_EXTENSIBLE is now possible. Finally, a bunch of warnings is added when on restoration of foreign metadata inconsistencies are found, for example when the length of the file has changed.
Music: sounds arranged such that they construct feelings.
 

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #31 –
Quote from: ktf on
When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV
Took some files from the upper section of https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html - the 8, 8C, 16, 16C, 16s (that is sowt), 24, 24C, 32, 32C and ran them through --keep-foreign-metadata-if-present with or without entering a tag field first. Decoded with --keep-foreign-metadata-if-present and let a file deduplicator check that they were bit-exactly the same as the original.

All of them did come out bit-identical. But, if fb2k is likely to only make "pretty standard" tags, it might not have been the hardest of tests.
Edit: tried afterwards an 8-bit sowt file, same (good) result. Why try? Just out of the knowledge that some players have rejected those (after all, who would make a fuss out of endianness on 8-bit? But it is a subformat of AIFC, so it is legit).

Obligatory suggestions coming up - after all, you didn't do all this hard work for users to turn grateful and stop being pain-in-the-ass about features they don't use themselves eh?   ;D
* When re-encoding flac to flac, it is reasonable to let --no-keep-foreign-metadata kill foreign metadata. (Is there any such provision in metaflac?)
Or if one is reluctant to making a change that will actually start killing data when the previous version did not: a --remove-foreign-metadata
* I think a "-k" for --keep-foreign-metadata-if-present should be on the table pretty soon.
* One will always think twice before changing behaviour and thrice before changing default behaviour, but it isn't unfair to assume that a user that encodes with foreign metadata intends them to be kept? That suggests that decoding by default employs --keep-foreign-metadata-if-present. But, but, but ... you might not want all the WTFs from users who don't understand why their pyr8ed downloads (hm, to be fair it could be purchases too) decode to .aiff.
(Once alternative behaviour deviates enough from 2007-era "-d", one can of course take note that -D is not taken ...)

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #32 –
Quote from: Porcus on
Quote from: ktf on
When decoding with --keep-foreign-metadata, the right format will be picked automatically instead of default to WAV
Took some files from the upper section of https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html - the 8, 8C, 16, 16C, 16s (that is sowt), 24, 24C, 32, 32C and ran them through --keep-foreign-metadata-if-present with or without entering a tag field first. Decoded with --keep-foreign-metadata-if-present and let a file deduplicator check that they were bit-exactly the same as the original.

All of them did come out bit-identical. But, if fb2k is likely to only make "pretty standard" tags, it might not have been the hardest of tests.
Edit: tried afterwards an 8-bit sowt file, same (good) result. Why try? Just out of the knowledge that some players have rejected those (after all, who would make a fuss out of endianness on 8-bit? But it is a subformat of AIFC, so it is legit).
Thanks!

Quote
* When re-encoding flac to flac, it is reasonable to let --no-keep-foreign-metadata kill foreign metadata. (Is there any such provision in metaflac?)
I'm not sure that would be very useful. We don't have a --no-transfer-vorbis-comment option either. One can remove the RIFF and AIFF data with metaflac --remove --block-type=APPLICATION:riff,APPLICATION:aiff.

Quote
* One will always think twice before changing behaviour and thrice before changing default behaviour, but it isn't unfair to assume that a user that encodes with foreign metadata intends them to be kept? That suggests that decoding by default employs --keep-foreign-metadata-if-present. But, but, but ... you might not want all the WTFs from users who don't understand why their pyr8ed downloads (hm, to be fair it could be purchases too) decode to .aiff.
(Once alternative behaviour deviates enough from 2007-era "-d", one can of course take note that -D is not taken ...)
I don't think keeping them by default is a good idea. I've seen an AIFF file come out a DAW with an empty AIFF chunk of 15MB for some reason. The user asked why FLAC didn't compress such a block. The answer is because FLAC compresses audio, not metadata.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #33 –
Quote from: ktf on
I don't think keeping them by default is a good idea. I've seen an AIFF file come out a DAW with an empty AIFF chunk of 15MB for some reason. The user asked why FLAC didn't compress such a block. The answer is because FLAC compresses audio, not metadata.
I agree, and that was not my suggestion either.
What I was suggesting - or at least suggesting to consider - was behaviour upon decoding. I argue that if there is foreign metadata in the .flac file, it reflects an intention to keep foreign metadata.
And even more so when the default encoding behaviour is to discard them. Then foreign metadata in the .flac must have been due to an active choice.

(Aside: I have no idea whether any of the wavefile compressors - WavPack, TAK, ALS, (La) and the two animals - do compress the foreign metadata, foreseeing DAWs misbehaving big this way.)

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #34 –
Thank you for this, the —keep-foreign-metadata command is an important one for me!

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #39 –
flac-1.4.2-4d21da1-20230227
Built on February 28, 2023, Intel compiles. win32-XP is Intel 19.0, others are Intel 19.2.
(Code Base : 1.4.2)

https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-nonXP.zip

https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-win32-XP.zip

https://www.rarewares.org/files/lossless/flac-1.4.2-4d21da1-20230227-x64-AVX2.zip

The targets are self-explanatory.  :)

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #40 –
I've had a report of possible issues with these compiles so please only use them for testing and not for archival. The particular problem was with '-8', but it could affect other settings also.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #42 –
I can confirm the problem with the Intel compiles which I will look into. Having just built a GCC version, I can confirm that it works as expected. So, go for NetRanger's build. ;)

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #43 –
Quote from: john33 on
I've had a report of possible issues with these compiles so please only use them for testing and not for archival.
This is something true for all these git compiles. I usually don't leave git in a state with known bugs, but a release is usually preceded by a few weeks without adding new features, to find bugs.

Still, I'm always curious about bugs that do not surface on GCC but do on other compilers. @john33, do you usually run the test suite on builds like these? Can you check whether the test suite fails on these builds?
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #44 –
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.

I have recompiled without this option and the compiles perform as expected. They are on the same links as above.

@ktf, no, I don't normally run the test suite. I have a bunch of files I've used over the years that I test against. I recall having an issue with '/Qipo' on the odd occasion in the past but this is the first time I've encountered it for some years. I'm not sure that it makes a whole bunch of difference in respect of speed, so probably not worth bothering with. Ignoring the XP build, I've tried using the latest Intel oneAPI compiler - based on Clang 16. It works quite well for the 64bit build but will not compile for 32bit. The Intel Classic Compiler - 19.2 - will be removed later this year from the Intel downloads.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #45 –
Quote from: john33 on
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.
Is it a bug in IPO or is it a bug in FLAC being triggered by IPO? Do you have some more details, I'm certainly curious.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #46 –
Quote from: ktf on
Quote from: john33 on
It turns out that the 'bug' was being caused by using the '/Qipo' Intel Procedural Optimization switch in the compilations.
Is it a bug in IPO or is it a bug in FLAC being triggered by IPO? Do you have some more details, I'm certainly curious.
I understand your interest, but I suspect the answer is way above my level of understanding!! If anything occurs to me, or comes to light, I'll certainly let you know.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #47 –
Could you perhaps disclose some more details, if necessary via PM, so I can look into this when I have the time?

Compiler bugs are pretty rare, and I find it especially interesting as you say you've run into this previously.
Music: sounds arranged such that they construct feelings.

Re: FLAC-git Releases (Code Base v1.4.x)

Reply #49 –
flac-git-07471c89-20230306
Built on March 6, 2023, GCC 12.2.0
(Code Base : 1.4.2)

Win32 generic: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x86.zip (Not XP friendly)

x64 generic: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-x64.zip

x64 AVX2 optimised: https://www.rarewares.org/files/lossless/flac-1.4.2-07471c89-20230306-AVX2.zip