PDA

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



Steinar Bjaerum
2005-04-04, 11:55
Josh,

Thanks a lot for your precise answers to the FLAC questions. Getting answers
right from the source is great.
One last question, do you use separate FLAC files for each track, or do you
use whole album encoding with embedded cuesheet?

Steinar

> -----Original Message-----
> From: discuss-bounces (AT) lists (DOT) slimdevices.com [mailto:discuss-
> bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Josh Coalson
> Sent: 4. april 2005 19:45
> To: Slim Devices Discussion
> Subject: [slim] SqueezeBox 2, Slimserver 6 and FLAC question
>
> --- Steinar Bjaerum <steinar.bjaerum (AT) online (DOT) no> wrote:
> >
> > - 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?
>
> yes, all 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?
>
> almost; in addition, for every frame you will have to get the
> encoder to store the blocksize in the header (blocksize bits =
> 0110 or 0111, c.f.
> http://flac.sourceforge.net/format.html#frame_header) to get
> the variable-blocksize logic to kick in, which the current libFLAC
> does not do because it is currently designed for fixed-blocksize.
> it uses blocksize bits 0001-0101/1000-1111 whenever possible
> (using only blocksize bits 0110/0111 for the last frame in a
> stream, or 0000 for --lax streams when the blocksize cannot be
> represented by blocksize bits 0001-0101/1000-1111).
>
> I really regret storing frame numbers in the frame header instead
> of just sample numbers but at the time I was trying to shave off
> bits everywhere.
>
> > 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?
>
> it will be faster but maybe not enough to be worth it. if speed
> is of the essence, 90% of the compression can be had with flac -0
> or flac -1 which encodes at 9-10x realtime on a PII 300MHz.
>
> Josh
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Personals - Better first dates. More second dates.
> http://personals.yahoo.com
>
>

Gordon Harris
2005-04-04, 17:42
Josh Coalson <xflac@...> writes:

>
> I use single file with embedded cue for CDs. all my metadata is
> in an external DB and I've been using custom s/w with a rio receiver
> for playback. now that I have a SB2 to play with I want to look
> into how to do the same thing (even if it means I have to tag
> the FLACs somehow).
>

Josh: I've been working on some c code to extract metadata from CDPLAYER.ini
and create cuesheets. It also stuffs the cuesheet into a "cuesheet=" comment
in the flac and then calls metaflac to import the cuesheet into the flac. I'm
sure you could modify the code to reference the metadata in your db. The code
isn't quite ready for a real release, but it's yours if you want it.