Bug #651
libcue 2.0 regression - music fragments are skipped at the end of some tracks
100%
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.
History
#1
Updated by John Lindgren over 7 years ago
Updated by - 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.
