All,
This mail is a survey to get some feedback about changes to the
FLAC Subset (see http://flac.sourceforge.net/format.html#subset).
FLAC hardware support is growing. The PhatBox was the first but
now there's the Rio Receiver, and FLAC is being worked into the
Audio ReQuest box, among others. Based on feedback from this
development I am contemplating restricting the subset a little
more.
The downside is that it's possible that people have generated
FLAC files according to the current subset definition that would
not be in the new subset definition. The upside is that this is
extremely unlikely (see below) and that the new subset would place
less demands on decoders that implement only the subset.
The changes I am thinking about are the following, and I note
the conditions under which an existing FLAC stream will 'break',
i.e. it was in the old subset and not new and so might not play
back on a newer subset decoder:
1. Limit the max Rice partition order in subset streams to 8.
The current limit is 15. This significantly reduces the
worst-case memory requirements on the decoder.
For this to 'break' an existing FLAC stream it must have
been encoded (via flac) with a -r value of > 8. None of
the -0 .. -8
options have ever exceeded -r 6 since flac 1.0,
so unless
you manually specify -r > 8 then the FLAC stream
will not
'break'.
2. Limit the max block size to 8192 or 16384 samples (I'm
leaning toward 16384 samples as tapers are starting to
use 96kHz). The current subset limit is 32768 samples.
For this to 'break' an existing FLAC stream it must have
been encoded (via flac) with a -b value of > 16384. None
of the -0 .. -8 options have ever exceeded -b 4608 since
flac 1.0.
3. Possibly limit the quantized linear predictor coefficient
precicion in a way that guarantees the inverse filter
requires only 32-bit math. This is currently the case for
16 bps but for 24 bps I would have to put an extra
restriction in place.
For this to 'break' an existing FLAC stream it must a
sample resolution >= 24 bits and have been encoded (via
flac) with -p or -q greater than 6 or so.
The bottom line is that if you use -0 .. -8 the streams would
still be in the new definition of the subset. I don't know
of any cases where people have strayed from -0 .. -8 but I
want to get more feedback before deciding on this. Has anyone
been using -r/-p/-q/-b this way? Would it be too disruptive to
restrict the subset now?
I should note that all hardware players currently use a
straight libFLAC which does the full format, but I don't
think they have tested their hardware against the memory
or processing demands of the full format (16bit 44.1kHz
stereo is the norm and pretty safe). My idea is to have
a subset so that up to 24bps/96kHz is feasible, finalize
it, and do a separate subset-only decoder, maybe under a
BSD license, that does no malloc and is more suitable to
hardware.
Josh
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
