similar to: Preprocessor error when trying to build integer-only

This patch adds support for other compilers and systems including MSVC, Intel C compiler etc.. --- src/libFLAC/bitmath.c | 48 ------------- src/libFLAC/bitreader.c | 54 ++------------- src/libFLAC/include/private/bitmath.h | 120 ++++++++++++++++++++++++++++++--- 3 files changed, 116 insertions(+), 106 deletions(-) diff --git a/src/libFLAC/bitmath.c

rutine -> routine Also MSVC complains that FLAC__uint32* (unsigned int*) is not of the same type as unsigned long* --- a\src\libFLAC\include\private\bitmath.h 2013-08-13 13:30:24.000000000 +0400 +++ b\src\libFLAC\include\private\bitmath.h 2013-08-14 10:20:51.484053700 +0400 @@ -78,12 +78,12 @@ return _bit_scan_reverse(v) ^ 31U; #elif defined(__GNUC__) && (__GNUC__ >= 4 ||

Hi all, I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if this is the right place to submit patches, but someone suggested this on the apparently dead SourceForge patch tracker. The first two are quite straight forward: - The ICL patch fixes a typo in bitmath.h and adds FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c. - The Ogg patch replaces

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 42ce639..e5c7695 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -74,7 +74,7 @@ static inline unsigned int FLAC__clz_uint32(FLAC__uint32 v) { /* Never

Hi, Martijn, Thank you for reaching out, and apologies for late reply It is a dedicated metadata for volume normalization on our player. Please kindly refer to our company information here: https://labelgate.com/ application ID: SONN application name: Sony Normalizer contact e-mail address: taku.kurosawa at labelgate.com<mailto:taku.kurosawa at labelgate.com> Taku From: flac-dev

Hello, While building from git, I'm getting the following failure (help please): CC ogg_mapping.lo CCLD libFLAC.la Creating library file: .libs/libFLAC.dll.a .libs/bitreader.o: In function `FLAC__clz_soft_uint32': ./include/private/bitmath.h:46: multiple definition of `_FLAC__clz_soft_uint32' .libs/bitmath.o:./include/private/bitmath.h:46: first defined here .libs/fixed.o:

Hi Martjn, and everyone, Apologies if I have missed the reply, but I think I have not got any comment so far on this. That means our new ID request is accepted? What should I do next to proceed?? Apparently this is my first time here, so appreciate any advice assistance. Best regards, Taku From: Kurosawa, Taku Sent: Thursday, November 22, 2018 8:41 PM To: 'Martijn van Beurden'

On 26-05-13 14:20, Martijn van Beurden wrote: > On 26-05-13 11:33, Erik de Castro Lopo wrote: >> Hi all, >> >> In my latest commit I have updated all version strings and copyright >> dates. > > Here are two patches for the website, updating the copyright as well > and copying the changelog. I would like to propose copying the > contents of flac-website.git

Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header

Hi all, Sorry for completely forgetting to inform the mailing list about this. It has been too quiet here lately. Anyway, RFC 9639 has been published, specifying the Free Lossless Audio Codec (FLAC) format. See https://www.rfc-editor.org/info/rfc9639 https://xiph.org/flac/2024/12/19/rfc-9639-published.html Although FLAC has had a specification document since 2000 and an open-source reference

--- src/libFLAC/include/private/bitmath.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/libFLAC/include/private/bitmath.h b/src/libFLAC/include/private/bitmath.h index 61b0e03..d32b1a7 100644 --- a/src/libFLAC/include/private/bitmath.h +++ b/src/libFLAC/include/private/bitmath.h @@ -42,7 +42,7 @@ #endif /* Will never be emitted for MSVC, GCC, Intel compilers */

Thanks for the help Martijn, I get the same FLAC__STREAM_DECODER_END_OF_STREAM error after doing the 2 steps you suggested. Scott On Mon, May 19, 2014 at 9:36 AM, Martijn van Beurden <mvanb1 at gmail.com>wrote: > Once more hi, > > I've tried to reproduce this issue, but I am unable to do so. Could you > try to re-encode the file with FLAC (to make sure it is not an

Martijn van Beurden wrote: > op 27-06-14 14:11, Erik de Castro Lopo schreef: > > There has been at least one person on this list who is able to do > > perfromance tests on FLAC. I would appreciate it if someone could > > run such a performance test before and after the above commit. > > Are you specifically referring to the ARM platform or to any > platform? The

To whom it may concern, Hi, I would like to register a new ID hrere, application ID: SONN application name: Sony Normalizer contact e-mail address: taku.kurosawa at labelgate.com<mailto:taku.kurosawa at labelgate.com> please advise what the next step would be. Best regards, Taku Kurosawa -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

Martijn van Beurden wrote: > On 12-12-12 19:47, Max Horn wrote: > I already submitted a patch (see the mailinglist for the 14th of > september) to update the news section (and to make it easier to update) > but no one has replied to that yet... Sorry, I can't find that patch. Can you resend it please? Erik --

Yes, this is such a case. However, implementing this in a future encoder/decoder would break compatibility with most (likely all) existing decoders, and only in some very, very rare cases where the material is such that the encoder chooses to use negative shifts, which makes it even harder to troubleshoot. Furthermore, as this can only be used in very rare cases, there is no benefit from allowing

Hi all, Last year the POWER8 and POWER9 specific improvements (for PowerPC) were completely rewritten, but as of yet no accurate performance tests of these have been performed. I have validated functionality and rough performance checks for these through Travis CI, but the numbers I get through that vary wildly. Recently the C code that these improvements mirror has been changed to allow

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

Hi all, Currently I'm looking for users of the --keep-foreign-metadata feature of FLAC. There has been some improvement of this feature in FLAC 1.4.0. Since 2007 there has been a warning in FLAC that --keep-foreign-metadata is a new feature. I think removal of this warning is long overdue, but there are still some issues surrounding it. So, if there are users of this feature on the mailing