Bugzilla – Bug 11950
TinySC: Album FLACs with cuesheet not working
Last modified: 2011-05-09 13:52:41 UTC
I am currently using version 5578 of fab4 firmware. My music collection is stored as whole album FLACs with embedded cue sheet. The albums are tagged using the scheme parsed with the function _getNumberedVCs in FLAC.pm. Music stored this way is not working very well with TinySC. The name of the album and artist appears correctly when browsing the music library. The album also seems to be divided into the correct number of tracks, but the track titles are empty. When pressing play on a track, the playback always starts with the first track in the album.
Created attachment 5178 [details] Whole album FLAC file with audio data removed Example of a whole album FLAC file with audio data removed. All the cue sheet and tagging information is present in the file. Might be useful when working on this bug.
Fixed in change 27094.
I am now at 6209. The scanner now recognizes all the tracks in the album. But whatever track is selected, the playback starts at the beginning of the first track in the album instead of at the selected track. It looks like the track position within the album flac file is not used by the flac decoder.
For Fat-SC, FLAC->FLAC transcoding is used to cut the relevant segment from the file, re-framing as necessary so that it is sample-perfect. There is no transcoding in TinySC. The standard FLAC library allows for sample-perfect location of the beginning of a portion of a stream (FLAC__stream_decoder_seek_absolute, Audio::FLAC::Decoder::time_seek()) but there in no method to cause decoding to stop at some desired endpoint. But even with this limitation, it may be possible to support sample-perfect cue-sheets by implementing the FLAC decoding in TinySC using Audio::FLAC::Decoder and streaming WAV/PCM to the player, stopping after the appropriate number of samples have been streamed.
This would be quite a bit of effort. We need to question how important it is to support whole-album FLAC files with CUE sheets in TinySC.
Why can't the --skip and --until arguments be used for flac decoding?
(In reply to comment #6) > Why can't the --skip and --until arguments be used for flac decoding? Because we cannot afford to run the flac process.
*** Bug 12565 has been marked as a duplicate of this bug. ***
I've improved the seeking in Audio::Scan for FLAC so it is *almost* perfect in that it seeks to the right frame containing the desired sample. Unfortunately the --skip/--until params do additional decoding to get to the *exact* sample required. The Audio::Scan version may be up to ~9.5ms of audio off the mark. This may be good enough for TinySC.
Andy: do you know of a wave file of a frequency sweep? I'll encode that into a test flac with an embedded cuesheet. That ought to be a good test, don't you think?
The other option is what Alan and I have discussed before, which is to stream only the original FLAC and change only the "virtual" track that is displayed while playing. This would be gapless and seeking would work properly, but may be a lot of work.
"Gappy" is a great first step, as far as I'm concerned. Here's a freq sweep gapless test flac: http://www.hegardtfoundation.org/slimstuff/GaplessTest.zip It's 2mb.
It is a very good idea to try a simplified solution. Just one comment to the timing error of ~9.5ms mentioned in comment #9 above: It is my understanding that the default blocksize is 4096 for CD music with sampling frequency 44.1kHz. One block would therefore have a duration of ~93ms. I would think the maximum timing error of track boundaries would be half of this if the closest block boundary is used as track boundary?
You're right, my math was wrong. :)
As far as I understand, your proposed scheme would give perfect gapless playback of consecutive tracks from he same albums. It will be interesting to hear how annoying the non-perfect track start/stop will be for a random playlist. I bet it will be acceptable.
Yeah we need to try it out and see.
Andy: is there a way for us to test your changes in r28813 in 'FatSC'? e.g. turn off transcoding for flacs-with-embedded-cues? Or does more work need to be done first?
A lot more work would have to be done first before we can test this. We'll get to this soon though.
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Moving P3 and lower bugs to next release target
Created attachment 6782 [details] Preliminary patch for native cue support Good news, I got this working! I realized that we were already doing exactly this for MP3 CUE sheets, so it was a mostly simple matter of adjusting the CUE anchor processing code to correctly determine the byte offsets using Audio::Scan. Now FLAC CUE files can play natively just like MP3. I didn't have time to rip a gapless album to test if it's gapless or not, will do that tomorrow. This should also fix some issues with Ogg Vorbis cue sheets. Will also need to test AAC/ALAC cues too, they probably need the same thing. There is still a bug in that you can't seek in anything but the first track (actually you can, but it seeks from the start of the file), but I believe this is not much more work to solve. The same thing is also broken for MP3 so the same fix will fix both formats.
Andy: my gapless test file posted to http://www.hegardtfoundation.org/slimstuff/GaplessTest.zip is still available. I'm also posting another gapless test flac with real music rather than the tone sweep that's in the 1st one. This is an actual ripped CD with lots of index points but with continuous music. My internet connection is way slow, so it will take three hours to post. When it's there, it will be http://www.hegardtfoundation.org/slimstuff/GaplessTest2.zip
== Auto-comment from SVN commit #30619 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=30619 == Fixed bug 11950, use native playback for FLAC CUE sheets, transcoding is no longer needed. Note: a full rescan is required
BTW I didn't mention, FLAC is still gapless with this method.
This sounds really, really great. I have limited time to spend on testing at the moment, but will try to do some testing once the appropriate 7.6 nightly becomes available. One question. When comparing transcoder/transcoderless flac+cue, is there an easy way to disable/enable the transcoderless method? I couldn't see a way of doing this in convert.conf...
The flc->flc transcoder method has been removed, there's no reason to have it anymore.
Removed just for cue sheets I mean, it's still used for things like resampling.
So that is a consequence of the changes you made in CUE.pm?
There was a hack in place in the TranscodingHelper.pm that forced transcoding for FLAC CUE URLs, so that was removed. Why are you concerned about needing the old transcoding method? The new way is much better! :) Also the old code did a horrible job of guessing the right FLAC offset by only using the average bitrate, the new one is sample-accurate, so the points in the CUE will actually be correct now. As a bonus this also works for Ogg Vorbis, and should work for AAC/ALAC once a few other things are fixed. I also found out that I've broken some other things such as AIFF->FLAC/WAV->FLAC transcoding though so I'm going back through and testing everything.
The cue sheet contains sample accurate track boundaries as defined on the CD. It is my understanding that in order to get transcoderless, the track boundaries are moved to the nearest FLAC frame boundaries. This will be perfectly fine when playing consecutive tracks from the same album. However, this method might include a fraction of a frame from the previous track at the start of a track. When having a playlist of unrelated tracks, this has the potential of generating some clicks/pops at track transitions. I doubt the problem will be severe, but it would be nice to have the chance of comparing the new approximative method to the old sample perfect method. Don't misunderstand me, I'm really pleased with this development!
I don't think there is any chance of getting clicks/pops as the stream will always start on a frame boundary. In fact, the FLAC decoder doesn't appear to even work at all if you send it data starting in the middle of a frame, which I found a bit surprising, although this could just be a firmware bug that we've never ran into as we always send FLAC data correctly.
Ok, testing with 7.6 trunk, svn 30624 on a Fedora 12 box, SQLite for the db, music library located on a NTFS formatted 2T disk. Transcodeless flac+cue playback seems to be working perfectly for me. Consecutive tracks in an album appear to play back perfectly gapless. Playing a collection of tracks from 5 different albums (by searching on "Tander" and then playing all) seems to work perfectly. No discernible start or end of track artifacts. I'll keep kicking the tires on this, but I think you've NAILED it, Andy. I've been waiting 5 years for this moment. Congratulations, and thank you very, very much!
Awesome!
So...how do I test on the Touch? When will there be a SqueezeOS update for the Touch that incorporates this fix?
The next nightly will have it. BTW I've been testing a bunch of cue sheet stuff today, here is the current status of the other formats on 7.6: FLAC: works + seeking, gapless Ogg: works + seeking, gapless MP3: works + seeking, not gapless AAC native: works + seeking, gapless AAC->FLAC: partial + seeking, start works, but faad needs end support ALAC native: works + seeking, gapless ALAC->FLAC: partial + seeking, start works, but faad needs end support WAV native: works + seeking, gapless WAV->FLAC: works + seeking, gapless AIFF native: works + seeking, gapless AIFF->FLAC: works + seeking, gapless WMA native: works + seeking, not gapless, offsets are wrong (Audio::Scan bug) WVP->FLAC: works + seeking, gapless
I am not concerned about artifacts caused by the implementation. I trust that given the samples streamed to the decoder, the playback is bit perfect. What I am concerned about, is the inherent effect caused by misalignment between album track boundary and FLAC frame boundary. I have tried to explain what I mean below. Hopefully the effect is negligible in practice. Album track transition at end of track 1 in playlist: Sample values, time is downwards -8 -6 -4 -2 0 0___FLAC frame boundary closest to track boundary 0 0___Track boundary 0 0 0 0 1 3 5 7 9 Album track transition at start of track 2 in playlist: Sample values, time is downwards 10 9 8 7 6___FLAC frame boundary closest to track boundary 5 4 3 2 1 0 0___Track boundary 0 0 1 2 3 4 5 6 7 8 9 10 Resulting playlist track transition between track 1 and track 2 in playlist: Sample values, time is downwards -8 -6 -4 -2 0 0___Playlist track transition occurs here. 5 | 4 | 3 | A short pop caused by misalignment of album track and FLAC frame boundary. 2 | 1 | 0 0 0 0 1 2 3 4 5 6 7 8 9 10
Well, when playing tracks in sequence the decoder should be getting both sides of the split which would make it gapless. If not playing in sequence, it's probably not something you would notice.
I think the default FLAC framesize is 4096. For CD audio sampled at 44.1kHz, this means that a default frame is approx 0.1s. The maximum mismatch between the album track boundary and the closest FLAC frame boundary is half the framesize, i.e. 0.05s. Hopefully this is short enough for this effect to be negligible.
Andy: I know this bug is marked fixed, and, for the most part, the fix is working very, very well for me. But I'm running into occasional cases with 7.6 FatSC where it seems to choke on some of my flacs. And unfortunately, the nature of the choke is inconsistent. Example: I have a flac that plays perfectly in FB2k and with SC 7.3.4 (transcoding) and who's metadata checks out in every regard. But with SBS 7.6 on windows, the last track is not playable. On linux, the last track cuts off prematurely. Three questions: 1). Even though this bug is marked fixed, are you getting CCed on this? 2). Does it make sense to reopen this bug and let it be a catch-all for weird, edge cases like the above? 3). Can you suggest a way for us to get the problem flacs to you? Typically, they weigh in at 300mb. Is there a slimdevices ftp resource (or something) that we could post to anonymously or otherwise?
Sure I suppose you could reopen this bug. I will setup an FTP tomorrow, I do get tired of not having an easy way for people to send me large files. Thanks for testing!
Thanks for that. I don't think I have the ability to reopen this. At least I don't see any way to do it.
Reopening.
I've setup anonymous FTP on my server at hybridized.org. It allows upload but not download, etc. Put files in the incoming directory.
== Auto-comment from SVN commit #674 to the opensource repo by agrundman == == http://svn.slimdevices.com/opensource?view=revision&revision=674 == Bug 11950, workaround a very odd Win32+filehandle bug where file pos would sometimes be off by one after a PerlIO_read
Oops, posted to the wrong bug. Gordon can you upload your file to me? http://wiki.slimdevices.com/index.php/Large_File_Upload
I'll upload it in a day or two as soon as I can borrow some bandwidth in town. Living out in the sticks, with flaky satellite internet access, has it's limitations.
Andy: I'm uploading two problem files to your ftp server, though it's going to take about 6 hours to do so with my poky internet connection. The files are wgh_test1.zip & wgh_test2.zip. With both files, SBS 7.6 (on Fedora 12 & Windows 7) has trouble playing the last track in the file. In both cases, playback cuts out about 10 seconds or so before the track is complete and playback jumps to the next album in the playlist. Also, I notice that both the WebUI and the SBTouch UI fail to display the last track after transitioning from the penultimate track in a playlist. This is probably a separate bug, though. As far as I can tell, there is nothing special about these files in terms of their metadata or anything else. I've dumped the metadata from these files and I'm uploading that, zipped, too. I'm noticing this "trouble with the last track" with about 1/10th of my files. I don't have any sort of an idea, as of yet, as to what might be causing this. My ripping method is extremely consistent, so I'll be surprised if you determine that these files are damaged in some way and that that is the cause of the "last track" problem.
Thanks I will take a look at these files.
It appears the problem is that Audio::Scan is finding a false-positive FLAC frame when seeking for the final end point of the last track and gets the wrong byte offset value. I need to review my code against the official code to make sure it's checking the frame header correctly.
In comment 49, Gordon wrote: "Also, I notice that both the WebUI and the SBTouch UI fail to display the last track after transitioning from the penultimate track in a playlist. This is probably a separate bug, though." Is this a general problem, or is it a problem only for the albums with incorrect playback of the last track?
== Auto-comment from SVN commit #30726 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=30726 == Fixed bug 11950, the last track in a cue sheet should always extend to the end of the file, no need to use findFrameBoundaries on it
"Is this a general problem, or is it a problem only for the albums with incorrect playback of the last track?" When I'm back home in a few weeks, I'll try to figure out when I'm seeing this behavior. If I see this with any sort of consistency, I'll file a new bug. Thanks.
Andy: I see that you've marked this bug as RESOLVED/FIXED. I'm running 7.6 svn 30813 and I'm still seeing the same "can't play the whole last track" behavior. Is a whole library rescan necessary to effect the bug fix?
Yeah, do a complete rescan.
OK, your fix plus the wipe & rescan seemed to solve the premature end of the last track problem. I'm uploading a YAPF (yet another problem flac) file to hybridized.org/incoming: YAPF_wgh_20100523.zip Problem with this flac: SBS 7.6 won't continue playing past track 7. Track 8 never starts. Attempting to manually play track 8 results in track 9 being displayed as playing..but in fact track 1 plays. This happens for tracks 12 & 13 too. Flac -t -s -c reports no problems with this flac file and the metadata all checks out. Sometimes, but not always, this message ends up in the server.log: [10-05-23 15:59:19.5854] Slim::Player::Protocols::File::open (190) Error: could not seek to -1 for /mnt/media/Music/c_Early_Baroque/Monteverdi, C/Messas - Ensemble Vocal Européen de la Chapelle Royale, Philippe Herreweghe.flac: Invalid argument This isn't the only flac file I'm now seeing with this problem. I'm not sure, though, if this behavior is new, new, or just 7.6. I wasn't seeing this with 7.4.3 with transcoding with these flacs.
I am sorry to report that I see the exact same issue with at least one of my files.
I only got the file YAPF_wgh_20100523_metadata.zip, can you try uploading it again?
Reopening...
I have uploaded The_Only_Ones-The_Only_Ones-1978.flac to your ftp server. Some observations with this file: 1. Start playback of album from the start. 2. Track 1 and 2 plays fine. Playback stops when transitioning to track 3. 3. When trying to play track 3, error message pops up on Radio display. Playback of track 1 starts. Radio display and web interface indicates that track 4 is being played back. 4. Track 4 won't play. Similar symptoms as with track 3. 5. Tracks 5 and 6 play OK. 6. Tracks 6, 7 and 8 won't play. 7. Tracks 9 to 13 play OK.
Sorry. It takes about 3 hours per attempt at 25kbs to upload. I tried twice yesterday and I'm trying again now. If this latest attempt doesn't work, I'll try again later in the week when I can get to the big city and steal some bandwidth.
Sorry, yeah I know how it is... thanks for taking the time to upload.
== Auto-comment from SVN commit #695 to the opensource repo by agrundman == == http://svn.slimdevices.com/opensource?view=revision&revision=695 == Bug 11950, approx_bytes_per_frame was being calculated wrong which could cause seeking to fail in some cases, also if we have to give up after max_tries, don't return -1 but use the last offset we found
OK, YAPF_wgh_20100523_b.zip uploaded. YAPF_wgh_20100523.zip is truncated, so you can toss that one. I'll wait for your changes to Audio-Scan/flac.c to hit Scan.so in the svn and then test. Thanks. PS: I may post a couple of text files to test a more robust ftp transfer script, if that's ok. They'll be named "delete me - test x.txt" or something like that. I'd delete them myself, except that I don't have permissions to do that, of course.
Fixed, tested with all of the various files from this bug.
Works for me. Thanks!
Able to play the long FLAC files (with embedded cue sheet) on Baby and SB TOuch