--- Evan Olcott <[EMAIL PROTECTED]> wrote: > > 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.
it's probably getting buffers of zeroes (or a constant number); that compresses really well with FLAC. at this point I think I'll need to see your code up to and including your call to FLAC__stream_encoder_process() where it fills the buffer in order to be able to figure it out. Josh __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
