GithubHelp home page GithubHelp logo

xiph / flac Goto Github PK

View Code? Open in Web Editor NEW
1.5K 67.0 269.0 8.48 MB

Free Lossless Audio Codec

Home Page: https://xiph.org/flac/

License: GNU Free Documentation License v1.3

Makefile 1.58% Shell 3.03% C 77.56% C++ 12.97% Scilab 0.09% Perl 0.16% M4 3.73% CMake 0.88%
audio decoding encoding lossless lossless-compression-algorithm c

flac's Introduction

Free Lossless Audio Codec (FLAC)

FLAC is open source software that can reduce the amount of storage space needed to store digital audio signals without needing to remove information in doing so.

The files read and produced by this software are called FLAC files. As these files (which follow the FLAC format) can be read from and written to by other software as well, this software is often referred to as the FLAC reference implementation.

FLAC has been developed by volunteers. If you want to help out, see CONTRIBUTING.md for more information.

Components

FLAC is comprised of

  • libFLAC, a library which implements reference encoders and decoders for native FLAC and Ogg FLAC, and a metadata interface
  • libFLAC++, a C++ object wrapper library around libFLAC
  • flac, a command-line program for encoding and decoding files
  • metaflac, a command-line program for viewing and editing FLAC metadata
  • user and API documentation

The libraries (libFLAC, libFLAC++) are licensed under Xiph.org's BSD-like license (see COPYING.Xiph). All other programs and plugins are licensed under the GNU General Public License (see COPYING.GPL). The documentation is licensed under the GNU Free Documentation License (see COPYING.FDL).

Documentation

For documentation of the flac and metaflac command line tools, see the directory man, which contains the files flac.md and metaflac.md

The API documentation is in html and is generated by Doxygen. It can be found in the directory doc/html/api. It is included in a release tarball and must be build with Doxygen when the source is taken directly from git.

The directory examples contains example source code on using libFLAC and libFLAC++.

Documentation concerning the FLAC format itself (which can be used to create software reading and writing FLAC software independent from libFLAC) was included in previous releases, but can now be found on https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/ Additionally a set of files for conformance testing called the FLAC decoder testbench can be found at https://github.com/ietf-wg-cellar/flac-test-files

If you have questions about FLAC that this document does not answer, please submit them at the following tracker so this document can be improved:

https://github.com/xiph/flac/issues

Building FLAC

All components of the FLAC project can be build with a variety of compilers (including GCC, Clang, Visual Studio, Intel C++ Compiler) on many architectures (inluding x86, x86_64, ARMv7, ARMv8 and PowerPC) for many different operating systems.

To do this, FLAC provides two build systems: one using GNU's autotools and one with CMake. Both differ slighly in configuration options, but should be considered equivalent for most use cases.

FLAC used to provide files specifically for building with Visual Studio, but these have been removed in favor of using CMake.

Building with CMake

CMake is a cross-platform build system. FLAC can be built on Windows, Linux, Mac OS X using CMake.

You can use either CMake's CLI or GUI. We recommend you to have a separate build folder outside the repository in order to not spoil it with generated files. It is possible however to do a so-called in-tree build, in that case /path/to/flac-build in the following examples is equal to /path/to/flac-source.

CMake CLI

Go to your build folder and run something like this:

/path/to/flac-build$ cmake /path/to/flac-source

or e.g. in Windows shell

C:\path\to\flac-build> cmake \path\to\flac-source

(provided that cmake is in your %PATH% variable)

That will generate build scripts for the default build system (e.g. Makefiles for UNIX). After that you start build with a command like this:

/path/to/flac-build$ make

And afterwards you can run tests or install the built libraries and headers

/path/to/flac-build$ make test
/path/to/flac-build$ make install

If you want use a build system other than default add -G flag to cmake, e.g.:

/path/to/flac-build$ cmake /path/to/flac-source -GNinja
/path/to/flac-build$ ninja

or:

/path/to/flac-build$ cmake /path/to/flac-source -GXcode

Use cmake --help to see the list of available generators.

By default CMake will search for OGG. If CMake fails to find it you can help CMake by specifying the exact path:

/path/to/flac-build$ cmake /path/to/flac-source -DOGG_ROOT=/path/to/ogg

If you would like CMake to build OGG alongside FLAC, you can place the ogg sources directly in the flac source directory as a subdirectory with the name ogg, for example:

/path/to/flac-source/ogg

If you don't want to build flac with OGG support you can tell CMake not to look for OGG:

/path/to/flac-build$ cmake /path/to/flac-source -DWITH_OGG=OFF

Other FLAC's options (e.g. building C++ lib or docs) can also be put to cmake through -D flag. If you want to know what options are available, use -LH:

/path/to/flac-build$ cmake /path/to/flac-source -LH

CMake GUI (for Visual Studio)

It is likely that you would prefer to use the CMake GUI if you use Visual Studio to build FLAC. It's in essence the same process as building using CLI.

Open cmake-gui. In the window select a source directory (the repository's root), a build directory (some other directory outside the repository). Then press button "Configure". CMake will ask you which build system you prefer. Choose that version of Visual Studio which you have on your system, choose whether you want to build for Win32 or x64. Press OK.

After CMake finishes you can change the configuration to your liking and if you change anything, run Configure again. With the "Generate" button, CMake creates Visual Studio files, which can be opened from Visual Studio. With the button "Open Project" CMake will launch Visual Studio and open the generated solution. You can use the project files as usual but remember that they were generated by CMake. That means that your changes (e.g. some additional compile flags) will be lost when you run CMake next time.

CMake searches by default for OGG on your system and returns an error if it cannot find it. If you want to build OGG alongside FLAC, you can download the OGG sources and extract them in a subdirectory of the FLAC source directory with the name ogg (i.e. /path/to/flac-source/ogg) before running CMake. If you don't want to build FLAC with OGG support, untick the box following WITH_OGG flag in the list of variables in cmake-gui window and run "Configure" again.

If CMake fails to find MSVC compiler then running cmake-gui from MS Developer comand prompt should help.

Building with GNU autotools

FLAC uses autoconf and libtool for configuring and building. To configure a build, open a commmand line/terminal and run ./configure You can provide options to this command, which are listed by running ./configure --help.

In case the configure script is not present (for example when building from git and not from a release tarball), it can be generated by running ./autogen.sh. This may require a libtool development package though.

After configuration, build with make, verify the build with make check and install with make install. Installation might require administrator priviledged, i.e. sudo make install.

The 'make check' step is optional; omit it to skip all the tests, which can take about an hour to complete. Even though it will stop with an explicit message on any failure, it does print out a lot of stuff so you might want to capture the output to a file if you're having a problem. Also, don't run 'make check' as root because it confuses some of the tests.

Summarizing:

./configure
make && make check
sudo make install

Note to embedded developers

libFLAC has grown larger over time as more functionality has been included, but much of it may be unnecessary for a particular embedded implementation. Unused parts may be pruned by some simple editing of configure.ac and src/libFLAC/Makefile.am; the following dependency graph shows which modules may be pruned without breaking things further down:

metadata.h
    stream_decoder.h
    format.h

stream_encoder.h
    stream_decoder.h
    format.h

stream_decoder.h
    format.h

In other words, for pure decoding applications, both the stream encoder and metadata editing interfaces can be safely removed. Note that this is specific to building the libraries for embedded use. The command line tools do not provide such compartmentalization, and require a complete libFLAC build to function.

There is a section dedicated to embedded use in the libFLAC API HTML documentation (see doc/html/api/index.html).

Also, there are several places in the libFLAC code with comments marked with "OPT:" where a #define can be changed to enable code that might be faster on a specific platform. Experimenting with these can yield faster binaries.

flac's People

Contributors

antonblanchard avatar ccawley2011 avatar chirlu avatar crrodriguez avatar dago avatar dekonvoluted avatar dryeo avatar elnull avatar enzo1982 avatar ephemeralriggs avatar erikd avatar evpobr avatar fingolfin avatar hendricks266 avatar krokoziabla avatar ktmf01 avatar lvqcl avatar manxorist avatar maxkellermann avatar mlichvar avatar neheb avatar nottsunami avatar pkubaj avatar rillian avatar robux4 avatar sezero avatar skurrier avatar soapgentoo avatar thesamesam avatar tmatth avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

flac's Issues

ICC compiler warnings: conversion from 'const __int64' to 'uint32_t', possible loss of data

Intel C Compiler produces a lot of warnings about type conversion during x64 build process. Here's output log:

1>------ Rebuild All started: Project: libFLAC_static, Configuration: Release x64 ------
2>------ Rebuild All started: Project: replaygain_analysis_static, Configuration: Release x64 ------
3>------ Rebuild All started: Project: getopt_static, Configuration: Release x64 ------
4>------ Rebuild All started: Project: replaygain_synthesis_static, Configuration: Release x64 ------
4>replaygain_synthesis.c
4>replaygain_synthesis_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\replaygain_synthesis_static.lib
5>------ Rebuild All started: Project: utf8_static, Configuration: Release x64 ------
2>replaygain_analysis.c
5>utf8.c
2>replaygain_analysis_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\replaygain_analysis_static.lib
6>------ Rebuild All started: Project: win_utf8_io_static, Configuration: Release x64 ------
5>utf8_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\utf8_static.lib
6>win_utf8_io.c
6>win_utf8_io_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\win_utf8_io_static.lib
1>bitmath.c
1>bitreader.c
1>bitwriter.c
1>cpu.c
1>crc.c
1>fixed.c
1>fixed_intrin_sse2.c
1>fixed_intrin_ssse3.c
1>float.c
1>format.c
1>format.c(580): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
1>format.c(582): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
3>getopt.c
3>getopt1.c
1>format.c(584): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
1>lpc.c
3>getopt_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\getopt_static.lib
1>lpc_intrin_sse.c
1>lpc_intrin_sse2.c
1>lpc_intrin_sse41.c
1>md5.c
1>memory.c
1>metadata_iterators.c
1>metadata_iterators.c(579): warning C4244: 'return': conversion from 'const __int64' to 'off_t', possible loss of data
1>metadata_iterators.c(1117): warning C4244: '+=': conversion from 'const __int64' to 'uint32_t', possible loss of data
1>metadata_iterators.c(1129): warning C4244: '=': conversion from '__int64' to 'uint32_t', possible loss of data
1>metadata_iterators.c(1152): warning C4244: '-=': conversion from 'const __int64' to 'uint32_t', possible loss of data
1>metadata_iterators.c(1647): warning C4244: '=': conversion from '__int64' to 'uint32_t', possible loss of data
1>metadata_iterators.c(1652): warning C4244: '=': conversion from '__int64' to 'uint32_t', possible loss of data
1>metadata_iterators.c(1666): warning C4244: '=': conversion from 'const __int64' to 'uint32_t', possible loss of data
1>metadata_object.c
1>metadata_object.c(1127): warning C4244: '=': conversion from 'FLAC__uint64' to 'uint32_t', possible loss of data
1>ogg_decoder_aspect.c
1>ogg_encoder_aspect.c
1>Compiling...
1>ogg_helper.c
1>ogg_mapping.c
1>stream_decoder.c
1>stream_encoder.c
1>stream_encoder.c(3942): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
1>stream_encoder.c(3944): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
1>stream_encoder_framing.c
1>stream_encoder_intrin_sse2.c
1>stream_encoder_intrin_ssse3.c
1>window.c
1>windows_unicode_filenames.c
1>lpc_intrin_avx2.c
1>stream_encoder_intrin_avx2.c
1>libFLAC_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\libFLAC_static.lib
1>Done building project "libFLAC_static.vcxproj".
7>------ Rebuild All started: Project: grabbag_static, Configuration: Release x64 ------
7>alloc.c
7>cuesheet.c
7>file.c
7>picture.c
7>picture.c(290): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
7>picture.c(308): warning C4244: 'function': conversion from 'const __int64' to 'FLAC__uint32', possible loss of data
7>replaygain.c
7>seektable.c
7>snprintf.c
7>grabbag_static.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\lib\grabbag_static.lib
7>Done building project "grabbag_static.vcxproj".
8>------ Rebuild All started: Project: flac, Configuration: Release x64 ------
8>analyze.c
8>decode.c
8>encode.c
8>encode.c(2859): warning #1786: function "fileno" (declared at line 2457 of "C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\stdio.h") was declared deprecated ("The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _fileno. See online help for details.")
8> if(flac_fstat(fileno(f), &stb) == 0 && (stb.st_mode & S_IFMT) == S_IFREG)
8> ^
8>
8>foreign_metadata.c
8>local_string_utils.c
8>main.c
8>main.c(2254): warning #1786: function "strdup" (declared at line 538 of "C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\string.h") was declared deprecated ("The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup. See online help for details.")
8> if(0 == (ret = strdup(source)))
8> ^
8>
8>utils.c
8>vorbiscomment.c
8>vorbiscomment.c(61): warning #1786: function "strdup" (declared at line 538 of "C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt\string.h") was declared deprecated ("The POSIX name for this item is deprecated. Instead, use the ISO C and C++ conformant name: _strdup. See online help for details.")
8> if(0 == (ret = strdup(source)))
8> ^
8>
8>libFLAC_static.lib(format.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
8>Generating code
8>Finished generating code
8>flac.vcxproj -> C:__WORKDIR\projects\flac-master\objs\x64\Release\bin\flac.exe
8>Done building project "flac.vcxproj".
========== Rebuild All: 8 succeeded, 0 failed, 0 skipped ==========

flac_internal_CreateFile_utf8 doesn't return a value

The issue with function flac_internal_CreateFile_utf8 - the portion of code between #if and #else doesn't return a HANDLE value.

HANDLE WINAPI flac_internal_CreateFile_utf8(const char *lpFileName, DWORD dwDesiredAccess, DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile)
{
#if _MSC_VER > 1900 && WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
	wchar_t *wname;
	HANDLE handle = INVALID_HANDLE_VALUE;

	if ((wname = wchar_from_utf8(lpFileName)) != NULL) {

		handle = CreateFile2(wname, dwDesiredAccess, dwShareMode, CREATE_ALWAYS, NULL);
		free(wname);
	}
#else
	if (!utf8_filenames) {
		return CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
	} else {
		wchar_t *wname;
		HANDLE handle = INVALID_HANDLE_VALUE;

		if ((wname = wchar_from_utf8(lpFileName)) != NULL) {
			handle = CreateFileW(wname, dwDesiredAccess, dwShareMode, lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
			free(wname);
		}

		return handle;
	}
#endif
}

Flac clobbers filenames that contain a backslash.

When filenames contain a backslash (\) flac will clobber the output filename.

Example:

  1. cp test.flac te\\st.flac
  2. flac --decode te\\st.flac
  3. Creates te\st.flac and prints...
flac 1.3.2
Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

st.flac: done

Or.

  1. flac te\\st.wav
  2. Creates st.flac and prints...
flac 1.3.2
Copyright (C) 2000-2009  Josh Coalson, 2011-2016  Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

st.wav: wrote 29732477 bytes, ratio=0.686

Interestingly with --decode the created file has the correct output filename, but when encoding a wav file the created file is wrong in addition to the incorrect verbose output.

OS: Slackware64-current
Version: flac 1.3.2

iOS/OSX build many warning about conversions

Hello,
I get many warnings

Possible misuse of comma operator 
encode.c
/* chunk identifier; really conservative about behavior of fread() and feof() */
		if(feof(infile) || ((c= fread(chunk_id, 1U, 4U, infile)), c==0U && feof(infile)))
'memset' call operates on objects of type 'FLAC__MD5Context' while the size is based on a different type 'FLAC__MD5Context *'
md5.c
memset(ctx, 0, sizeof(ctx));	/* In case it's sensitive */
Comparison of constant 126 with expression of type 'FLAC__MetadataType' is always false
metadat_object.c
if(type > FLAC__MAX_METADATA_TYPE_CODE)
Comparison of constant 9223372036854775807 with expression of type 'unsigned int' is always false
if(options->ops.capacity > SIZE_MAX / 2) /* overflow check */
Comparison of constant 126 with expression of type 'FLAC__MetadataType' is always false
if(type > FLAC__MAX_METADATA_TYPE_CODE)
Comparison of constant 9223372036854775807 with expression of type 'unsigned int' is always false
if(to->data.seek_table.num_points > SIZE_MAX / sizeof(FLAC__StreamMetadata_SeekPoint))

unused functions in alloc.h

static FLaC__INLINE void *safe_calloc_(size_t nmemb, size_t size)
static FLaC__INLINE void *safe_malloc_muladd2_(size_t size1, size_t size2, size_t size3)
static FLaC__INLINE void *safe_malloc_add_3op_(size_t size1, size_t size2, size_t size3)
static FLaC__INLINE void *safe_malloc_add_4op_(size_t size1, size_t size2, size_t size3, size_t size4)
static FLaC__INLINE void *safe_malloc_mul_3op_(size_t size1, size_t size2, size_t size3)
static FLaC__INLINE void *safe_malloc_mul2add_(size_t size1, size_t size2, size_t size3)
static FLaC__INLINE void *safe_realloc_add_4op_(void *ptr, size_t size1, size_t size2, size_t size3, size_t size4)
static FLaC__INLINE void *safe_realloc_add_3op_(void *ptr, size_t size1, size_t size2, size_t size3)
static FLaC__INLINE void *safe_realloc_add_2op_(void *ptr, size_t size1, size_t size2)

about 100 warnings in encode/decode like

Implicit conversion loses integer precision: 'unsigned long' to 'int'
const int ilen = strlen(d->inbasefilename) + 1;
unsigned int frames= bytes_read/bytes_per_frame;
unsigned wide_samples = bytes_read / bytes_per_wide_sample;
unsigned skip_bytes = bytes_per_wide_sample * (unsigned)encoder_session.skip;
entry.length = strlen((const char *)entry.entry);
end = (br->words*FLAC__BYTES_PER_WORD + br->bytes + bytes + (FLAC__BYTES_PER_WORD-1)) / FLAC__BYTES_PER_WORD;

Update ReplayGain functionality

The metaflac tool allows users to update their flac files with REPLAYGAIN_* tags. The support offered by metaflac is lacking:

  1. No multi-channel support.
  2. All files must have the same characteristics regarding bit, sample rate, and channels.
  3. Loudness algorithm is unknown? In-house?

Over time there have been advances in loudness algorithms and even a well-adopted standard has come about called "ITU BS.1770-4" a.k.a. "EBU R 128" and a few tools have been created that follow this standard.

I'm creating this issue to update metaflac because most users and even some software (Soundkonverter) uses metaflac's replay gain functionality. Updating it here will benefit everyone.

Would this project be willing to adopt an EBU R 128 library and switch metaflac to use it?

[Website] Wrong navbar links on changelog page

On website's changelog page, last item of navbar is "more", and points to the website root.

(this is actually originating from FLAC's bundled HTML documentation, where there is such item "more", letting going from the local files to the online full website)

Therefore, this "more" item should be replaced with items "links" and "developers", as on the other pages.

Conflicting types in source and header files

I posted this last night to the mailing list. Reposting here:

I'd like to compress a 32 kHz 16-bit mono using an STM32F4 microcontroller (RTOS not Linux). My plan is to capture from 500-1000 ms of data, compress, and send the result over a UART.

I have the arm-none-eabi tools installed on MacOS. I used homebrew to install autoconf, automake, and libtool. autogen.sh succeeded and I was able to create my makefiles using the following:

./configure --build=x86_64-apple-darwin16.7.0 --host=arm-none-eabi --prefix=$PWD/export CFLAGS="-O3 -mthumb -mcpu=cortex-m4 -lc -lrdimon -specs=rdimon.specs" --disable-cpplibs --disable-ogg --disable-oggtest --disable-examples --disable-xmms-plugin
  Configuration summary :

    FLAC version : ........................ 1.3.2

    Host CPU : ............................ arm
    Host Vendor : ......................... none
    Host OS : ............................. eabi

    Compiler is GCC : ..................... yes
    GCC version : ......................... 5.4.1
    Compiler is Clang : ................... no
    SSE optimizations : ................... yes
    Asm optimizations : ................... no
    Ogg/FLAC support : .................... no

I'm getting some errors around type mismatches between the declarations and definitions for example:

grabbag/cuesheet.c:32:10: error: conflicting types for 'grabbag__cuesheet_msf_to_frame'
 uint32_t grabbag__cuesheet_msf_to_frame(uint32_t minutes, uint32_t seconds, uint32_t frames)
          ^
In file included from ../../include/share/grabbag.h:24:0,
                 from grabbag/cuesheet.c:29:
../../include/share/grabbag/cuesheet.h:32:10: note: previous declaration of 'grabbag__cuesheet_msf_to_frame' was here
 unsigned grabbag__cuesheet_msf_to_frame(unsigned minutes, unsigned seconds, unsigned frames);

I can see that the variables in the header are not declared using the <stdint.h> values.

More broadly though: Assuming I can sort out these errors, am I on the right track/ My experiments have shown that a compression level of zero will meet my needs and I have read that encoding is faster than real-time. Once I have the library built I plan to measure things. But I'm seeing calls to fprintf etc that I don't need. If I just want encodying functions but not the general purpose flac tool is there any advice as to how to pare this back further so I'm only building what I need. I'm not too concerned about library size as the linker should just pull in what is needed. It's more that I would like fewer things to debug in the build.

Is it possible to encode on-the-fly? I have 192 KB of RAM. It'd be nice if I could compress straight to a buffer.

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.

Ogg M4 script ignores sysroot setting

When cross-compiling and invoking configure with parameters like --with-sysroot=/foo --prefix=/usr, FLAC finds libogg installed in host's /usr, adding it to include path and wreaking havok.

Looking into ogg.m4, it seems like while $prefix is one of the places being checked, it doesn't include the sysroot at all. I don't know much about autotools, but replacing things like OGG_LIBS="-L$prefix/lib" with OGG_LIBS="-L$sysroot/$prefix/lib" might be enough.

A workaround is to specify path manually using --with-ogg.

Parallel Processing FrontEnd

#1.
i write here because the FrontEnd does not allow to OpenTickets in SourceForge... and there is No e-mail in the web page of the FrontEnd...
https://sourceforge.net/projects/flacfrontend/?source=typ_redirect
http://flacfrontend.sourceforge.net

a very easy modification to the Front End...

there is a Law https://en.wikipedia.org/wiki/Amdahl%27s_law
that calculates speed increases with parallel processing...

FLAC.exe 1.2.3 is more Serial Processing than parallel, and that´s OK for this modification...

if Processing Multiple files with the Frontend, Frontend is also Serial..
and that is a BIG mistake...

i have a .bat that forces Affinity for each flac.exe to a unique dedicated core/thread...
so a 8-thread CPU can Process 8-files Parallel, increasing speed A LOT!
a 32-Core CPU can Processes 32-files simultaneously, but becomes limited by HDD SATA 6Gbps speed.,
also limited by Power Management Level.

the modification for the FrontEnd, is to autodetect, also allow manual select Threads, similar to SystemStabilityTester.
https://sourceforge.net/projects/systester/

forcing each thread CPU AFFINITY to a different file...
converting 32 large "700MB" .wav files in Parallel, with a 32-core CPU, speed increase is incredible...
30-seconds vs. 1-hour.

start /AFFINITY 0x1 flac.exe %file1%
start /AFFINITY 0x2 flac.exe %file2%
start /AFFINITY 0x4 flac.exe %file3%
start /AFFINITY 0x8 flac.exe %file4%
start /AFFINITY 0x10 flac.exe %file5%
start /AFFINITY 0x20 flac.exe %file6%
start /AFFINITY 0x40 flac.exe %file7%
start /AFFINITY 0x80 flac.exe %file8%
start /AFFINITY 0x100 flac.exe %file9%
start /AFFINITY 0x200 flac.exe %file10%
start /AFFINITY 0x400 flac.exe %file11%
start /AFFINITY 0x800 flac.exe %file12%
start /AFFINITY 0x1000 flac.exe %file13%
start /AFFINITY 0x2000 flac.exe %file14%
start /AFFINITY 0x4000 flac.exe %file15%
start /AFFINITY 0x8000 flac.exe %file16%
start /AFFINITY 0x10000 flac.exe %file17%
start /AFFINITY 0x20000 flac.exe %file18%
start /AFFINITY 0x40000 flac.exe %file19%
start /AFFINITY 0x80000 flac.exe %file20%
start /AFFINITY 0x100000 flac.exe %file21%
start /AFFINITY 0x200000 flac.exe %file22%
start /AFFINITY 0x400000 flac.exe %file23%
start /AFFINITY 0x800000 flac.exe %file24%
start /AFFINITY 0x1000000 flac.exe %file25%
start /AFFINITY 0x2000000 flac.exe %file26%
start /AFFINITY 0x4000000 flac.exe %file27%
start /AFFINITY 0x8000000 flac.exe %file28%
start /AFFINITY 0x10000000 flac.exe %file29%
start /AFFINITY 0x20000000 flac.exe %file30%
start /AFFINITY 0x40000000 flac.exe %file31%
start /AFFINITY 0x80000000 flac.exe %file32%
etc...

#2.
there is a FLACCL that uses GPU+CPU and is very FAST, but the time it needs to Start the Engine, kills the purpose of the software in very small files...

another modification would be to also use FLACCL.exe
https://hydrogenaud.io/index.php/topic,64628.0.html
http://cue.tools/wiki/FLACCL

NULL is returned in FLAC__StreamMetadata_VorbisComment_Entry->entry

See for more context: MusicPlayerDaemon/MPD#108 (comment)

When decoding some FLAC (I guess, corrupted) file, libflac sets the entry pointer as NULL, while the documentation (https://xiph.org/flac/api/structFLAC____StreamMetadata__VorbisComment__Entry.html) doesn’t say it can.

This causes client applications (here MPD) to segfault, because it doesn’t expect it to be NULL.

Let me know if you want me to send you a file by e-mail that reproduces this issue.

Multiple errors when building DLL with Visual Studio 2017

Severity	Code	Description	Project	File	Line	Suppression State
Error	C2491	'FLAC__stream_decoder_get_channels': definition of dllimport function not allowed	C:\Windows\system32\CMakeLists.txt	C:\Users\user\Source\Repos\flac\src\libFLAC\stream_decoder.c	861	
Error	C2491	'FLAC__stream_decoder_get_channel_assignment': definition of dllimport function not allowed	C:\Windows\system32\CMakeLists.txt	C:\Users\user\Source\Repos\flac\src\libFLAC\stream_decoder.c	868	
Error	C2491	'FLAC__stream_decoder_get_decode_position': definition of dllimport function not allowed	C:\Windows\system32\CMakeLists.txt	C:\Users\user\Source\Repos\flac\src\libFLAC\stream_decoder.c	896	

This happens because public API symbols are marked as __declspec(dllimport) with FLAC_API in both definition (header) and declaration (source) files. Visual Studio wants only definition to be marked.

The solution is to mark public symbols as FLAC_API in headers only. GCC and compatible compilers are not affected by this change, they allow visibility attribute on definition and declaration or even on both.

"Double free or corruption" involving client data in decoder

OK, I've spent several hours yesterday and today trying to figure this out, and so I'd like to try to seek help here. I'm writing a Haskell binding to libFLAC. It's quite complete right now and everything works, except for one issue with decoder.

The decoder looks like this:

-- | Decode a FLAC file to WAVE.
--
-- 'DecoderException' is thrown when underlying FLAC decoder reports a
-- problem.

decodeFlac :: MonadIO m
  => DecoderSettings   -- ^ Decoder settings
  -> FilePath          -- ^ File to decode
  -> FilePath          -- ^ Where to save the resulting WAVE file
  -> m ()
decodeFlac DecoderSettings {..} ipath' opath' = liftIO . withDecoder $ \d -> do
  ipath <- makeAbsolute ipath'
  opath <- makeAbsolute opath'
  liftInit (decoderSetMd5Checking d decoderMd5Checking)
  (maxFrameSize, wave) <- runFlacMeta def ipath $ do
    let waveFileFormat   = decoderWaveFormat
        waveDataOffset   = 0
        waveDataSize     = 0
        waveOtherChunks  = []
    waveSampleRate <- retrieve SampleRate
    waveSampleFormat <- SampleFormatPcmInt . fromIntegral
      <$> retrieve BitsPerSample
    waveChannelMask <- retrieve ChannelMask
    waveSamplesTotal <- retrieve TotalSamples
    maxFrameSize <- fromIntegral <$> retrieve MaxFrameSize
    return (maxFrameSize, Wave {..})
  let bufferSize = maxFrameSize * fromIntegral (waveBlockAlign wave) + 1
  withTempFile' opath $ \otemp ->
    withBuffer bufferSize $ \buffer -> do
      initStatus <- decoderInitHelper d ipath buffer
      case initStatus of
        DecoderInitStatusOK -> return ()
        status -> throwIO (DecoderInitFailed status)
      liftBool d (decoderProcessUntilEndOfMetadata d)
      processedRef <- newIORef (0 :: Word64)
      writeWaveFile otemp wave $ \h -> fix $ \nextOne -> do
        processed <- readIORef processedRef
        unless (processed == waveSamplesTotal wave) $ do
          liftBool d (decoderProcessSingle d)
          frameSize <- fromIntegral <$> decoderGetFrameSize d
          let toGrab = frameSize * fromIntegral (waveBlockAlign wave)
          -- FIXME This method relies on the fact that host architecture is
          -- little-endian. It won't work on big-endian architectures. Right
          -- now it's fine with me, but you can open a PR to add big-endian
          -- support.
          hPutBuf h buffer toGrab
          modifyIORef' processedRef (+ fromIntegral frameSize)
          nextOne
      liftBool d (decoderFinish d)
      renameFile otemp opath

decoderInitHelper C internals:

https://github.com/mrkkrp/flac/blob/master/cbits/stream_decoder_helpers.c

The issue I'm getting only manifests itself with compiled code (test suite), it does not seem to exist when I use GHCi. It looks like this:

*** Error in `/home/mark/projects/programs/haskell/flac/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/tests/tests': double free or corruption (out): 0x000000000138cf60 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x70c4b)[0x7f69d630bc4b]
/usr/lib/libc.so.6(+0x76fe6)[0x7f69d6311fe6]
/usr/lib/libc.so.6(+0x777de)[0x7f69d63127de]
/usr/lib/libFLAC.so.8(+0xa401)[0x7f69d7400401]
/usr/lib/libFLAC.so.8(FLAC__stream_decoder_finish+0x52)[0x7f69d7443e42]
/home/mark/projects/programs/haskell/flac/.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/tests/tests[0x52b2da]
======= Memory map: ========

Yep, double free or corruption means I free something twice or try to free something not previously allocated with malloc or similar. Through experimentation I know that three parts of the program influence this:

  • decoderFinish invocation

  • decoderDelete, which is hidden inside withDecoder like this:

    withDecoder :: (Decoder -> IO a) -> IO a
    withDecoder f = bracket decoderNew (mapM_ decoderDelete) $ \mdecoder ->
      case mdecoder of
        Nothing -> throwM
          (DecoderFailed DecoderStateMemoryAllocationError)
        Just x -> f x
  • free in withBuffer:

    withBuffer :: Int -> (Ptr Void -> IO a) -> IO a
    withBuffer n = bracket (mallocBytes n) free

If I remove all three decoderFinish, decoderDelete, and free, the problem is not visible. If I put back any of these, the issue is back too.

From reading source code of libFLAC, I see that decoderFinish resets client_data to 0 and decoderDelete calls decoderFinish. However it sets pointer to 0, and pointer itself is passed by value, so I don't see how this may cause any problems at all. I've checked every mention of client_data in source code of stream decoder, nothing looks suspicious.

Haskell's mallocBytes looks like thin wrapper around C malloc, similarly to free, no catch there too.

You can see the entire source code here: https://github.com/mrkkrp/flac

So far I'm quite exhausted, I only suspect there must a connection between the allocated buffer and freeing of decoder instance, at least it looks like it.

@erikd, Knowing that you're familiar with both Haskell and libFLAC, I wonder if you know what might be going on here. Thanks a lot in advance, I really want to finally finish this ;-)

Specific encoding options should always have precedence over presets

Currently, extending encode presets depends on the order of the arguments.

This command applies the "-epr8" options:

flac --best -epr8 myfile.wav

While this command doesn't apply them:

flac -epr8 --best myfile.wav

I think the user expects the options he specifies to take precedence over the preset, no matter in what order they are specified.

See the options parsing in encode.c

CMake flac build error with BUILD_SHARED_LIBS=ON

[71/118] cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=src\flac\CMakeFiles\flacapp.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1421~1.277\bin\Hostx64\x64\link.exe  src\flac\CMakeFiles\flacapp.dir\analyze.c.obj src\flac\CMakeFiles\flacapp.dir\decode.c.obj src\flac\CMakeFiles\flacapp.dir\encode.c.obj src\flac\CMakeFiles\flacapp.dir\foreign_metadata.c.obj src\flac\CMakeFiles\flacapp.dir\main.c.obj src\flac\CMakeFiles\flacapp.dir\local_string_utils.c.obj src\flac\CMakeFiles\flacapp.dir\utils.c.obj src\flac\CMakeFiles\flacapp.dir\vorbiscomment.c.obj  /out:src\flac\flac.exe /implib:src\flac\flacapp.lib /pdb:src\flac\flac.pdb /version:0.0  /machine:x64 /debug /INCREMENTAL  /subsystem:console  src\share\getopt\getopt.lib src\share\replaygain_synthesis\replaygain_synthesis.lib src\share\utf8\utf8.lib src\share\win_utf8_io\win_utf8_io.lib src\share\grabbag\grabbag.lib src\libFLAC\FLAC.lib D:\vcpkg\installed\x64-windows\debug\lib\ogg.lib src\share\win_utf8_io\win_utf8_io.lib src\share\replaygain_analysis\replaygain_analysis.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
FAILED: src/flac/flac.exe 
cmd.exe /C "cd . && "C:\Program Files\CMake\bin\cmake.exe" -E vs_link_exe --intdir=src\flac\CMakeFiles\flacapp.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1421~1.277\bin\Hostx64\x64\link.exe  src\flac\CMakeFiles\flacapp.dir\analyze.c.obj src\flac\CMakeFiles\flacapp.dir\decode.c.obj src\flac\CMakeFiles\flacapp.dir\encode.c.obj src\flac\CMakeFiles\flacapp.dir\foreign_metadata.c.obj src\flac\CMakeFiles\flacapp.dir\main.c.obj src\flac\CMakeFiles\flacapp.dir\local_string_utils.c.obj src\flac\CMakeFiles\flacapp.dir\utils.c.obj src\flac\CMakeFiles\flacapp.dir\vorbiscomment.c.obj  /out:src\flac\flac.exe /implib:src\flac\flacapp.lib /pdb:src\flac\flac.pdb /version:0.0  /machine:x64 /debug /INCREMENTAL  /subsystem:console  src\share\getopt\getopt.lib src\share\replaygain_synthesis\replaygain_synthesis.lib src\share\utf8\utf8.lib src\share\win_utf8_io\win_utf8_io.lib src\share\grabbag\grabbag.lib src\libFLAC\FLAC.lib D:\vcpkg\installed\x64-windows\debug\lib\ogg.lib src\share\win_utf8_io\win_utf8_io.lib src\share\replaygain_analysis\replaygain_analysis.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\PROGRA~2\MIB055~1\2019\COMMUN~1\VC\Tools\MSVC\1421~1.277\bin\Hostx64\x64\link.exe src\flac\CMakeFiles\flacapp.dir\analyze.c.obj src\flac\CMakeFiles\flacapp.dir\decode.c.obj src\flac\CMakeFiles\flacapp.dir\encode.c.obj src\flac\CMakeFiles\flacapp.dir\foreign_metadata.c.obj src\flac\CMakeFiles\flacapp.dir\main.c.obj src\flac\CMakeFiles\flacapp.dir\local_string_utils.c.obj src\flac\CMakeFiles\flacapp.dir\utils.c.obj src\flac\CMakeFiles\flacapp.dir\vorbiscomment.c.obj /out:src\flac\flac.exe /implib:src\flac\flacapp.lib /pdb:src\flac\flac.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console src\share\getopt\getopt.lib src\share\replaygain_synthesis\replaygain_synthesis.lib src\share\utf8\utf8.lib src\share\win_utf8_io\win_utf8_io.lib src\share\grabbag\grabbag.lib src\libFLAC\FLAC.lib D:\vcpkg\installed\x64-windows\debug\lib\ogg.lib src\share\win_utf8_io\win_utf8_io.lib src\share\replaygain_analysis\replaygain_analysis.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:src\flac\CMakeFiles\flacapp.dir/intermediate.manifest src\flac\CMakeFiles\flacapp.dir/manifest.res" failed (exit code 1120) with the following output:
Microsoft (R) Incremental Linker Version 14.21.27702.2
Copyright (C) Microsoft Corporation.  All rights reserved.

main.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
vorbiscomment.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
grabbag.lib(picture.c.obj) : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
analyze.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
decode.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
encode.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
foreign_metadata.c.obj : error LNK2001: unresolved external symbol flac_internal_fopen_utf8
decode.c.obj : error LNK2019: unresolved external symbol flac_internal_unlink_utf8 referenced in function DecoderSession_destroy
encode.c.obj : error LNK2001: unresolved external symbol flac_internal_unlink_utf8
main.c.obj : error LNK2001: unresolved external symbol flac_internal_unlink_utf8
grabbag.lib(file.c.obj) : error LNK2001: unresolved external symbol flac_internal_unlink_utf8
main.c.obj : error LNK2019: unresolved external symbol flac_internal_rename_utf8 referenced in function encode_file
win_utf8_io.lib(win_utf8_io.c.obj) : error LNK2019: unresolved external symbol flac_internal_set_utf8_filenames referenced in function get_utf8_argv
win_utf8_io.lib(win_utf8_io.c.obj) : error LNK2019: unresolved external symbol flac_internal_get_utf8_filenames referenced in function CreateFile_utf8
grabbag.lib(file.c.obj) : error LNK2019: unresolved external symbol flac_internal_stat64_utf8 referenced in function grabbag__file_copy_metadata
grabbag.lib(replaygain.c.obj) : error LNK2001: unresolved external symbol flac_internal_stat64_utf8
grabbag.lib(file.c.obj) : error LNK2019: unresolved external symbol flac_internal_chmod_utf8 referenced in function grabbag__file_copy_metadata
grabbag.lib(replaygain.c.obj) : error LNK2001: unresolved external symbol flac_internal_chmod_utf8
grabbag.lib(file.c.obj) : error LNK2019: unresolved external symbol flac_internal_utime_utf8 referenced in function grabbag__file_copy_metadata
src\flac\flac.exe : fatal error LNK1120: 8 unresolved externals

@krokoziabla

flac-1.3.2: case07-expect.meta test failure

The release tarball available on http://downloads.xiph.org/releases/flac/ doesn't carry the changes from ac39d37 for the case07-expect.meta file, resulting in a test failure:

[...]
test case06: --set-tag=TITLE... OK
test case07: --show-vendor-tag --show-tag=ARTIST... make[1]: Leaving directory '/var/tmp/paludis/build/media-libs-flac-1.3.2/work/flac-1.3.2/test'
ERROR: metadata does not match expected ../test/metaflac-test-files/case07-expect.meta
make[1]: *** [Makefile:707: check] Error 1
make: *** [Makefile:486: check-recursive] Error 1
[...]

Please restart FLAC Internet Draft in IETF

Hi!
Please restart FLAC Internet-Draft,Because
1.FLAC has already widely applied (Microsoft Windows,Google Chrome,Mozilla Firefox and Google Android)
2.FLAC has implemented by libFLAC FFmpeg and more(some DAW software like Adobe Audition)
3.FLAC is a polpular and de-facro,widely applied in lossless
music sevices and lossless audio preservation
4.opus is a standardized audio codec in IETF, its wiki recommend high sampling rate user to use FLAC

CRC update performance gain ?

According to
https://www.phoronix.com/scan.php?page=news_item&px=Faster-FLAC-Ogg-CRC-Performance

5% performance gain should be expected on flacs.
I've seen that the patch has been integrated and committed into the master branch

I did some performance tests on Ubuntu (18.04/gcc 7.3.0/Broadwell NUC) and couldn't get more then 2% gain out of the change.

OK. It's better then nothing. Still it's not 5% as suggested.

Keep up your great work.

Encoding test:


*** DURATION:00:06:28.93
*** SAMPLERATE:44100
*** BITRATE:24
*** COMPRESSION:5


Binary = /tmp/flac-ubuntu-10-2017

real 0m1,259s
user 0m1,210s
sys 0m0,049s


Binary = /tmp/flac-newcrc-git-master-05-2018

real 0m1,244s
user 0m1,187s
sys 0m0,057s


All files located on tmpfs.

Improve documentation for removing an interface.

I've read the notes for embedded developers:

Unused parts may be pruned by some simple editing of src/libFLAC/Makefile.am

It's not clear to me how to remove the metadata interface. I tried commenting some source files and then running automake:

	#metadata_iterators.c \
	#metadata_object.c \

When I build I get linker errors. Linux calls that I don't want/need as I am running on an RTOS:

metadata_iterators.c:(.text+0x52c): undefined reference to `chmod'
metadata_iterators.c:(.text+0x534): undefined reference to `utime'
metadata_iterators.c:(.text+0x540): undefined reference to `chown'
metadata_iterators.c:(.text+0x552): undefined reference to `chown'

My goal is only to encode data that will be pushed to the cloud.

Let metaflac output to a different file

TL;DR: metaflac should support outputting to a different file, like vorbiscomment(1).

Background: I have created a music compilation system which works kinda like a software build system. When possible, it encodes and tags in different steps so that a mere tag change doesn't result in the reencoding of the entire library. Unfortunately, metaflac doesn't support outputting to a different file (or to stdout), so I have to copy the untagged files manually.

Currently:

flac -o song-untagged.flac song.wav
cp -- song-untagged.flac song.flac
metaflac --set-tag=TITLE=Song song.flac

Desired:

flac -o song-untagged.flac song.wav
metaflac --set-tag=TITLE=Song -o song.flac song-untagged.flac

Since metaflac is designed to operate on multiple files simultaneously and we don't want to break the interface, I think the easiest would be to add a -o option. If it is specified, only one input file may be passed; any more should cause an error.

issue with flac_internal_CreateFile_utf8

Hi guys,

There is a missing return type in flac_internal_CreateFile_utf8 in case of

#if _MSC_VER > 1900 && WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)

I suppose there should be a

return handle;

Thanks !

flac_set_utf8_filenames is not exported

Hi!
I wanted to use libflac from vcpkg. I need to handle utf8 filenames under Windows and there are two issues:

  1. include/share folder is not included in the resulting package. This is vcpkg issue and I can work around this by manually copying the folder to appropriate location.
  2. flac_set_utf8_filenames is not exported so I am not able to call it from the main application. This would required modification of the libflac library.

Could you make the flac_set_utf8_filenames function exported?

FLAC__stream_decoder_seek_absolute sometimes fails when it shouldn't

Function FLAC__stream_decoder_seek_absolute sometimes returns false when the file (and the requested offset) are both absolutely fine. This is because of a bug in read_subframe_lpc_ (in stream_decoder.c) which fails to notify its caller that the decoder has not yet got into frame sync.

The faulty line of code is:

if(!read_residual_partitioned_rice_(decoder, order, subframe->entropy_coding_method.data.partitioned_rice.order, &decoder->private_->partitioned_rice_contents[channel], decoder->private_->residual[channel], /*is_extended=*/subframe->entropy_coding_method.type == FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2))
	return false;

And this should read (I reckon):

if(!read_residual_partitioned_rice_(decoder, order, subframe->entropy_coding_method.data.partitioned_rice.order, &decoder->private_->partitioned_rice_contents[channel], decoder->private_->residual[channel], /*is_extended=*/subframe->entropy_coding_method.type == FLAC__ENTROPY_CODING_METHOD_PARTITIONED_RICE2))
{
	send_error_to_client_(decoder, FLAC__STREAM_DECODER_ERROR_STATUS_UNPARSEABLE_STREAM);
	decoder->protected_->state = FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
	return true;
}

Something like that, anyway. I didn't dig that deeply.

--keep-foreign-metadata discards WAV cue markers

I noticed that option --keep-foreign-metadata discards WAV cue markers. Here is how to reproduce the bug:

  1. Create a 24-bit 96khz in SoundForge8, add 20 seconds of silence, and add two markers with "m" key shortcut
  2. Save it, compress it with flac --keep-foreign-metadata testmarkers.wav
  3. Decompress it with flac -d testmarkers.flac
  4. Open the decompressed WAV in SoundForge: the markers have disappeared.

Here is a WAV containing markers: http://gget.it/q4uh4/testmarkers.zip if you want to test it.

emscripten can't make : host cpu detection failure

It seems that there is no fallback mode for unknown hosts.

I am making for WASM using emscripten and cpu.c fails to build.

config.log report the following :
configure:5500: checking host system type
configure:5513: result: x86_64-pc-linux-gnu

Build reports the following :

CC cpu.lo
cpu.c:91:43: error: invalid output constraint '=a' in asm
asm volatile (".byte 0x0f, 0x01, 0xd0" : "=a"(lo), "=d"(hi) : "c" (0));

Configure outputs the following :
-=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-

Configuration summary :

FLAC version : ........................ 1.3.2

Host CPU : ............................ x86_64
Host Vendor : ......................... pc
Host OS : ............................. linux-gnu

Compiler is GCC : ..................... no
Compiler is Clang : ................... yes
SSE optimizations : ................... yes
Asm optimizations : ................... no
Ogg/FLAC support : .................... yes

"modified time" attribute not updated when overwriting files

In a nutshell, I am reencoding files like so: FOR %a IN (*.flac) DO flac -f --best "%a". This allows me to apply stronger compression settings, update the encoder, etc.

But I just noticed the "modified time" attribute is not updated (at least on Windows). This is problematic because e.g. most backup softwares use this attribute to determine what file have been modified.

[Embedded]"long long" not recognize by my compiler (VisualDSP++4.5)

Hello,

I'm trying to implement a Flac encoder/decoder on a Sharc DSP board, with VisualDSP++ 4.5 as the compiler IDE, but I keep encountering the same error when compiling:

__int64 "long long" is a nonstandard type

This happen when the compiler interpret any line with the use of "__int64" type. Have you any ideas how can I bypass this problem?

Best regards,

Tolgotha

Livestreaming silence causes client timeouts

Hello! I’m a software developer for XBN, and we’re trying to improve our lossless streaming infrastructure. We’ve discovered that when live streaming OGG+FLAC to Icecast and digital silence occurs, stream clients misbehave. For instance, VLC will stop incrementing the play time counter, then time out and exit. MPV will play twice the length of the silence, once as it happens (empty buffer), and again after it ends (the silent data). To mitigate this problem we’ve been inserting dithering noise into our audio workflow, but this workaround somewhat defeats the point of lossless streaming. Digital silence can occur surprisingly often if using virtual audio devices, digital audio workflows (ie. S/PDIF) or when streaming any audio file that contains silence with no dither.

Through testing, we’ve figured out that the problem is caused by the CONSTANT subframe type waiting for the stream of identical samples to end before sending any data to clients. Using a test pipeline with the undocumented --disable-constant-subframes flag for flac seems to solve the timeout problems in the clients we tested. Of course, disabling the CONSTANT sub-frame type drastically reduces the efficiency of the codec in these cases, so it is a suboptimal solution. The easiest interim solution would be to make these private API functions (FLAC__stream_encoder_disable_constant_subframes() and company) public so that broadcast software can disable the feature when necessary, but since the problem isn’t inherent to the CONSTANT subframe optimization, there should be a better way to solve it.

Perhaps a “live” option could be added to the FLAC encoder (or perhaps the OGG muxer?) so that as digital silence occurs in an OGG+FLAC stream the encoder does not stop outputting data entirely. This would ensure that audio data continues to be streamed, preventing client buffers from emptying.

Step up git revision

When downloading sources from flac git, it still shows version 1.3.2 - binary,library,...

Due to rather limited number of releases, people use the git sources as base.
And that's causing confusion.

Beside that you also offer 1.3.2 from 1.1.2017 as stable on https://ftp.osuosl.org/pub/xiph/releases/flac/

Of course those 2 - git and stable - have nothing in common.

Files generated with the git version will also get below vendor string written into the Vorbis header:
"vendor string: reference libFLAC 1.3.2 20170101"

Which is IMO not OK. It wouldn't reflect all the changes that went into flac-git recently.

I'd think stepping up the revision in git or introducing a development branch would make a lot of sense to me and live much easier. Thx a lot.

FLAC__bitwriter_write_byte_block "could be faster"

I'm profiling a performance bottleneck in my .NET Core application (calls libFLAC via p/invoke), and it looks like the FLAC encoder is spending a good 70% of its time in this method, after I call FLAC__stream_encoder_init_stream. This happens when I write a (pretty large, ~3MB) picture block along with the audio.

I expect some overhead, but noticed the comment in the code:

inline FLAC__bool FLAC__bitwriter_write_byte_block(FLAC__BitWriter *bw, const FLAC__byte vals[], uint32_t nvals)
{
	uint32_t i;

	/* this could be faster but currently we don't need it to be since it's only used for writing metadata */
	for(i = 0; i < nvals; i++) {
		if(!FLAC__bitwriter_write_raw_uint32_nocheck(bw, (FLAC__uint32)(vals[i]), 8))
			return false;
	}

	return true;
}

I'm not a C guy... anyone able to take a stab at improving this method?

flac.exe compiled using MSVC 2017 produces zero-size files

it seems that the issue resides within this part of code in "windows_unicode_filenames.c":

#if _MSC_VER > 1900 && WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_APP)
wchar_t *wname;
HANDLE handle = INVALID_HANDLE_VALUE;

if ((wname = wchar_from_utf8(lpFileName)) != NULL) {

	handle = CreateFile2(wname, dwDesiredAccess, dwShareMode, CREATE_ALWAYS, NULL);
	free(wname);
}

#else

it causes these warnings:

8>c:__workdir\projects\flac-master\src\libflac\windows_unicode_filenames.c(212) : : warning C4716: 'flac_internal_CreateFile_utf8': must return a value
8>c:__workdir\projects\flac-master\src\share\grabbag\file.c(133) : : warning C4700: uninitialized local variable 'h1' used
8>c:__workdir\projects\flac-master\src\share\grabbag\file.c(133) : : warning C4700: uninitialized local variable 'h2' used

compiling FLAC using Visual Studio 2010 compatibility

Hi,

I'm in the process of compiling sox audio tool including FLAC using Visual Studio. For compatibility reasons everything has to be compiled using toolset v100 (Visual Studio 2010 compatibility).
FLAC's compat.h file has the following lines

#if defined _MSC_VER
#  if _MSC_VER >= 1800
#    include <inttypes.h>

inttypes.h is marked missing by the IDE as the compiler version is right, but the tools - including the used header files - do not match the compiler.

Maybe you can check the test if it's safe to include the header.

Unresolved external symbols when building with UWP

I'm getting unresolved external symbols when compiling in following cases:

CreateFileA CreateFileW from here: https://github.com/xiph/flac/blob/master/src/libFLAC/windows_unicode_filenames.c
when compiling on Windows Universal Platform (UWP does not have CreateFileA CreateFileW, it only has CreateFile2)

flac_max flac_min from here:
https://github.com/xiph/flac/blob/master/src/libFLAC/include/private/macros.h
when compiling on Android with latest Android NDK (Clang)

there are so many options in that file, but can you just keep it simple to one version in all cases:

#define flac_min(a,b) ((a) <= (b) ? (a) : (b))
#define flac_max(a,b) ((a) >= (b) ? (a) : (b))

[cmake] linking with libFLAC++

MSVC 2019 and flac latest git master branch (95a9423) built with cmake.

I'm trying to work with libFLAC++ but I kept hitting these errors when linking:

2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_new
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_process_until_end_of_metadata
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_set_md5_checking
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_process_single
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_init_ogg_stream
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_set_metadata_respond
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_init_stream
2>flac.obj : error LNK2001: unresolved external symbol _FLAC__stream_decoder_delete

After some digging I found that I should also link to libFLAC which then solves the linking error.
The extra linking to libFLAC isn't required when libFLAC++ is built with msvc solution files, so here is my question: Is the extra linking to libFLAC expected/a bug when using cmake?

[cmake] msbuild error MSB5004

I'm using MSVC 2019 and compiling the latest master branch.

I ran:

cmake -G "Visual Studio 16 2019" -A Win32 ..\
msbuild FLAC.sln /target:FLAC++

Then msbuild shows the error:

Solution file error MSB5004: The solution file has two projects named "flac"

I suspect it is because these 2 are the same name flac:
https://github.com/xiph/flac/blob/master/src/flac/CMakeLists.txt#L4
https://github.com/xiph/flac/blob/master/src/libFLAC/CMakeLists.txt#L59
AFAIK MSVC solution file name is case-insensitive so in this case so they will be treated in-differently and thus result in error.

I tried to rename one of them to some other name, then the problem is gone.

Unsupported file format?

I'm trying to encode a wav file, which soxi reports to be a 32 bit floating point pcm (2 channels, 44100 Hz), and flac aborts encoding.

ERROR: unsupported format type 3

So, is floating point in wave not supported?

[flac built using latest source code from master branch, btw]

encoding/reencoding material - blocksize for > 48kHz

I am in the process of re-encoding my collection. I own quite a number of HiRes albums.

Your "help" on encoding says:

Specify the block size in samples. Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz). The reference encoder uses the same block size for the entire stream.

I guess that'll also apply for re-encoding:
I actually planned to use following command (all tracks to c-level 0) to run that re-encoding process:

flac --no-utf8-convert --totally-silent --no-error-on-compression-fail "Si" --force --compression-level-0

Now. Your (widely used) shortcuts e.g. compression-level-0:

-0, --compression-level-0, --fast Synonymous with -l 0 -b 1152 -r 3

wouldn't meet the blocksize criteria as suggested in your "help" and as far I understood it.

  1. flac still allows to apply the c-level-X shortcuts with the small blocksize on >48kHz material - without issuing a warning/error (I tried that).
    Would that be an issue?

  2. If I shouldn't be using the c-level-X shortcuts on >48kHz material, I guess using e.g. "-l 0 -b 8192 -r 3" would then the right way to do it, wouldn't it!?!?

New feature idea:
If above blocksize considerations are relevant at all - perhaps I misunderstood something here - for samplerates >48kHz, it would be nice if flac would adjust the blocksize automatically at a given shortcut for SRs >48kHz.

How to calculate bit rate of a FLAC file using libFLAC (that is, C)?

Hello, I'm not sure this is a correct place to ask this sort of question, but since flac-dev mailing list doesn't seem to be too active, I decided I would try here.

My question is regarding calculation of bit rate. In order to calculate bit rate we need to divide total size of compressed audio data by its duration in seconds. Duration in seconds can be calculated from sample rate and total number of samples, both values come from stream info metadata block and I have no problem with reading those. However, I don't see how I can get total size of audio data using libFLAC. So far I've read only the section about metadata, but stream encoder/decoder modules do not seem to provide a way to get this information either.

What is the correct way to get total size of audio data?

Compression level - "No compression"

The dbPoweramp designer desgined a compression level "no compression" for flac some time ago.
There seem to be people around appreciating this feature. It also shouldn't be too difficult
to make it happen inside flac.

dbPoweramp is offering this feature exclusive as it seems.

As we all know the known flac compression level "0" is not "0". That might be a bit misleading for some people.
But that's not the issue here.

It would be nice to have a compression level "no compression".
Basically an umcompressed PCM track (.wav) in a flac container.

  • .wav files could potentially be neglected altogether
  • tagging features, replaygain etc. of flac could be used throughout the lossless PCM collection
  • postprocessing could be more generalized (less filetypes) in some cases
  • some might use it for this or test purpose

I read somewhere that "no compression" can be accomplished by using certain options of
the flac binary. I didn't manage to come up with a positive result on that one.

My questions:

  1. Is there a set of options to flac which let me generate an uncompressed flac data file with just a
    PCM block and the tags inside.

  2. Would you guys consider it doable to introduce a single option to flac to accomplish a "no compression" file. I'd appreciate it.

SC

FLAC 1.3.2 appears to require an SSE3 processor (Intel x86)

I have compiled the latest FLAC sources for x86 (32 bit) and they appear to require an SSE3 processor. Specifically, I have a report from a customer with a XEON Prestonia processor that he cannot read his existing FLAC files (at all) and this processor supports SSE2 only.

I have replicated his problem here with a very old machine (which has no SSE support at all) but I have not investigated why this is happening. It doesn't crash - it's just that FLAC__stream_decoder_xxx functions do nothing and return FALSE. This is all happening in a release build. I have not checked whether debug builds are similarly affected. I am building with Visual Studio 2017.

Is this deliberate? I really hope not. The version I have been using up to now (1.3.1) works fine on all processors, even those without any form of SSE, and I value that. I have therefore, slightly reluctantly, reverted to that.

I did see in the change log that 1.3.2 requires SSE2 but I'm not actually sure that's true. Certainly the code as originally written has CPU detection logic and a set of dispatch functions so I don't see why this is necessary. I also ran a quick benchmark on my Core i3 and 1.3.1 and 1.3.2 perform identically. Overall, this all feels like a step backwards,

FLAC__stream_decoder_process_single decodes final frame twice?

Here is the minimal example that demonstrates the problem:

#include <FLAC/stream_decoder.h>
#include <FLAC/metadata.h>
#include <stdlib.h>
#include <stdio.h>

static FLAC__StreamDecoderWriteStatus write_callback
  ( const FLAC__StreamDecoder *decoder
  , const FLAC__Frame *frame
  , const FLAC__int32 *const ibuffer[]
  , void *client_data)
{
  return FLAC__STREAM_DECODER_WRITE_STATUS_CONTINUE;
}

static void error_callback
  ( const FLAC__StreamDecoder *decoder
  , FLAC__StreamDecoderErrorStatus status
  , void *client_data )
{
  return;
}

int main (int argc, char *argv[])
{
  unsigned block_size, state;
  FLAC__StreamDecoder *decoder = FLAC__stream_decoder_new();

  FLAC__stream_decoder_init_file(decoder, argv[1], write_callback, NULL, error_callback, NULL);
  FLAC__stream_decoder_process_until_end_of_metadata(decoder);

  /* Total samples: 14442750 */

  while ((state = FLAC__stream_decoder_get_state(decoder)) != FLAC__STREAM_DECODER_END_OF_STREAM)
    {
      printf("State so far: %d\n", state);
      FLAC__stream_decoder_process_single(decoder);
      block_size = FLAC__stream_decoder_get_blocksize(decoder);
      printf("Processed frame of size: %d\n", block_size);
    }
  FLAC__stream_decoder_delete(decoder);
}

Compile it:

$ gcc -lFLAC -o my_prog main.c

Next I feed it a FLAC file that I know contains exactly 14442750 samples. With frame size of 4096, the behavior I expect is that the program prints

State so far: 2
Processed frame of size: 4096

…quite a few times, but eventually it should say that it processed the final frame of length 14442750 % 4096 == 254 samples. After that the status sholud change to FLAC__STREAM_DECODER_END_OF_STREAM and the application should finish.

The actual result is:

…
Processed frame of size: 4096
State so far: 2
Processed frame of size: 254
State so far: 2
Processed frame of size: 254

As you can see it processes 254 final samples twice, which leads to exactly 254 “extra” samples in output (the code that puts the result into a buffer is not shown here for simplicity).

Is this a bug or a feature? Am I wrong in my undrestanding of how it should work?

Option to disable intro text in console output

The following text is outputted at the beginning of each and every processing:

flac 1.3.2
Copyright (C) 2000-2009 Josh Coalson, 2011-2016 Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are
welcome to redistribute it under certain conditions. Type `flac' for details.

When working in batches, this text makes visually parsing the console output much more difficult.

Currently there is no way to disable this text, I think an option should be added to allow disabling it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.