View Full Version : SqueezeBox 2, Slimserver 6 and FLAC question

Josh Coalson
2005-04-01, 14:43
--- Steinar Bjaerum <steinar.bjaerum (AT) online (DOT) no> wrote:
> To extract a single track from an album-FLAC without complete
> transcoding,
> you suggest to re-encode only the first and last frame of the track
> on the
> server before streaming to the client, and stream the other frames as
> is.
> This means that the first frame would be shorter than the other
> frames. How
> does that relate to the "FLAC subset" format described at
> http://flac.sourceforge.net/format.html#subset where it is stated
> that to be
> truly streamable the block size should be constant?

it would not technically be 'subset' but the decoder should
still be able to handle it in this case. however due to a
bad design decision about the way the sample/frame number is
stored in the frame header, the decoder after receiving the
partial frame would not be able to rely on the sample number
decoded by libFLAC.

the problem is that FLAC either stores the sample number or
the frame number in the frame header, but not *which* one is
stored; that has to be inferred from other parameters, and
sending a shortened frame first breaks the inference model.
if I ever get to updating the format that will be one of
the first things I fix. for now, if seeking is all handled
on the server side by converting generic seek instructions
from the client to libFLAC seek calls on the server, which
serves back a valid FLAC stream, then the client probably
doesn't pay attention to the sample number returned from
the libFLAC decoder anyway, it just gets decoded samples and
plays them. hopefully soon I'll have a better understanding
of the protocol.

> I am not at all an expert on this, just an idea: Do you consider
> functionality for sample-accurate extraction of a track from a
> CUE-embedded
> FLAC to a separate standalone format compliant FLAC stream to be
> generic
> enough to be added to libFLAC? I know this can be easily done by
> using the
> index points to decode and then encode (as is currently done in
> SlimServer).
> I'm thinking about a more efficient method that could take advantage
> of the
> fact that both the input and output is FLAC.

hmm, maybe a frame-cutting interface would do the job. I've
thought about that in order to facilitate a FLAC-splitting
tool but have balked so far because of this design problem in
FLAC framing above.