flac dev - Jan 2007 - Is FLAC fully cooked for OS X yet?

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.

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/c3b51c59/attachment.htm

--- Evan Olcott <ev@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