Accurip found but also not found

[Daniel6372]

    Accurip:          found (max confidence: 2)
    EAC CRC32:        0D28EDC4
    Accurip v1:       0C0BF6BD (not found in the Accurip database)
    Accurip v2:       A34CF5D9 (not found in the Accurip database)
    Accurip v1 450:   48D78CE5 (not found in the Accurip database)

Accurip result returns "found (max confidence: 2)", even though both v1 and v2 returned "not found in the Accurip database" This happens with all the tracks on the CD.

Before this I ripped another CD not present in the database, and it didn't have this issue. Main difference is that one also wasn't in MB's db, so it was ripped as Unknown disc. The former disc is also badly damaged and unable to rip properly.

    Accurip:          not found
    EAC CRC32:        7E5A37B0
    Accurip v1:       5D99F435
    Accurip v2:       C061540D
    Accurip v1 450:   EE8483F9

[cyanreg]

That's just unfortunately bad wording. Accurip: found (max confidence: 2) means that the disc has been successfully found in the Accurip database (done TOC, no audio data involved at all). Accurip v1: 0C0BF6BD (not found in the Accurip database) means that the audio data doesn't match any of the Accurip entries. Accurip doesn't tell you if a disc has been badly ripped, only if it has been found or not.

[Daniel6372]

I see, thanks for the clarification. As the CD is badly damaged, it returns random checksums with every rip, so it makes sense that it's not found in the databases.

I was actually just going to open another issue for this: Other rippers (EAC, whipper) rip each track twice to compare the checksums and make sure it's accurately ripped. Cyanrip doesn't seem to do this and is actually able to rip most of the tracks on my CD and reports Track 1 ripped and encoded successfully!, but with each track having different checksums on subsequent ripping attempts. The aforementioned programs report that the checksums did not match (e.g. whipper gives INFO:whipper.program.cdparanoia:checksums do not match, cdb5fac0 a9873f55) and then proceed to retry until they do match or the max number of retries is reached.

This means that cyanrip is able to "successfully" rip damaged CD's but the resulting files are not accurate to the data on the disc. This would also mean that any disc not found in the database would currently need to be ripped twice with cyanrip in order to verify a good rip.

[cyanreg]

Could you test https://github.com/cyanreg/cyanrip/tree/accurip_test Sentencing should be better, and accurip is such an awful SUM, maybe it's worth comparing bits, so report if the 450 checksum has any percentage match.

I'll write an extreme mode that rips multiple times. But I'm not entirely sold on the premise that it's not accurately ripped - it's in the database. There may be multiple equally valid ways of ripping, each changing on how the hard drive/ripper does error correction. Even if it's stable, it's stable just for a sample size of 1.

[cyanreg]

Also, does setting -r to a really high number (thousands) still create rips with different checksums?

[Daniel6372]

The 450 sums did match on my initial tests, at least for the first track (didn't test the rest). I can test the accurip_test branch with -r set to something really high, but I'm not expecting to be able to rip a single track accurately due to the condition of the CD.

[Daniel6372]

Attempt 1:

Preemphasis:      none detected
    Cover art:        Motion JPEG
    Duration:         00:01:57.060
    Samples:          5159700
    Frames:           8775
    Pregap LSN:       0
    Start LSN:        25
    End LSN:          8799
    Offset end:       8800
    Accurip:          disc found in database (max confidence: 2)
    EAC CRC32:        EB1E3894
    Accurip v1:       370A9CE0 (not found, either a new pressing, or bad rip)
    Accurip v2:       94141246 (not found, either a new pressing, or bad rip)
    Accurip v1 450:   A79ACE46 (not found, 53.12% match)

Attempt 2:

Preemphasis:      none detected
    Cover art:        Motion JPEG
    Duration:         00:01:57.060
    Samples:          5159700
    Frames:           8775
    Pregap LSN:       0
    Start LSN:        25
    End LSN:          8799
    Offset end:       8800
    Accurip:          disc found in database (max confidence: 2)
    EAC CRC32:        7A810159
    Accurip v1:       12EB4AAC (not found, either a new pressing, or bad rip)
    Accurip v2:       70BD3BD4 (not found, either a new pressing, or bad rip)
    Accurip v1 450:   A79ACE46 (not found, 53.12% match)

-r was set to 10000 for both

[cyanreg]

Thanks, I'll keep the new accurip changes, I guess. I've updated the branch and added an extreme mode. Enable it with -Z 1 (means after ripping each checksum has to match at least one previous checksum), or 2, or however many times you'd like for a checksum to have a previous match. Do test and report if it works.

[Daniel6372]

It seems to be working just fine. The rip doesn't progress beyond track 1, which is the expected behavior.

Ripping track 1, progress - 100.00%, ETA - 38m   
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 100.00%, ETA - 37m
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 100.00%, ETA - 37m
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 100.00%, ETA - 36m
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 100.00%, ETA - 35m
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 100.00%, ETA - 34m
Repeating ripping (0 out of 1 matches for current checksum)
Ripping and encoding track 1, progress - 26.83%, ETA - 35m 

Thanks!

[Daniel6372]

One minor issue, upon quitting it seems to repeat the ripping 2 more times without actually doing anything, judging by the output, I'm guessing both of these return 000000 and it says 1/1 match.

^C
Trying to quit

Stopping, ripping incomplete!

Repeating ripping (0 out of 1 matches for current checksum)

Stopping, ripping incomplete!

Done; (1 out of 1 matches for current checksum)

Flushing encoders...
    File(s):
        Szabad-e bejönni ide betlehemmel？ [FLAC]/01 - Csordapásztorok.flac
    Metadata:
        mbid: 3bfdcb71-ec88-41fe-9d23-68f244601d34
        title: Csordapásztorok
        artist: Kaláka
        track: 1
        tracktotal: 30
        discid: 9G08C9sQ0CQoMQnKFKUFe9x_1xc-
        cddb: C90EA81E
        media_type: CD
        comment: cyanrip 0.9.0
        date: 1990
        release_id: ae64d2cb-8e47-47e3-ab7e-fdce16c9c13d
        album: Szabad-e bejönni ide betlehemmel?
        country: HU
        status: Official
        album_artist: Kaláka
        totaldiscs: 1
        disc: 1
        format: CD
        creation_time: 2023-07-05T01:14:44
    Preemphasis:      none detected
    Cover art:        Motion JPEG
    Duration:         00:01:57.060
    Samples:          5159700
    Frames:           8775
    Pregap LSN:       0
    Start LSN:        25
    End LSN:          8799
    Offset end:       8800
    Accurip:          disc found in database (max confidence: 2)
    EAC CRC32:        00000000 (after 10 rips)
    Accurip v1:       00000000 (not found, either a new pressing, or bad rip)
    Accurip v2:       00000000 (not found, either a new pressing, or bad rip)
    Accurip v1 450:   00000000 (not found, 53.12% match)

Tracks ripped accurately: 0/30

Paranoia status counts:
    READ:          7939
    VERIFY:        3062
    FIXUP_ATOM:    12518
    OVERLAP:       1025

Ripping errors: 0
Ripping finished at 2023-07-05T01:24:58

[cyanreg]

If ripping is incomplete, checksums are all meaningless anyway. I've updated the branch. -r now controls how many times to repeat ripping in total. -r 10 will stop after 10 attempts.

[Daniel6372]

Tested this and it doesn't seem to work. It does 1 attempt only.

cyanrip -s 6 -Z 1 -r 5

Ripping track 1, progress - 100.00%, ETA - 34m   
Done; (no matches found, but repeat limit of 5 hit)

[Daniel6372]

I also think that when the -Z option is used, if the specified number of matches is not achieved, ripping should stop and not continue with the next track. As that's the point of the option - make sure that you don't end up with a bad rip.

[cyanreg]

Fixed, and pushed to master. Decided to not exit if retries fail - better to have something than nothing. Hardly much you can do, other than carefully resurface the plastic with superglue - if the CD isn't rotted. Thanks.

[Daniel6372]

I'm assuming these should both say 10 is the default: https://github.com/cyanreg/cyanrip/blob/d457cd5ae181931e4c6b86979ae7a1ab174004ab/README.md?plain=1#L90 https://github.com/cyanreg/cyanrip/blob/d457cd5ae181931e4c6b86979ae7a1ab174004ab/src/cyanrip_main.c#L1404 Thanks again for adding this feature!