--- embeddeddev <embeddeddev@yahoo.com> wrote:> Hi,
>
> we are implementing FLAC decode on an embedded device.
> FLAC, as you know, can have block sizes up to ~65K.
> For an embedded implementation, memory is limited: what would be the
> maximum block size we should support?
> We have seen the encoder encodes either 1152 or 4608 in its default
> setup. Should we support other block sizes?
currently users have to go out of their way to use a blocksize
other than 1152 or 4608 because those are the only sizes used
by the presets. I don't know of any software or users creating
files with other blocksizes.
the first support target for FLAC is the subset:
http://flac.sourceforge.net/format.html#subset
it was specified with embedded devices in mind. users again
have to go out of their way to create files not in the subset
and this causes a big warning. so all files that I know about
are subset files.
the subset limits blocksizes to 32768 max but embedded
implementations can lower the limit at their discretion.
since blocksizes over 4608 tend to yield worse compression and
you have to go out of your way to create such a file, it's
pretty safe to disallow if necessary.
> Also another unrelated question:
> given most existing files don't have a seek table in their metadata,
> what would be the right and easy to way to compute the byte offset
> corresponding to time T in the file?
> Obviously, we are looking for a way not to have to decode all the
> frames before...
actually most files do have a seek table since they are added
by default.
absent hints from the seek table, a search algorithm is needed
to find a frame, where you guess at a landing spot, resync on
a frame, decode the frame header and see how close you got, then
adjust your guess and repeat. see
src/libFLAC/seekable_stream_decoder.c in libFLAC for an example.
Josh
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com