PDA

View Full Version : SqueezeBox 2, Slimserver 6 and FLAC question



Steinar Bjaerum
2005-03-31, 10:41
Gordon Harris wrote:

>
> As a whole-disc/cue-embeded flac fan (I guess mostly because of my time
> investment in the format) I can live with the current Slimserver
> transcoding
> arrangement for the time being. I don't think I'd use any sort of track-
> ifying
> script, thank you.
>
> But, in terms of the need to use flac.exe to transcode individual tracks
> from
> flacs: I guess I'm just not getting what the problem is with writing the
> perl
> code to seek to the appropriate place in a whole-disc/cue-embeded flac
> file.
> (Forgive me if I'm speculating above my pay-grade here: I've never written
> a
> single line of perl code.) If a flac file has a cuesheet-metadata-block,
> flac
> version 1.1.2 allows one to use cuepoints to decode a portion of the flac
> file. So, rather than using the "-skip=mm:ss.ss -until=mm:ss.ss" command
> line
> form, one can use "-cue=n.n-n.n" to select a specific track/index range to
> decode. I assume that this means that flac.exe isn't having to use any
> sort
> of "time to byte-offset" calculation to seek to the appropriate section of
> the
> flac file. The cuesheet-metatdata-block includes sample offsets from the
> beginning of the flac audio stream for each track and index in the
> cuesheet
> metadata. Personally, I've never figured out how to convert a sample
> offset
> into a byte offset, but, how hard could it be?
>
> Sean? Vidor?
>

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!

Steinar

vidurapparao
2005-03-31, 11:26
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

vidurapparao
2005-03-31, 11:37
Vidur Apparao wrote:

> Steinar Bjaerum wrote:
>
>> .....
>> 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.

Sorry, that's "send the decoder the number of __samples__ to drop at the
start and end..."

--Vidur