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

Steinar Bjaerum
2005-04-02, 00:06
- Josh Coalson wrote:
> --- 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.
So a decoder which has as only task to sequentially decode the frames as
they appear in the FLAC stream will be able to handle the variable-sized
input frames. From the frame headers the decoder can extract the (variable)
sizes of the frames and decode them properly. I guess problems can occur if
the decoder relies on the size of the first frame to allocate buffers etc.
The discrepancies in the sample/block number in the frame headers will not
be a problem as long as the decoder will not perform searches in the stream.
Am I correct?

> > 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.
Assuming the track is to be extracted to a separate file, not necessarily
intended for streaming. Would it work to modify the STREAMINFO header
properly, i.e. indicate variable sized blocks etc, then reencode the first
and last frames to get correct track start and stop, and finally modify the
headers of the frames in the middle with the correct sample numbers?
If done properly, will such a solution result in a file compliant with the
FLAC format?

I know that the CRCs have to be recalculated because of the modified
headers, but the actual FLAC encoding could be kept unchanged for all the
blocks except the first and last. What gain in efficiency can be expected
with such a solution compared to a compete re-encoding of the track?