similar to: How to handle multiple STREAMINFO blocks?

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

Thank you very much! But how to deal with endianness in the case of bit stream? Some blocks (for example MinBlockSize) require 16bits (simply swap first and second), some block (e.g.MinFrameSize) require 3 byte-array to be reverted. Finally totalSamples is stored in 5 bytes ( only last 4 bits from first one byte are used). It was a real issue to make it little-endian (here is how I did it:

Hello Ilia, The FLAC format by nature is not a byte stream, it's a bit stream. Therefore, in order to parse it you need too build a bit-reading infrastructure. Eg. a class that accepts a byte stream, implements buffering, etc, etc, and supports reading a specified number of bits, not bytes as you are used to. There is quite a lot of bit logic there, but nothing too scary. Best Regards,

I have some FLACs that have STREAMINFO that looks like this: METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minumum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 0 bytes maximum framesize: 0 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 0 MD5 signature: 00000000000000000000000000000000 (This came

Oops. I proofread my email a little too late. I corrected the example. Hopefully what I am suggesting is clear. Brian Willoughby Sound Consulting On Jun 22, 2010, at 22:15, Brian Willoughby wrote: > What you need to do is write a bitStream function. It should only > read each byte from the stream once and completely deal with all 8 > bits before reading the next byte. You

Using Trader's Little Helper 2.4.1.160 when testing some 16/96 FLAC files I run into the following error: "file is decodable without error, but flac fingerprint cannot be checked since it was unset in the streaminfo block." Is there an automatic checksum verification when testing/decoding? Is there any way to fix this, i.e. get rid of the error? Martin

Op wo 16 okt 2024 om 16:25 schreef Stefan Oltmanns <stefan-oltmanns at gmx.net>: > > Yes, overwriting the streaminfo total_samples number is a bit of a hack, > but it would only affect those files with more than 2^36 samples that > contains the special seek point, so no difference for the average flac user. > > Not sure how the applications actually read flac files, if they

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

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

Am 16.10.24 um 15:15 schrieb Martijn van Beurden: > > But how should such a number be presented to the libFLAC user? You > suggested overwriting the streaminfo total_samples number, but > streaminfo always precedes the seektable, so the streaminfo metadata > block is already parsed by the application before the seektable is > even read. Also, I think it is quite hacky to not pass

I've been implementing Ogg FLAC support in an editor I'm working on, and I must admit to being frustrated by the lack of support for the codec on the Ogg layer... and this is more than lacking granulepos. The codec's I've worked with, and my own (Writ), use Page 0 for general information about the codec. Specifically, the samplerate, bitrate, quality, number of channels, all

Op di 15 okt 2024 om 21:27 schreef Alistair Buxton <a.j.buxton at gmail.com>: > > I would like to see this kind of thing put into a secondary metadata block aimed specifically at SDR. This could be completely ignored by regular audio players - these files are not meant to be listened to anyway. I could probably figure out how to implement that, I even started looking into it once, but

On Jun 22, 2010, at 21:27, Ilia Ternovich wrote: > Thank you very much! But how to deal with endianness in the case of > bit stream? Some blocks (for example MinBlockSize) require 16bits > (simply swap first and second), some block (e.g.MinFrameSize) require > 3 byte-array to be reverted. > > Finally totalSamples is stored in 5 bytes ( only last 4 bits from > first one byte

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

Am 15.10.24 um 19:03 schrieb Martijn van Beurden: > > No, seeking to a specific sample can take a while because of all the > back-and-forth, but seeking to almost the end of the file is very quick. > > I know this is not the cleanest way, but as this only for the rare cases Ah, I see, because the frame header also include either the sample number (variable frame size) or the frame

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: