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

I managed to get around it. I used the stream functions and provided my own callbacks for reading and writing. What's strange is that what I've done is just copied the contents of read/write/seek/tell/eof callbacks from the sources to my application and it works just fine, no glitches. When I use the build-in implementation, it just crashes without any reason. It's not a problem to

I thought about this, and the MSVCRT mismatch also. What annoys me is that I even tried compiling the library myself (with exactly the same Visual Studio 2008 as my application) and the bug didn't change the least. Thank you for your ideas, but unless someone can confirm this, there still remains the possibility that I've made an error somewhere. Also someone with more experience with

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

Hello, I am currently learning the FLAC C API and had the code working with FLAC__stream_decoder_init_file. However, since I'd need the Unicode filename support, I tried _wfopen_s in combination with FLAC__stream_decoder_init_FILE, however I get a runtime crash as sonn as I call FLAC__stream_decoder_process_until_end_of_stream. The same code (partially taken from the examples) is working

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

Hello, My partner and I are both high school students who are working on a device that encrypts secret messages into sound files. The method that we are using involves the conversion of data into an mp3 format, and this results in a loss of data that is crucial to the success of the device. We would like to be able to predict which points are going to be modified significantly or lost completely

Hi everyone. Is it possible for me to get the source code for the flac program? especially the .c file. I got confused when I downloaded the file at the web, and only got the .h file. It's is really confused me. Or maybe can anybody tell me about the algorithm that is used? Sorry if it bothering all of you, because I still newbie in audio compression. Fyi, I want to use flac algorithm for my

else. Stuart =20 ----- Original Message -----=20 From: Ivailo Karamanolev=20 To: flac-dev at xiph.org=20 Sent: Wednesday, January 06, 2010 7:49 AM Subject: Re: [Flac-dev] FLAC C API / Visual Studio 2008 FILE* Issue I thought about this, and the MSVCRT mismatch also. What annoys me is = that I even tried compiling the library myself (with exactly the same = Visual Studio 2008 as my

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

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

I'm implementing a FLAC decoder from scratch (save OGG stuff if I can help it) because libFLAC simply will not fit my embedded platform, For the most part I'm implementing using just the documentation but not all of the documentation is concise (especially about variable sized fields) and after looking at the libFLAC source I find myself befuddled so I thought it best to get the

Dear Rexperts, lately I'm having troubles installing the rgl package via install.packages("rgl", dependencies=T) in the R 2.4.0 backport running under Ubuntu 6.06 LTS. I get the following error messages, despite having installed libx11-dev (as recommended in a similar post about SUSE 10.1): trying URL 'http://cran.xedio.de/src/contrib/rgl_0.68.tar.gz' Content type

Dear Rexperts, after building R 2.4.0 from source in a temporary directory (*without* installation), and subsequently moving the whole source/build tree to another location, I have noticed that I had to change the variables R_SHARE_DIR, R_INCLUDE_DIR, and R_DOC_DIR in the wrapper-script /lib/R/bin/R as to reflect the current situation. However, when I try to run the HTML help via

Ivailo - FILE objects are internal to the C runtime library, they are not system objects like HANDLEs (windows) or file descriptors (unix). This means that if libFLAC has linked against a different C runtime library than your application, then the two FILE objects are incompatible. This isn't just a Windows specific issue either - if libFLAC was compiled against libc and your application

Hi Ivailo The problem with an embedded CUE sheet is that this requires 2 preconditions. 1 - that the FLAC files are taken from an Audio CD, and 2 - that a drive is used such as a Plextor that can manage to do this properly. Neither condition applies here. The files I needto turn into FLAC files are 24 bit 48kHz streams that exist as WAV files on HDD. They are not from CD - I keep trying to

Dear list-members, I have switched (back) to a terminal-based workflow for a while now and have noticed that after starting the HTML-based help [help.start()], then visiting the package-list (at http://127.0.0.1:<random_port>/doc/html/packages.html), and after the accessed page has been "generated" (as indicated by the message "Making 'packages.html' ... done"),