Bugzilla – Bug 12565
TinySC can't play flacs with embedded cuesheets
Last modified: 2011-01-13 23:03:14 UTC
A back-burner issue: flacs with embedded cuesheets don't play well on TinySC. While the TinySC scanner parses the cuesheets just fine, the player doesn't seek to the correct track position within the flac to start playback. The current FatSC method for playing this type of content involves transcoding...which isn't slated to be supported in the initial release of TinySC. So, if TinySC could support transcoding in the future by including an arm compile of flac, that would be a bonus. Extra credit awarded if we could do away with transcoding for this format altogether. sbjaerum and Josh Coalson sketched out a method way back in 2005 by which SC and the SBs could nativly support. See the closed bug https://bugs-archive.lyrion.org/show_bug.cgi?id=1426 which discussed this.
I guess that there are two practical ways of doing this: (a) all in SC, (b) partly in the decoder. (a) would involve, as in the previous discussion, SC producing a FLAC stream with modified start and end frames. I looked at this with the existing perl/XS binding to libflac and came to conclusion that quite a bit of work would be required. I guess that the new scanner might make that easier, although still non-trivial. The existing 'initalAudioBlock' facility could be used to get the first frame correct. Something similar would need to be added for the final frame. (b) could involve SC telling the player to skip the first N samples and the last M samples (or play only Q samples in total). My guess is that this would be easy to do for SP but less likely to be backported to ip3k players.
This would be cool, but is it really worth the effort? Just split your single-album FLAC into multiple files. What is the point of keeping the album in a whole file? I don't think you will lose anything by splitting into per-track files.
Hummm...the effort... How much of the transcoding infrastructure have you guys torn out of TinySC? Would this really require much more than an arm compile of flac and a custom-convert.conf file?
It's all still there, although we start it with --no-transcoding so you'll have to modify the init script. We need to add a flac binary to our ARM build of 7.4.
Just for my own edification: is it your expectation that by starting TinySC with transcoding enabled, TinySC will grind to a halt because of the extra memory requirements? I'm trying to get a sense of what's at stake here. Anyway, if it's "easy" for you to build a flac ARM binary and point me to a link to it, I'll be happy to test this before you go to the trouble of formally adding it to the 7.4 build. I agree that if the results are at all marginal, it's probably not worth your time pursuing. Or, if building the flac ARM binary is possible for mere mortals like me, point me in the direction of the necessary tools.
I don't think the additional transcoding code in SC will be a problem, but running the transcoding process(es) may be. Only one way to find out.
This is the custom-convert.conf file that I use to keep flac to a single instance while transcoding: flc flc transcode * # FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d} [flac] -c --totally-silent --compression-level-0 $START$ $END$ $FILE$ So...only half the system resource hit than what the normal convert.conf flc flc imposes. As far as I know, the only reason for the flac | flac double transcoding in convert.conf is to gracefully handle those very rare and non-standard flac files that have inappropriate id3v2 tags rather than the officially supported vorbis tags.
Combining this with bug 11950 because the remaining work is common. *** This bug has been marked as a duplicate of bug 11950 ***