Bug 45 - Locally cached CDDB entries are not queried when converting single FLAC file to Vorbis
Summary: Locally cached CDDB entries are not queried when converting single FLAC file ...
Status: CONFIRMED
Alias: None
Product: abcde
Classification: Unclassified
Component: CD lookup (show other bugs)
Version: unspecified
Hardware: PC Linux
: Normal normal
Assignee: Steve McIntyre
URL:
Depends on:
Blocks:
 
Reported: 2016-11-06 14:32 GMT by MontyHimself
Modified: 2018-02-21 21:20 GMT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MontyHimself 2016-11-06 14:32:54 GMT
Whenever I try to encode a single FLAC file with embedded cue sheet to Vorbis, the locally cached CDDB entries in ~/.cddb are not queried. They are certainly there, though, I checked manually. When I rip a CD to a single FLAC file, it works flawlessly (like when I want to rip a CD that I have ripped before), but when I then try to convert this file to individual Vorbis files, the CDDB entries are not recognized anymore. The weird thing about this is that it works when I use one of the older FLAC files that I ripped in the past on Ubuntu with abcde v2.7.1. I recently switched to Fedora and only the newer ones which I ripped with abcde v2.7.2 on Fedora have this issue.

This leads me to believe that the issue lies within the ripped FLAC files themselves. One thing that changed when switching from Ubuntu to Fedora and with it from abcde v2.7.1 to v2.7.2 is that I now have to use abcde's internal implementation of mkcue, since there is no package for mkcue in Fedora. Maybe this is the source of the problem.

Here is the command line output:

$ abcde -d The\ Reprise\ Collection\ \[Disc\ 4\].flac
[WARNING] switching to flac CDROMREADERSYNTAX...
Executing customizable pre-read function... done.
Getting CD track info... Grabbing entire CD - tracks: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20
Checking CDDB server status...
Querying the CDDB server...
Obtaining CDDB results...
Retrieving multiple matches... done.
Which entry would you like abcde to use (0 for none)? [0-3]:

I would expect to be asked if I want to use the locally cached CDDB entry for this CD, but as you can see this doesn't happen.

Here is my abcde.conf for converting to Vorbis:
http://pastebin.com/raw/sHiyYBa5

Here is the one for ripping CDs to FLAC files (the only thing I changed when switching to Fedora was replacing mkcue with abcde.mkcue):
http://pastebin.com/raw/HHkqLYXb

Here is the embedded cue sheet for a new FLAC file, ripped with v2.7.2 on Fedora (exported with metaflac):
http://pastebin.com/raw/JTzTN0v9

Here is the separate cue sheet for the new FLAC file, ripped with v2.7.2 on Fedora:
http://pastebin.com/raw/GzJxN1Z4

The cue sheets for the older FLAC files don't seem to contain any important additional information.

Here is the embedded cue sheet for an old FLAC file, ripped with v2.7.1 on Ubuntu (exported with metaflac):
http://pastebin.com/raw/8wjKTxaN

Here is the separate cue sheet for the old FLAC file, ripped with v2.7.1 on Ubuntu:
http://pastebin.com/raw/etfhFmM3
Comment 1 Nino Burini 2016-11-08 18:59:19 GMT
I've stumbled in this problem, which eventually led me to open issue 47: https://abcde.einval.com/bugzilla/show_bug.cgi?id=47

I found that the problem was in the cue files generated with the single-file flac rip.
When ripping from cd, the discid used to query CDDB is generated with cd-discid.
When you are ripping Ogg Vorbis files from the resulting flac, the discid is instead generated from the cue file.
I noticed that the two discids were different, which of course caused a cache-miss.

I tried using MKCUE="mkcue" and MKCUE="abcde.mkcue" in the configuration file, but I didn't notice any difference.

Then, reading in the documentation and the code, I noticed that abcde.mkcue() accepts a --wholedisk option, which basically determines how the cue file is written. So I set MKCUEOPTS="--wholedisk" in the configuration file, and noticed that it made no difference.

Further digging led me to open the aforementioned issue and submit a patch. Applying the patch fixed the problem and the cache-miss, at least for me.
Comment 2 Steve McIntyre 2018-02-21 21:20:09 GMT
I've just applied Nino's patch from Bug 47 in git. Could you test and confirm if this fixes your bug too please?