Bug #651

libcue 2.0 regression - music fragments are skipped at the end of some tracks

Added by Igor Kushnir almost 8 years ago. Updated almost 8 years ago.

Target version:
Start date:
July 11, 2016
Due date:
% Done:


Estimated time:
Affects version:


This is a regression in Audacious using libcue 2.0 (compared to Audacious using libcue 1.4).
I'm not sure if this is an actual libcue issue or if Audacious uses this library incorrectly.
Maybe Audacious should be adapted to the modified libcue API.

Attached a cue file that is affected by the regression. Here is a link to the associated flac file:
The 7th track is cropped at the end with {Audacious + libcue 2.0 or later}. Not only incorrect track time (2:52) is displayed in the Audacious UI, but playback automatically skips to the 8th track without finishing the 7th.

After I have reverted the offending libcue commit, Audacious UI still displays incorrect time (2:54), but it finishes playing the 7th track even though the UI shows that it has switched to the 8th track. I believe that it worked like this with libcue 1.4 too. Not perfect, but still acceptable - at least the music stream was not interrupted or cropped.

Qmmp player, which does not use libcue, shows correct track lengths in the UI and does not crop them.

Screenshots attached.

Classical Symphonies CD5.cue (2.25 KB) Classical Symphonies CD5.cue Igor Kushnir, July 11, 2016 19:45
QMMP.png (143 KB) QMMP.png Igor Kushnir, July 11, 2016 19:45
Audacious-with-libcue-2.1.png (126 KB) Audacious-with-libcue-2.1.png Igor Kushnir, July 11, 2016 19:45
Audacious-with-libcue-2.1-and-reverted-commit.png (126 KB) Audacious-with-libcue-2.1-and-reverted-commit.png Igor Kushnir, July 11, 2016 19:45


#1 Updated by John Lindgren almost 8 years ago

  • Status changed from New to Closed
  • Target version set to 3.8
  • % Done changed from 0 to 100

Hmm. The nominal length of track 7 is 2m52s, but there is a 2-second gap between tracks 6 and 7 (during which an old-school CD player would count down from -0:02 to 0:00) and then a longer 7-second gap between tracks 7 and 8.

libcue 1.4 included the 2-second starting gap as part of track 7, reporting the length as 2m54s, which is what Audacious displayed. QMMP seems to do the opposite, reporting the 7-second ending gap as part of the track, making the length 2m59s. I agree with you that QMMP's approach is better.

libcue 2.0 stopped reporting either gap as part of the track, and now reports only the nominal length (2m52s). I'm not happy about the unannounced API break, but the best thing for Audacious to do at this point is probably to ignore the length that libcue reports and compute it ourselves (length = start of track 8 - start of track 7). With libcue 2.0, this will give a length of 2m59s, matching QMMP. With libcue 1.4, it will give 2m54s, as it did before.

Also available in: Atom PDF