similar to: FLAC specification clarification

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

I am also philosophically opposed to changing the specification. That said, there's nothing wrong with adding a note to the specification about the common implementations, particularly the reference library. Then, future developers will know both the precise specification and still have the warning that they risk incompatibility by deviating from the reference implementation. I own devices

Is this a case where something allowed by the specification isn't implemented by the reference encoder/decoder (such as 25-32 bits per sample) but could be in a different implementation? If so, I am not sure whether it makes sense to change the specification based on the reference implementation. Stephen On Wed, Jun 17, 2020 at 3:22 PM Martijn van Beurden <mvanb1 at gmail.com> wrote:

To me the real question is not whether that portion of the spec has been implemented by any existing encoders/decoders but whether the spec is broken (i.e. cannot be implemented as written). I don't know the rationale for making the LPC shift explicitly signed. In C a negative shift is undefined and it does seem in FLAC__lpc_restore_signal() for example that the LPC shift is used as the

Refs http://sourceforge.net/p/flac/bugs/424/ --- doc/html/format.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/html/format.html b/doc/html/format.html index 8598941..2ce82c2 100644 --- a/doc/html/format.html +++ b/doc/html/format.html @@ -1578,7 +1578,7 @@ &lt;5&gt; </td> <td> - Quantized linear predictor coefficient shift needed

>From the FLAC format description: <5> Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement). What happens when the shift is negative? Problem is that libFLAC decoder (and possibly all other decoders) uses always '>>' operator and this operator shifts only to right. (int)x >> -1 is the same as (int)x

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

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

Tristan Matthews wrote: > Refs http://sourceforge.net/p/flac/bugs/424/ > - Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement). > + Quantized linear predictor coefficient shift needed in bits (NOTE: this number is signed two's-complement and must be non-negative). Maybe it's better to explain why? At least

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

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

ERROR while decoding data state = FLAC__STREAM_DECODER_END_OF_STREAM It's happening with every file that I've tried now, using both 1.2.1 and 1.3.0. If a file has artwork and I remove padding, I get the above error when verifying or decompressing. If no artwork and I remove padding, the file verifies and decompresses with no issues. I'm writing tags via

Op 07-02-12 19:50, Ralph Giles schreef: > Basically the audio is chopped into a blocks and each block is coded > either uncompressed, as a constant value (good for silence), or with > linear predictive coding plus a rice-coded residual. I don't know how > the encoder decides where to put the block boundaries. AFAIK, FLAC uses a fixed block length so block boundaries are just put

Hi Martijn Thank you for the link. Could those old installers be taken down or at least moved to a 'old' folder ? I'm new to this, so I am a good example of how a new user works. I use google, or I visit the homepage, and then I download and install. As that installer version doesn't work at all, it cant convert WAV files, I suggest to delete it completely. Regards, Jonny On

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

I can confirm git head builds and passes /make fullcheck/ (skipping the noise part of test_streams.sh) on - armv6-linux (Raspbian), GCC 4.6 & GCC 4.8 - i686-pc-mingw32, GCC 4.8.1 - MSVC 2005 Express 32-bit (make fullcheck with MinGW) - MSVC 2013 Express 32-bit (make fullcheck with MinGW) Furthermore, I've also ran the test_streams.sh of FLAC 1.2.1 with FLAC 1.2.1 as encoder and git as

Op 03-12-14 om 16:48 schreef Olivier Tristan: > Looks like I've missed the talk about this regression introduced in 1.3.1.

Please cc: the results from dev list back here though I would run some tests on a diff platform but don't have access to my PC for a few weeks Would also be interesting to see what decoding stats you get > On Jul 25, 2014, at 7:38 AM, Scott Brown <scottcbrown at gmail.com> wrote: > > I will post to the dev list, sorry about that. > > To give an idea, though, at flac

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'

Op 02-02-16 om 16:54 schreef lvqcl: > BTW, 64-bit flac can benefit from 64-bit words in > bitreader/bitwriter routines. Currently it requires > --enable-64-bit-words switch in ./configure parameters. It > would be interesting to test its effect, especially on ARM. Okay, I might test that as well. I've checked performance with the brand new laptop my employer gave me, which is