Activity for FLAC-Free Lossless Audio Codec
-
lynxtwo created ticket #122
Brainstormed Ideas for Improving Compression
-
Robust error correction
-
megaslowpoke posted a comment on ticket #486
Yes, I can look for and ask people I know about such files to test on them if it would help in any way. You can email me at my nickname tuta dot io, or on telegram at the same nickname, it will be easier and faster.
-
Martijn van Beurden posted a comment on ticket #486
You might be interested in hearing that I'm working on fully incorporating aifc support, including restoring the sowt byte order. If you are willing to test this functionality, please let me know
-
No, FLAC does not compress foreign metadata. Also, you are right that FLAC cannot restore AIFF data with sowt order. This is a limitation of the command line program
-
Yes, sorry, I completely forgot to add, here for example: https://soundcloud.com/professorkliq/chasing-time-pk-remix Button "More" => "Download file" How to reproduce, compress: "flac.134 --keep-foreign-metadata --no-padding --best --verify" Now unpack with different versions: "flac.132 -d --keep-foreign-metadata" "flac.134 -d --keep-foreign-metadata" Unpacked 134: will be with a different header.
-
I don't know what kind of chunk it is, the author creates a file on the "OP-1 sketch sequencer" device, so this is probably some kind of padding hardwired by the manufacturer according to some kind of standard or for his own purposes. In general, I just thought that such extra-data with the "keep-foreign-metadata" key can be stored compressed, anyway, when playing, they are never used and are not displayed anywhere, i.e. needed only to return the original file. In addition, the "option" to archive...
-
Do you have an example file? I'm unable to reproduce this. I tried compressing an old format 24-bit file with a cue chunk to FLAC, restoring it to WAVEFORMATEXTENSIBLE kept the cue chunk.
-
The problem here is that the foreign metadata is larger than the 16MB allowed maximum by FLAC, triggering some bugs. Do you have any idea what kind of chunk this is? It seems of the 63.504.112 bytes of that AIF file, only 47.424.520 contain actual audio, it seems the rest is some sort of metadata. I'll look into adding errors when this happens, but I cannot change FLAC to accept this data: the 16MB limit is one of the format and cannot be changed without breaking backward compatibility.
-
Hi, What preset have you used? Most presets, except presets -0 and -3, do stereo decorrelation.
-
Seamus de Mora created ticket #162
github README is wrong/incomplete
-
flac does not properly handle "keep-foreign-metadata" with format "aiff" and codec "sowt"
-
Flac versions 1.33/34 ignore the "--keep-foreign-metadata" option when unpacking
-
Dr. Sultan Aszazin posted a comment on ticket #484
My excuses, a small correction: I speak about approx. 15% improvement in file size, but I just discovered my frontend made an error, in converting from stereo to mono, it also converted from 16bits to 24 bits. So probably there isn't any kind of compression between channels at all? I believe this could be an improvement, if this was possible. There is no greater waste of space then keeping identical information where it can be avoided.
-
Compression of mono material recorded in 2 (identical) channels
-
Ah, it wasn't clear to me both accounts pointed to the same user :)
-
Erhard F. posted a comment on ticket #475
Thanks for pointing out! But the patches didn't work out yet. I'll test & answer directly on https://github.com/xiph/flac/issues/199 from now on. Reporting on 2 bugtrackers seems a bit of an overkill. ;)
-
Could you perhaps check whether these patches fix the problem? PR: https://github.com/xiph/flac/pull/317 Code: https://github.com/ktmf01/flac/tree/vsx
-
codesoap created ticket #483
Broken links for example code
-
Meanwhile I checked 1.3.4 on the G5 I originally reported the bug. Result is the same. BTW power9 is not necessary for VSX, it only needs power7 (https://en.wikipedia.org/wiki/AltiVec#VSX_(Vector_Scalar_Extension)).
-
It seems for some reason the compiler provides attribute((target("cpu=power9"))) but not the vsx functions in altivec.h when -mcpu=power9 isn't defined. This is much unlike GCC on x86, so I'm not sure how to proceed. I could check for the precence of vec_vsx_ld in altivec.h, but that would mean power9 functions aren't compiled in on your power9 machine when -mcpu=power9 isn't specified.
-
Just tested 1.3.4 on my Talos II (POWER9). There it get the same problem. See attached files. 1.3.4 builds however if I use./configure --disable-vsx && make or if I do a standard build explicitely for capable CPUs, e.g. ./configure && CFLAGS="-O2 -mcpu=power9" make. On my PowerMac G4 (ppc32) 1.3.4 builds and runs fine wieh ./configure && make. And I can check out 1.3.4 on my G5 (the machine I originally reported the bug on) next weekend.
-
Just tested 1.3.4 on my Talos II (POWER9). There it get the same problem. See attached files. 1.3.4 builds however if I use./configure --disable-vsx && make or if I do a standard build explicitely for capable CPUs, e.g. ./configure && CFLAGS="-O2 -mcpu=power9" make. On my PowerMac G4 (ppc32) 1.3.4 builds and runs fine wieh ./configure && make. And I can check out 1.3.4 on my G5 (the machine I originally reported the bug on) next weekend.
-
Another patch for decoding can be found here: https://github.com/xiph/flac/pull/283
-
Clark Dunson posted a comment on ticket #482
Thank you. Close this bug, we figured out that it happens when only when the Sitara is clocked at 1GHz. Thank you
-
It turns out these files have samples that exceed the range offered by 16-bit signed integers. I don't know how these FLAC files came to be, but they are invalid. I'm not yet sure how this is best handled (there's no way to really fix this) but there is already a patch to prevent these files from being created in the future: https://github.com/xiph/flac/pull/273
-
SSE2 was introduced in 2000 and has been mandatory for all 64-bit CPUs. Is it really such a big problem that those ancient CPUs get the best possible binary?
-
Michal Dec posted a comment on ticket #479
Well, this just leaves a portion of CPUs served worse than others. Non-SSE CPUs get their non-SSE binary, and only SSE2 CPUs get the SSE binary. My point is that the interests of the middle ground between these 2 CPUs should be covered. I could write a patch when I find the time. W dniu 1.03.2022 o 08:37, Martijn van Beurden pisze: This was done on purpose. Support for older CPUs (at the expense of a slower binary for newer CPUs) is enabled with --disable-sse as you noticed. This is nothing strange,...
-
Never mind, I was just able to reproduce this. Will investigate
-
Have you checked (as the error message says) that these errors always appear in the exact same spot?
-
Is this still an issue with the latest version of foobar? This doesn't seem to be an issue with flac.
-
The flac format doesn't specify any standard tag names. Whether a player recognized TRACK or TRACKNUMBER is up to the player.
-
I can no longer download the track, but this might be fixed with https://github.com/xiph/flac/pull/245
-
This is fixed as of FLAC 1.3.3, see https://xiph.org/flac/changelog.html
-
Release 1.3.4 has Windows compiles with ogg, see https://github.com/xiph/flac/releases/tag/1.3.4
-
FLAC version 1.3.4 has been released with some fixes for PPC. Can you try whether this is fixed now?
-
Are you using libFLAC directly or are you processing a WAV file through FLAC? Please note all data supplied to libFLAC has to be signed, so a signal between 0 and -1 would not be normalized as libFLAC sees it.
-
FLAC has no feature of creating read-only files. If this is still an issue, you should post a little more info on what system you're using, on what filesystem you are working, what exact commands you use etc.
-
How is this information stored in WAV files? Isn't using --keep-foreign-metadata sufficient to keep these?
-
This was done on purpose. Support for older CPUs (at the expense of a slower binary for newer CPUs) is enabled with --disable-sse as you noticed. This is nothing strange, many programs (browsers for example) and OSes (Windows 8.1 and up) require SSE2. FLAC however, still allows you to compile your own version without this requirement, but it is set as default.
-
I'm sorry this wasn't replied to earlier, but these trackers are pretty much abandoned. A workaround was included in the 1.3.4 release. More information can be found here: https://github.com/xiph/flac/pull/227
-
The flac utility needs a STREAMINFO to create a correct WAV file. The code could be changed such that the # of channels is retrieved from the frame headers, but the chunk size must be taken from the STREAMINFO. The fact that the FLAC format is streamable is only applicable to decoding on the fly (for immediate playback), this was never meant to make it properly decodable to WAV.
-
You shouldn't do cmake ../src but cmake .. instead in your case.
-
I am unable to reproduce this. I see a few strange things as well: it seems the seektable is 1.4MB in size. This is unusually large for a seek table. How did you create it? Perhaps this large seektable is the reason for the slowdown?
-
Patch is here: https://github.com/xiph/flac/pull/294
-
FLAC 1.3.1 is a very old version, and has been superseded by newer versions for more than 5 years. Please update.
-
This is not possible with the reference decoder. You can use one of the many other FLAC decoders available. For example, dr_flac can be used as you describe. See https://github.com/mackron/dr_libs
-
yixinuestc created ticket #161
How to use FLAC in synchronous way
-
test.wav: ERROR during encoding
-
Philippe created ticket #481
Channels not set in WAV header when decoding file w/o STREAMINFO
-
Simon Giddings created ticket #480
Using a seek table increases processing by 10 to 15 times
-
Cannot build FLAC with cmake
-
configure script incorrectly assumes sse2 availability
-
Till Schäfer modified a comment on ticket #478
Given the above analysis a more minmal patch, which produced a better assembly was created. (just adding a != 0 check to convert FLAC__bool to an actual bool (FLAC__bool is int)
-
Given the above analysis a more minmal patch, which produced better code was created. (just adding a != 0 check to convert FLAC__bool to an actual bool (FLAC__bool is int)
-
an in depth analysis downstream (see gentoo bug https://bugs.gentoo.org/719792) has revealed, that this issue is occurring only with certain optimization levels. Furthermore a minimal test example was created for assamber analysis (attached). Compiled with gcc -O2 -S -o test.s test.c callback1 (the erroneous case), is reduced to movzbl 56(%rsi), %eax movl %eax, (%rdx) ret Calling gcc with -O1 actually calls memcmp.
-
Benjamin Moody posted a comment on ticket #451
This does seem like it would be more convenient. And yet, it would be a significant change to the clearly documented API, and would undoubtedly break applications, including some of mine.
-
my analysis about the gcc versions was wrong, working was gcc 8.3 and failing was gcc 9.{2,3}
-
downstream bug reference: https://bugs.gentoo.org/719792
-
I can confirm the bug on gentoo after rebuilding flac 1.3.3. with gcc 9.3.0 (worked with gcc 9.2.0).
-
kda created ticket #478
has_md5sum fails when first byte of md5sum is zero.
-
isidroco created ticket #477
Can't write --replay-gain due to ReadOnly flacs
-
Gerd Feldkirch posted a comment on ticket #120
... without loosing the loop information.
-
add loop points
-
Upanita created ticket #476
Writing a simple tone to 'flac' file shows dropout.
-
config.h
-
1.3.3 fails to build on non-VSX ppc64 CPUs
-
Erik modified ticket #474
FLAC 1.3.3 package seems to don't include CMakeLists.txt.
-
Shigemasa Watanabe posted a comment on ticket #474
I don't seem to have permission to edit. Please close this.
-
Raised https://github.com/xiph/flac/issues/140 . I will close this.
-
Please raise this issueat https://github.com/xiph/flac/issues and then close this.
-
FLAC 1.3.3 package seems to don't include CMakeLists.txt.
-
Riccardo La Marca created ticket #473
--ogg parameter missing in flac for win64 and there is only for win32.
-
No Name posted a comment on ticket #472
I got to the bottom of it. $ metaflac --list 02\ -\ Angelica.flac ... METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 233 vendor string: reference libFLAC 1.3.2 20170101 comments: 8 comment[0]: ALBUM=Eternity [Peaceville Records-Pony Canyon Inc PCCY-01050] comment[1]: TRACKNUMBER=02 comment[2]: TRACKTOTAL=15 comment[3]: ARTIST=Anathema comment[4]: PERFORMER=Anathema comment[5]: GENRE=Doom Metal comment[6]: DATE=1996 comment[7]: TITLE=Angelica This shows that the correct tag is TRACKNUMBER,...
-
Players don't recognise TRACK (uppercase)
-
jook posted a comment on ticket #471
according to microsoft, bits-per-sample must be either 8 or 16 for type 1 (which is wave_format_pcm). for 24bit pcm, wave_format_extensible must be used. see https://msdn.microsoft.com/en-us/library/windows/desktop/dd390970(v=vs.85).aspx
-
flac.exe -d 24bit.flac 24bit.wav does NOT create 24bit wav with WAVEFORMATEXTENSIBLE
-
Constantine Kyriakopoulos created ticket #470
Too large output size
-
Engin Gürel created ticket #469
There is no "duration" and "bitrate" info when converted to mono
-
Max modified a comment on ticket #157
I have a Pentium III and I followed this guide. It works, but when I want to add cover image to file gives me an error: "ERROR: (--picture) error opening picture file" I have an another version from here (It works fully) but I want to build myself.
-
@lvqcl I have a Pentium III and I followed this guide. It works, but when I want to add cover image to file gives me an error: "ERROR: (--picture) error opening picture file" I have an another version from here (It works fully) but I want to build myself.
-
Cinema modified a comment on ticket #467
Hi, I also tried building this with the latest version of Cygwin64, (and the necessary packages). This also fails becuase _O_BINARY isn't defined on modern Cygwin, but O_BINARY is. It's also found in stream_encoder.c.
-
Hi, I also tried building this with the latest version of Cygwin64, (and the necessary packages). This also fails becuase _O_BINARY isn't defined on modern Cygwin, but O_BINARY is. It's also found in `stream_encoder.c`.
-
Hi, I also tried building this with the latest version of Cygwin64, (and the necessary packages). This also fails becuase `_O_BINARY` isn't defined on modern Cygwin, but `O_BINARY` is. It's also found in `stream_encoder.c`.
-
swansong created ticket #468
FLAC cannot work with three tracks
-
Compilation brakes on Windows w/ GCC and MSYS2
-
Signed Integer Overflow (65738191)
-
Signed Integer Overflow
-
Signed Integer Overflow - 65657174
-
This one is like #466, undefined behavior in the audio path. I highly recommend only fuzzing FLAC with the address sanitizer enabled and the undefined behavior sanitizer disabled.
-
This one is like #466, undefined behavior in the audio path. I highly recommend only fuzzing FLAC with the address sanitizer enabled and the undefined behavior sanitizer disabled.
-
The code contains at least hundreds of these audio path only computations that may trigger undefined behavior. Refactoring them as you suggest would be a significant amount of work and likely have significant impact on the performance of the program. My advice would be to only fuzz FLAC with the address santizer.
-
Google-Autofuzz posted a comment on ticket #466
Thanks for taking a look at this issue! If this does not represent any kind of problem, one thing to consider would be annotating the function with attributes to avoid sanitizer instrumentation: http://releases.llvm.org/5.0.0/tools/clang/docs/UndefinedBehaviorSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-undefined This may entail a small refactoring, i.e. to move 'safe' overflows that would result in garbage data into a dedicated function and keep other computations for things...
-
Signed Integer Overflow (65738191)
-
I've reproduced it: > examples/c/decode/file/example_c_decode_file autofuzz_65738191/poc-3aa012a1999dee3c9f817c022b2c79c89942f45d7b3309d744f69681aa2a6f40_min /dev/null sample rate : 12000 Hz channels : 8 bits per sample: 16 total samples : 53165582111 stream_decoder.c:2095:39: runtime error: signed integer overflow: 7995392 + 2142466002 cannot be represented in type 'int' ERROR: this example only supports 16bit stereo streams decoding: FAILED state: FLAC__STREAM_DECODER_ABORTED Thats the undefined...
-
Signed Integer Overflow (65738191)
-
the rent-a-brain created ticket #465
"Error: Got partial sample" causes modified time to be lost
-
Signed Integer Overflow
-
Phoenix created ticket #119
metaflac: Ability to export tags as XML
-
Andrew created ticket #118
Ability to tetect truncated files without md5 when using --test
1 >