similar to: Max Sample Rate FLAC

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

lvqcl wrote: > Martin Leese wrote: >> Why place restrictions on which speaker a >> user can use? ... >> Finally to answer your question, for a >> single-channel file, FLAC should accept any >> one of the three masks 0x00000001 (FL), >> 0x00000002 (FR), 0x00000004 (FC), plus any >> one of the 15 other single-bit masks, plus zero. Please note that the

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

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

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

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

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

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

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

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 'Exponential Golomb Coding.' • Clarifications have been made for binary representation. • Typos and other small changes have been

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

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

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:

sorry if I'm not reading this close enough, I'm ploughing through a bunch of emails here, but the source of this problem is what I consider a design defect in FLAC which uses frame numbers to save space, and confusing logic for determining whether the frame number or sample number is stored. if I had it to do again I would just have it store the sample number always. if you are going to

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:

Hi, I'm trying to write a FLAC decoder for my Java audio app. Can I ask a couple of questions to this list about the format? I think there are a couple of things not-quite-mentioned in the official spec. RICE CODING: Which order are Rice-coded numbers stored in? (a) [sign-bit][low-order bits]["k" zeroes][1] (b) [sign-bit]["k" zeroes][1][low-order bits] (c)

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

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