No search result with CUE file tags.

[nousernouser]

[cantata 2.2.0, mpd 0.20.15, Devuan amd64]

Most of my audio archive is made of non-splitted audio files (one flac file containing entire cd without splitting tracks) + external cue sheets.

So I started using cantata recently, looking for a mpd client with a good cue support (being not satisfied with gmpc).

Problem: searches ('Serarch' view) related to tags in the cue files do not return any result.

Example:

Any kind of search (Artist, Performer, ..., Any) for 'Pontes' give me no result, being the CUE file content:

REM DISCID "850aa60a"
REM CATALOG "0000000000000"
REM LABEL "SPA"
REM DATE "1995"
REM GENRE "Folk"
REM DISCNUMBER "1"
REM TOTALDISCS "2"
REM COMMENT ""
PERFORMER "Dulce Pontes"
TITLE "A Brisa do Coração [CD1/2]"
FILE "audiocd.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Os Índios Da Meia Praia"
    PERFORMER "Dulce Pontes"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Se Voaras Mais Perto"
    PERFORMER "Dulce Pontes"
    INDEX 01 05:35:00
...

Thank for your work and support. A.

[CDrummond]

Search in the search view is via MPD, if no results are returned then its probably an MPD issue.

Start Cantata from a terminal window using CANTATA_DEBUG=-3 cantata This will then cause Cantata to output some debug about its MPD communications. Do a search, and look for the request/response to be shown. Does it show anything useful?

Searching in the 'Library' view might work better here. If you have configured Cantata so that it can see your files, then it will split cue files into separate tracks. These can then be searched.

[nousernouser]

Thank for you response.

(a) Started Cantata with CANTATA_DEBUG=-3 cantata; heere below the request/response for searching Any: pontes:

" , socket state: QAbstractSocket::ConnectedState
MPDConnection 0x7f897e9da700 0x23b8d70 sendCommand - sent
MPDConnection 0x7f897e9da700 0x23b8d70 sendCommand: "search any "pontes"" true true
MPDConnection 0x7f897e9da700 Timeout (ms): 2000
MPDConnection 0x7f897e9da700 Socket state after write: 3
MPDConnection 0x7f897e9da700 0x23b8d70 Waiting for read data, attempt 0
MPDConnection 0x7f897e9da700 0x23b8d70 Read: "OK
" , socket state: QAbstractSocket::ConnectedState
MPDConnection 0x7f897e9da700 0x23b8d70 sendCommand - sent
MPDConnection 0x7f897e9da700 0x23b8d70 sendCommand: "status" true true
MPDConnection 0x7f897e9da700 Timeout (ms): 2000
MPDConnection 0x7f897e9da700 Socket state after write: 3
MPDConnection 0x7f897e9da700 0x23b8d70 Waiting for read data, attempt 0
MPDConnection 0x7f897e9da700 0x23b8d70 Read: "volume: -1
repeat: 0
random: 0
single: 0
consume: 0
playlist: 222
playlistlength: 24
mixrampdb: 0.000000
state: stop
song: 21
songid: 202
nextsong: 22
nextsongid: 203
OK

It seems that mpd give no result... Right? Maybe this is a mpd bug?

(b) I did not know searching in the 'Library' view was allowed (no search field or search button was displayed)... Anyway, by pressing CTRL+F the search field opened to me... and searching works quite well!

[CDrummond]

Seeing as the search is done via MPD, and response from MPD, not sure there is much I can do. Plus, as stated, you can search in Library.

[CDrummond]

MPD does not add the contents of CUE files to its DB. There is an open bug/feature request about this - https://github.com/MusicPlayerDaemon/MPD/issues/39

[nousernouser]

Il giorno Thu, 01 Feb 2018 07:50:44 +0000 (UTC) CraigD notifications@github.com ha scritto:

MPD does add the contents of CUE files to its DB. There is an open bug/feature request about this - https://github.com/MusicPlayerDaemon/MPD/issues/39

Ah ok! It is exactly what I reported...

Fortunately Cantata let us searching in the 'Library' view and this circumvent the MPD issue!

Hope MPD devs will integrate cuesheets (possibly with better tag support) into the database...

Regards

[nousernouser]

Just to inform I have added a comment to the MPD bug /feat.req. asking a solution for this.

[Thaodan]

I don't want to be to offtopic but what's the issue with having multiple flac files?

[nousernouser]

Il giorno Thu, 01 Feb 2018 05:58:49 -0800 Thaodan notifications@github.com ha scritto:

I don't want to be to offtopic but what's the issue with having multiple flac files?

Ok, sorry but this need a quite long response.

First of all I think having one_flac or multiple_flac is not a yes/no issue question. It depends. Some people prefer a music archive with only one_flac files, some prefer only multiple_flac files, others use a mixed approach.

I prefer having one_flac+cuesheet for each album. Below the main reasons.

I have a large (physical) CD and LP collection (about 1/2 are classical music albums). I have already ripped many of my CDs and LPs (but the work is still in progress) using good hw equipments and sw tools (i.e. a linux workstation with realtime audio optimization with hi-end audio interface, hi-end audio cd reader, a stereo system with hifi preamp, DAC and turntable connected with hi-end cables etc., cdparanoia, ardour etc.).

This "setup" let me to have an accurate audio digital archive of my Cds and LPs, to be used either for backup (CDs and LPs deteriorate with time and use) or for being bit-perfectly and faithfully played using my hifi DAC.

In this way ripping Cds and LPs comes to a single folder helding a single album with a single native .wav file (which can be quickly and easily converted to a .flac file) + its native .toc file including CD-TEXT if present (which can be quickly and easily converted to a .cue file). These files are all the backup files I keep archived (plus covers and other art image) and which I need either to burn a copy identical to the original or to play with a DAC or any other audio player.

Splitting them into multiple flac, fixing the cuesheet (track filenames, track timing etc.), doubling (or more) the storage occupation disk space, producing a mess of thousand files to be keeptwell named, ordered and tagged... become a detrimental nonsense if you are focused to albums (not tracks)!

More (as I have largely experimented) using single WAV/FLAC+CUE ensures burned copies will be identical to the original; coming also to a better audio playback quality sound (yes this latter might be questionable, but it is my experience which I shared with other people). Also it avoids at the root any GAP handling problems (most with live/classical albums) that in some cases you might have when burning (playing the CD copy in a CD player, the previous track would finish and the player would start counting down -00:30, -00:29, 00:28, -00:27 etc.) or playing separate track files (audio clicks).

In my collection I also have some album, wich were ripped by other people, with multiple flac + a single cue file. If they were well ripped and all timing cue/toc information are available and accurate (and I cannot know it in advance), then joining them to a single flac+cue could come to a good result when burning a CD copy and playing audio, otherwise I need to do extra work spending time... or let tracka splitted... And this is another reason for I prefer native single wav/flac + single cue files.

On the other side, people which do not have physical CDs and LPs (and do not need to backup them) and/or listen only to various (often downloaded) tracks (being focused to artists and tracks and not entire albums) and/or do not want listen to live/classical using a hifi stereo system but with different (often mobile) devices and players, may preferer using multiple track audio files.

So, in my opinion, audio players/clients suitable also for losseles high quality audio and live/classical music, should have good support for both one_flac+cue or multiple_flac+cue schemes.

Regards