mkcue review

[poddmo]

• rich CUE files are important context
• the CUE file must accurately represent the CD it is derived from, including handling of pre-gaps
• how much external metadata should we import to make the CUE more useful?
• internal function or external program?

I'm split in my preference for doing things "in-house" versus the Unix way of leaving that to a dedicated external program. In this case the external helper is not adequately maintained [ie old bugs in C++ code] (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mkcue), also the support outside the debian-sphere doesn't appear to be very broad (https://www.rpmfind.net/linux/rpm2html/search.php?query=mkcue&submit=Search+...&system=&arch=)
I also use external by default. We have had someone reporting use of the internal mkcue.

[poddmo]

https://en.wikipedia.org/wiki/Cue_sheet_(computing)

On further thought about externally derived metadata, GENRE is subjective and YEAR is ambiguous as to whether year of original release, CD release, reissue, metadata modification, etc. CUE file does not maintain the referential integrity for that info and becomes less representative of the CD. That info is fine for the encoded tracks because:

• tracks are removed from the exact CD layout, besides the track number
• music players do use genre and year from track metadata

If YEAR and GENRE exist in the original CD-TEXT then that should persist into abcde created CUE file.

Cue files are not used by music players, only useful for CD writing.

I'm open to an option like VERBOSE_CUE and put those externally derived metadata fields in the REM statements as shown in the wikipedia examples

[pccasto]

I have a music player that opens *.cue files and uses the data on the FILE line to open the associated *.flac (in my case).
That player was created without support for flacs with internal cue sheets (maybe I should update :-) ).
So, in this case, consistency in the naming convention is important.

CDDB might show releases with original year, or cd release year, but as long as the physical filename, and the FILE representation in the *.cue match it seems to be the optimal approach. Since FILE is built from the OUTPUTFORMAT variable, then all the variables that are advertised as available in that format should match their use elsewhere. If the physical filename is wrong (base on year or genre vagaries), then the FILE name will be equally wrong in the same direction :-)

I'll put together a pull request, and do a little bit more analysis on the abcde.mkcue.
Also, in looking at this issue, I found some inconsistencies in GENRE, where the data from the CDDB/MBZ was not properly referenced (an assignment from $GENRE rather than $CDGENRE). I'll include that as well, since it is interrelated.