similar to: FLAC StreamInfo Parsing

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:

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

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,

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

If compression level is not default (!=5), is it stored? If compression level is stored in some case, where I can find it? Frames number works OK according to your instructions. Thank you ----- Original Message ----- From: "Josh Coalson" <xflac at yahoo.com> To: "Santiago Jimeno" <sjimeno at ya.com>; <flac at xiph.org> Sent: Tuesday, January 27, 2009 7:43

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

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

Erik, It turns out bc(1) is too accurate, and a little slow, for this purpose. I've switched to using awk(1) which uses floating point. Do you feel I need to test for the presence of awk(1) ? It is specified as one of the standard commands in the LSB : http://refspecs.linuxfoundation.org/LSB_1.0.0/gLSB/command.html Earl ??? awk -- ' ??? BEGIN { ??????????? samplerate = 8000;

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

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

Here's how I set up the data for processing: // For moving data into 32 bit shape uint8_t *buffer8 = NULL; uint16_t *buffer16 = NULL; uint32_t *buffer32 = NULL; unsigned sample32; unsigned sample, channel; uint32_t bitsPerSample = this->get_bits_per_sample(); numFrames = inData.GetSize();

Hi all, > On Jun 5, 2017, at 11:52 PM, Andrew James Weaver <weevz at uw.edu> wrote: > > Hello all! > (cc-ing the flac-dev list) > > I would like to give an update as to the recent CELLAR work on the FLAC specification. > > • Work has been done to make internal and external links more accurate and reliable. > • 'Rice Coding' has been clarified as

I'm using seekable_stream_decoder, And., this is my write_callback. I'm not getting the required output. The PCM i get is not the proper music. Am I doing something wrong here? FLAC__StreamDecoderWriteStatus AFLACStreamPlayer::StreamWriteCb ( const FLAC__SeekableStreamDecoder *decoder, const FLAC__Frame *frame, const FLAC__int32 * const buffer[], void *client_data) { int Channels,

I can't be totally sure what 'short' is on your platform, but if it's (probably) 16-bits, it looks like you're treating the samples in buffer[] as packed 16 bit numbers. but all samples in buffer[] are 32-bit signed integers in host order, regardless of the bits-per-sample of the frame. so to get them down to shorts (assuming they'll fit), do like: FLAC__int32 *

Martin Leese wrote: > Your proposed wording was: > 0000-0111 : (number of independent channels)-1. The channel order > follows SMPTE/ITU-R recommendations. The assignments are as follows: > > The channel order might not follow SMPTE/ITU-R > recommendations, so this proposed wording > seems misleading to me. But this text describes only those 4 bits in frame header. IMHO

Earl Chew wrote: > I'm a little reluctant to introduce another compiled program when there are > so many other options that will work well enough out of the box. > > Here are two ideas: > > 1. Use bc(1) to compute the raw samples > 2. Use perl(1) to compute the raw samples > > To generate raw unsigned samples using bc(1) for example: > > samplerate = 1000;

lvqcl wrote: > Martin Leese wrote: >> Note that the channel order may not be defined. > > IMHO it doesn't matter in this place of documentation (which describes > default channel assignments for FLAC). Your proposed wording was: 0000-0111 : (number of independent channels)-1. The channel order follows SMPTE/ITU-R recommendations. The assignments are as follows: The

I'm a little reluctant to introduce another compiled program when there are so many other options that will work well enough out of the box. Here are two ideas: 1. Use bc(1) to compute the raw samples 2. Use perl(1) to compute the raw samples To generate raw unsigned samples using bc(1) for example: samplerate = 1000; duration = 2; bitspersample = 24; samplerange = 2 ^ (bitspersample-1) -

On Nov 26 22:39:27, hans at stare.cz wrote: > ./test_replaygain.sh fails for me in tonegenerator(), saying: > > ./test_replaygain.sh[91]: mawk: not found > Testing FLAC replaygain 8000 (8000 x 1) ... -: ERROR: got partial sample > > Apparently, the tone-generating awk script does not work with > my system's awk, which is "awk version 20110810" as distributed