Strange INDEX01 behavior for cd last track

2023-03-08 16:18:48

Hello
I've just bought The Graeme Edge Band's two cd's - Kick Off Your Muddy Boots and Paradise Ballroom (Graeme Edge - Moody Blues drummer). These are both compilation re-releases and both contain the original album plus one bonus track (one side of an earlier single release), which might be a clue to what's going on - see below.  They are released on the Esoteric Records label, catalogue numbers ECLEC 2142 and ECLEC 2143. As all my music is digital these days (LMS via Max2Play on an RPi, and a SqueezeBox Classic v3 hardware player) I ripped both cd's to lossless flac images with CueRipper v2.1.9 using the included libFLAC encoder (v1.3.3 20190804 according to Mp3tag), Encoder Mode 6. They are both shown as ripped accurately and the .log's confirm.

Now, when I play the resulting flac images with Window's Groove Music player or Media Player, or VLC (v3.0.16 and 3.0.18) they play fine, right through to the end with no problems. However, if I play the same audio in VLC, but by opening the .cue file created by CueRipper, VLC cannot find the last track on either album, it goes into the yellow "buffering/searching" mode in the progress bar. This happens whether I play the whole album, press "Next" from the penultimate track, or double-click the last track. I passed the flac's and cue's to a friend, and he sees exactly the same thing.

In both cases the INDEX 01 position for the last track in the .cue matches the start time shown in the .log.  But after some experimentation we've found, again in both cases, that if we edit the .cue to subtract 1 sec and 3 frames from the INDEX 01 time, the final track then plays OK . One frame later and it doesn’t work.

Examining the KOYMB flac in Audacity, by setting the selection points to the unmodified INDEX00 and 01 values, the last track's pregap sits well inside the observable silence between the last two tracks.

I then used CueTools to split the KOYMB flac into mp3's with gaps appended. That is successful. For the last track mp3, the audio starts immediately, so at it's original INDEX 01 point, with nothing missing from the beginning.

Out of interest, my friend converted a flac tracks split of KOYMB (done with the original unedited .cue) back to an image with CueTools. The resultant .cue timing matched the original and the resultant .cue plus flac image gives exactly the same track 10 symptoms with VLC.

I've re-ripped the cd's on a different machine, running CueRipper v2.2.2 using the included libFLAC encoder, with the same result.

Playing the physical discs in a cd player they play fine, either all the way through (which also shows the pregap countdowns) or seeking to the last track (which plays from the track start, ie after the pregap).

So why can't VLC find the last track by it's .cue data. I think it's got to be something awry with the physical cd's messing up the rip, can anyone explain what's going on ?

Re: Strange INDEX01 behavior for cd last track

Reply #1 – 2023-03-08 17:44:56

Can you share the cue and log files? It sounds like you may have found a bug in VLC rather than a problem with the CDs.

Re: Strange INDEX01 behavior for cd last track

Reply #2 – 2023-03-08 19:16:39

Kick Off Your Muddy Boots .cue and .log files as requested

Just to add that I've never seen this problem between VLC and any of my previous 800+ cd rips, it does seem to be peculiar to these two cds

Re: Strange INDEX01 behavior for cd last track

Reply #3 – 2023-03-14 00:44:16

I thought I'd post an update.

My friend, fellow forum member Twangster, and I, haven't got very far, as trying to find other examples involves trying to play every track from the ripped flac image's associated cue file with VLC. However we have found two more examples;  Diana Krall’s A Night in Paris and Sheryl Crowe's The Very Best of Sheryl Crowe.

What's really odd with these two cd's is that just like my two Graeme Edge cd's they are both re-issues with a bonus track. We're beginning to wonder if there's something odd introduced into the bitstream by the later addition of the bonus track, a discontinuity of some sorts. Even more bizarre with the Krall cd is that it's not the bonus track that VLC won't play, it's the penultimate track before the bonus track, it plays the final "bonus" track fine. Twangster adds this snippet of info; ...the penultimate track which fails (track 11) being a bit like a bonus track as it was recorded at Avatar Studios, New York whereas tracks 1 – 10 were recorded live at the Paris Olympia. As he doesn't have the initial release he can't say whether the last track (11) on that cd is a problem in this regard or not. Also, he says, even though the INDEX 01 for track 11 in the .cue has to be pulled back by 11sec 10frames for VLC to play it, if VLC plays through from the end of track 10, when it hits the modified INDEX01 time it jumps to the actual start time of track 11 to continue playing. We've found these two new examples require different tweaking of the INDEX 01 offsets in the cue file to play properly than the 1s3fr both my cd's needed. We don't have enough data to hazard a guess as to what's going on, we need to continue to look for lots more examples.

Using the Clementine player on W10 (listed in the flac documentation on the xiph.org website) all tracks play properly from the .flac when selected via it's cue file, all with the correct pregaps where appropriate. So we don't think it's a CueTools problem per se.

However all this testing has uncovered an anomaly with CueRipper. I won't call it a bug as there may well be a good reason for this behaviour. It concerns the use of the ellipsis (three dots) character in Album titles, notably "The Best Air Guitar Album in the World… Ever!" series. CueRipper correctly creates the folder name with the Unicode character (U+2026 ) for the ellipsis when using the %Album% code in the OutputPathFormat, and the correct filenames with the same Unicode character for the %Album%.flac filename, along with the correctly named .cue, .accurip and .log

But, the cue file itself is saved in Windows-1252 codepage, and the ellipsis is transcoded to x'85' in the FILE statement. Consequently when VLC tries to open the flac file which it constructs from the cue file path and the cue file's FILE statement it can't find the flac file, as it's looking for a file in the correct path, but with the wrong filename. VLC is behaving correctly here, it's just a consequence of the mixing of Unicode and Windows 1252 characters to represent the same visual character - the three dots. This took a while to root out as visually, it all looks OK, it only becomes apparent when poking about with a Hex Viewer.

Using a Hex Viewer to examine the contents of the flac file, the same cue file is embedded correctly in UTF-8 encoding in the Vorbis Comment Block with the ellipsis correctly coded as x'E2' x'80' x'A6'. The .xml file in the local MetadataCache folder is also correctly coded in UTF-8 with the ellipsis as x'E2' x'80' x'A6'.

Also, when using CueTools to split the flac into mp3s, the TALB (Album Title) tag in each mp3 is correctly encoded in UTF-16 with the ellipsis as x'2026' (stored as '2620' as it's little-endian).

This behaviour is probably the same for the Apostrophe too when the Unicode Right Single Quote Mark (U+2019) has been used (a frequent occurrence I've noticed), as that is transcoded to x'92' in Windows-1252 codepage, so that's what the cue files contain. They are are not limited to the FILE statement, they're littered through the track TITLE statements too

I just wonder if there's a good reason for the cue file being saved in 1252 or if it's just a hangover from the past. It could be problematic if anyone is creating any scripting or coding to process the cue file contents, or possibly even filtering using cue file derived lists under PowerShell.   x'85' is not a valid Unicode code point. The correct UTF-8 encoding for 1252 codepage character x'85' is x'C2' x'85' and for UTF-16 it is x'8500' (little endian).

Can anyone shed any light as to why 1252 is used for the cue file ?

Re: Strange INDEX01 behavior for cd last track

Reply #4 – 2023-03-14 02:35:45

There's nothing unusual in the cue or log files you posted. Does changing the FLAC compression level change VLC's behavior?

Since you've confirmed that the files work in other players, you should submit a bug report to the VLC developers.

Re: Strange INDEX01 behavior for cd last track

Reply #5 – 2023-03-14 03:10:18

The ellipsis issue was also mentioned in https://hydrogenaud.io/index.php?topic=120854.0
Usually CUETools/CUERipper doesn't write the CUE in UTF-8 unless the text contains characters not in your local codepage.
https://hydrogenaud.io/index.php/topic,117151.0.html (couldn't find a better reference for some reason)
Request for option to always write UTF-8 CUE

Re: Strange INDEX01 behavior for cd last track

Reply #6 – 2023-03-14 09:02:38

Thanks for the explanation korth, the requested option to always write UTF-8 cues would be great little enhancement.

Once we've accumulated more examples of the initial INDEX 01 issue for what at first glance looks like "Bonus" tracks, we'll file a bug report with the VLC developers.