View Single Post
Old 05-30-2008, 01:44 AM   #44
Dstruct
Human being with feelings
 
Join Date: Jul 2006
Posts: 10,010
Default

Justin, it's not really fixed (in Foobar2000):

Quote:
Originally Posted by Peter (Foobar2000 developer)
Looks like I accidentally left the fix active in 0.9.5.2 release. I still don't believe that this is a legit behavior of FLAC tools and anybody else converting FLAC decoder's output to floating-point values will run into the same problem.
I hope Josh is looking into this.
http://www.hydrogenaudio.org/forums/...dpost&p=561926



Looks like Reaper doesn't encode correctly to 24 bit FLAC:

Quote:
Originally Posted by jcoalson (FLAC developer)
ok, short story, I'm pretty sure 24_bps.flac is corrupt, was it created with reaper? I would like to see the code it is using to call libFLAC because I'll bet it's not passing in properly sign-extended data to FLAC__stream_encoder_process().

the giveaway is that if you decode it to wav with flac.exe and re-encode it with flac.exe, this .flac file is ~20% smaller than 24_bps.flac. and it all happens to work because of 1) the magic of 2's-complement arithmetic; 2) flac.exe does the same 'fix' that foobar is now doing. these 2 things together magically cancel out the initial encoding error.

long story:

in this clip, sample 0 of channel 0 is 0 and sample 1 of channel 0 is -364 (0xfffe94 in the wav file). the first FLAC subframe of channel 0 is a FIXED subframe with order 1, meaning the first sample (0) is stored raw and the second sample (-364) is stored as a residual value "sample[1]-sample[0]" == -364 - 0 == -364

but that is not what is actually in 24_bps.flac, the first residual sample it has encoded is 16776852 (0xfffe94), which is exactly what I would expect if the client passed in bad data (explained next), and also explains why the compression ratio is bad (because 16776852 takes more bits to store than -364)

when samples are passed in to FLAC__stream_encoder_process(), they must be 32-bit signed ints regardless of the sample resolution. so to pass in -364, the sample value should be 0xfffffe94, but if the client is not sign-extending properly, it will pass in 0xfffe94 and due to the above mentioned magic, it will all appear to work (magic extends even to the md5 summing).

now this could have been avoided if libFLAC did range checking on the input but this noticeably slows things down, which I am hesitant to do for something that should be caught in testing. (maybe it could be done in debug builds.)

Josh
http://www.hydrogenaudio.org/forums/...dpost&p=568080


FIXED

Last edited by Dstruct; 03-05-2009 at 12:47 AM.
Dstruct is offline   Reply With Quote