[Flac-dev] Is FLAC fully cooked for OS X yet?

[Josh Coalson]

--- Evan Olcott <ev at audiofile-engineering.com> wrote:
> 
> On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote:
> 
> > The binary frameworks distribution, as found on:
> > http://xiph.org/quicktime/download.html , hasn't really been tested
> > much outside the XiphQT project. I never had any problems with
> them,
> > but any improvement suggestions or help is welcome.
> 
> Well, ok, then if the framework is intended to work, then let me  
> describe closer the situation I'm seeing:
> 
> I'm using FLAC__file_encoder_process to encode the audio I'm getting 
> into an FLAC file. I can prove that the audio I'm sending it via the 
> buffers is valid: I've written it to a raw file to confirm it's the  
> same as the source file, and it is. I've tried it with multiple  
> channels and single channels to the same error. I'm giving the  
> processor audio in blocks of 1024...
> 
> The file apparently gets created successfully, but when I convert the
> FLAC file back to aiff (using MacFLAC - I haven't written a decoder  
> just yet), it seems like the blocks were written to the encoder with 
> the first 512 samples being every *other* sample, and the remaining  
> 512 of the block being random data. This continues throughout the
> file.
> 
> I have double and triple checked my buffering techniques and they are
> indeed giving it the audio data I want to give it, and this just  
> seems like bad buffer usage in the file_encoder side. (Thus my  
> reasoning for wanting to step through it with the source)...
> 
> Are there any ideas about this, is it a known issue? Is there  
> something I need to be setting up that I'm not?

this is reported a lot.  usually it is a misunderstanding in how
to send samples to FLAC__stream_encoder_process() or
FLAC__stream_encoder_process_interleaved().  if you could send
your code where you are doing that, it would help.

note that samples going in to the process calls must be converted
to signed 32-bit integers (this is lossless) regardless of the
initial format.  see also:
http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga63

from your description it sounds like you might be sending packed
16-bit samples somehow which could cause every other sample to get
encoded.

Josh


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com