Clarity of log messages

[pmoris]

1. When ripping a cd that does not exist at all in AccurateRip, the final terminal stdout reads:

track 1: rip NOT accurate (max confidence 6) v1 [63720ac4], v2 [597c862e], DB [b16ef3bd]

This confused me at first, until I checked the log file itself, which clearly states that the tracks are not present in AccurateRip:

    Test CRC: FF8977DF
    Copy CRC: FF8977DF
    AccurateRip v1:
      Result: Track not present in AccurateRip database
    AccurateRip v2:
      Result: Track not present in AccurateRip database
    Status: Copy OK

Perhaps the message could be clarified for new users like myself?

Additionally, am I correct in assuming that the rip is still probably OK in this case, since the test and copy CRC values match? I've tried to verify myself by ripping the CD twice and comparing the resulting FLAC files too.

I observed the same issue for another cd where all but one track were present in AccurateRip. The terminal output simply stated that the rip was “NOT accurate,” even though the test and copy CRCs match according to the full log file.

As an aside, is this missing track problem a common situation with AccurateRip, or could this indicate something going wrong on whipper’s side?

---

2. Similarly, one of the CDs in my collection has a "copy controlled technology" label, and indeed my rip attempts have proven unsuccessful so far. However, no log file gets written out (I guess this only happens for successful rips?), and I initially overlooked the stderr output about the test/copy CRCs (INFO:whipper.program.cdparanoia:checksums do not match, 50a53a2c 14a34a83), because I was capturing everything with a regular redirect instead of using 2>&1).

Perhaps a helpful message can be printed at the stdout level of whipper too when rip attempts fail due to CRC mismatches (rather than mismatches against AccurateRip)?

Verifying track 1 of 13 (try 5) (3 of 8) ...   0 %
I am doing something. (4 of 8) ...   0 %          
I am doing something. (4 of 8) ...   0 %          
Encoding track to FLAC (5 of 8) ...   0 %         
Encoding track to FLAC (5 of 8) ...   0 %         
I am doing something. (6 of 8) ...   0 %          
I am doing something. (6 of 8) ...   0 %          
Calculating peak level (7 of 8) ...   0 %         
Calculating peak level (7 of 8) ...   0 %         
Writing tags to FLAC (8 of 8) ...   0 %           
INFO:whipper.program.cdparanoia:checksums do not match, 50a53a2c 14a34a83
Writing tags to FLAC (8 of 8) ...   0 %           
CRITICAL:whipper.command.cd:giving up on track 1 after 5 times
                                                  
track can't be ripped. Rip attempts number is equal to 'MAX_TRIES'

I guess that #612 might alleviate this problem though.

Related topic I found about copy control: https://hydrogenaudio.org/index.php/topic,47872.0.html

3. Lastly, is there any additional documentation explaining the various log messages and how to interpret them? For example:,

• What is the content of the 3 columns (v1, v2, DB) in the accuraterip output on the terminal?
• The log file contains a file SHA-256 checksum. Is this the checksum of the entire folder after ripping? Of a multi-track flac file? Of the wav? It seems to differ between multiple rips of the same cd, so I assume it also hashes the log file itself?
• What is the meaning of the x of y part of these log messages? Reading track 1 of 13 (try 2) (1 of 8) ... 0 %

All that said, thanks a bunch for all the effort that's gone into this tool. It's been great to use overall!

[github-actions]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing instructions.

[MerlijnWajer]

To be clear, the first two parts that you provided contain different checksums, are those for the same track, or is the second part a separate part from the log file? Would you mind sharing the full log file here?

[pmoris]

Oh, I should have clarified. Those sections are indeed from two different log files for two different albums. I've attached both here:

1. whipper log file for cd not in accuraterip: missing-accuraterip.log
   Terminal output for the same cd (I only captured stdout here unfortunately): missing-accuraterip.stdout

2. Terminal output (2>&1) for copy-controlled cd: copy-control-cd.stdout

[pmoris]

Just to add to this, running whipper image verify <.cue> on the album that was not present in AccurateRip, also returns a rip NOT accurate warning, without informing the user that the tracks just couldn't be found.

Oddly enough, it does state that it found 3 responses (while the initial rip log shows no responses at all):

INFO:whipper.common.program:3 AccurateRip response(s) found
track  1: rip NOT accurate (max confidence      6) v1 [63720ac4], v2 [597c862e], DB [b16ef3bd]
track  2: rip NOT accurate (max confidence      6) v1 [1c8c8a2b], v2 [c6f0bd10], DB [1f08b4be]
track  3: rip NOT accurate (max confidence      6) v1 [af3e6712], v2 [e4b44069], DB [e382fbb3]
track  4: rip NOT accurate (max confidence      6) v1 [56e3db45], v2 [18d1f34c], DB [af3603bb]
track  5: rip NOT accurate (max confidence      6) v1 [1f7c4b70], v2 [bc691fa3], DB [65ece739]
track  6: rip NOT accurate (max confidence      6) v1 [cd8e2b01], v2 [c98b3f8d], DB [c04b9e34]
track  7: rip NOT accurate (max confidence      6) v1 [ec60f7e5], v2 [e76d724d], DB [26a64012]
track  8: rip NOT accurate (max confidence      6) v1 [198eed5d], v2 [bce0358d], DB [bb3931a0]
track  9: rip NOT accurate (max confidence      6) v1 [30f778b9], v2 [2fd879ef], DB [bc845ca5]
track 10: rip NOT accurate (max confidence      5) v1 [d641fccd], v2 [6d134f90], DB [76f126be]
track 11: rip NOT accurate (max confidence      6) v1 [4fe0b954], v2 [89456abb], DB [0203ad8d]
track 12: rip NOT accurate (max confidence      6) v1 [4a49aa44], v2 [4bfe387b], DB [6ec0eae3]
track 13: rip NOT accurate (max confidence      6) v1 [013eaed1], v2 [9c0bef98], DB [d7b0dc94]
track 14: rip NOT accurate (max confidence      6) v1 [9a8cdc8e], v2 [d11c40ca], DB [1560c3a5]
track 15: rip NOT accurate (max confidence      6) v1 [5bb62002], v2 [1ef9475f], DB [8d04e9e2]
track 16: rip NOT accurate (max confidence      6) v1 [843ecea3], v2 [0e4d30af], DB [ee912928]

[drjaska]

1. I would like to see this changed myself too tbh.

---

2. AccurateRip checksum mismatches cannot make it fail AFAIK. For me it was intuitive that you're comparing 2 track reads against each other and then compare your track copy to remote checksums. The wording wasn't super intuitive but changing it now could break some various scripts which rely on parsing our output.

You could try cdparanoia for the CC CD and manually rerip until you get a copy from which you can't hear any audio glitches. If you can't get that then I would recommend finding the media elsewhere but I don't have any experience with whipper failing on CC CDs for the 2 or 3 I've found :/

---

3. Probably not :S

Q: What is the content of the 3 columns (v1, v2, DB) in the accuraterip output on the terminal?A: v1 and v2 are different AccurateRip checksum calculation methods. DB is for the received AR DataBase reply, it should match your v2.

Q: The log file contains a file SHA-256 checksum. Is this the checksum of the entire folder after ripping? Of a multi-track flac file? Of the wav? It seems to differ between multiple rips of the same cd, so I assume it also hashes the log file itself?
A: It is the hash of the log file, an attempt to prevent manual editing etc.

Q: What is the meaning of the x of y part of these log messages? Reading track 1 of 13 (try 2) (1 of 8) ... 0 %
A: I have no idea where you have seen this print or what the 1/8 could mean. I have no seen it myself and "Reading track" is only used for offloaded cdparanoia calls in whipper/program/cdparanoia.py.

---

the album that was not present in AccurateRip

INFO:whipper.common.program:3 AccurateRip response(s) found

Are you sure that it was not in AccurateRip? An actual 404 looks like this for me

$ whipper image verify 'Various Artists - Suomipoppia (Disc 1 of 2).cue'
INFO:whipper.image.cue:parsing .cue file 'Various Artists - Suomipoppia (Disc 1 of 2).cue'
INFO:whipper.image.cue:parsing .cue file 'Various Artists - Suomipoppia (Disc 1 of 2).cue'
ERROR:whipper.common.accurip:error retrieving AccurateRip entry: HTTP Error 404: Not Found
WARNING:whipper.common.accurip:entry not found in AccurateRip database
AccurateRip entry not found
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 1
track  1: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 2
track  2: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 3
track  3: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 4
track  4: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 5
track  5: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 6
track  6: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 7
track  7: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 8
track  8: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 9
track  9: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 10
track 10: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 11
track 11: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 12
track 12: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 13
track 13: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 14
track 14: unknown          (error)
ERROR:whipper.common.accurip:no track AR CRC on non-HTOA track 15
track 15: unknown          (error)

I have found a few CDs which seem to have bogus checksums in AccurateRip, no matter what drives I test those on I get the same """incorrect""" results, while over 90% of my CDs work just fine. I assume that you hit one of those too. For example I have this which looks like yours.

$ whipper image verify 'Various Artists - Pokémon: The First Movie: Music From and Inspired by the Motion Picture.cue'
INFO:whipper.image.cue:parsing .cue file 'Various Artists - Pokémon: The First Movie: Music From and Inspired by the Motion Picture.cue'
INFO:whipper.image.cue:parsing .cue file 'Various Artists - Pokémon: The First Movie: Music From and Inspired by the Motion Picture.cue'
INFO:whipper.common.program:6 AccurateRip response(s) found
track  1: rip NOT accurate (max confidence      8) v1 [27b1ffb6], v2 [8eb15cbc], DB [a0396935]
track  2: rip NOT accurate (max confidence      6) v1 [ce77cadd], v2 [4c2cfefa], DB [a087f41d]
track  3: rip NOT accurate (max confidence      8) v1 [9a635289], v2 [138a8113], DB [8b1d711d]
track  4: rip NOT accurate (max confidence      8) v1 [63530d55], v2 [3248ebe0], DB [0e7f23e9]
track  5: rip NOT accurate (max confidence      8) v1 [7aa7615a], v2 [171bd4c8], DB [b95998d1]
track  6: rip NOT accurate (max confidence      7) v1 [f0a4c356], v2 [983038f8], DB [487dcb0b]
track  7: rip NOT accurate (max confidence      7) v1 [4dffaeca], v2 [7d97eab5], DB [0df931e0]
track  8: rip NOT accurate (max confidence      7) v1 [d24fe58c], v2 [e43a98f1], DB [52898265]
track  9: rip NOT accurate (max confidence      7) v1 [e4b33f4a], v2 [52ed24f3], DB [7fdb3ebc]
track 10: rip NOT accurate (max confidence      7) v1 [6670af08], v2 [4060b8d6], DB [b58c6d22]
track 11: rip NOT accurate (max confidence      6) v1 [6ff3c731], v2 [7ee99061], DB [beffb267]
track 12: rip NOT accurate (max confidence      8) v1 [54f7676d], v2 [7752ee76], DB [0ee9773b]
track 13: rip NOT accurate (max confidence      7) v1 [3ae71986], v2 [45cfd6d0], DB [87533598]
track 14: rip NOT accurate (max confidence      7) v1 [f5d5ae9b], v2 [91b5f29d], DB [06e41c3e]
track 15: rip NOT accurate (max confidence      6) v1 [fd88c5c6], v2 [1058c26e], DB [aac9cf39]
track 16: rip NOT accurate (max confidence      6) v1 [a56cb21c], v2 [cb79b117], DB [3f0bbc04]

Log file's end looks like this for ^

    AccurateRip v1:
      Result: Track not present in AccurateRip database
    AccurateRip v2:
      Result: Track not present in AccurateRip database
    Status: Copy OK

Conclusive status report:
  AccurateRip summary: None of the tracks are present in the AccurateRip database
  Health status: No errors occurred
  EOF: End of status report

[pmoris]

Cheers for the elaborate reply! Really appreciate you took the time to write all that out.

Q: What is the meaning of the x of y part of these log messages? Reading track 1 of 13 (try 2) (1 of 8) ... 0 %
A: I have no idea where you have seen this print or what the 1/8 could mean. I have no seen it myself and "Reading track" is only used for offloaded cdparanoia calls in whipper/program/cdparanoia.py.

Those log messages just appear in my terminal output when ripping. Looking at them more closely, I suspect these are just the steps wipper is taking for each individual track (Reading track 4 of 19 (1 of 9) => I am doing something. (2 of 9) ... => Verifying track 4 of 19 (3 of 9) => etc.), and the number of steps changed when I switched to the latest version of whipper instead of the one in the fedora stable repo.

I have found a few CDs which seem to have bogus checksums in AccurateRip, no matter what drives I test those on I get the same """incorrect""" results, while over 90% of my CDs work just fine. I assume that you hit one of those too. For example I have this which looks like yours.

Ohh, that could be it. Very odd!