Recently v2.8.1 came over the wire. For some reason my installation has switched figuring out how to calculate the disc id. Previously (as I understand the code) abcde would call abcde-musicbrainz-tool with the 'id' command. That would call the musicbrainz perl library, which would then call a c library, which would return the discid. With 2.8.1 the processing changed so that abcde-musicbrainz-tool is called with the 'calcid' command, which attempts to replicate the musicbrainz c library calculation. I am attempting to rip this cd: https://musicbrainz.org/release/812b7543-8126-4869-b2d3-0ab2eb16c835 If I call "abcde-musicbrainz-tool --command id" the output is "j8anAjQyKxealyzRquW0VCwrfbA- 21 180 15432 28204 38311 45867 60326 70496 92880 101984 124801 138162 155721 173154 189189 198360 220171 237208 245017 262510 280378 309659 4346" with the first item being the discid, the correct one as far as musicbrainz is concerned. If I run abcde 2.8.1, it calls abcde-musicbrainz-tool as: abcde-musicbrainz-tool --command calcid --discinfo 1 21 150 325802 30 15282 28054 38161 45717 60176 70346 92730 101834 124651 138012 155571 173004 189039 198210 220021 237058 244867 262360 280228 309509 and that returns a discid = 2lHKZKdjZTAwU6PeQu_X2wo5o_A- The code for calculating the discid does not seem to have changed from v2.7.2. What seems to have changed is that instead of using the "id" command to calculate the discid, abcde v2.8.1 now calls abcde-musicbrainz-tool with the "calcid" command, and that command returns the wrong value. I can't say if it is my .abcde.config that has changed the behavior or not, but I can say that the result of the "calcid" command is not correct. I am having the same problem on all cds I have looked at.
I edited my .abcde.config and set: CDDBMETHOD=cddb This works around the issue. I note that it was set to 'musicbrainz' before I made the change. Since I hadn't seen this issue before, I'm guessing that the setting was ignored.
I have done some more testing, and in a very small sample (eleven CDs) I have found that somewhere near 50% get the right discid and the other half don't. These tests have been done against CDs that are recognized by musicbrainz Picard, so I know they exist in the musicbrainz db. Further they all work if I change out the method for calculating the discid. Through some further research in the code I have found the change that has brought on this problem. In do_discid() there is a section in a case statement that has an option "cdparanoia|debug)". This was commented out in 2.7.2, but is active in 2.8.1. The last step in this calls "makeids", which is what calls abcde-musicbrainz-tool in the way it hadn't in the past. Regarding my previous comment, I have found that changing to CDDB does much more that change the method of calculating the discid. I have changed my .abcde.conf back to "musicbrainz", but I have also changed the call to "makeids" in abcde (approximately at line 2015) to use the method for calculating the discid in the default case instead: < makeids > case "$CDDBMETHOD" in > cddb) TRACKINFO=$($CDDISCID "$CDROM") ;; > musicbrainz) TRACKINFO=$($MUSICBRAINZ --command id --device "$CDROM") ;; > esac
*** Bug 61 has been marked as a duplicate of this bug. ***
Created attachment 51 [details] Replace call to makeids with calls to external discid programs Per the workaround suggested by abcde@jrdev.com, this patch re-instates the external utilities. ** This is a workaround, versus actually fixing makeids **
Worth pointing out in this bug that petecollins24 suggested a possible fix to makeids in his duplicate bug 61. I don't know how best to address it but it looks like he has pretty much solved the issue and it comes down to someone aware of possible side-effects to implement it. To quote what he said there (with subsequent edits): "On the call to musicbrainz to get DISCID in line 495, it seems the LEADOUT number should be increased by the value of the PREGAP number to get the correct DISCID. This clearly doesn't matter if the PREGAP is 0 but a non-zero PREGAP gets the wrong DISCID."
+1 Ashley. Looks like we have a ready to implement solution. https://www.internetvergelijken.nl/g
Hi! Thanks for the clue in Bug 61 and the suggested fix. I don't know of any of my CDs that exhibit the problem, but I've just committed this fix in git now. Please test and confirm?
I wish I had put in more CDs to test. I have just received 2.9.1. The two commands, abcde-musicbrainz-tool --command id and abcde-musicbrainz-tool --command calcid --discinfo 1 21 150 325802 30 15282 28054 38161 45717 60176 70346 92730 101834 124651 138012 155571 173004 189039 198210 220021 237058 244867 262360 280228 309509 still return the values they returned in my comments, i.e. the wrong value for the first and the right for the second. That said, abcde now finds the correct disc at musicbrainz, so I'm assuming that it is no longer calling "--command id" path. The CD I used to demonstrate the bug seems to work now. I will keep alert in case this is somehow locally-cached data, but I don't think so.
Hi! The --command id syntax will only be used in a few cases, basically if you're not reading from flac files or using cdparanoia. I'm travelling atm and don't have a drive with me to test, so can't really say much more at the moment...
Hi abcde@jrdev.com, I hope I've understood your comment correctly but I think you would expect the two commands, abcde-musicbrainz-tool --command id and abcde-musicbrainz-tool --command calcid --discinfo 1 21 150 325802 30 15282 28054 38161 45717 60176 70346 92730 101834 124651 138012 155571 173004 189039 198210 220021 237058 244867 262360 280228 309509 to still produce different results as abcde-musicbrainz-tool has not been changed. A fix was made to abcde in 2.8 to increase the LEADOUT number by the PREGAP number. If you change the above call to increase the LEADOUT 325802 by the PREGAP number 30 abcde-musicbrainz-tool --command calcid --discinfo 1 21 150 325832 30 15282 28054 38161 45717 60176 70346 92730 101834 124651 138012 155571 173004 189039 198210 220021 237058 244867 262360 280228 309509 then you will get the same correct answer for both calls - j8anAjQyKxealyzRquW0VCwrfbA-