--- 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.


Do you Yahoo!?
Yahoo! Personals - Better first dates. More second dates.