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? Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/
--- Evan Olcott <ev@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
On Jan 2, 2007, at 1:54 PM, Josh Coalson wrote:> 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#ga63Well THAT's interesting! I get the impression from the documentation that you can give it whatever bit range you define in the set_* calls. But if it has to be only 32-bit integer (signed, I assume?), then that's easy enough.> from your description it sounds like you might be sending packed > 16-bit samples somehow which could cause every other sample to get > encoded.This would make sense. I will try the 32-bit technique and see if it works. Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070102/17ae9fa3/attachment.html
On Jan 2, 2007, at 1:54 PM, Josh Coalson wrote:> 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.OK, now I'm totally stumped. I can confirm that I'm sending the encoder 32-bit signed integers, and that they are correctly representing the original file. I still get a silent file. I tried making the resulting integers forcibly little-endian, and I got a FLAC file result that sounded like what a byte-reversal might sound like - noisy when there's data, but 0 is 0. I've heard it before, I recognize it... But why when I send it *correctly* to the encoder do I get silence? Another clue is that they see to be super-small files, but with the proper length. Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering http://www.audiofile-engineering.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20070103/15e68069/attachment-0001.htm