|
|
|
04-15-2008, 02:05 PM
|
#41
|
Administrator
Join Date: Jan 2005
Location: NYC
Posts: 15,721
|
Quote:
Originally Posted by Dandruff
|
Doesn't help us much, probably would help the flac devs...
|
|
|
04-21-2008, 03:29 PM
|
#42
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
It's fixed in Foobar2000 version 0.9.5.2!
|
|
|
04-21-2008, 08:16 PM
|
#43
|
Human being with feelings
Join Date: Jan 2007
Location: Underworld
Posts: 1,188
|
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.
Cheers!
Last edited by DuX; 04-21-2008 at 08:18 PM.
|
|
|
05-30-2008, 01:44 AM
|
#44
|
Human being with feelings
Join Date: Jul 2006
Posts: 12,480
|
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.
|
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 07:17 AM.
|