CUE-split files are loaded with improper duration and (possibly) start time

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 09, 2012 10:53:17

What steps will reproduce the problem? 1. Open 1234.cue (attached) in Clementine (assuming not-in-a-library case, just an external cue+wav pair) What is the expected output? What do you see instead? Expected output: 4 tracks: 3, 2, 2 and 3 second-long. What i see instead: 4 tracks 0, 0, 0 and 9 seconds-long.

When tested on other, longer (up to 1 hour) files, using various formats (wav+PCM, mp4+AAC, with longer timestamps in CUE indices (up to several minutes), durations of individual tracks after loading the .cue file might go as high as a few seconds - but that's it. Also, track start times are clustered at the start of the file, regardless of INDEX 00 values. What version of the product are you using? On what operating system? Clementine 1.0 AND 1.0-109-g8d19432

Attachment: 1234.tar.xz

Original issue: http://code.google.com/p/clementine-player/issues/detail?id=2594

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 09, 2012 01:55:41

Oh, yes, completely forgot. On what operating system? NT 6.1.7601

[Clementine-Issue-Importer]

From john.maguire on January 09, 2012 02:32:34

Otherwise known as Windows 7 I presume?

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 09, 2012 03:28:14

Yes, that is correct.

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 15, 2012 14:23:00

The bug is present in 0.7.1 too, both on NT and on Debian, as well as in 1.0-128-gfdf10af on NT The bug is not present in 0.6 (doesn't seem to support .cue sheets).

What am i doing wrong? Have ANYONE had success in using .cue files? If so, how were they written?

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 15, 2012 15:41:21

OK, it's not a bug, it's a feature :( Here's something for documentation, CUE sheet should look like this: FILE 1234.wav WAVE PERFORMER "LRN" TITLE "123456789 10" TRACK 01 AUDIO TITLE "1" INDEX 01 00:00:00 TRACK 02 AUDIO TITLE "2" INDEX 01 00:03:00 TRACK 03 AUDIO TITLE "3" INDEX 01 00:05:00 TRACK 04 AUDIO TITLE "4" INDEX 01 00:07:00

That is: 1) Use indices 01 to denote start time (end time is inferred automatically, AFAIU; INDEX 00 has special meaning) 2) CUE timestamp format is not hours:minutes:seconds , but minutes:seconds:frames (75 frames per seconds)

Because regex used for timestamps is "(\d{2}):(\d{2}):(\d{2})", it's not possible to address songs longer than 99 minutes (well, impossible to put a start time past that barrier).

None of the CUE specs i've seen says anything about hours.

Now, i'd like for Clementine to support either more-than-99-minutes format "(\d{2,}):(\d{2}):(\d{2})" (very easy to implement - add a ",") or hours-minutes-seconds-frames format "(\d{2}):(\d{2}):(\d{2}):(\d{2})". For reading only (Clementine can't write CUE sheets yet, but when it would, i guess it shouldn't write in non-compliant format).

The reason why i need this is that i have longer-than-1-hour tracks that i'd like to split. I haven't found any other way to split long tracks logically (without physically splitting the file), so CUE sheets would do nicely for this generic purpose, without changing the original file. Not requiring any modifications to the original file is an advantage, as the original file might be in a format that does not allow easy metadata insertion (because the format is not metadata-friendly, or because Clementine doesn't support saving metadata for files in that format, while still being able to play them).

[Clementine-Issue-Importer]

From LRN1...@gmail.com on January 16, 2012 02:22:12

OK, after toying a bit with CUE sheets, i've found a problem: Whenever a track from a CUE-cut file is ending, and Clementine has (due to random shuffling or due to the fact that there's some other track, not from the same CUE sheet, after the track that is ending) to start playing a track that is not from the same CUE file, Clementing plays first few seconds of audio that was coming AFTER the track that ended (the beginning of the next track in the CUE-cut file, that was not supposed to be played next), jumps to the next track (not from the same CUE file), and stops playing anything (it's possible to nudge it into action though, so it's not a freeze). After a few minutes (that would have been just enough to play through the rest of the CUE-cut file, i've checked with a timer) it DOES start playing the track that was supposed to be playing after all. Clementine doesn't seem to do I/O, but that probably means that the CUE-cut file is buffered completely in the memory. This doesn't happen if either of the following is true: 1) Next track is from the same CUE-cut file 2) The track that ended is the last track of the CUE-cut file

My guess: something is wrong with the way you handle GStreamer pipeline when playing CUE-cut files. Obviously, GStreamer doesn't support CUE by itself in any way (in decodebin or playbin), so you must have been doing some very potent pipeline magic to achieve the effect.

P.S. Maybe file a new issue for that?

[Clementine-Issue-Importer]

From leonel.m...@gmail.com on January 22, 2012 02:53:41

Well this pretty much sums up a largely annoying bug for people who use CUE/FLAC CD images. This same problem has been reported in issues 1679 and 2461, at least. Any chance we get an update soon?