Add feature to parse cue sheets contents into the MPD database

[paolobormida]

Might be very useful to have MPD database update logic to process cue sheets found in the music directory to add the songs listed in the cue sheet to the database with all the propers tags.
This feature will allow for a single audio file with a cue sheet (flac, ape, wavpack or whatever other codec cue sheets might support) to be searchable in the database just as individual music files.
Support for CUESHEETS embedded in tags would be nice as well.

[MPconta]

I want to support this topic.
And i hope, that not only standard tags for cuesheets, "album", "artist", "title" and "track" will be considered, but also additional tags, which are stored in the "rem"-lines.
I would really love to see this feature in a coming version of MPD!

[enachesilviu]

I tried M.A.L.P. Android client, I can use the CUE sheet through the Files section but if I have many albums I wish I could just use the library since folders are undesirable for navigating music.

[MPconta]

Info for all, who do not know how to handle their SACD-Iso's the best way. Playback is a difficult thing with MPD and splitting them up in dsf or dff often creates disturbing cracks at the beginning of the created tracks:
Since this year it is possible to create WavPack-files with DSD-content and MPD can read this files easily. And it is possible to convert a whole SACD-Iso in one big WavPack with a cuesheet. So it should be possible to store SACD-Iso's in a way, that MPD can handle it AND there are no disturbing cracks.
At least i hope to use this possibility in future, when MPD can integrate cuesheets into the database. ;-)

[nousernouser]

Also I want to support this feature.

It seems to me many people (becoming more and more) have a music library made of single audio files (mostly flac) with a external (or internal) cue sheet, so this would be a great enhancement.

In accordiance with Mpconta, I hope this feature will come with support either for "standard" (CDRWIN) cuesheet tags (as TRACK, TITLE, PERFORMER, SONGWRITER) and for other common (flac/vorbis) tags even if stored in the REM lines (also with attention for tags related to Classical music), such: GENRE, DATE, DISCNUMBER, DISCTOTAL, ORGANIZATION (or LABEL), COMPOSER, DIRECTOR etc.

More, development of clients with cueshhet suppport (like Cantata has) would have benefit from this.

I would really appreciate having this feature in MPD!

[martinKempa]

Here is a patch to handle flac files with embedded cue sheets as container:

mpd-0.20.15-flac_container.patch.zip

Also I migrated it to version 0.19 because some people still stick to elder linux versions:

mpd-0.19.19-flac_container.patch.zip

Unfortunately I'm not very familiar with C++, so feel free to improve the modification.

[martinKempa]

Here is a small update fixing a problem displaying the correct time duration of tracks in processing stand-alone cue sheets:
mpd-0.20.15-flac_container.patch.zip
mpd-0.19.19-flac_container.patch.zip

[mateinegriu]

@martinKempa Looks nice, could you submit upstream?

[nousernouser]

COMMENT UPDATED (2019-05-13)

Hi

Since I would like to make the best use of MPD with my large digital audio collection (1 flac file per album + 1 CUE file corresponding -- as it happens for a large number of users), I tried to contribute by studying a way to best implement support for CUE files in MPD.

I tried to deepen the question, and the main issues that occur and that should be fixed should be:

• correlations between the PERFORMER and COMPOSER CUE commands and the albumartist, artist, performer and composer MPD tags, often result to be ambiguous for musical genres for which the artist may not correspond to the performer (as is for 'Classical' et al)
• further ambiguity arise when PERFORMER is set to 'Various' in the header section of the cuesheet

As CUE files can contain a lot of information which do not are directly correlable with the available MPD tags, a further step should be:

• extend support for CUE and MPD metadata as to handle other relevant information (without however introducing further ambiguity).

So I have therefore done an extensive and detailed work on this subject, which is available for download from here:
OLD VERSION (DEPRECATED): SUPPORTING CUE FILES IN MPD: SYNTACTIC AND SEMANTIC CONSISTENCY WITH STANDARD FORMATS FOR AUDIO METADATA

UPDATED version: SUPPORTING CUE FILES IN MPD: SYNTACTIC AND SEMANTIC CONSISTENCY WITH STANDARD FORMATS FOR AUDIO METADATA ver. 2.0 (pdf, 335KB)
NOTE: This document version 2.0 replaces any previous one, which now are deprecated. The old version 1.3 of the proposed pseudocode (who was listed here below) has been removed. The new proposed pseudocode version 2.0 is available within the provided document.

Summarizing this work, the specifications of the main formats for audio metadata (CCDB (freedb and MusicBrainz), TOC/CD-TEXT, CUESHEET, Vorbis comment and, obviously, MPD tags) were first examined with the aim of overcoming the critical issues. Having considered the results of the analisys carried out on these formats, it was possible to deepen the syntactic and semantic knowledge of the CUESHEET format, also in relation to the use conventions generally adopted in CUE files.

The correlations between CUE and MPD (and thus MPD clients) metadata were discussed, identifying a common set of audio metadata to be supported* exactly specifying their meaning and use, and finally understanding how to establish correlations so as to ensure syntactic and semantic consistency. Also, this has meant to precisely specify the syntactic and semantic use of the involved (standard and non-standard) CUE commands, and to define a proposal to extend the MPD specification introducing several new extra "extended" tags, that were necessary to achieve the optimal correlations.

All of this has been reported in a reference summary for CUE and MPD audio metadata (both standard and extended), which also contains the proposals to standardize and extend both the CUE commands and the MPD tags. More, a pseudocode has been proposed, which implements the parsing of CUE file commands in relation to the MPD tags so as to realize the appropriate correlations between the medatata. Some synthetic examples showing what result should be obtained with this implementation were also given.

I also tried to study the source code to see if I can propose the necessary changes. The code is very broad and structured in a fairly complex way to me, so it is difficult for me to understand where and how changes should be introduced ... Furthermore, my experience with C++ is quite limited ...

I hope that my contribution in terms of results and proposals will allow those who are able to better implement the support for CUE files in MPD.

I am however available to contribute as much as I can (build and test, documentation, etc.).

Please do it!!!
Thanks

PS: The proposed pseudocode is also listed here below (please, refer to the previously indicated work for the full understanding of the code flow).

- old pseudocode ver. 1.3 removed (deprecated)
- new pseudocode ver. 2.0 available within the provided document

[mateinegriu]

Hi,  Thanks for the detailed analysis. I think it would be desirable that at one moment we should have all the features described below. However the first step in my opinion would be at the creation/updating of the library to just automatically parse .CUE sheets when they are associated with .flac/.eac/other audio sources. Parsing .CUE files is already implemented in MPD for loading of playlists. (browsing folders and opening .CUE files results in the current playlist being populated with entries in the CUE file). So we would just need to add this existing functionality to the library parsing stage. For somebody familiar with the MPD code I assume this would be a fairly straight-forward task.  We could try and tackle some of the proposals below (discerning between PERFORMER and COMPOSER, aditional MPD tags etc) in further steps.  Thanks, Matei

[MPconta]

I would think, this issue is conected to the topic here:

#451

[nousernouser]

@mateinegriu

Please, could you delete the pseudocode quoted from my comment (as it is now deprecated since I have updated it to a new version)? Thanks