Cue file handling

[RobbH]

My earlier posts were to do with cue files with multiple source files.
The Nov/Dec LMS problem with Cue files was related to cue files with multiple source files - this seems to be similar to the edge case you are referring.
The cue file you posted had only one source flac file.
The point I made earlier was that not all multi source cue file formats are supported - in particular EAC generated ones. Cue files with multiple flac files were tested. They seemed to be OK with just the correct file name - never tested whether the flac (or WAV) file name had to be the exactly same as track name.

Post a the cue file with multiple source files.

Please forgive me if I'm wildly off base here. That's not at all unlikely. But I think what makes certain multi-source cue files non-standard is the addition of a pregap (index 0 command) for each track (>1) to the end of the preceding track. Without this quirk, multi-source cue files can meet all standards.

[bpa]

Please forgive me if I'm wildly off base here. That's not at all unlikely. But I think what makes certain multi-source cue files non-standard is the addition of a pregap (index 0 command) for each track (>1) to the end of the preceding track. Without this quirk, multi-source cue files can meet all standards.

You're probably right. I don't use cue files and the comment about "INDEX" makes sense as when I tested the unsupported EAC generated variant it had "INDEX" entries.

I can't share the files unfortunately. It's copyrighted material.

Isn't the just the audio copyrighted not the CUE text file ?
Can you not even share the CUE file with the specific track title associated the audio files obscured.
The structure of the CUE file is important so that it can be checked not the value of the fields.

[vco1]

You're probably right. I don't use cue files and the comment about "INDEX" makes sense as when I tested the unsupported EAC generated variant it had "INDEX" entries.


Isn't the just the audio copyrighted not the CUE text file ?
Can you not even share the CUE file with the specific track title associated the audio files obscured.
The structure of the CUE file is important so that it can be checked not the value of the fields.

Sorry, I misunderstood. Of course I can share the CUE sheet. Artist, album and titles replaced, but the structure fully intact.

REM DATE 2019
PERFORMER "Artist Name"
TITLE "Album Title"
FILE "Artist Name - Album Title 1.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Title 1"
    PERFORMER "Artist Name"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Title 2"
    PERFORMER "Artist Name"
    INDEX 01 09:2:00
  TRACK 03 AUDIO
    TITLE "Title 3"
    PERFORMER "Artist Name"
    INDEX 01 17:00:00
  TRACK 04 AUDIO
    TITLE "Title 4"
    PERFORMER "Artist Name"
    INDEX 01 26:19:54
  TRACK 05 AUDIO
    TITLE "Titel 5"
    PERFORMER "Artist Name"
    INDEX 01 35:32:00
  TRACK 06 AUDIO
    TITLE "Title 6"
    PERFORMER "Artist Name"
    INDEX 01 42:36:45
FILE "Artist Name - Album Title 2.flac" WAVE
  TRACK 07 AUDIO
    TITLE "Title 7"
    PERFORMER "Artist Name"
    INDEX 01 00:00:00
  TRACK 08 AUDIO
    TITLE "Title 8"
    PERFORMER "Artist Name"
    INDEX 01 07:46:00
  TRACK 09 AUDIO
    TITLE "Title 9"
    PERFORMER "Artist Name"
    INDEX 01 17:00:00
  TRACK 10 AUDIO
    TITLE "Title 10"
    PERFORMER "Artist Name"
    INDEX 01 22:02:00
  TRACK 11 AUDIO
    TITLE "Title 11"
    PERFORMER "Artist Name"
    INDEX 01 26:31:54
  TRACK 12 AUDIO
    TITLE "Title 12"
    PERFORMER "Artist Name"
    INDEX 01 33:50:54
  TRACK 13 AUDIO
    TITLE "Title 13"
    PERFORMER "Artist Name"
    INDEX 01 37:56:26
  TRACK 14 AUDIO
    TITLE "Title 14"
    PERFORMER "Artist Name"
    INDEX 01 43:43:10
  TRACK 15 AUDIO
    TITLE "Title 15"
    PERFORMER "Artist Name"
    INDEX 01 50:45:02

[RobbH]

You're probably right. I don't use cue files and the comment about "INDEX" makes sense as when I tested the unsupported EAC generated variant it had "INDEX" entries.
....

Specifically, I think it's the "INDEX 0" (or 00) command that's the problem, when it's appended to the file containing the previous track. That's the pregap, usually silent, that a CD player starts with when you tell it to play a single track. When playing the whole CD or any subset of multiple tracks in the original order, the pregaps are skipped. At least, I think that's how I remember it working.

The INDEX 01 commands in vco1's cue file are entirely in accordance with the standard. I don't think they should be a problem.

Again, that's what I think, but my expertise is very limited and not very recent.

[vco1]

I'm still working my way through the code, especially cue.pm. Being not fluent in Perl (to say the least ;-)) and unfamiliar with the inner workings of LMS altogether, that takes a while. Still, I'm pretty sure the handling of a cue sheet with multiple files contains a bug. The fact that the 'source' files show up in the LMS lists with file type 'cur' while these should be hidden (line 656 onwards) is one thing I'm looking into.

[bpa]

Specifically, I think it's the "INDEX 0" (or 00) command that's the problem, when it's appended to the file containing the previous track. That's the pregap, usually silent, that a CD player starts with when you tell it to play a single track. When playing the whole CD or any subset of multiple tracks in the original order, the pregaps are skipped. At least, I think that's how I remember it working.

The INDEX 01 commands in vco1's cue file are entirely in accordance with the standard. I don't think they should be a problem.

Again, that's what I think, but my expertise is very limited and not very recent.

The INDEX 01 description seems to match what Nov?Dec fix was about.

When checking the Nov/Dec fix, my tests were done with CUE files which had a file per track.
Other tests were done with cue files which had one file and multiple tracks.
vc01 cue file has two files and multiple tracks. I don't know if this format variation was considered or tested.
How are these cue files generated so test files can be created ?

The "cur" filetype was a symptom of the Nov/Dec problem - badly processed track had a the "cur" filetype which I think is "internal" to LMS.

My understanding, when parsing an non cue playlist, LMS create a track entry database for each real file.
IIRC when parsing a cue files, LMS creates a virtual track entry for each track - referencing the most recent flac/WAv source files with the offset & duration of the track.

Since 7 tracks are created, it looks like LMS manages the first "FILE" correctly and may have assumed it is a "single " source CUE files and so processing of remaining tracks breaks down.

A comment on the original pull request may notify the author of multi source processing of the issue - https://github.com/Logitech/slimserver/pull/434