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 _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
