--- Steinar Bjaerum <[EMAIL PROTECTED]> wrote: > > - Josh Coalson wrote: > > > > --- Steinar Bjaerum <[EMAIL PROTECTED]> 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 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
