Hi All,
I am designing flac decoder for an embeded aplication.The flac document gives some information about the maximum size of uncompressed size for the subset(I think present encoder support only 16384 MAX_BLOCK SIZE)(http://flac.sourceforge.net/format.html ).I need to fix the maximum frame size(Compressed data) independent of streamss.
Can any one suggest,How to calculate maximum frame size before decoding
Regards,
Raghunath.K.P
Unless I'm mistaken, it is theoretically possible for the lossless compressed data to be larger than the uncompressed. Lossless compression relies on some redundancy in the data to achieve compression. If there is no redundancy then there is no compression. Hopefully nobody is going to compress random data, but theoretically that could happen.
Unless I'm mistaken, it is theoretically possible for the lossless compressed data to be larger than the uncompressed. Lossless compression relies on some redundancy in the data to achieve compression. If there is no redundancy then there is no compression. Hopefully nobody is going to compress random data, but theoretically that could happen.
you can refer to ffmpeg s implementation.
here
http://www.ffmpeg.org/doxygen/trunk/flac_8c_source.html (http://www.ffmpeg.org/doxygen/trunk/flac_8c_source.html)
Unless I'm mistaken, it is theoretically possible for the lossless compressed data to be larger than the uncompressed. Lossless compression relies on some redundancy in the data to achieve compression. If there is no redundancy then there is no compression. Hopefully nobody is going to compress random data, but theoretically that could happen.
Bar container or metadata features that would take up some space, a compressed format could have 'uncompressed' as special case. Regarding the OP's question, FLAC can specify a block as VERBATIM (i.e. uncompressed) at size up to 16384.
But there is nothing in the FLAC specification that prevents an encoder to overlook the VERBATIM option and write a predictor+residual block with stream larger than uncompressed? Then the question is, would any (widespread) FLAC encoder actually do this?
But there is nothing in the FLAC specification that prevents an encoder to overlook the VERBATIM option and write a predictor+residual block with stream larger than uncompressed? Then the question is, would any (widespread) FLAC encoder actually do this?
The official FLAC tools have the undocumented option "--disable-verbatim-subframes" which is used for testing, to force the encoder to encode whatever signal with predictors. I know two similar option that are used by dBpowerAMP, --disable-fixed-subframes and --disable-constant-subframes to generate "uncompressed FLAC" (only to store metadata), which is of course BS, but still, these options are out there and can be used. So, if you need the maximum length to protect against buffer overflows or something like that you might not want to rely on it. If it just chrashes the decoder I wouldn't try to fix it, because if it happens, the user probably tries it on purpose. I can't see a reason to do this.