similar to: libFLAC optimizations request

Hi, On Sat, Feb 3, 2018 at 10:10 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Gabriel Corneanu wrote: > >> Is this interesting for the project? > > I would theoretically accept a patch that allows direct access to the > functionality you seek, as long as it doesn't change the existing API. > >> If yes, how should I share it? As a patch against

Correction, the flac command-line does create a 40-byte Vorbis comment by default. I just never noticed it before. I’ve been using —no-padding all these years for minimal file sizes without realizing that I could save another 40 bytes. Anyway, since metaflac can remove the Vorbis comment using the standard library, then you should be able to create a solution without modifying libFLAC. Brian

Hello all I am using libFLAC in a corner application, compressing *a lot* of small signals. First is a general question: in our application we have signals in range 5-10 MHz, potentially 40MHz! Is there any potential problem with that?? The mac sample rate is limited in flac, but it doesn't really seem to be a problem. The output is stored as blob in a sqlite database, it *never *needs to be

I wasn’t suggesting that you run metaflac, but that you examine its source to see how it creates new FLAC files without the Vorbis comment. As far as I know, metaflac uses the standard libFLAC and creates files without the Vorbis overhead. My quick review of the source seemed to indicate that calling FLAC__metadata_object_new(FLAC__METADATA_TYPE_VORBIS_COMMENT) will create the comment, but I

Gabriel, metadata_has_vorbis_comment is a FLAC__bool which defaults to false. There should be no reason to modify stream_encoder.c, but just modify the caller. The following command: metaflac —remove —block-type=VORBIS_COMMENT —don’t-use-padding … will remove Vorbis comments from existing files, so is must be legal without modifying the library. metaflac can clearly create a new FLAC file

The problem is really as I wrote: 1. Metaflac is no option for me, I use libFLAC.dll 2. There is no way (at least how I read the code) to avoid saving comment with libFLAC; I would appreciate an extra option to avoid it, which can default to old behavior if compatibility is important. 3. I have a high speed application, where re-initializing an encoder is really significant. On corner cases it

Hello, I'm currently doing a little music player using libflac and libao. What I've currently done works as it should, but I have a problem where only one metadata block is detected, even if there are more (it doesn't have the last attribute set to true). This is using flac 1.3.2 on Gentoo amd64. The main code file is attached, it mainly follows the examples given with the libflac

Yes, it's finally here. See the homepage for details, but here's a summary: - 10-15% decoder speedup - 24-bit input support restored - more robust plugins - new metadata block for Vorbis-style tags - vastly improved metadata editor - fixed bug with pipes and Windows - new libFLAC++, a C++ object wrapper around libFLAC - new metadata editing interface in libFLAC and libFLAC++ - and

I'm writing a program that plays FLAC files using the libFLAC API's. Is there a specific way I'm supposed to handle multiple STREAMINFO metadata blocks? For example, should I ignore all but the first, or all but the last? The format spec doesn't mention anything. Thanks, - Brian Waters

On 2006-03-09 (Thu) ,at 23:20:50 Josh Coalson wrote: > the vorbiscomments are not in the streaminfo. you want to do: > > FLAC::Metadata::VorbisComment tags; > if (FLAC::Metadata::get_tags("somefile.flac", tags)) { > FLAC::Metadata::VorbisComment::Entry entry = > tags->get_comment(tags->get_num_comments-1); //e.g. last tag > // do something with

It's certainly best to honor what the specification says. My assumption is that a "stream" could also be a continuous broadcast, not just a file. With a hypothetical server streaming FLAC bitstreams, I would assume that the most recent STREAMINFO is valid until another one comes along. If you're writing a file player, then perhaps you can trust the spec and assume

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 issue: When calling FLAC__stream_decoder_process_single() the error callback is triggered

Hi. I was wondering if there was any interest in extending the flac container format to support sample rates above the 655k current limit. Please note this is not for using ridiculously high sample rate sourced audio for some imaginary audible benefit. I've been involved in some experimentation with offline upsampling in software prior to delivery to an external DAC as a way to bypass the

Replying to myself once again, since I seem to have found the answer I was looking for. Sorry for the noise. It seems CRAM is indeed misusing FLAC, since stated in the Notes section of the FLAC format for the FRAME_HEADER is the fact that only block size values 0110 and 0111 can be used for variable block size data (i.e., the block size is specified as an 8 or 16 bit value at the end of the

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

Hello, I'm currently doing a little music player using libflac and libao. What I've currently done works as it should, but I have a problem where only one metadata block is detected, even if there are more. This is using flac 1.3.2 on Gentoo amd64. The main code file is attached, it mainly follows the examples given with the libflac and libao doc. And here's what metaflac --list

I'm trying to use libFLAC++ v1.1.2, to read Song information (like artist, trackname etc..). So.. I read metadata from file FLAC::Metadata::get_streaminfo("somefile.flac", infosik); and It's ok - no error, then I read vorbis info: FLAC::Metadata::VorbisComment vorbis_kom(infosik); int number_of_comments = vorbis_kom.get_num_comments(); and after that I have

Thanks for the quick response on the C++ thing. It would also be nice if the host program could correctly write the STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback:

Hello, I'm looking into storing FLAC audio in Matroska and I have a few questions. 1. Can I use libflac to extract the compressed frames? Or will I need to write up a simple file parser? 2. What is required to decode the frames? From the docs I understand that you need the FRAME and you may need the METADATA_BLOCK. Thanks, Jory Stone jcsston@toughguy.net Matroska, the new,

Hello all, I am writing an implementation of a FLAC decoder and I am polishing up some details. The format <http://flac.sourceforge.net/format.html> page leaves some room for interpretation. Can anyone help me by clarifying the official rules about the following? Most of them are degenerate cases that probably don't happen in practice: Thanks, --Jonathan Can the bits per sample