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 v1.3.3 (Read 159524 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: FLAC v1.3.3

Reply #150 –
I guess it's time to edit all Wikipedias that FLAC doesn't support Windows anymore.

Re: FLAC v1.3.3

Reply #151 –
...so, finally, I don't exact understand which build is recommended (compression efficiency oriented) to use inside CUEtools 2.1.9: any suggestion ?
Hybrid Multimedia Production Suite will be a platform-indipendent open source suite for advanced audio/video contents production.
Official git: https://www.forart.it/HyMPS/

Re: FLAC v1.3.3

Reply #152 –
Quote from: forart.eu on
...so, finally, I don't exact understand which build is recommended (compression efficiency oriented) to use inside CUEtools 2.1.9: any suggestion ?
So that isn't obvious. Not even what you mean by "compression efficiency" (are you taking time into account, or are you only interested in "smallest file for reasonable time, but time isn't crucial as long as it is reasonable"?).
CUETools have a couple of alternative encoders which once upon a time compressed better and/or faster. Meanwhile both CUETools flake and the reference implementation have improved - and hardware has improved, and with that the assessment of what time is "reasonable". Some testing done in 2017: https://hydrogenaud.io/index.php?topic=114084.msg939675#msg939675

* FLACCL can utilize GPU though CUDA. Depending on what GPU and what CPU you have, that may or may not be faster.

* CUETools flake is a further development of the original flake, a 3rd-party FLAC implementation (also to a large extent incorporated into ffmpeg's FLAC encoder)
Flake does certain things better - like, it uses double precision to compute autocorrelation. More discussion at https://hydrogenaud.io/index.php?topic=120158.msg999746#msg999746 where ktf has published a few flac.exe betas (warning: beta is beta is beta) that incorporate double precision. From that thread you can see that double precision costs a bit extra time. You can also see that there are potential great improvements for hi-rez, which CUETools does not support. (CUETools flake does, but if your point was recommendation for CUETools the application, then hirez improvements are irrelevant.)

Note that flake 9 to 11 produce non-subset streams.

Re: FLAC v1.3.3

Reply #153 –
can someone build the latest flac.exe with a recent compiler and aggressively optimized for Intel Comet Lake-S? i9-10850K to be exact. does not have to be able to run on older CPUs

Re: FLAC v1.3.3

Reply #154 –
FLAC 1.3.3 + LibFLAC_dynamic.dll  (x86 & x64)
MSVC 2019 (v142) SDK version 10.0.19041.0
commit 79e462f
(2022-02-09)

Re: FLAC v1.3.3

Reply #155 –
Thanks, Ozz
EZ CD Audio Converter / FLAC or WavPack

Re: FLAC v1.3.3

Reply #157 –
Quote from: Ozz on
MSVC 2019 (v142) SDK version 10.0.19041.0
Just curious, do you build these with the sln files or with CMake?
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #158 –
Intel 19 compiles of flac-V1.3.3-e8143ab5:

www.rarewares.org/files/lossless/flac-V1.3.3-e8143ab5-x64.zip

www.rarewares.org/files/lossless/flac-V1.3.3-e8143ab5-x86.zip

www.rarewares.org/files/lossless/flac_dll-v1.3.3-e8143ab5-x64.zip

www.rarewares.org/files/lossless/flac_dll-v1.3.3-e8143ab5-x86.zip

 :) (All built using the VS sln.)

Re: FLAC v1.3.3

Reply #160 –
Quote from: john33 on
(All built using the VS sln.)
Note that building with the sln files supplied in git or tarball will be deprecated in favor of building with sln files configured with CMake starting with release 1.3.4. See
https://github.com/xiph/flac/blob/29e5b507894c4fce8c59ded5cd2f633a7dc5bfed/README#L214-L216
and
https://github.com/xiph/flac/blob/dee83e0633da5984c5a3450564050132fe14e13d/doc/html/changelog.html#L49

Configuring through CMake still has some issues that need to be worked out, but it wouldn't surprise me if 1.3.4 is the last release to support building through MSVC without using CMake. (There's a bunch of CMake+MSVC fixes here but those probably won't be applied before release 1.3.4)
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #161 –
Quote from: ktf on
Quote from: john33 on
(All built using the VS sln.)
Note that building with the sln files supplied in git or tarball will be deprecated in favor of building with sln files configured with CMake starting with release 1.3.4. ...
Noted, thanks. It will still be a pain in the rear having to modify all the compiler options as it is now.

Re: FLAC v1.3.3

Reply #162 –
Quote from: john33 on
Noted, thanks. It will still be a pain in the rear having to modify all the compiler options as it is now.
That, or you could make sure those compiler options are included in the CMake config, i.e. have your changed merged. If you want, I can help with that. The major benefit of CMake is that you can configure a build instead of having to modify the sln files by hand to change build behaviour.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #163 –
Quote from: ktf on
Quote from: john33 on
Noted, thanks. It will still be a pain in the rear having to modify all the compiler options as it is now.
That, or you could make sure those compiler options are included in the CMake config, i.e. have your changed merged. If you want, I can help with that. The major benefit of CMake is that you can configure a build instead of having to modify the sln files by hand to change build behaviour.
And, thanks again. I'll give it a try and see how I get on. ;)

Re: FLAC v1.3.3

Reply #164 –
I'm building with custom Xcode project files instead of CMake. Probably excluding all the assembly and intrinsics, too. Is ARM optimization ever happening, or is that unnecessary?

Re: FLAC v1.3.3

Reply #165 –
Quote from: kode54 on
Is ARM optimization ever happening, or is that unnecessary?
There is quite a bunch of ARM64 intrinsics routines for encoding waiting to be merged. Execution time with these is halved.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #166 –
Suggestion from Peter, implement FLAC__bitreader_read_unary_unsigned__LZCNT, using __lzcnt intrinsics provided by the compiler, and in the case of Clang, surround the implemented function with:

Code: [Select]
#pragma clang attribute push (__attribute__((target("lzcnt"))), apply_to=function)
...
#pragma clang attribute pop

And detect the instruction at runtime with the cpuid function, like all other optional x86 code paths.

BitScanReverse and such do not automatically optimize to lzcnt on the supporting Haswell or K10 processors unless you hard enable it at compile time. This optimization brings approximately a 20-30% improvement in decode time. Not too much to be impressed by when the figures are a comparison between 8000x and 12000x realtime, but maybe worth implementing anyway.

Clang, at least from Xcode, requires the instructions to be enabled per function, or per module. Per function is best in this case, since the requisite function will only be called if cpuid flags it present. In the case of Macs, this would be every Mac with at least a Haswell processor. Not including Apple Silicon running under Rosetta, though. But that already has a clz instruction which gets compiled in automatically for the __clz intrinsic function.

Re: FLAC v1.3.3

Reply #167 –
Quote from: kode54 on
Code: [Select]
#pragma clang attribute push (__attribute__((target("lzcnt"))), apply_to=function)
...
#pragma clang attribute pop
It would be even nicer (less code clutter) if Xcode's clang supports the target_clones attribute. Can't find anything about it. That has been in GCC for quite a while now and the next vanilla clang will support it too.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #169 –
target_clones duplicates a function for several architectures or instruction sets, without needing to add any runtime code to select. Selection is done by some code added by the compiler or in the C library. You can for example add target_clones("default,lzcnt") to a function to have it compile a non-lzcnt and an lzcnt version without having to add any code at all.
Music: sounds arranged such that they construct feelings.

Re: FLAC v1.3.3

Reply #170 –
Then by all means, try that. I don't think MSVC supports it, either, though.

Re: FLAC v1.3.3

Reply #171 –
Quote from: ktf on
Quote from: john33 on
Noted, thanks. It will still be a pain in the rear having to modify all the compiler options as it is now.
That, or you could make sure those compiler options are included in the CMake config, i.e. have your changed merged. If you want, I can help with that. The major benefit of CMake is that you can configure a build instead of having to modify the sln files by hand to change build behaviour.
The existing sln files, with the switch to the Intel compiler, compile 'out-of-the-box' when the 'ogg' directory and library are placed as specified. They binaries are also built without runtime dependencies. The current cmake files do not find the ogg directory, or the library in the places specified and, excluding ogg from the build, the resulting binaries are runtime dependent. I would expect that the cmake environment would at least generate sln files that match the current included versions. Without that I see no point or benefit in switching to the cmake process.

Re: FLAC v1.3.3

Reply #173 –
Thanks, I'll let you know. ;)

Re: FLAC v1.3.3

Reply #174 –
After much trial and error, the following 'FindOgg.cmake' works:
Code: [Select]
find_package(PkgConfig)
pkg_check_modules(_OGG QUIET ogg)

file(GLOB _OGG_DIR "./include")
file(GLOB _OGG_STATIC_LIB "./objs/Release/lib")

find_path(
    OGG_INCLUDE_DIR
    NAMES "ogg/ogg.h"
    PATHS ${_OGG_DIR}
#    HINTS "${_OGG_DIR}/include"
    )

find_library(
    OGG_LIBRARY
    NAMES libogg_static.lib
#    PATH ${_OGG_STATIC_LIB}
    HINTS "${_OGG_STATIC_LIB}"
    )

mark_as_advanced(
    OGG_INCLUDE_DIR
    OGG_LIBRARY)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Ogg
    REQUIRED_VARS OGG_INCLUDE_DIR OGG_LIBRARY
    VERSION_VAR _OGG_VERSION)
if(OGG_FOUND AND NOT TARGET Ogg::ogg)
    add_library(Ogg::ogg UNKNOWN IMPORTED)
    set_target_properties(Ogg::ogg PROPERTIES
        INTERFACE_INCLUDE_DIRECTORIES "${OGG_INCLUDE_DIR}"
        IMPORTED_LOCATION "${OGG_LIBRARY}")
endif()
and static libs are built, and statically linked executables. The usual dlls are not, however, built. Nevertheless, good progress!