SqueezeBox 2, Slimserver 6 and FLAC question

[Steinar Bjaerum]

>
> Steinar Bjaerum wrote:
>
> > ...
> >
> >Is the FFWD/REW done by skipping to flac frame boundaries in the server
> >before streaming to the client?
> >
> >
> Yes, we do some rudimentary parsing on the server to find frame
> boundaries. This involves looking for a frame header sync mark and then
> confirming that the header CRC is correct. The existence of the CRC
> actually gives us a good confidence level that we're sending valid
> frames to the decoder on the box.
>
> The same technique is used for FFWD/REW for MP3, but MP3 frame headers
> don't contain a CRC value (at least not for the header itself), so you
> can sometimes hear squeaks and pops while scanning through MP3 tracks.
> Luckily the MP3 decoder on the box is very robust. :-)
>
> --Vidur

My follow-up question is then:
Is it feasible to get FFWD/REW for audio being transcoded to Flac on the
server.

Steinar

[vidurapparao]

Steinar Bjaerum wrote:

>>Steinar Bjaerum wrote:
>>
>>
>>
>>>...
>>>
>>>Is the FFWD/REW done by skipping to flac frame boundaries in the server
>>>before streaming to the client?
>>>
>>>
>>>
>>>
>>Yes, we do some rudimentary parsing on the server to find frame
>>boundaries. This involves looking for a frame header sync mark and then
>>confirming that the header CRC is correct. The existence of the CRC
>>actually gives us a good confidence level that we're sending valid
>>frames to the decoder on the box.
>>
>>The same technique is used for FFWD/REW for MP3, but MP3 frame headers
>>don't contain a CRC value (at least not for the header itself), so you
>>can sometimes hear squeaks and pops while scanning through MP3 tracks.
>>Luckily the MP3 decoder on the box is very robust. :-)
>>
>>--Vidur
>>
>>
>
>My follow-up question is then:
>Is it feasible to get FFWD/REW for audio being transcoded to Flac on the
>server.
>
>
Unfortunately, not. The implementation of FFWD/REW expects to be able to
seek on the handle to the audio source. For a local file this is
possible, of course. When we're transcoding, we open a pipe (or in
certain cases, a socket) to the transcoding application and it's not
possible to seek on a pipe/socket. In the long term, we can investigate
other options that allow us to seek in more cases, such as:

1) Use a Perl package such as Audio::FLAC::Decoder to do the transcoding
and not require a pipe. In fact, if we used this package, we could
probably avoid doing FLAC->FLAC transcoding for cusheets and just do a
time-based seek directly. This option might not make sense for other
types of transcoding since we may still need to open a pipe to other
transcoding applications.

2) Do server-side audio processing to speed up the stream. This would be
done after the transcoding process and we wouldn't need to seek.

--Vidur