similar to: Support for ultra-high sample rates?

Browsing the sources, it looks to me that libFLAC decoder already supports sample rates as 20-bit numbers in the STREAMINFO metadata block so up to 1,048,575 Hz if a trick is done by having in FRAME_HEADER of each frame the sample rate as "0000 : get from STREAMINFO metadata block". If explicitly given in the frame header, the maximum sample rate is 655350 Hz. However, the libFLAC

Op do 25 jun. 2020 om 16:02 schreef Con Kolivas <kernel at kolivas.org>: > The idea is to actually use it for playback, not just storage, and > nothing else has the nice asymmetrical fast decompression with such > effective compression (wavpack supports 705/768 but is woefully slow > on decompression and poorly supported). Mostly the sample rates would > be multiples of the

Isn't the FLAC encoder 'tuned' for the compression of audio data at common sample rates anyway? Does it make sense to use FLAC to compress arbitrary analog data at very high sample rates as opposed to other general purpose compression algorithms? Tor Am 25.06.2020 um 14:49 schrieb Martijn van Beurden: > Op di 2 jun. 2020 om 05:59 schreef Con Kolivas <kernel at kolivas.org

Hi, I would like to clear something up about Sample Rate, If the Frame header can look to the metadata block streaminfo for sample rate what (if anything limits it to 655350Hz)? Can all frame headers not just point to streaminfo and it be specified in streaminfo as all 1s ie 2^20-1 = 1,048,575Hz? It would be really good to be able to use 1MHz and beyond for some of my/our work. Does anything

On Thu, 25 Jun 2020 at 23:11, Tor-Einar Jarnbjo <tor-einar at jarnbjo.name> wrote: > > Isn't the FLAC encoder 'tuned' for the compression of audio data at common sample rates anyway? Does it make sense to use FLAC to compress arbitrary analog data at very high sample rates as opposed to other general purpose compression algorithms? The idea is to actually use it for

On Fri, 26 Jun 2020 at 00:37, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Op do 25 jun. 2020 om 16:02 schreef Con Kolivas <kernel at kolivas.org>: >> >> The idea is to actually use it for playback, not just storage, and >> nothing else has the nice asymmetrical fast decompression with such >> effective compression (wavpack supports 705/768 but is

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

Martijn, I don't use any metadata when encoding and decoding. When I call *FLAC__StreamDecoderStateString[FLAC__stream_decoder_get_state(m_decoder)] * * * it returns FLAC__STREAM_DECODER_SEARCH_FOR_METADATA enum value. Is it an error ? 2013/7/2 Burak Or?un ?zkablan <borcunozkablan at gmail.com> > Hi again, > > I can not solve problem. I want to mention my source code, so

On 6/7/14, 1:55 AM, Jean-Marc Valin wrote: > Actually... no! 24-bit can indeed be useful as extra margin and Opus > can actually represent even more dynamic range than 24-bit PCM. That's > not the case for 192 kHz. There's no "margin" that 192 kHz buys you > over 48 kHz. You can do as much linear filtering as you like, the > stuff above 20 kHz isn't going to

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

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

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

from the zaptel sample config: # "dacs" : The zaptel driver cross connects the channels starting at # the channel number listed at the end, after a colon # "dacsrbs" : The zaptel driver cross connects the channels starting at # the channel number listed at the end, after a colon and # also performs the DACSing of RBS bits dacs=1-24:48

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

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

On Mon, 2003-11-17 at 11:04, Josh Coalson wrote: > could you clarify your plan... are you thinking about > 1) encoding to a FLAC container and using metadata blocks > for everything that is not data? > 2) writing your own container? > > 1) seems kind of impractical to do in a general way. > I'm starting to also think that 2) is the best route. I was originally

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

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:

I am making a program to obtain information from FLAC files in Visual Basic. NET language. If somebody needs it I can send it. I can also translate it to C #. But I have read the documentation and I have looked for in sdk 1.2.2 and I don't find how to get the frames number of the file and the used compression level (5 default and others) Can somebody help me? Greetings. Santiago Jimeno