--- Evan Olcott <[EMAIL PROTECTED]> 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 _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
