Bugzilla – Bug 4296
Problem parsing FLAC file embedded CUE sheets containing frame numbers
Last modified: 2008-12-18 11:12:53 UTC
Hi, I have a number of FLAC files with embedded CUE sheets in the following format: FILE "dummy.wav" WAVE TRACK 01 AUDIO INDEX 01 0 TRACK 02 AUDIO INDEX 01 6528000 TRACK 03 AUDIO INDEX 01 13968000 TRACK 04 AUDIO INDEX 01 18384000 TRACK 05 AUDIO INDEX 01 30000000 TRACK 06 AUDIO INDEX 01 39264000 TRACK 07 AUDIO INDEX 01 46560000 TRACK 08 AUDIO INDEX 01 60144000 TRACK 09 AUDIO INDEX 01 64608000 TRACK 10 AUDIO INDEX 01 74400000 REM FLAC__lead-in 0 REM FLAC__lead-out 170 85936128 (indexes are specified as frame numbers and not times). The reason for this is that these are 48kHz files, converted from DVD audio (AC3 or DTS) using the spdifconvert utility. These files need to use absolute frame numbers, as when metaflac imports a CUE sheet containing times, it assumes that the file was sampled at 44.1kHz. If I look in Slim/Formats/Playlists/CUE.pm, I find the following: elsif (defined $currtrack and $line =~ /^\s*INDEX\s+00\s+(\d+):(\d+):(\d+)/i) { $tracks->{$currtrack}->{'PREGAP'} = ($1 * 60) + $2 + ($3 / 75); } elsif (defined $currtrack and $line =~ /^\s*INDEX\s+01\s+(\d+) :(\d+):(\d+)/i) { $tracks->{$currtrack}->{'START'} = ($1 * 60) + $2 + ($3 / 75); } This appears to only recognise 'INDEX' lines of the form 'MM:SS:FF'. These files used to be correctly recognised in Slimserver v6.3, so I'm assuming that this capability (to read in CUE sheets containing frame numbers) has been removed. Can it be re-instated? I can provide a FLAC file in this format if required. Thanks Andy
Bit more info, I'm tracking the 6.5 branch using Subversion. I update most days.
from 6.3.1, Slim::Formats::Parse::parseCUE(): } elsif (defined $currtrack and $line =~ /^\s*INDEX\s+00\s+(\d+):(\d+):(\d+)/i) { $tracks->{$currtrack}->{'PREGAP'} = ($1 * 60) + $2 + ($3 / 75); } elsif (defined $currtrack and $line =~ /^\s*INDEX\s+01\s+(\d+):(\d+):(\d+)/i) { $tracks->{$currtrack}->{'START'} = ($1 * 60) + $2 + ($3 / 75); 6.3.0 is the same. not sure how it would have worked correctly with 6.3.x. lucky, I guess, becuase it doesn't appear to have been supported.
Hmm...well it's definitely worked in the past, as I've listened to these files via my SB2! Is this likely to be supported at some time in the future? Or can you suggest a workaround in the meantime? If memory serves, the reason the CUE sheet entries are in 'frames' rather than 'times' is because the FLAC software has decided it's not come from a CD (I think based on the sample rate).
Alternatively, am I mis-diagnosing the problem (just because metaflac exports a CUE sheet containing frame numbers, does that necessarily mean that the FLAC code in Perl will also receive frame number?) I'd appreciate someone who knows a bit more about how the code works taking a look to see why these files aren't being recognised. I'm in the process of uploading a FLAC right now, but it's about 200Meg so is taking a while. I'll add a reference to it here once it's uploaded.
Well, I'm not well versed with cue sheets myself (too many wild variations in formatting to even consider taking time to learn them all for testing), but here is how I would recommend attacking the diagnosis: Install 6.3 again, different location from 6.5 so you can run either one. Run 6.3 from a command prompt: slim.exe --d_parse --d_source to make it quick, put just this one same cue/file into a folder and set that as the audiodir, then scan. d_parse will result in output of how the server is parsing the whole file. then play some tracks. d_source will give output that shows how each track is able to play. Then do the same with 6.5 and compare. I am quite surprised that this would work with 6.3 and not 6.5. Perhaps you've played the album from start to finish, in order only? It could be that 6.3 was loose enough to just attempt to play whatever is there. 6.5 is definately more rigid in order to better avoid playing stuff that won't play correctly. I realise I may have been a bit general here, but if you need more specific steps, just let me know which part. Other option: if you prefer to wait, chris will eventually get someone at SD to reproduce. I can't speak to when and how it will be supported. On one hand, SD appears very committed to all levels of Flac support, but CUE sheets in particular are a very messy(for lack of any slick term for it) format. The only workaround I could suggest would be to hide the CUE sheet (rename or make non-readable) and play the whole-album as a track, or split the whole album in to per-track flac files for tagging and playback.
Ok, now I'm confused. 6.3 also didn't see the albums. 6.2.1 also doesn't see them I *know* these files have been seen before, and I haven't played them all the way through, I've been able to access individual tracks in them. I've placed one of the files on my web space. It's at http://www.gently.org.uk/ep1.flac I'd appreciate it if someone could take a look, and see what they can see. I'm starting to wonder if perhaps I've updated a Perl module (I was developing some FLAC software myself, and it's possible I tried to use one of the same modules as SlimDevices use in SlimServer)? Maybe this change in interface or something has caused the problem? As far as renaming the CUE sheets, that's not really possible as they're embedded in the FLAC file. I can see the albums if I remove the CUE sheet and adjust the tags appropriately, but I'd rather be able to have access to individual tracks (again!).
I'm using 7.0a1 right now. parsing is as follows: 2006-10-05 13:55:08.2456 parseCUE: baseDir: [D:\mp3tmp] 2006-10-05 13:55:08.2495 URL: file:///D:/mp3tmp/ep1.flac#0-136 2006-10-05 13:55:08.2499 TRACKNUM: 1 2006-10-05 13:55:08.2502 URL: file:///D:/mp3tmp/ep1.flac#136-291 2006-10-05 13:55:08.2506 TRACKNUM: 2 2006-10-05 13:55:08.2509 URL: file:///D:/mp3tmp/ep1.flac#291-383 2006-10-05 13:55:08.2612 TRACKNUM: 3 2006-10-05 13:55:08.2631 URL: file:///D:/mp3tmp/ep1.flac#383-625 2006-10-05 13:55:08.2633 TRACKNUM: 4 2006-10-05 13:55:08.2636 URL: file:///D:/mp3tmp/ep1.flac#625-818 2006-10-05 13:55:08.2638 TRACKNUM: 5 2006-10-05 13:55:08.2645 URL: file:///D:/mp3tmp/ep1.flac#818-970 2006-10-05 13:55:08.2757 TRACKNUM: 6 2006-10-05 13:55:08.2782 URL: file:///D:/mp3tmp/ep1.flac#970-1253 2006-10-05 13:55:08.2785 TRACKNUM: 7 2006-10-05 13:55:08.2789 URL: file:///D:/mp3tmp/ep1.flac#1253-1346 2006-10-05 13:55:08.2792 TRACKNUM: 8 2006-10-05 13:55:08.2794 URL: file:///D:/mp3tmp/ep1.flac#1346-1550 2006-10-05 13:55:08.2911 TRACKNUM: 9 2006-10-05 13:55:08.2932 URL: file:///D:/mp3tmp/ep1.flac#1550-1790.33333333333 2006-10-05 13:55:08.2936 TRACKNUM: 10 2006-10-05 13:55:08.2940 matched: ARTIST = Douglas Adams 2006-10-05 13:55:08.2943 matched: ALBUM = Tertiary Phase 2006-10-05 13:55:08.2946 matched: YEAR = 2006 2006-10-05 13:55:08.2952 matched: DISCNUMBER = 1 2006-10-05 13:55:08.2955 matched: TRACKNUMBER[1] = 1 2006-10-05 13:55:08.2957 grouped as track 1 2006-10-05 13:55:08.2959 matched: TITLE[1] = An Updated Guide 2006-10-05 13:55:08.2960 grouped as track 1 2006-10-05 13:55:08.2962 matched: TRACKNUMBER[2] = 2 2006-10-05 13:55:08.3148 grouped as track 2 2006-10-05 13:55:08.3192 matched: TITLE[2] = The Two Earth Survivors 2006-10-05 13:55:08.3194 grouped as track 2 2006-10-05 13:55:08.3196 matched: TRACKNUMBER[3] = 3 2006-10-05 13:55:08.3198 grouped as track 3 2006-10-05 13:55:08.3200 matched: TITLE[3] = A Frustrating Encounter 2006-10-05 13:55:08.3314 grouped as track 3 2006-10-05 13:55:08.3340 matched: TRACKNUMBER[4] = 4 2006-10-05 13:55:08.3343 grouped as track 4 2006-10-05 13:55:08.3345 matched: TITLE[4] = Wowbagger 2006-10-05 13:55:08.3347 grouped as track 4 2006-10-05 13:55:08.3349 matched: TRACKNUMBER[5] = 5 2006-10-05 13:55:08.3461 grouped as track 5 2006-10-05 13:55:08.3479 matched: TITLE[5] = Reunion 2006-10-05 13:55:08.3481 grouped as track 5 2006-10-05 13:55:08.3484 matched: TRACKNUMBER[6] = 6 2006-10-05 13:55:08.3485 grouped as track 6 2006-10-05 13:55:08.3487 matched: TITLE[6] = Chasing the Sofa 2006-10-05 13:55:08.3603 grouped as track 6 2006-10-05 13:55:08.3627 matched: TRACKNUMBER[7] = 7 2006-10-05 13:55:08.3629 grouped as track 7 2006-10-05 13:55:08.3631 matched: TITLE[7] = Starships of Legend 2006-10-05 13:55:08.3633 grouped as track 7 2006-10-05 13:55:08.3635 matched: TRACKNUMBER[8] = 8 2006-10-05 13:55:08.3751 grouped as track 8 2006-10-05 13:55:08.3774 matched: TITLE[8] = Martin Rotating 2006-10-05 13:55:08.3777 grouped as track 8 2006-10-05 13:55:08.3778 matched: TRACKNUMBER[9] = 9 2006-10-05 13:55:08.3780 grouped as track 9 2006-10-05 13:55:08.3783 matched: TITLE[9] = The Ratchet Screwdriver Fruit 2006-10-05 13:55:08.3904 grouped as track 9 2006-10-05 13:55:08.3922 matched: TRACKNUMBER[10] = 10 2006-10-05 13:55:08.3924 grouped as track 10 2006-10-05 13:55:08.3926 matched: TITLE[10] = Goodbye Trillian 2006-10-05 13:55:08.3934 grouped as track 10 2006-10-05 13:55:08.4039 parse: calculating duration for anchor: 136 2006-10-05 13:55:08.4042 parse: calculating header 0, startbytes 0 and endbytes 16240752 2006-10-05 13:55:08.6693 parse: calculating duration for anchor: 155 2006-10-05 13:55:08.6712 parse: calculating header 0, startbytes 16240752 and endbytes 34750432 2006-10-05 13:55:08.7534 parse: calculating duration for anchor: 92 2006-10-05 13:55:08.7555 parse: calculating header 0, startbytes 34750432 and endbytes 45736824 2006-10-05 13:55:08.7966 parse: calculating duration for anchor: 242 2006-10-05 13:55:08.7988 parse: calculating header 0, startbytes 45736824 and endbytes 74635809 2006-10-05 13:55:08.8342 parse: calculating duration for anchor: 193 2006-10-05 13:55:08.8345 parse: calculating header 0, startbytes 74635809 and endbytes 97683347 2006-10-05 13:55:08.8701 parse: calculating duration for anchor: 152 2006-10-05 13:55:08.8730 parse: calculating header 0, startbytes 97683347 and endbytes 115834776 2006-10-05 13:55:08.9104 parse: calculating duration for anchor: 283 2006-10-05 13:55:08.9107 parse: calculating header 0, startbytes 115834776 and endbytes 149629871 2006-10-05 13:55:08.9507 parse: calculating duration for anchor: 93 2006-10-05 13:55:08.9530 parse: calculating header 0, startbytes 149629871 and endbytes 160735679 2006-10-05 13:55:08.9957 parse: calculating duration for anchor: 204 2006-10-05 13:55:08.9977 parse: calculating header 0, startbytes 160735679 and endbytes 185096807 2006-10-05 13:55:09.0357 parse: calculating duration for anchor: 240.33333333333 2006-10-05 13:55:09.0390 parse: calculating header 0, startbytes 185096807 and endbytes 213796764 2006-10-05 13:55:09.0775 returning: 10 items playback is as follows: 2006-10-05 13:56:20.2827 openSong on: file:///D:/mp3tmp/ep1.flac#0-136 2006-10-05 13:56:20.2845 openSong: duration: [136] size: [16240752] endian [] offset: [0] for file:///D:/mp3tmp/ep1.flac#0-136 2006-10-05 13:56:20.2856 undermax = 1, type = flc, softsqueeze = ba:43:80:ae:96:cd 2006-10-05 13:56:20.2860 checking formats for: flc-ogg-softsqueeze-ba:43:80:ae:96:cd 2006-10-05 13:56:20.2864 checking formats for: flc-ogg-*-ba:43:80:ae:96:cd 2006-10-05 13:56:20.2866 checking formats for: flc-ogg-softsqueeze-* 2006-10-05 13:56:20.3004 checking formats for: flc-ogg-*-* 2006-10-05 13:56:20.3023 checking formats for: flc-flc-softsqueeze-ba:43:80:ae:96:cd 2006-10-05 13:56:20.3025 checking formats for: flc-flc-*-ba:43:80:ae:96:cd 2006-10-05 13:56:20.3028 checking formats for: flc-flc-softsqueeze-* 2006-10-05 13:56:20.3031 checking formats for: flc-flc-*-* 2006-10-05 13:56:20.3032 Checking to see if flc-flc-*-* is enabled 2006-10-05 13:56:20.3034 enabled 2006-10-05 13:56:20.3036 Found command: - 2006-10-05 13:56:20.3040 Matched Format: flc Type: flc Command: [flac] -dcs --skip=$START$ --until=$END$ -- $FILE$ | [flac] -cs --totally-silent --compression-level-0 - 2006-10-05 13:56:20.3042 openSong: this is an flc file: file:///D:/mp3tmp/ep1.flac#0-136 2006-10-05 13:56:20.3045 file type: flc format: flc inrate: 955.305 maxRate: 0 2006-10-05 13:56:20.3047 command: [flac] -dcs --skip=$START$ --until=$END$ -- $FILE$ | [flac] -cs --totally-silent --compression-level-0 - 2006-10-05 13:56:20.3065 Using command for conversion: "D:\slim\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dcs --skip=0:00.00 --until=2:16.00 -- "D:\mp3tmp\ep1.flac" | "D:\slim \server\Bin\MSWin32-x86-multi-thread\flac.exe" -cs --totally-silent --compression-level-0 - | 2006-10-05 13:56:20.3268 openSong: Streaming with format: flc 2006-10-05 13:56:20.3389 ba:43:80:ae:96:cd New play mode: play 2006-10-05 13:56:20.3471 Transporter::play - setting DigitalInput to 0 for [file:///D:/mp3tmp/ep1.flac#0-136] 2006-10-05 13:56:20.3476 Transporter switching to digital input 0 2006-10-05 13:56:20.3564 ba:43:80:ae:96:cd: Current playmode: play 2006-10-05 13:56:23.9241 Got a track starting event 2006-10-05 13:56:23.9262 Song 0 has now started playing 2006-10-05 13:56:23.9272 Song queue is now 0 2006-10-05 13:58:17.2260 Read to end of file or pipe sounds unlistenable, however, loud oscillating white noise. I've also noticed that the songinfo reports 48khz sampling. Not sure how well 48kHz is supported in this case, as the CUE sheet requires that the file be transcoded on the fly to extract the desired segment.
extracting using: "D:\slim\server\Bin\MSWin32-x86-multi-thread\flac.exe" -dc --skip=4:51.00 --until=6:23.00 -- "D:\mp3tmp\ep1.flac" > d:\mp3tmp\temp.wav temp.wav is the same oscillating white noise. Decoding should be aware of the sample rate, so not sure what to suggest from here.
The white noise is expected. This is an AC3 file, so will only be listenable via the digital out, through an appropriate receiver with the SB volume turned up full. How 'unstable' is 7.0 likely to be? I might take a look at the code change and see if I can work out why it's working there.
Just a thought, any chance you can try it on the 6.5 branch? I've still got a horrible suspicion that I've upgraded a Perl module and that's what's caused the problem. Thanks
7.0 is still basically 99% match to 6.5.1 nightly builds, which are definately a big improvement over 6.5.0. If you haven't tried 6.5.1, I'd go with that as I really don't think there should be any difference in parsing. I expect that the calculted times may be off, as I am not finding anything (at least not yet) that takes the sample rate into account.
Well, if I'm in the right area of the code, 7.0 looks the same to me as 6.5. This just makes me think more and more that it's some sort of CPAN type module problem. Can anyone tell me which module is responsible for extracting the CUE sheet from a FLAC file?
I'm tracking the 6.5 branch through subversion, updating most days I still think it might be a CPAN module issue.
svn should already contain the cpan modules used in slimserver. lib\Audio\FLAC right now, I'm testing on a windows system, so that could always be part of the issue.
Is there a way to force the slimserver (under Linux) to use those modules rather than the system wide ones?
the ones in lib should be getting used first. slimserver.pl --d_startup (to confirm)
Ok, I've just tried the latest subversion trunk, and that still doesn't see the albums. It must be a CPAN module problem. Anyone suggest which one might be the culprit? Audio::Header::FLAC is certainly an older version in my Perl installation compared to the one in the slimserver/lib directory. I tried --d_startup, and there's no mention of that module.
d_startup should show the @inc, which is the module locations searched in order.
Ok, I've got a result. I had the following files: /usr/local/lib/perl/5.8.4/Audio/FLAC/Header.pm /usr/local/lib/perl/5.8.4/auto/Audio/FLAC/Header/Header.bs /usr/local/lib/perl/5.8.4/auto/Audio/FLAC/Header/Header.so I've renamed these so that they can't be found, and it's now picking up all the albums correctly. I suspect that it's the ones in the 'auto' directory that were the problem. Anyone got any idea what these are? I'll update the thread I created in the 'ripping / tagging' forum with this info. Thanks for the help in identifying this. If you're happy we've got to the root of the problem, then we can close this and blame user error (being a software developer myself, I know how satisfying that can be sometimes!)
I will let you have the satisfaction if you want it, KDF :)
Thanks! Now that we've tracked down the cause, I'm actually going to leave this for Chris to evaluate. I'm not sure what the current policy is for cases of module conflicts (using system vs included libraries). I will downgrade the severity at least ;)
I'm sure I don't know if this behavior is consistent with our module priority policy, so I'll assign it to Dan for his judgment.
I see this has been assigned a target milestone, does that mean an issue has been identified? Is it something to do with the Perl library search paths?
The remaining issue is to consider if it's sensible to try to check module versions in Slimserver, or otherwise try to prevent this kind of problem. It may well get marked as 'wontfix' as the next stage of its buggy life. :)
Marking as wontfix for now. If the module loading order is still an issue for you, please open a new bug for that issue.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.