--- Evan Olcott <[EMAIL PROTECTED]> wrote: > > On Jan 3, 2007, at 3:28 PM, Josh Coalson wrote: > > > the FLAC parts look OK but I don't know how the audio converter > > works. I think that's where the problem is. it is probably > > converting float to 32-bit int full scale. > > well, here's what I found out about the 32-bit integer conversion. > > If the original 16-bit sample is 0x52F3, it goes through floating > point, then comes to the 32-bit integer as 0x52F30000 > As far as I know that's the proper conversion, yes? Simple adding > some LSB to make it 32-bit. > > > but if [audioFile range] is 16 (i.e. 16 bits per sample), then > > after conversion, the integer PCM samples in outputBuffers > > should all be in the range [-32768,32767], that's the first > > thing I'd check. > > OH so wait... > What you're saying then is that the buffers always have to be filled > > with 32-bit-SIZED-FIELDS, inside of which > exists a low-aligned integer sample value? > > So the VALUES aren't 32-bit integer, but the SPACE FOR THE SAMPLE > VALUE is 32-bit. > Wow, that's very trippy. Honestly, I *never* would have guessed that > > from the documentation. > > That would explain the silence, too.
yep, that's right. I'm adding this sentence to the docs which should hopefully clear things up in the future: Each sample should be a signed integer, right-justified to the resolution set by FLAC__stream_encoder_set_bits_per_sample(). For example, if the resolution is 16 bits per sample, the samples should all be in the range [-32768,32767]. __________________________________________________ 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