search for: streaminfo

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 that there will never be more than one. But I suppose it all depends upon which is easier to handle in your code. Some implementations might make it more complica...

...bFLAC unit test: metadata manipulation [...] | ++++++ testing level 2 interface [...] | PASS: ./test_libFLAC.sh | Memory fault (core dumped) | ERROR during test_libFLAC++ | FAIL: ./test_libFLAC++.sh sparc64 (gcc 3.1): | +++ libFLAC++ unit test: metadata objects | | testing class FLAC::Metadata::StreamInfo | testing StreamInfo::StreamInfo()... OK | testing StreamInfo::StreamInfo(const StreamInfo &)... + | StreamInfo::operator!=(const StreamInfo &)... OK | testing StreamInfo::~StreamInfo()... OK | testing StreamInfo::StreamInfo(const ::FLAC__StreamMetadata &)... + | StreamI...

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

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 start > using the total_...

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...

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

...sys/stat.h> -#include <fcntl.h> +#include <unistd.h> #include <stdarg.h> -#include "FLAC/all.h" -#include "id3_tag.h" -#include "configure.h" - -gboolean get_file_info(char *filename, flac_file_info_struct *tmp_file_info) -{ - FLAC__StreamMetadata streaminfo; - - if(0 == filename) - filename = ""; +#include <gtk/gtk.h> - if(!FLAC__metadata_get_streaminfo(filename, &streaminfo)) { - return FALSE; - } - - tmp_file_info->sample_rate = streaminfo.data.stream_info.sample_rate; - tmp_file_info->channels = streaminfo.data.stream_...

Am 16.10.24 um 19:46 schrieb Martijn van Beurden: > libFLAC reads a file from start to back, and returns data to the > client as soon as it is done parsing. So, it first encounters a > streaminfo metadata block, sends that to the application, then starts > on the seektable etc. In fact, for a lot of applications, the seek > table is simply ignored because libFLAC uses it internally. > > I don't know how libFLAC should indicate that streaminfo isn't > complete yet, but...

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 the actual > streaminfo metadata block to the application but ...

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 currently support this?...

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

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,

...e > 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: > http://code.google.com/p/sharpflac/source/browse/trunk/SharpFlac/ > Blocks/StreamInfo.cs). > > So to make stream little endian, I can't simple get each 4 bytes of > the stream one by one and revert them... > > Anyways I've managed to decode StreamInfo, VorbisComments,SeekPoints > and Application blocks without bitStream implementation. But I'd be > r...

...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: http://code.google.com/p/sharpflac/source/browse/trunk/SharpFlac/Blocks/StreamInfo.cs). So to make stream little endian, I can't simple get each 4 bytes of the stream one by one and revert them... Anyways I've managed to decode StreamInfo, VorbisComments,SeekPoints and Application blocks without bitStream implementation. But I'd be really pleased if anyone pointed m...

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.....

...o I suppose there probably isn't really an issue with the frame size becoming a significant overhead, but I'm curious if combining small samples would make sense in that case. Likely its more trouble than its worth. > also, if using your own container, you don't really need the > STREAMINFO block, might as well just throw away all metadata > when encoding. > Looking at the API, would the stream encoder/decoder be the option to use for this? Or is there a more appropriate interface? Using that interface I suppose I could ignore the "fLaC" signature (at least for each...

Hello! I'm implementing custom flac metadata parser. Currently the very big trouble is to parse StreamInfo metadata block. According to specifications (http://flac.sourceforge.net/format.html#metadata_block_streaminfo) we've got 2 bytes fir minBlockSize, 2 bytes for maxBlock size, 3 + 3 bytes for min/max FrameSize. Now the interesting point -- sampleRate. number of channels, buts per sample and to...

....html#frame_header Not quite sure the best way to fix this. I'd love to hear any ideas.. CRAM files usually consist of several audio samples all packed into the same file (with binary segments compressed with zlib). FLAC is used to store only the compressed audio and no other FLAC headers (STREAMINFO, etc) are actually found in a CRAM file. A single sample could (and is currently) compressed using a single block size. It might be advantageous to change the block size between audio samples though, depending on the individual sample parameters (sample rate, length, etc), I have yet to determine...

...coder > just like before, new files are treated by old decoder also just like > before, only new file and new decoder will result in that feature. > And this only affects files with more than > 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 the actual streaminfo metadata block to the application but 'patch' it fir...

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. If this is a seekable s...