similar to: [PATCH] Fix dead links/anchor and update comparison

Erik de Castro Lopo wrote: > Martijn van Beurden wrote: >> the second fixes some dead links in the website pages > The first and the third patch were fine, but the second (Fix dead links > and update news) doesn't apply. Can you please try regenerating that > patch and resending? That was due to a conflict with my patch to update the download link. Here is a rebased

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

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

Once more big patches, this time updating the comparison and links pages. http://www.icer.nl/misc_stuff/0001-Add-more-brands-to-links-page.patch http://www.icer.nl/misc_stuff/0002-Update-comparison.patch

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'

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

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

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

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

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

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

Moving them will break links, and they should be kept for future reference. The installer works properly on Windows XP and earlier, it was broken because of the UAC introduced in Vista. Op 16-09-14 om 15:56 schreef Notes Jonny: > > Ping > > On 3 Sep 2014 10:29, "Notes Jonny" <jongmob at gmail.com > <mailto:jongmob at gmail.com>> wrote: > > Hi

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.

Hi all, When trying to better understand the way LPC exactly works, I stumbled upon something which, after some digging, was already reported and (partly) fixed: https://sourceforge.net/p/flac/bugs/424/ Apparently, the FLAC specification has a LPC shift that can be both positive and negative, but the encoder specifically makes sure that only positive shifts are encoded and the decoder only

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

Sorry, I am newbie. Sample codes are from https://github.com/oneman/libflac/tree/master/examples/cpp. I used FLAC__stream_decoder_process_single function but it still gives exception. Maybe I could not control read callback, you're right. I will check it and write result in this thread. Thanks for help. 2013/7/1 Martijn van Beurden <mvanb1 at gmail.com> > I'll top-post this

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

Sorry, for the late repsonse Martijn. I've been crazy busy. Martijn van Beurden wrote: > On 28-08-12 10:46, Erik de Castro Lopo wrote: > > I think thats a great idea. WOuld be happy to have someone pick > > this up and run with it. > > So I got busy but stumbled upon several things. I'm not sure why there > are two boxes displaying the same news on the homepage

Are you sure they didn't change the default encoding level ? I would include some example timings to give a better idea of what "significantly slower" is Wonder if you see same for 44/16 files? > On Jul 25, 2014, at 2:29 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Hi, > > You might want to report this to the flac-dev mailinglist instead of the