[Flac-dev] Is FLAC fully cooked for OS X yet?
xflac at yahoo.com
Wed Jan 3 14:12:56 PST 2007
--- Evan Olcott <ev at audiofile-engineering.com> 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
More information about the Flac-dev