Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Thread Tools Display Modes
Old 04-15-2008, 02:05 PM   #41
Justin's Avatar
Join Date: Jan 2005
Location: NYC
Posts: 12,964

Originally Posted by Dandruff View Post

here a new reply from the foobar2000 developer:


Is this helpful?

Doesn't help us much, probably would help the flac devs...
Justin is offline   Reply With Quote
Old 04-21-2008, 03:29 PM   #42
Human being with feelings
Join Date: Jul 2006
Posts: 12,341

It's fixed in Foobar2000 version!
Dstruct is offline   Reply With Quote
Old 04-21-2008, 08:16 PM   #43
Human being with feelings
DuX's Avatar
Join Date: Jan 2007
Location: Underworld
Posts: 1,097

Many thanks Dandruff for such dedication to hunting bugs such as this.

And I updated Foobar. We have a peak meter again, yay! Brilliant player.


Last edited by DuX; 04-21-2008 at 08:18 PM.
DuX is offline   Reply With Quote
Old 05-30-2008, 01:44 AM   #44
Human being with feelings
Join Date: Jul 2006
Posts: 12,341

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

Originally Posted by Peter (Foobar2000 developer)
Looks like I accidentally left the fix active in 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.

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

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.)



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

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT -7. The time now is 12:51 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.