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

Steinar Bjaerum
2005-04-01, 08:58
> --- Vidur Apparao <vidur (AT) slimdevices (DOT) com> wrote:
> > Steinar Bjaerum wrote:
> >
> > >..
> > >
> > >Please correct me if I am wrong, but:
> > >
> > >The Flac file consists of frames which are the smallest entity that
> > can be
> > >decoded independently. The Seekpoints in the SEEKTABLE metablocks
> > are
> > >located at frame boundaries. The start sample of a track is
> > typically
> > >located in the middle of a frame. In order to start playing a track
> > at the
> > >correct position, the entire frame containing the start sample of
> > the track
> > >needs to be decoded, and the samples in the frame prior to the track
> > start
> > >sample needs to be thrown away (these samples belong to the previous
> > track).
> > >Similarly, the frame containing the end sample of the track needs
> > special
> > >treatment.
> > >
> > >It is feasible to let Perl parse the SEEKTABLE and have the server
> > start
> > >streaming at the frame containing the start sample of the track.
> > However,
> > >the Flac decoder in the client needs to get additional information
> > about the
> > >samples that need to be thrown away after decoding the frames
> > containing the
> > >start and end samples of the track. This means that it is not just a
> > Perl
> > >parsing job that has to be done in order to avoid transcoding the
> > cued
> > >Flacs. However, I'm sure the guys at SlimDevices can do it!
> > >
> > >
> >
> > You are absolutely correct. If we did cuesheet-based seeking within
> > the
> > server, we'd have to start streaming to the SB2 from the start
> > position
> > of the frame *and* send the decoder the number of frames to drop at
> > the
> > start and end of the stream.
> >
> > Thanks for your vote of confidence. ;-)
> > --Vidur
> sorry I'm late to the party (I'm the guy who started FLAC),
> just recently joined the lists. I missed most of the context
> but is there something I can answer or maybe add to flac
> that would facilitate cuesheet support? I'm still coming up
> to speed on the code and workings of slimserver/squeezebox,
> so I'm not sure how cuesheet-based seeking works, but another
> possibility is to decode/chop/reencode any partial start/end
> frame on the server side. (as long as there was a mechanism in
> perl to do this.) that way the seeking protocol would not
> have to be changed.
> Josh


Having the possibility of contributions from you, Sean will hopefully not
pursue the idea of abandoning support for whole-album CUE-embedded FLACs,

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?

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.