similar to: libFLAC header checking

On 06.11.2008 22:16, LRN wrote: > In stream_decoder.c function find_metadata_() checks whether a file is > valid or not. There are 4 cases it recognizes: > 1) file begins with 'fLaC' > 2) file begins with ID3 (skipped), followed by 'fLaC' > 3) file may begin with 11111111 111110?? sync code (or 11111111111110, > depends on endianess i suppose). That is - a raw

Here's a patch to allow flac and metaflac handle files with malformed vorbiscomment metadata block. -------------- next part -------------- diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index d50df39..39cb276 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -78,7 +78,7 @@ static FLAC__Metadata_SimpleIteratorStatus

Hi, I have a problem when I try to open a file, which is not a FLAC file. When I open a non-flac file with the stream decoder API, one of the first things called is FLAC__stream_decoder_process_metadata, which itself calls stream_decoder_find_metadata_. Unfortunately the non-flac file contains some content, which leads to the state set to FLAC__STREAM_DECODER_READ_FRAME. However in

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

Here you are: soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ metaflac --list 02\ St?rtebecker.flac METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minimum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 14 bytes maximum framesize: 15637 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 5857656

Dear list, i'm doing a bit of analisys on flac's source code and i've run into something i can't quite grasp. flac version 1.2.1 flaclib C stream_encoder.c function "process_subframes_" line 2999 ++++++++++++++++++++++ if(do_mid_side) { FLAC__ASSERT(encoder->protected_->channels == 2); for(channel = 0; channel < 2; channel++) {

So, let's provide some information then :-) ---------------------------------------------------------------------------------------------- soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ flac -aF 02\ St?rtebecker.flac flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add

Hello, I manage to successfully write 8, 16 and 24 bit, all stereo, FLAC files. But when I try to write 32 bit FLACs my program crashes. *FLAC__stream_encoder_set_bits_per_sample *is called to match the desired bit depth (8, 16, 24, 32) It's the same code for all bit depths, i provide a fixed-size signed int buffer to the lib (size=16384), with values with appropriate ranges for each bit

Open src/flac/decode.c, find write_callback() function and add return FLAC__STREAM_DECODER_WRITE_STATUS_ABORT; to the beginning of the function. Decoding will fail with the following message: test.flac: ERROR while decoding data state = FLAC__STREAM_DECODER_READ_FRAME As you can see, decoder state isn't quite correct. One of the ways to fix this is in the attached

Hello! I'm using the seekable stream decoder API of libFLAC 1.02 and I think that I found a possible bug in process_metadata(). The problem is as follows: I have a file which isn't a FLAC sample (it's actually an ACE archive) where process_metadata() returns TRUE. And even worse, the metadataCallback() is never called (which means process_metadata() succeeds, although no metadata is

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

Patch v2, now handles more malformed cases. Original patch was for a file for which I had a sample from a user but this allows handling some manually broken test cases. On 25.9.2014 21:53, Janne Hyv?rinen wrote: > Here's a patch to allow flac and metaflac handle files with malformed > vorbiscomment metadata block. > > > _______________________________________________ >

https://bugs.freedesktop.org/show_bug.cgi?id=111110 Bug ID: 111110 Summary: Nvidia quadro + nouveau : second terminal wake up but doesn't more display Product: Mesa Version: 19.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked