similar to: frames number & compression level

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

Hi Harry I attach you FLACInfo C# class and also for the forum. I already added frames number code. Code for VORBIS Tags is not included . But taking as sample the code for Vendor and following the specifications you can make it easily.With a loop similar to Vendor you can read all Tags. It's only necessary to keep in mind two things: VORBIS is litteleendian and FLAC doesn't use the

"Santiago Jimeno" wrote: > Flac files, as us knows, follows the Vorbis Tags system included in block 4 > Recently Vorbis has established the possibility to include picture files by > means of 2 Tags: COVERARTMIME AND COVERART. > To work therewith is quite easy. No. this in incorrect. The VorbisComment "COVERART" was only ever unofficial, and has been deprecated

You said "With the exception of where to put a picture file, VorbisComments in a Vorbis stream are the same as VorbisComments in a FLAC stream." In METADATA_BLOCK_PICTURE case they would not be the same. Up to now we could exchange the complete block of VorbisComments. But with the addiction of METADATA_BLOCK_PICTURE doesn't happen this way. In Ogg files the METADATA_BLOCK_PICTURE

OK Martin. Thank you for the explanations and for your time. I am writing a program that reads and writes all existent Tags types. It lacks only to end the edition (rewriting) of "Native" Flac and Matroska. Both cases for the same problem: the separation of Tags and Picture in different blocks. In Flac I resolved it, but now I have to add METADATA_BLOCK_PICTURE. Reading Vorbis

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

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

HI Josh, I'm starting now to compile the ACM codec. I don't know how long it will take, since I do it in my free time, but I guess it will not take to long. About Mark Powell's comment, with an ACM codec there will be a lot of Windows GUIs for FLAC. I'm writing this message to talk about the FLAC format. The GUIs for the Audio Codec Manager, including Winamp and Windows Media

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

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

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

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

Op 01-10-15 om 18:14 schreef lvqcl: > Currently libFLAC stores residual signal as 32-bit signed int. And there > are the following comments in stream_encoder.c: The residual is stored as a Golomb/Rice code. As far as I know, that is not limited to 32-bit in the format itself, only in the implementation. However, there are two residual coding methods now: rice and rice2. rice2 was added

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

If processing time is not a big factor -- say, I could put up with four to six times the duration of compressing at -8 -- what command-line settings could one use to get even more compression? I have a case where the FLACs encoded at -8 are about 653.3 MB, but the set comes with artwork whose jpegs are 50.5 MB (I tried zipping the jpegs, realizing it would do very little, and the zip file

Early this past week, Miroslav Lichvar suggested for me: > Ok, you need 0.04% improvement, that should not be a problem. Try > flac --lax -e -p -l 32 -r 10 --no-padding Thank you again, Miroslav. I tried that, and it took almost two full days (surprisingly, Windows ME stayed up that long without crashing) to re-encode the entire set on my 266-MHz machine. After all, in the help file

Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header

I posted to this list a couple years back and then again sometime a year ago about using Flac to compress SoundFont instrument files. I never got around to finalizing the specification for that project, and I have since realized that a more generic approach would be better. I registered the "SFFL" Sound Font FLAC application meta data ID. I would like to remove that, since it was never

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