similar to: hi

hi, i am undergraduate engineering student in communication engineering. I am doing my final year project on lossless speech and audio compression algorithms,i have chosen FLAC as one of the lossless audio codecs. I would like to ask for help about the block diagram of the FLAC codec,i try searching on the internet but couldn't find it. Any help will be appreciated. Yours Sincerely

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

I have in my working directory the trivial header changes necessary to allow FLAC library functions to be used in C++ programs. Is it OK to commit this? -- - mdz -------------- next part -------------- ? Makefile ? Makefile.in ? ordinals.h Index: file_decoder.h =================================================================== RCS file: /cvsroot/flac/flac/include/FLAC/file_decoder.h,v

I'm guessing here, but it seems that some encoders might only be able to process samples in 4-bit or 8-bit groups, maybe even 16-bit multiples, so this flag would allow the decoder to remove any padding that might have been necessary on the encoder side. For example, if someone were to encode 12-bit samples, but the encoder was forced to use 16-bit registers for calculations, then

Version 1.2.1 introduced new rice coding techniques that are used by the reference encoder for 24 bit files. An older version of the decoder will have trouble with frames that use this encoding... Maybe that's where the strange noises come from... Pyt. On 6 f?vr. 2011, at 06:01, Brian Willoughby <brianw at sounds.wa.com> wrote: > Thanks for bringing up this aspect, Nicholas. I

it's really not complicated I think: only api changes to write on any position in the file if that's not possible already with existing function. I'm not sure if decoding can have multi-core support: you need an api for writing pcm files in different parts then and this is maybe more difficult to check if it's valid pcm data since the decoder can only check for valid flac streams

On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug > report related to decoding of CRAM files. This issue occurs with > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that > the same file is used for this test (hopefully ruling out any issue with > the encoder). > > Details of the

Hi, I'm a FLAC beginner and I had a question. Suppose I encode my whole CD collection now in the FLAC format, using the FLAC encoder version 1.1.4 (the most recent one at this time). Will I still be able to decode all FLAC files to WAV files in the future using the latest FLAC decoder, when for example version 2.0 of FLAC (or a later version) is released or is it possible that at some point

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

Hi Harry, First of all, if you keep a copy of flac 1.1.4 then you will always be able to decode the files. Why not make a backup of flac 1.1.4? Second of all, flac is open-source, so somebody will always be able to compile flac 1.1.4 for any new platform. There are never any guarantees about the future. Some day, MP3 won't decode on a new computer, AIFF and WAV might be unheard of.

During my current dealings with the FLAC library I think I discovered a memory leak. After an encoder stream has finish()'ed, I believe you are supposed to use it again by calling init(). However, when verification is enabled, the init() routine will create a new stream decoder (to verify the data) without deleting (or reusing) the existing one. A small program demonstrating this is pasted

Yeah, de-/encoding a stream would have a lot of advantages but there is no streaming en-/ decoder I would be aware of and for the application I'd intend to use it for, it might be sufficient to de-/ encode a file in whole. Dependent of the time and efforts for creation and maintenance of a stream encoder, it might not fit into the time budget. (Apart from that, as of now, it gives a nice demo

Largest risks are: 1) encoding errors in a scenario not exercised by the tests 2) violations of the spec that are tolerated by the decoder. I've seen this before with, e.g. x264, where a bug is repeated in the encoder and decoder and hence not caught by any tests. On Apr 26, 2012, at 2:49 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Josh Coalson wrote: > >>

sorry if I did not reply to this, answers below: --- Josh Green <josh@resonance.org> wrote: > On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a > bug > > report related to decoding of CRAM files. This issue occurs with > > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note >

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:

On Fri, Jan 07, 2011 at 05:11:26PM -0800, brianw at sounds.wa.com wrote: > Lots of comments throughout this one... And I'm going to cherry-pick a few replies as it's getting late. > What I found most interesting was that I had > hired a professional studio in Seattle, and the owner actually stuck > his head in the room for this one track. He'd heard a lot of >

Hi, the patch below fixes function prototypes/defintions with void argument to shut up the heartful warnings by recent gcc :) It doesn't cover all places, e.g. test directories. The patch is to 1.1.2. Takashi --- src/metaflac/operations.c-dist 2005-05-25 16:20:02.000000000 +0200 +++ src/metaflac/operations.c 2005-05-25 16:20:09.000000000 +0200 @@ -26,7 +26,7 @@ #include <stdlib.h>

> I was wrong about it going up to 11 - it actually goes up to 12. Too bad. I thought for a minute there that it goes up to eleven because... "Well, it's one louder, isn't it? It's not ten. You see, most blokes, you know, will be playing at ten. You're on ten here, all the way up, all the way up, all the way up, you're on ten on your guitar. Where can you go from

Version 1.2.1 of the standard/spec or the local implementation? I've not seen "FLAC 1.0/1.1 Compliant" or "FLAC 1.2 Compliant" on the specs of hardware gear for example when FLAC is stated supported. Just a curious on-looker. On 7 February 2011 02:34, Pierre-Yves Thoulon <py.thoulon at gmail.com> wrote: > Version 1.2.1 introduced new rice coding techniques

On Sat, May 19, 2001 at 12:55:08AM -0400, Matt Zimmerman wrote: > On Sat, May 19, 2001 at 02:05:14AM +0000, Christian Weisgerber wrote: > > > Problems in FLAC 0.9: > > > > - On alpha, flac immediately dumps core for both encoding and > > decoding (FreeBSD/alpha). > > I have reproduced this on Debian/alpha as well. I will spend some time > debugging it