Given a flac of an entire CD and a CUE sheet referencing the original WAV file, is it possible for an application such as a music player to seek to the beginning of individual tracks without first decoding the flac?

Foobar2000 can do this. I think the plugin is in the special installer. IIRC seeking isn't as responsive as with standard stuff, but when you load the cuesheet into the playlist you see all the individual tracks. It's the only player I know of that can do this, although I'm sure there are others.

Thanks. I wasn't looking for specific applications so much as I was just wondering if the structure of a flac encoded file supported seeking by time stamp or other parameter.

not sure I get the question but maybe this will help.

1) you can guess at the byte offset of the sample you want to decode, seek there, then start decoding. you probably will not hit the target sample exactly.

2) you can look in the seektable for a seekpoint at your target sample. if there is one you can seek and start decoding at that exact sample. if there is not a seekpoint you can at least use seekpoints to refine your guess at 1). if you are seeking to a track or index point start AND you imported the cuesheet to the FLAC file, there will be a seekpoint at each track and index start.

3) you can call the decoder's seek function which handles all this for you. any decoding it has to do will be done internally.

native FLAC does not have timestamps, it has 'sample-stamps' (like granulepos in Ogg) which can be converted to timestamps if you know the sample rate and the sample rate is constant.

Josh

Actually, this is a question that is sparking some interest on the slimdevices forums. Their new SqueezeBox2 device can natively decode flac streams coming from their SlimServer v6 software. However, in the case of multi-track flacs with cuesheet metadata, they are using flac.exe to transcode and stream the individual tracks to the SqueezeBox. This seems a little silly, though it works just fine. Us "whole-disc" flac folks feel like we're being penalized.

Given that one can parse the cuesheet metadata block and get sample offsets for all the track and index points, how hard is it to calculate byte offsets from the sample offsets so that one could seek to the appropriate place in the flac file? Am I missing something here, Josh?

it's trivial to get the byte offset for a track/index point from just the metadata if of course the cuesheet was imported. but it does require using the metadata interface if you want to do it without even setting up a decoder, and I'm not sure that the metadata interface was ported to the squeezebox2 since it's mostly for editing.

I just got a squeezebox2, and my whole CD library is in FLAC-image format, so this is something I'll be looking into.

Josh

Actually, all the "seeking" within the flac file would take place on the server side...in the SlimServer applicaion, so there isn't any need for the SqueezeBox2 to understand metadata. What I've gathered from what the SlimServer developers are saying is that the problem is with supporting both embeded cuesheet metadata and external CDTEXT/CDRWIN style text cuesheet files. Apparently, there is a feeling that implimenting seeking code in perl (which is what SlimServer is written in) that would find the appropriate sample offset in the flac file from a MM:SS:FF time offset in an external text CUE file would present real performance problems.

but only if the time offset did not already correspond exactly to a seek point the the FLAC file, which it will if the time is a track/index point and the FLAC had a cuesheet imported.

hmm, it should be possible to whip up a little proggie that just translated a timecode to a FLAC byte offset of the correct frame, plus that frames starting sample number (so you'd know how many samples to discard to get to the exact sample).

will join the forums there soon.

Josh

Though i am aware this could be seen as 'blatant adverstising' again, you could pack your FLAC files into matroska container, which is timestamp based, and strip the container on the server side. That means you had FLAC MKA files on the server, so you can seek to any place you like in no-time, and strip the container on the server side and stream only the pure FLAC files.

We do have code for this already, look the mkvtoolnix suite http://mkvtoolnix.matroska.org, and look at mkvmerge and mkvextract.

Christian
matroska project admin
http://www.matroska.org

P.S. matroska container will allow to attach CUE sheets as real files, but normally we 'translate' CUE sheets into chapter information, so every song is a chapter in the whole album file.