similar to: [PATCH] Fix rice partition order documentation

Hi all, Just as I said I would do in a previous mail to this mailing list (http://lists.xiph.org/pipermail/flac-dev/2013-January/003644.html), I've set up a sourceforge project with a remake of FLAC Frontend. After a few months of development (with loads of help from people at HydrogenAudio) I think it is fairly stable. As soon as FLAC 1.3.0 is released, I will release the first stable

Hi all, The past few weeks I've been busy comparing lossless audio codecs to update the comparison.html page on the FLAC website (and because I wrote a comparison for Hydrogenaudio in the past) and its ready now. Because the patch is pretty large, I've placed it here: http://www.icer.nl/misc_stuff/update-comparison-and-fix-IE-news.patch.zip The reason to do this is because the

Hi all, I was reading the discussion about this 1.3.0pre1 release on HydrogenAudio and someone linked an old thread in which one patched FLAC 1.2.1 to support WAV-files larger then 2GB. It might be worth investigating: http://www.hydrogenaudio.org/forums/?showtopic=84014#entry725304

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

Op 01-10-15 om 18:14 schreef lvqcl: > Currently libFLAC stores residual signal as 32-bit signed int. And there > are the following comments in stream_encoder.c: The residual is stored as a Golomb/Rice code. As far as I know, that is not limited to 32-bit in the format itself, only in the implementation. However, there are two residual coding methods now: rice and rice2. rice2 was added

For some reason all documentation lists the max rice partition order to be 16, while the maximum is 15. This fixes thee HTML online documentation --- documentation_tools_flac.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation_tools_flac.html b/documentation_tools_flac.html index bc1f2b8..5100cb4 100644 --- a/documentation_tools_flac.html +++

On 10.4.2013 10:39, Martijn van Beurden wrote: > On 08-04-13 22:00, Janne Hyv?rinen wrote: >> On 8.4.2013 21:38, Janne Hyv?rinen wrote: >>> Friendly people on Hydrogenaudio found some bugs with the Unicode >>> printing code, so I was forced to make adjustments. >>> [...] >> The long line patch is broken and requires much more work, please >> ignore

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.

For some reason all documentation lists the max rice partition order to be 16, while the maximum is 15. This fixes flac -H, the man page and the HTML source code documentation --- doc/html/documentation_tools_flac.html | 2 +- man/flac.1 | 8 ++++---- man/flac.sgml | 8 ++++---- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git

On 8.4.2013 21:38, Janne Hyv?rinen wrote: > Friendly people on Hydrogenaudio found some bugs with the Unicode > printing code, so I was forced to make adjustments. > > While doing testing I noticed that long filenames cause printing bugs > on Linux too. If line length on status printing exceeded console > length it kept printing the same line over and over. > The patch I

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

Hi, > If I understand this correctly, these new apodization functions only > affect compression and that files compressed with these new functions > will still decode correctly with older versions of the FLAC decoder. > > Is that right? Yes, that is correct. These functions are used to window the audiodata, but only for the predictor stage. What these new function enable,

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

On 28-05-13 19:38, Miroslav Lichvar wrote: > I'm always interested in performance tests :). In that case I hope you saw the previous one, because the decoding speed-up was credited to be one of your patches, according to some people over at HydrogenAudio: http://lists.xiph.org/pipermail/flac-dev/2013-March/003856.html Really, great stuff ;) > I think if you are setting CFLAGS you

Recently I was trying some new approaches to improve FLAC compression, when I stumbled on a possible overflow. The reason this has not come up earlier is because the encoder only hits this point when the estimate of the rice_parameter is very much off. To trigger this overflow, one has to force rice_parameter to 0 in for example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c. When

On 04-03-13 23:19, Erik de Castro Lopo wrote: > Link please? http://www.hydrogenaudio.org/forums/index.php?showtopic=99757 > Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig.

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

Going in details through the FLAC format specification, I realize that there are 2 rice coding methods now supported for residual encoding. I thought I remembered in the 1.1.3 times that there was only 1 method (with 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change log, I didn't find any reference to such an addition to the format. Now, the decoder implementation I'm

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 ma 6 jul. 2020 om 10:22 schreef Erik de Castro Lopo <mle+la at mega-nerd.com>: > > Martijn van Beurden wrote: > > > To trigger this overflow, one has to force rice_parameter to 0 > > Ok, that sounds dodgy. Yes, well, it is. It could very well be that without patching, nobody ever has a problem with this, but as the rice code is based on an estimate, it might,