Bugzilla – Bug 750
Gap between songs while using FLAC
Last modified: 2008-12-18 11:55:35 UTC
Im geting gaps between songs while playing back FLAC files on the Squeezebox, this happens on every album, but its noticeable the most (obviously) on live albums. . I have my cds converted to FLAC (one file per album). I have external cuesheets, but I also have the cuesheets embedded into the flac files. The bit rate limiting is set to NO LIMIT for the Squeezebox. Im running the nightly update of the future 5.4.1 version.
the external cuesheet will effectively break teh FLAC file into tracks. Since each track must be converted to WAV by an ouside process, the gap is produced by the time it takes to start a new process for each song. The only way to possibly to this gapless would be the creation of a special case when a FLAC split by cuesheet is played in its entirety, and in order. Thus, the server would simply play the single file, start to finish and updating meta info with the cue sheet data at the required intervals.
I imagined that something like that was going on , thanks. Is there any chance that kind of change you mentioned to be added to SlimServer? I have many live recordings, and also many classical recordings will highlight this issue (opera, etc), thus preventing some audiophiles or classic music lovers to join the boat.
Ideally, the behaviour should be something like: 1) if a whole album is chosen, then the whole flac file should be played back, no gaps 2) if a particular song is selected, and the option to play other songs from the same album is selected, then the flac file should be played back, without gaps, starting at the selected song, until the file ends. Dont know how feasible is that, but thats what I would expect when trying to listen to a live recording disc, or similar.
As a tangent, I imagine that differentiating "album" mode play from "individual songs" could come in handy for dealing with cross-fading as well (when that becomes available).
I'm a bit surprised that, if kdf's theory is correct, it really takes longer to start a new decoding process than the player buffer can accomodate. While the solution proposed here would definitely be a good optimization, I'm a bit skeptical that it would cause/prevent an audible gap on all but the slowest systems. Is it possible that something about the way we're ending one decode and starting the next isn't matching up quite right?
dont get freaked by my theories...it was complete speculation. I'l spit out anything in my head in case it might actually spark an idea from someone with a working brain :)
I buy kdf's theory. FWIW, this is significantly better with SB2, since we don't transcode. Pushing the correct fix for SB1 (we should not create separate streams for consecutive tracks) to post 6.0.
I'm sure this change would certainly fix the issue, whichever explanation is correct about the cause. And I think this change is certainly worthwhile for a number of other possible features as well (crossfade, track vs. album replaygain, pregap handling, etc.). I've got the beginnings of a few flac/cuesheet changes that I'm holding onto until after 6.0 branches, which could tie into this as well.
I don't think that there is a fix for this, except a faster machine. If the buffer runs out in the player while launching a new instance of the transcoder then you'll hear a gap. One possible optimization in the case that you are using cue sheets would be to convince the flac decoder to open the contiguous section and stream that. Unfortunately, this would make it hard to make the progress indicator work correctly.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.