Re: [flac-dev] Possible overflow of _candidate_bits in stream_encoder.c
Martijn van Beurden wrote: > > P.S.: I'm sending this for the second time, sorry if it arrives twice. > It seems to me e-mails over 50kb don't get through. Would it be possible to submit these patches as a PR on Github? Thanks, Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Possible overflow of _candidate_bits in stream_encoder.c
Martijn van Beurden wrote: > To trigger this overflow, one has to force rice_parameter to 0 Ok, that sounds dodgy. > in for > example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c. > When encoding noisy material, which needs a high rice parameter, it can > happen that the return value of that function overflows. Te value is currently uint32_t ? > Should I send a patch to change all affected uint32_t to uint64_t? Or is > this benign enough not to matter? As far as I can tell, such a patch should > only touch private functions, no public ones. Would be interested if there is any measureable difference in performance from this change. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Mid-Stream Meta Data Updates for ICEcast
b...@radio42.com wrote: > Any News to this question? I don't even fully understand the issue. > Any chance to get an meta-data update interface for automatic chained > channels on the encoder side implemented? Clean patches to add this accepted. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Erik de Castro Lopo wrote: > Hopefull the final release candidate: > > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz > http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz.asc I am assuming everyone was happy with that and that I can release a new version. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Erik de Castro Lopo wrote: Hopefull the final release candidate: http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz.asc Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Dagobert Michelsen wrote: > I did use autotools, the problem is that -lrt is missing for the respective > binary > during linkage. I created > https://github.com/xiph/flac/pull/112 > to take care of this. I suggest to continue discussion on this PR on Github. Merged, thanks. I will roll one more pre-release, probably today. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Erik de Castro Lopo wrote: > Which build system are your using? Any chance of a patch? I just checked, and the autotool build system should just do the right thing on Solaris. Maybe you are using the CMake build system and should try the other one. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Dagobert Michelsen wrote: > I have an undefined symbol on Solaris 10 Sparc with GCC 5.5: > > > Undefined first referenced > > symbol in file > > clock_gettime util.o > > At the moment librt is only added for Linux whereas it would be better to > check > on all operating systems if the function is in librt. Which build system are your using? Any chance of a patch? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Erik de Castro Lopo wrote: > I have a new pre-reelase (with a GPG signature) up here: New version: http://mega-nerd.com/tmp/flac-1.3.3rc2.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc2.tar.xz.asc Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Janne Hyvärinen wrote: > Replace 'PACKAGE_VERSION=\1.3.2\' with > 'PACKAGE_VERSION=\1.3.3rc1\' in > src/libFLAC/libFLAC_dynamic.vcproj and libFLAC_static.vcproj. And > replace 'PACKAGE_VERSION="1.3.2"' with 'PACKAGE_VERSION="1.3.3rc1"' in > src/libFLAC/libFLAC_dynamic.vcxproj and libFLAC_static.vcxproj. Never mind, I responded before the coffee had kicked in. I can do that. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Erik de Castro Lopo wrote: > Janne Hyvärinen wrote: > > > Minor changes needed for Visual Studio as the version is defined in the > > project files. > > > > Replace 'PACKAGE_VERSION=\1.3.2\' with > > 'PACKAGE_VERSION=\1.3.3rc1\' in > > src/libFLAC/libFLAC_dynamic.vcproj and libFLAC_static.vcproj. And > > replace 'PACKAGE_VERSION="1.3.2"' with 'PACKAGE_VERSION="1.3.3rc1"' in > > src/libFLAC/libFLAC_dynamic.vcxproj and libFLAC_static.vcxproj. > > I have not way of verifying if any hand edit I do is correct. > > For that reason I reall do need a proper diff. Sorry, The diff can be against current git master. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Prelease now available
Janne Hyvärinen wrote: > Minor changes needed for Visual Studio as the version is defined in the > project files. > > Replace 'PACKAGE_VERSION=\1.3.2\' with > 'PACKAGE_VERSION=\1.3.3rc1\' in > src/libFLAC/libFLAC_dynamic.vcproj and libFLAC_static.vcproj. And > replace 'PACKAGE_VERSION="1.3.2"' with 'PACKAGE_VERSION="1.3.3rc1"' in > src/libFLAC/libFLAC_dynamic.vcxproj and libFLAC_static.vcxproj. I have not way of verifying if any hand edit I do is correct. For that reason I reall do need a proper diff. Sorry, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Prelease now available
Hi all, I have a new pre-reelase (with a GPG signature) up here: http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc1.tar.xz.asc This code is built from commit 10a28d482a8e48b806f61ab766992b2add98ec43 plus another commmit to change the version numbers which I will not be pushing to the public repo before the final release. Note that audio files encoded with a pre-releases will be 3 bytes longer than the the file encoded with the 1.3.3 final release because the version string is "1.3.3rc1" instead of "1.3.3". I hope to make a full release within a week. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Inquiry about use case
minoru_tamam...@audio-technica.co.jp wrote: > Dear Customer Service, Sorry, we do not have customer service. Its just us developers here :). > My name is Tamamura and I am in charge of Audio-Technica. Hi! > I want to be able to play FLAC using the API that BT IC has. Sorry, what is BT and/or IC ? > Do I need to get permission from you? As long as you abide by the license, you do not ned to ask for permission from me or anyone else. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Proposal to remove the Visual Studio project files
Hi all, Thanks to the hard work of two contributors, FLAC will soon have a complete CMake build system (https://github.com/xiph/flac/pull/97). My understanding is that once this is part of the main distribution, the Visual Studio project files will no longer be needed and can therefore be removed. The removal will happen *after* the next release (which will contain both CMake and VS build systems). For people who have github accounts, comments can be made here: https://github.com/xiph/flac/issues/100 People witout github accounts can comment here. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] move CreateFile() function from libFLAC
lvqcl wrote: > This patch renames flac_internal_CreateFile_utf8() function to > grabbag__CreateFile_utf8() and > moves it from /src/libFLAC/windows_unicode_filenames.c into > src/share/grabbag/file.c > This function is not used by libFLAC anyway. > > After this, it should be possible to compile libFLAC as UWP. Was submitted via github and has been merged. Thanks! Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix more GCC warnings about case fall-through
lvqcl wrote: > THere was a patch that silences GCC -Wimplicit-fallthrough warnings, see > https://git.xiph.org/?p=flac.git;a=commit;h=1b5c09e4c692e243239945be3cba3ec72ea1699f > > There are a few more places that need this treatment. The patch is attached. Applied. Thanks! Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Question: MSVS 2005/2008 support?
lvqcl wrote: > Are there any developers that want to use libFLAC in their programs > and still use Visual Studio 2005 or 2008 ? 2008 is 10 years ago and the other is older. The don't work now (due to ogg) and they cannot be fixed. These should be removed. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] libFLAC optimizations request
Gabriel Corneanu wrote: > Is this interesting for the project? I would theoretically accept a patch that allows direct access to the functionality you seek, as long as it doesn't change the existing API. > If yes, how should I share it? As a patch against current git? Probably easiest as as PR against: https://github.com/xiph/flac/ > > Other small details: > - I commented out by default the vorbis comment; if this is important > to be kept, I would like an option (e.g. I could save ~100MB out of > ~1.1GB compressed data). I'm pretty sure this default vorbis comment is part of the official specfication of FLAC and hence should probably not even be made optional. You can probably avoid it by using the library directly instead of using the flac command line program. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] libFLAC optimizations request
Gabriel Corneanu wrote: > I am using libFLAC in a corner application, compressing *a lot* of small > signals. You are of course aware that this is *not* what FLAC was designed for, > First is a general question: in our application we have signals in range > 5-10 MHz, potentially 40MHz! Is there any potential problem with that?? No idea whatsoever. It really depends on the signal. FLAC is *designed* and optimised for compressing audio signals, specifically music. For cases where the FLAC compressed signal is does not actually compress well (on example is white noise) the audio is included uncompressed. > The > mac sample rate is limited in flac, but it doesn't really seem to be a > problem. FLAC is the Free Lossless **AUDIO** codec. > The output is stored as blob in a sqlite database, it *never *needs to be a > valid audio file outside our application. > In my tests, the signals are compressed very well, much better than general > compression libraries like zlib, zstd, etc. So regardless of the higher sample rate your signals seem to be enough like audio for FLAC to compress them well. > Now other small issues; I also made some tickets about them, but I thought > asking here might be better. > > 1. I would like to avoid saving vorbis comment, by default ~40 bytes. Right > now the only option is to modify stream_encoder.c, see > "metadata_has_vorbis_comment". Are you using the FLAC library directly or the flac command line program? If you are using the flac command line program, please feel free to hack that to your hearts content (as long as you abide by the very libreral license). > 2. Speed is very important, therefore I would like to reuse an encoder > without re-initializing everything. > Ideally I would like 2 (exported) functions: "flush" and "restart". > "Flush" is self-explanatory, should properly end the encoding. I could > split myself "flush" from "finish", it looks relatively simple. > "Restart" should keep all current settings, generate a new stream header > and clear everything for encoding a new signal. > It' clear that current settings, re-creating windows, cpu-dependent > functions, etc could be kept around. > I was not quickly able to extract all the necessary initialization from > "init_stream_internal_" into a new "FLAC__stream_encoder_restart" function. I would theoretically accept a patch that allows direct access to the functionality you seek, as long as it doesn't change the existing API. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Build failed on macOS after upgrade to 1.3.2
Baoshan Sheng wrote: > After upgraded to 1.3.2, when compiling using Xcode, I received many errors > on `#if ... FLAC__HAS_X86INTRIN` lines. I noticed the `defined` before > `FLAC__HAS_X86INTRIN` is removed by contributor Erik de Castro Lopo. > > Could someone provide a way to compile 1.3.2 on Xcode for macOS? What version of XCode are you using? Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC compression experiment
z1x2c3v4z1x2c3v4 wrote: > I feel I have found a super high compression way of FLAC. I > have tested a 1 hour WAV file of 440HTZ with a 5,25,50,75,100 > normalize volume preset So this a a test file with just a 440Hz sine wave? That signal is totally unlike actual music that people use FLAC to encode. If you can test with normal music signals and still see the same results then you may get some more interest. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] GCC7: -Wimplicit-fallthrough
lvqcl wrote: > If I compile libFLAC with GCC 7.1 I see many warnings like > > lpc.c: In function 'FLAC__lpc_compute_residual_from_qlp_coefficients': > lpc.c:489:18: warning: this statement may fall through Yeah, that is a new warning in GCC 7. There is a way of annotating the code with a comment to tell the compiler that the fall through is intentional. I'll install gcc 7 and fix these ASAP. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] PR on Github
lvqcl, I would appreciate it if you could have a look at this PR on Github. It updates the file `lpc_intrin_sse.c`. https://github.com/xiph/flac/pull/33 Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] doc: Add notes about subframe sample size
Ruud van Asseldonk wrote: > Here you go. Wonderful. Thank you! Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [Cellar] FLAC Markdown
Ruud van Asseldonk wrote: > I'm jumping in on this thread to make a few remarks about the spec. I > implemented a FLAC decoder by only looking at the spec, and I have a few > notes that would have saved me a lot of time if the spec had mentioned > them. They are obvious in hindsight, of course. > > * If the channel assignment includes a difference channel, then the > subframe for that channel has one extra bit per sample in order to > encode the difference. > > * The number of bits per sample for a subframe, is the number of bits > per sample of the frame, minus the number of wasted bits per sample of > the subframe (and possibly plus one for a difference channel). > > I hope this helps future implementers. I would love to see a patch against the documentation for this. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] warning that legacy WAVE file has format type 1 but bits-per-sample is 24
Brian Willoughby wrote: > Are there some (old) programs that will not accept WAVEX headers? I'm > trying to think of why the flac utility worked this way in the first place. Yes probably. But that was probably 10 years ago or more. > In any event, it seems like it would be prudent to add a command line > option to preserve the existing behavior, just in case anyone has archived > their audio using FLAC and would need to maintain compatibility with the > legacy WAVE format. Its trvially easy to losslessly convert between legacy and WAVEX formats. Like I said, sndfile-convert does it. > It's not always possible to replace certain old programs, > especially in recording studios. A program that suppoprts 24 bit WAV and does support WAVEX would have had to be really old even 10 years ago. I don't think its worth adding this command line flag unless someone actually runs into the problem. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] warning that legacy WAVE file has format type 1 but bits-per-sample is 24
Erik de Castro Lopo wrote: > > Notice the warning was given only for the WAVE file produced by the > > flac reference executable. > > I agree. The flac decoder should not generate WAV files which it > warns about when encoding. Fixed in Git. Thanks, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] warning that legacy WAVE file has format type 1 but bits-per-sample is 24
Mark H. David wrote: > Notice the warning was given only for the WAVE file produced by the > flac reference executable. I agree. The flac decoder should not generate WAV files which it warns about when encoding. > Should I file a bug for this? No need. This is sufficient. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] libFLAC with Android NDK: use of undeclared identifier 'SIZE_MAX'
Steve wrote: > Please let me know if theres any other process involved in getting this > patch upstreamed. A slightly modified version of your patch is in git HEAD: https://git.xiph.org/flac.git Please test and report back. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Windows Universal Platform?
Hi all, Anyone know anything about Windows Universal Platform? Someone raised an issue on github: https://github.com/xiph/flac/issues/32 The `flac_max`/`flac_min` issue is resolved, but the WUP one is not. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC decoding
m201672...@hust.edu.cn wrote: > I want to know more about FLAC decoding, rice coding and LPC, more details or > examples. These can all be found on Wikipedia: https://en.wikipedia.org/wiki/Golomb_coding https://en.wikipedia.org/wiki/Linear_predictive_coding > I view https://xiph.org/flac/format.html. But only know some theory which is > very abstract. Sorry, but it is what it is. > what is the table for FLAC decoding? Table? You mean like the lookup tables for u-law and A-law? FLAC doesn't work that way. For FLAC there is no table. Its a lot more complex than that. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] error message for flac --sign
Michael W. Bombardieri wrote: > The --sign option in flac can be signed or unsigned, > but the error message mentions "uint32_t". Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] some typos in header files.
lvqcl wrote: > The attached patch fixes a few typos. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Flac build issue in debug win x32
Olivier Tristan wrote: > Here is a patch that fixes the issue. > > There are multiple way to fix it though. Applied. Thanks. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 6/5] comments in stream_decoder.c
lvqcl wrote: > There are 2 comments in stream_decoder.c that mention > FLAC__lpc_restore_signal_asm_ia32_mmx() requirement for > the output array. > The text is updated to include intrinsic functions too. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code
lvqcl wrote: > > The patch is attached. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 5/5] SIMD: remove outdated SSE2 code
lvqcl wrote: > > Ok, will do it, but currently xiph git still contains old code. Sorry, should be updated now. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 4/5] SIMD: accelerate decoding of 16-bit FLAC
lvqcl wrote: > This patch adds 2 new functions, > FLAC__lpc_restore_signal_intrin_sse41() and > FLAC__lpc_restore_signal_16_intrin_sse41(). > > The decoding speed of Subset-compatible 16-bit FLAC files > is slightly increased on SSE4.1-compatible CPUs. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 3/5] SIMD: accelerate decoding of some 24-bit FLAC
lvqcl wrote: > This patch accelerates decoding of non-Subset 24-bit FLAC files > (where lpc_order > 12). > > (The improved function is FLAC__lpc_restore_signal_wide_intrin_sse41(). > It requires SSE4.1 and it's used only by 32-bit libFLAC) Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 1/5] SIMD: add const qualifier
lvqcl wrote: > This patch adds const to some variables, to make code slightly easier to > read. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] about "cpu.h: Fix compiler detection" patch
lvqcl wrote: > So I thought that the directive > > #if defined __clang__ && __has_attribute(__target__) > > is ok for GCC because "defined __clang__" is false and > preprocessor shouldn't try to parse "__has_attribute(...)" part. It seems this is actually a pre-processor parsing bug. It hits the bug *before* the logic is evaluated. My current solution in the above PR is to avoid `__has_attribute` and use this: #elif defined __clang__ && (__clang_major__ > 3 || \ (__clang_major__ == 3 && __clang_minor__ >= 6)) /* clang */ which I have tested with clang 3.6. If someone has an earlier version of clang and can verify that it work, I'll drop the version number. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] about "cpu.h: Fix compiler detection" patch
lvqcl wrote: > After this patch, all FLAC__SSEN_SUPPORTED variables are > undefined for GCC, so intrinsic versions of functions are > not compiled into libFLAC. Sigh! The C preprocessor is by far the very worst feature of the C langauge. Its hard to read, hard to debug, hard to verify and just incredibly fragile. > Now, it's basically: I think its fixed in: https://github.com/xiph/flac/pull/30 > By the way, what's the problem with GCC 4.6? The travis build log is at: https://travis-ci.org/xiph/flac/jobs/201678000 > According to <https://gcc.gnu.org/onlinedocs/cpp/If.html>: > "... and logical operations (&& and ||). The latter two obey the usual > short-circuiting rules of standard C." > > So I thought that the directive > > #if defined __clang__ && __has_attribute(__target__) > > is ok for GCC because "defined __clang__" is false and > preprocessor shouldn't try to parse "__has_attribute(...)" part. I agree. I would call that error a compiler bug. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] cpu.h: add defines for clang
lvqcl wrote: > I forgot that all avx2 functions are inside "#ifdef FLAC__AVX2_SUPPORTED" > conditional, so they simply don't exist if FLAC__AVX2_SUPPORTED is not set. > > Anyway, stream_encoder_intrin_avx2-after.txt shows that the code > contains AVX2 instructions such as vpabsd/vpaddd/vphaddd, so > this function was compiled properly. Thanks. Patch applied. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] cpu.h: add defines for clang
Erik de Castro Lopo wrote: > What am I looking for? Is posting the before and after versions > sufficient? Disassembly of the object files (before and after) is here: http://mega-nerd.com/tmp/stream_encoder_intrin_avx2-before.txt http://mega-nerd.com/tmp/stream_encoder_intrin_avx2-after.txt This is with clang version 3.8.1 from Debian testing. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] cpu.h: add defines for clang
lvqcl wrote: > Currently cpu.h lacks FLAC__SSE_TARGET and FLAC__SSEnn_SUPPORTED > macros for clang. I added them, but I cannot properly test them > as I can't get compiled flac.exe under Windows (don't know > how to setup clang under MSYS2). I can relatively easily install Clang on Linux. > If somebody has working clang, please test this patch. > Does it affect en/decoding speed? How reliable a test is that? I do 99.9% of my dev work on a laptop and whenever I need to benchmark something I need to do so on a desketop machine because the laptop doesn't give consistent results. > Or at least, dows it affect disassembly of functions > such as FLAC__precompute_partition_info_sums_intrin_avx2()? What am I looking for? Is posting the before and after versions sufficient? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix compile with cygwin
Rosen Penev wrote: > The underscores are wrong. The comment is also correct. > > Also remove the configure.ac option. Otherwise it tries to compile the > windows unicode stuff which POSIX(cygwin) does not understand. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Re-release of version 1.3.2?
Patrick McCarty wrote: > Since this appears to have been a re-release of version 1.3.2, was this > an intentional re-release? Yes it was. The bad tarball was on on the main upload site for a couple of hours but problems with the mirroring meant that the bad tarball lingered on some of the mirrors for much longer. The reason the bad tarball was bad the bad date in one of the test files.shown in the diff below. Erik diff -Nru flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta --- flac-1.3.2-v1/test/metaflac-test-files/case07-expect.meta 2016-12-31 16:52:09.366371726 -0800 +++ flac-1.3.2-v2/test/metaflac-test-files/case07-expect.meta 2016-12-31 19:54:28.827304796 -0800 @@ -1,4 +1,4 @@ -reference libFLAC 1.3.1 20141125 +reference libFLAC 1.3.2 20170101 ARTIST=The_artist_formerly_known_as_the_artist... ARTIST=Chuck_Woolery ARTIST=Vern -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Clean up CFLAGS detecting code and add AX macro for _FORTIFY_SOURCE
David Seifert wrote: > --- Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Clean up CFLAGS detecting code and add AX macro for _FORTIFY_SOURCE
David Seifert wrote: > - AC_PROG_SED > - CFLAGS=$(echo "$CFLAGS" | $SED 's/-O2//') > - CFLAGS="-O3 -funroll-loops $CFLAGS" > + CFLAGS="-O3 -funroll-loops" Doesn't this mean that `-O2` and `-O3` will end up in CFLAGS? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 1/2] for lpc_intrin_sseNN.c
lvqcl wrote: > This patch fixes bracket placement, extra space, etc > in lpc_intrin_sse2.c and lpc_intrin_sse41.c Both patches applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Flac multi channel
Olivier Tristan wrote: > This could make sense indeed. > I suppose this is not a libFlac feature and that I should end up using > libogg and or adding myself basic ogg support > in order to support that ? libFLAC supports writing a single FLAC stream to an OGG container. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] metaflac crashes adding cuesheet
James wrote: > The command used by abcde is > > metaflac --no-utf8-convert >--import-cuesheet-from=/home/me/Audio/abcde.50107806/cue-50107806.txt >--import-tags-from=- /home/me/Audio/abcde.50107806/track1.flac Unfortunately, that is still insuffuicent for me to debug this. The command line you provided is importing tags from stdin and you haven't provided the data that is being fed into metaflac's stdin. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] for compat.h
lvqcl wrote: > Description: redefine inline as __inline only for C, not for C++. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
Dave Yeo wrote: > GCC supports __declspec(dllexport) though it still needs a def file, > with no exports. Libtool doesn't currently and as flac uses libtool... So you're happy with this patch? http://lists.xiph.org/pipermail/flac-dev/2017-January/006170.html Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] os/2 support using Watcom
Ozkan Sezer wrote: > Anyways, with the changed exports.h patch, every need should > be met now.. Sorry, which patch is that? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] metaflac crashes adding cuesheet
James wrote: > (Apologies if I'm in the wrong place for this...) > > I'm trying to use the abcde program to archive CDs to flac files. > (Each CD to 1 file, and ultimately multi-disk performances to 1 > file.) It extracts the audio to a .flac file and creates a cue > sheet with track names & locations. However, when it tries to > run metaflac with the --import-cuesheet-from option, it core > dumps. > > I'm using the latest version (1.3.2), which I downloaded & compiled > myself. I've tried to run gdb on the core file, but just get a message > about using zypper to download separate debug info, but when I > try to run the specified command, it says the info doesn't exits. > I'm running OpenSUSE 42.2. > > I have compiled everything with the --enable-debug flag, but I > can't figure out where to run metaflac from to pick up the source. > > Any help would be appreciated. If there isn't something obvious > that I'm doing wrong, I can dig into debugging the code, but it'd > be nice to have some idea of where to start. Please provide the command that causes this. It would also be useful if you could make the cue sheet available. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 1/2] Do not override CFLAGS, as CFLAGS is a user flag.
David Seifert wrote: > * Furthermore, use NDEBUG globally to detect the presence > of building with more debug output information. > AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays > Gnome has also switched to it from its own custom solution. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix cppcheck warnings
Rosen Penev wrote: > src/libFLAC/bitreader.c | 4 ++-- > src/libFLAC/bitwriter.c | 4 ++-- > src/plugin_xmms/plugin.c| 2 +- > src/share/utf8/charset.c| 1 + > src/test_libFLAC++/encoders.cpp | 8 > src/test_libFLAC/decoders.c | 4 ++-- > src/test_libFLAC/encoders.c | 8 > 7 files changed, 16 insertions(+), 15 deletions(-) Applied. minus the incorrect fix to charset.c. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix cppcheck warnings
Rosen Penev wrote:
> index 432e32d..0c2d1ee 100644
> --- a/src/share/utf8/charset.c
> +++ b/src/share/utf8/charset.c
> @@ -522,6 +522,7 @@ int charset_convert(const char *fromcode, const char
> *tocode,
>if (to) {
> newbuf = realloc(tobuf, p - tobuf);
> *to = newbuf ? newbuf : tobuf;
> +free(newbuf);
That bit is not actually correct. I've corrected that idependently.
Erik
--
----------
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix cppcheck warnings
Rosen Penev wrote: > fedora comes with 1.75 so I used that. I also used some additional > flags: cppcheck --enable=all --inconclusive --std=posix --force Thanks! I had wanted to use verison 1.76.1 from Debian in CI, but never enabled it because it was giving me a false positive even with relatively standard command line options. I've now refactored the code so that there is no false positive and I'm playing around with `--enable=warning` which enables the unsigned/print warning you patch fixes and a couple of other interesting things. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] Fix cppcheck warnings
Rosen Penev wrote: > src/libFLAC/bitreader.c | 4 ++-- > src/libFLAC/bitwriter.c | 4 ++-- > src/plugin_xmms/plugin.c| 2 +- > src/share/utf8/charset.c| 1 + > src/test_libFLAC++/encoders.cpp | 8 > src/test_libFLAC/decoders.c | 4 ++-- > src/test_libFLAC/encoders.c | 8 > 7 files changed, 16 insertions(+), 15 deletions(-) Interesting! What version of cppcheck are you running? With what options? I currently run cppcheck over FLAC in CI. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] fix MSVC 2005/2008 build
lvqcl wrote: > Thanks. But I can't see new file share/msvc2005_int.h in > the current git snapshot. Yeah, fixed in a later commit. This is why I prefer git patches over plain diffs :). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] fix MSVC 2005/2008 build
lvqcl wrote: > > These versions of Visual Studio don't have stdint.h and > > all [u]intNN_t types. But now these types are everywhere > > in FLAC codebase. > > Here is the patch that fixes the problem: > it moves definitions of all [u]intNN_t types from share/compat.h > into new file share/msvc2005_int.h and then includes this file > into all files (via "Force Includes" option in *.vcproj files). > > The definitions of these types are inside #if block with > _MSC_VER < 1600 condition, so these changes affect only MS Visual > Studio compilers with _MSC_VER < 1600 (i.e. MSVS 2005 and 2008). Thats a really great solution to this problem. Applied! Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 2/2] Only compile and run tests when running 'make check'
David Seifert wrote: > --- Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] fix getopt.c
lvqcl wrote: > This patch fixes 2 problems in getopt.c: > > 1) MSVC 2005 (and probably 2008) can't compile it because > it doesn't have stdint.h > > 2) nameend and nextchar are pointers and the difference > between them should be casted to 'size_t' type, not > 'unsigned int' or 'uint32_t'. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] How is the MD5 hash calculated?
Marcus Johnson wrote: > is it on a per subframe basis, and if so, is each frame padded if > it’s not a multiple of 512 bits? or do I have to decode all the data, > and run it over the decoded file at once? Documentation is here: https://xiph.org/flac/documentation_format_overview.html MD5SUM is of the un-encoded audio data and of the whole stream. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
lvqcl wrote: > Ok, Visual Studio doesn't complain if idx is declared as uint32_t. As expected :). Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
lvqcl wrote: > > Ah, missed that because it was MSVC code. They should be `uint64_t`. > > No, sizeof(unsigned long) is always 4 on Windows. > See http://www.viva64.com/en/t/0012/ Bah! Trust Windows to be different :). > >> According to MSDN _BitScanReverse*() functions have signatures: > >> unsigned char _BitScanReverse(unsigned long *, unsigned long); > >> unsigned char _BitScanReverse64(unsigned long *, unsigned __int64); > > > > The `unsigned long` type should be synonymous with `uint64_t` so using > > `uint64_t` should be safe. Furthermore if they aren't synonymous we > > *want* that to be a compile error! > > It's synonymous to uint32_t, but if the 1st parameter for > _BitScanReverse*() > functions has 'pointer to unsigned long' type then IMHO it's better to > simply use unsigned long variable there. Sorry, I disagree on the idea of using `unsigned long` exactly because anyone that comes from Unix will assume that is `uint64_t`. Better to use `uint32_t` which is totally platform independant and unambiguous. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 1/4] Do not override CFLAGS, as CFLAGS is a user flag.
David Seifert wrote: > * Furthermore, use NDEBUG globally to detect the presence > of building with more debug output information. > AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays > Gnome has also switched to it from its own custom solution. This patch removes `-funroll-loops` which from memory provides a significant boost in encoding/decoding speed. What's the best way to fix all this stuff but still turning `-funroll-loops` be default? Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 0/5] Allow multiple targets to be disabled
lvqcl wrote: > I think that FLAC sources should remain compatible with Visual > Studio 2010 (and probably earlier), people still need it. > For example: <https://github.com/xiph/flac/issues/23> > > Is it possible to simply exclude win_utf8_io.c from compiling > if target OS is WinRT/non-desktop? And I defer to others like lvqcl for what we do and do not support on Windows. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] add missing string.h include to cpu.c (for memset())
Ozkan Sezer wrote: > On 1/13/17, Ozkan Sezer <seze...@gmail.com> wrote: > > Attached patch adds missing string.h include to cpu.c (for memset()) > > Simpler patch attached, which just replaces memory.h with string.h > cpu.c was the only source to use memory.h instead of string.h. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 3/4] Honor user's $(htmldir) and do not override GNU defaults for $(docdir)
David Seifert wrote: > * HTML files should be installed to $(htmldir), and $(docdir) should > not be changed, as this is a user flag in the GNU conventions. Applied, but this one required a few extra tweaks to keep "make distcheck" working. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 4/4] When using libtool, use LTLIBICONV instead.
David Seifert wrote: > * This is required, as otherwise -Wl,--as-needed could fail. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH 2/4] Make building/installing examples optional
David Seifert wrote: > --- > Makefile.am | 6 +- > configure.ac | 5 + > 2 files changed, 10 insertions(+), 1 deletion(-) Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Upstreaming Gentoo patches
David Seifert wrote: > I would like to get some of our patches merged into master. Most > of them deal with adhering to GNU conventions, respectively not > overriding flags/variables that are up to the user to set. For instance, > honoring $(htmldir) is important, as we have installation paths for the > documentation that differ from what is currently coded in the various > Makefile.am's. Thanks for these David. I'll have a look. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
Ozkan Sezer wrote: > Well, the commit seems like overkill :) not all the unsigned needed > converting. Not all of them *needed( converting, but afaiac this makes the code base better. I never liked the way the original C standard allowed the use of `unsigned` alone as type. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
lvqcl wrote: > Also MSVC fails because src/libFLAC/include/private/bitmath.h now > contains "uint32_t long idx" instead of "unsigned long idx". Ah, missed that because it was MSVC code. They should be `uint64_t`. > According to MSDN _BitScanReverse*() functions have signatures: > unsigned char _BitScanReverse(unsigned long *, unsigned long); > unsigned char _BitScanReverse64(unsigned long *, unsigned __int64); The `unsigned long` type should be synonymous with `uint64_t` so using `uint64_t` should be safe. Furthermore if they aren't synonymous we *want* that to be a compile error! > Other than that, it compiles everything without errors. Thanks! Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] workaround for DJGPP missing wcswidth()
Ozkan Sezer wrote: > Attached patch works around for DJGPP missing wcswidth() > in flac/utils.c:strlen_console() Applied, thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
Ozkan Sezer wrote: > > Ozkan Sezer wrote: > > > >> unsigned int and FLAC__uint32 are used interchangeably, leading to > >> warnings with platforms (e.g. djgpp) where int32_t is long: > > > > Is `sizeof int == 4` though? > > Yes, obviously it is Well I've just pushed a patch that purges the code base of `unsigned`. Please test and let us know how it goes. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] unsigned int and FLAC__uint32 are used interchangeably
Ozkan Sezer wrote: > unsigned int and FLAC__uint32 are used interchangeably, leading to > warnings with platforms (e.g. djgpp) where int32_t is long: Is `sizeof int == 4` though? I couldn't image FLAC working correctly if it wasn't. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] configure.ac: relax linux OS detection
Peter Korsgaard wrote: > Not all linux hosts match the *-pc-linux-gnu wildcard, causing build > failures for older glibc versions where we need to link with -lrt for > clock_gettime - E.G.: Applied. Thanks. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2: FLAC__CPUINFO_IA32_CPUID_SSE3 undeclared
Christian Weisgerber wrote: > FWIW, here's a minimal fix to deal with this. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] fix compile in MSVC if UNICODE is defined (SF bug 447)
lvqcl.mail wrote: > Erik de Castro Lopo wrote: > > > This fix probably warrants a new release, but I'll hold off for a > > week or so to make sure nothing else needs fixing. > > Speaking of which... the attched patch fixes building when UNICODE > preprocessor macro is defined (it's explained here: > <http://stackoverflow.com/questions/3298569/difference-between-mbcs-and-utf-8-on-windows>). > > It should fix this - <https://sourceforge.net/p/flac/bugs/447/> > Not a big problem though. I'm not even sure that it's a bug. Applied. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
Dave Yeo wrote: > The Oregon State U, Open Source Lab mirror is still missing 1.3.2 downloads.xiph.org (actually ftp.osuosl.org) is more than one machine. Some of them have been updated, others haven't. Will chase it. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
Ozkan Sezer wrote: > Also, the xiph downloads page https://xiph.org/downloads/ still lists > 1.3.1 for flac download. Thats a different issue that I'm still chasing. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
Declan Kelly wrote: > > The official website doesn't link to the SourceForge project, which > seems to be the only place that's hosting the 1.3.2 files. There was an issue with the osul.org mirrors but it should be fixed now. Please let me know if any download.xiph.org/flac/ site is missing the 1.3.2 files. Erik -- ------ Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
Janne Hyvärinen wrote: > Attached is a patch to fix the incorrect CPU feature detection: Patched applied, but the CPU detection code remains, horrible to read, difficult to reason about, work on and maintain. This fix probably warrants a new release, but I'll hold off for a week or so to make sure nothing else needs fixing. Thanks, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.3.2 has been released
Janne Hyvärinen wrote: > That shouldn't matter. I realise that, but I wanted a better idea about how many people this is like to affect. If you were on Windows XP on some old processor this would probably not affect many people, but since you are on Windows 10 with a Core i7 thats a different matter. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] FLAC 1.3.2 has been released
Hi all, The latest version of FLAC has been releases. See: https://xiph.org/flac/index.html https://xiph.org/flac/changelog.html The source tarball and Windows binaries are available (with md5 and sha256 checksums) at: http://downloads.xiph.org/releases/flac/ The source tarball is also available at: https://sourceforge.net/projects/flac/files/flac-src/ and similarly the Windows binaries at: https://sourceforge.net/projects/flac/files/flac-win/ Please feel free to spread the word and please reply to this email to let us know where this is being announced. I have announced it here and on my personal G+ account. Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Facebook page for FLAC
Declan Kelly wrote: > This might be overkill, but we could also set up a Facebook Event for > the next release. It would be of absolutely no benefit to FLAC, but it > might help to spread the word a bit further. > > We would need to have some advance notice. > > The post on HydrogenAudio has pre1 in the subject line; there isn't any > need to 'bump' that to pre3, but a separate thread for the actual > release would stand out better for regular forum users and for Web > searches. > > If any Bandcamp developers are on this list, can we get a blog post or > other announcement (through the many channels that Bandcamp has built up > over the years to artists and fans)? I'm hoping to do this release today so maybe the Facebook Event will not work out. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2pre3 (Hopefully final)
c.helmr...@ecodis.de wrote: > In libFLAC/src/stream_encoder.c, the following C++ style comment was added > recently: > > //FLAC__ASSERT(samples <= blocksize); > > Since all other comments in this file (and, possibly, the entire lib) are > C-style /* */, > I suggest to remove this line again. Fixed. Thanks. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2pre3 (Hopefully final)
lvqcl.mail wrote: > I compiled sources from flac-1.3.2pre3.tar.xz (MinGW/Windows) > and ran 'make check'. The result is: "All tests passed". > > Then I replaced flac.exe and metaflac.exe with the files from > flac-1.3.2pre3-win.zip and re-ran the tests. Again the result > is: "All tests passed". Awesome. Thats the best test I can think of for the Windows binaries. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2pre3 (Hopefully final)
Orestes Zoupanos wrote: > For what it's worth, I tested both the 32- and 64-bit flac.exe's on my > Windows 10, with about 45 WAV files I have. > > Got some warnings about unexpected metadata, but the audio was encoded > fine. Using the --keep-foreign-metadata flag cleared those warnings. > > I even had a weird WAV that caused "WARNING: legacy WAVE file has format > type 1 but bits-per-sample=24", but flac dealt with it without problems > and the output file was fine and playable. Thanks! All of what you saw is expected behaviour. Cheers, Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] 1.3.2pre3 (Hopefully final)
Hi all, New pre-release here is at: http://mega-nerd.com/tmp/flac-1.3.2pre3-win.zip http://mega-nerd.com/tmp/flac-1.3.2pre3.tar.xz Changes: * Fix tests with Makefile.lite build system. * Fixes for non-Intel CPUs. MD5 and SHA256 sums: > md5sum flac-1.3.2pre3* 61aa8597a220303daf4beb2b8756979d flac-1.3.2pre3.tar.xz 8b470ceac02340600db73bc6daea4fc7 flac-1.3.2pre3-win.zip > sha256sum flac-1.3.2pre3* 9f3e333db6bf9aea8fa211a0d598ec28e2e24c47830ba2f585dc5647b756e4c8 flac-1.3.2pre3.tar.xz f0af11afb7f2187317677fd719cad1493d3bd52d0498a4facc8a937ce366ba88 flac-1.3.2pre3-win.zip Really need someone to test the Windows binaries because I don't have Windows. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2pre2
Robert Kausch wrote: > Unfortunately, the Makefile.lite files in win_utf8_io and flactimer are > still missing. The attached patch adds them and also changes config.mk > to not use -fPIC on Windows (to avoid compiler warnings, because all > code is position independent on Windows). Patch applied. Thanks. > make test fails because common.sh is missing (it's generated from > common.sh.in during configure). The only variable being replaced in that > step is @EXEEXT@, so one possible solution would be to detect a Windows > OS using something like '|if["$(expr substr $(uname -s) 1 > 10)"=="MINGW32_NT"];|' and set EXE=.exe in that case instead of > generating the file from common.sh.in. Currently working on this. Its a little tricky. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] 1.3.2pre2
Hi all, New pre-release here is at: http://mega-nerd.com/tmp/flac-1.3.2pre2-win.zip http://mega-nerd.com/tmp/flac-1.3.2pre2.tar.xz Changes: * Fix PACKAGE_VERSION in MSVS project files. * Fix Makefile.lite in tarball (make test is still failiing). MD5 and SHA256 sums: > md5sum flac-1.3.2pre2* e276e3a9e99ae07f4bd25278f533b9e5 flac-1.3.2pre2.tar.xz 2c8854dd361bfa654fa5aa4245ab1c54 flac-1.3.2pre2-win.zip > sha256sum flac-1.3.2pre2* fca283281227736a4371758b8c30c39c9e5e17c1bb36c7b742d2aa94fd6b4a4a flac-1.3.2pre2.tar.xz 91bdc4257995127b49ea9e4f455b6d217ea2ce50579854d2d10dfed75a0c1ce6 flac-1.3.2pre2-win.zip Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 1.3.2 News announcement
MauritsVB wrote: > “Over two years of development have culminated in a new release. FLAC > 1.3.2 improves encoding speed on older CPUs, provides a slightly better > compression and contains a lot of build improvements, small bug fixes > and code cleanups. See the changelog > [url=https://xiph.org/flac/changelog.html] > for more details.” Thanks, Sounds good. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Do we need a pre-release?
Robert Kausch wrote: > Yes, the missing Makefiles solve most of the issues. The patch can be > reduced to the attached version. Applied. Thanks. > I'm not sure about the other files you listed. I guess they should > either be added to the tarball or removed from git. I'll make sure the Makefile.lite build system works from the tarball. Erik -- ---------- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Do we need a pre-release?
lvqcl.mail wrote: > The patch is attached. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
