Bugzilla – Bug 1482
WAV CUE files start playing on first track always
Last modified: 2008-08-18 10:54:16 UTC
It doesnt matter what track you select in an EAC CUE file, it always starts playing the start of the WAV file which is of course Track 1. Same happens if you try and use the Next/Previous controls. I have had to revert back to 5.4.1 to get proper CUE file support back which means I am unable to use my new SB2's. Also, if you browse a CUE file using Browse Music, you get a list of 'CD image' rather than the track listing. Lastly, I am not convinced that searches see the CUE file contents either.
Michael, is this possibly related to bug1360?
The "cd image" when browsing music folder is the "sort by filename" version of bug 1360. (the behaviour kevin described in 1360 is the "sort by song information" version.) Browsing by "Music Folder" has known problems with cuesheets, but everything else should be working. Andy, can you attach one of the cuesheets you're having problems with?
Created attachment 527 [details] Example cue file The attached is an example CUE file, this CUE file works fine on V5.
Michael: what's your assessment of this?
Michael is AWOL. Hopefully vidur can look at this.
sorry, my internet connection will be spotty at best, until I return to the US after the 17th. I'll take another look at this then, if it hasn't already been taken care of.
Michael - what are your thoughts on this?
I took a quick peek at this, and it does indeed always start playing at the beginning of the file. The cuesheet seems to be getting parsed correctly, and the entries in the db include the offset anchors, but they seem to be ignored during playback. I haven't dredged up a 5.x install to compare against yet.
I dont have any valid cue sheets in my setup so I canot really test. How does this look in the d_source logs? Are the anchors showing up in the constructed playback command?
> Are the anchors showing up in the constructed playback command? no, but nothing in convert.conf suggests that they should. so just for kicks I tweaked convert.conf for wav -> flc so that it pipes through sox with "trim" set to the $START$ anchor. Then frobbed Source.pm so it would interpolate the anchor values for non-flac files (not sure why it has that restriction to begin with), and sure enough the playback starts with the expected song. A bit more tweaking of Source.pm and convert.conf could produce a semi-usable workaround hack, but I think what we really want to do is fix seeking to the proper offset when reading the wav file to begin with.
Seeking in PCM files sounds right to me. We're already doing it in time2offset and when doing a FFWD or REW.
Michael, any chance you'd be willing to own this for 6.1?
Digging a bit deeper, it seems this really is just a convert.conf issue. sb2 converts wav to flac, and the conversion line didn't account for offset anchors. Changing the convert.conf (didn't need sox after all) and the aforementioned tweak to Source.pm and it seems to be working as expected. This worked in 5.x because we didn't try to transcode the wav file (or we converted it to mp3). Revision 3588 fixes this for wav files, but trying to make this work for anything other than wav, flac, and mp3 is going to be tricky.
Do we care about anything other than wav, flac and mp3? Those are the common cue sheet source files, yes? What else, if anything uses them?
I haven't stumbled across anything else yet, but theoretically you could use any format you wanted. I vote for leaving it at these three, and if someone wants a particular format added they just have to figure out how to make that formats decoder do the equivelent of the skip/until options. I would've marked this as "fixed" after the above changes, but it doesn't give me that option when it's not assigned to me. :)
mark as you see fit :)
marking as "fixed" as the issue described in the summary is, well, fixed.
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!