Bug #651

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

Added by Igor Kushnir about 1 year ago. Updated 12 months ago.

Status:Closed Start date:July 11, 2016
Priority:Major Due date:
Assignee:- % Done:

100%

Category:plugins/cue
Target version:3.8
Affects version:3.7.2

Description

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: https://drive.google.com/open?id=0B0F-aqLyFk_PQkNjNWhIV24xN1E
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 https://github.com/lipnitsk/libcue/commit/8855ccdb4b37908263a01751b81a7233498e08ab, 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.3 kB) Igor Kushnir, July 11, 2016 19:45

QMMP.png (143.4 kB) Igor Kushnir, July 11, 2016 19:45

Audacious-with-libcue-2.1.png (126.5 kB) Igor Kushnir, July 11, 2016 19:45

Audacious-with-libcue-2.1-and-reverted-commit.png (125.6 kB) Igor Kushnir, July 11, 2016 19:45

Associated revisions

Revision 9fa62152
Added by John Lindgren 12 months ago

cue: Fix track pre-gap being skipped with libcue 2.0. Closes: #651.

History

#1 Updated by John Lindgren 12 months ago

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

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