Bugzilla – Bug 1426
Client-side decoding of tracks from whole-album Flac files
Last modified: 2010-04-15 17:21:40 UTC
Currently there is done a Flac->Flac transcoding in the server for whole-album Flac files with embedded cuesheet. It would be advantageous to stream tracks in such Flac files directly without this transcoding. Most importantly, without transcoding, it would probably be easier to implement Fast FWD/RWD for audio encoded as whole-album Flac. This is the main reason for me to request this enhancement in functionality. Secondly, getting rid of the transcoding would lower the CPU load of slimserver. At http://forums.slimdevices.com/showthread.php?t=13343 there is a discussion with Josh Coalson about streaming individual tracks from whole-album Flac files. Useful information can be found there, may be most relevant for this issue: > > So a decoder which has as only task to sequentially decode the frames > > as > > they appear in the FLAC stream will be able to handle the > > variable-sized > > input frames. From the frame headers the decoder can extract the > > (variable) > > sizes of the frames and decode them properly. I guess problems can > > occur if > > the decoder relies on the size of the first frame to allocate buffers > > etc. > > The discrepancies in the sample/block number in the frame headers > > will not > > be a problem as long as the decoder will not perform searches in the > > stream. > > Am I correct? > > yes, all correct. (Josh Coalson) This means that by manipulating at the server side the first and last frames which contains the track boundaries, it would be possible for the Flac decoder in SB2 to decode the incoming stream. It should also be possible to skip between Flac frames in the server in order to get Fast FWD/RWD.
Just tried to reduce length of bug description title in order to be more readable in bug list.
Doubtful for 6.1, but Vidur may correct me.
just revisiting this... this one solution proposed was I think to have flac be able to take an image.flac and produce a FLAC file for a single requested track, is that right? this is problemating to do by splicing for the reasons mentioned. but if the protocol allows the client do ffwd/rew (i.e. seek) through FLAC, why can't it open the FLAC file on the server and seek to the track start sample? this will be in the CUESHEET block and FLAC seeking is sample-accurate. Josh
No comments for Josh's question?
I will not have time to get to this for 7.2. It requires some careful design and is related to use of CUE sheets in general (not just FLAC ones).
This is a request for a method of achieving a feature, rather than a feature itself. The features of sample-correct play of tracks from whole-album FLAC files, including scanning (FFWD/REW) is available in SC7.3. Marking this as fixed. Please open a new enhancement request if you specifically want to for transcoding-less support of these features.
Fixed - Closed Message (SC) This bug has been fixed in the 7.3.3 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Alan: have you verified that the 7.3.3 flac | sox transcoding actually works on limited horsepower hardware, i.e. the ReadyNAS? Respectfully, the bug enhancement request was NOT, as you say, a "method of achieving a feature, rather than a feature itself". Citing FF/RW was to merely point out ONE advantage of eliminating server side transcoding for this format, NOT the only advantage. I appreciate the work you've done here to alleviate this particular symptom. But I stand by my original request that this audio format get full support from SqueezeCenter and not be kept in the transcoding ghetto. I'm asking that this bug be reopened, please.
I'm sorry that this is what you needed but it was not clear from the report. No, I have not specifically tested this on a ReadyNAS but I know from the results of tests by others that it will very likely not work. However just flac decoding and then streaming as WAV does work on the ReadyNAS and provides the same overall functionality at the expense of rather more LAN bandwidth. The custom-convert.conf file that gets distributed with the ReadNAS build disables the flac|sox pipeline in favour of just flac. I beleive that this should do what you need. Actual client-side processing of this type of functionality is not going to happen. The player hardware does not have the capacity for it. The native support in the players is for MP3, FLAC, WMA, PCM and Ogg with each data stream played in its entirety. All other capabilities and formats are provided by SC, mostly via transcoding. Technically I can see that it could be possible to support what you want in SC with less overhead than that used by the transcoding process. Whether this would be sufficiently less to facilitate these capabilities on a ReadyNAS I cannot say.
My assumption all along is that any changes to fully support this format without the need for transcoding would happen in SC's code, not in the player firmware; i.e. a pure perl solution. Any changes to player firmware, I've assumed, would come from changes that Josh Coleson might make to libFlac (portions of which, I'm guessing, are incorporated in the firmware.) Again, my motivation here is simply to see this format "fully" supported. I'm not saying that there is anything wrong, per se, with SC's current support for flacs-with-embedded-cues. In fact, it's working really, really well for me. Again, thank you for your recent work to make FF/RW possible with this format. That said, it does seem that some of the current handling still smacks of being a kludge...not just in terms of the need for transcoding, but also in terms of how cuesheets themselves are handled. (E.G. I believe that there are still places in the code where cuesheets are treated as playlists, rather than as "albums".) Perhaps it's just an inferiority complex on my part, but it still feels as though flacs-with-embedded-cues are second-class-citizens in SC land. So, my request to re-open this is really just a plea to keep this on the farthest back-burner...say, target this for SqueezeCenter 11? If you guys aren't willing to do that, then I'll just have to seek more therapy for that inferiority complex thing.
Correction: SqueezeCenter version is 7.3.2
Reduce number of active targets for SC
Quick note for history's sake: Andy Grundman has resolved this issue and made flac+cue transcodeless in svn 30619 as part of resolving bug 11950. Flac+cue is now supported natively and is no longer a 2nd class citizen.
Wow.