--- 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. > 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. Josh __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
