[Flac-dev] Is FLAC fully cooked for OS X yet?

[Josh Coalson]

--- 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 
http://mail.yahoo.com