Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Listing accurate Rips under 0 Confidence due to Pregap (Read 2359 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Listing accurate Rips under 0 Confidence due to Pregap

Hello

I have several CDs that were ripped without any issues with a confidence of often more than 10 or so. Though, when looking them up in CUETools under "By CTDB Confidence" they are listed under 0 confidence. Here an example (Berliner Philharmoniker - Peer Gynt Suites):

Code: [Select]
[CUETools log; Date: 26.12.2021 22:05:24; Version: 2.1.9]
[CTDB TOCID: mTWXjdr_UDtfia9xicilJdlrAIA-] found.
        [ CTDBID ] Status
        [f1ca47f9] (16/16) Has pregap length 00:00:32, Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
[AccurateRip ID: 0026ac40-01d358c8-f210b110] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL] 
 --   93.6 [FF56C0E6] [49291658]           
 01   79.0 [759C9433] [7DCC4C29]           
 02   87.0 [F72B2DFD] [2A66FA8F]           
 03   48.4 [A73D891A] [5F5F758F]           
 04   90.6 [369B38BE] [41EF6AA8]           
 05   91.1 [2DB12D9D] [8F1C9E06]           
 06   87.2 [36833A40] [0E3C0A9B]           
 07   91.3 [58B861F9] [09A239BE]           
 08   78.6 [53FC97E7] [CAF63B1F]           
 09   41.2 [27CEADD4] [232D4AF6]           
 10   31.8 [1F0A79F7] [83D34A41]           
 11   37.4 [0AB27D00] [6E4CD085]           
 12   44.6 [07F65FFB] [72232939]           
 13   41.9 [3C05B6C9] [2A3B9331]           
 14   93.1 [8492238F] [7A3E3C88]           
 15   72.0 [8DEDD017] [40E40F75]           
 16   93.6 [85546720] [BEB500F1]          
   

This seems to be due to the pregap. What is the reason for this? I mean most people probably don't really care what the pregap is. If it has a confidence of 16 I would simply expect it to see under the "< 20" folder.

Related to this: Another cool feature could be that the most common pregap value (if there is more than 1 possible pregap value detected) CUETools detects could be automatically applied for the AccurateRip check so that this would also deliver a hit. I know I can do that manually but, for example, it would be nice if CUETools automatically would apply a pregap of 00:00:32 for the CD mentioned above which would then deliver:

Code: [Select]
[CUETools log; Date: 20.02.2022 21:35:25; Version: 2.2.1]
Pregap length 00:00:32.
[CTDB TOCID: mTWXjdr_UDtfia9xicilJdlrAIA-] found.
        [ CTDBID ] Status
        [f1ca47f9] (16/16) Accurately ripped
Track | CTDB Status
  1   | (16/16) Accurately ripped
  2   | (16/16) Accurately ripped
  3   | (16/16) Accurately ripped
  4   | (16/16) Accurately ripped
  5   | (16/16) Accurately ripped
  6   | (16/16) Accurately ripped
  7   | (16/16) Accurately ripped
  8   | (16/16) Accurately ripped
  9   | (16/16) Accurately ripped
 10   | (16/16) Accurately ripped
 11   | (16/16) Accurately ripped
 12   | (16/16) Accurately ripped
 13   | (16/16) Accurately ripped
 14   | (16/16) Accurately ripped
 15   | (16/16) Accurately ripped
 16   | (16/16) Accurately ripped
[AccurateRip ID: 0026ae60-01d36be7-ee10b110] found.
Track   [  CRC   |   V2   ] Status
 01     [97198a21|1a3510a7] (02+07/13) Accurately ripped
 02     [0f85548d|ae83483f] (03+07/14) Accurately ripped
 03     [432bdf03|4edaa40e] (03+07/14) Accurately ripped
 04     [ba7b3d38|b13a1907] (03+07/14) Accurately ripped
 05     [c7a69c5b|dd6e3256] (03+07/14) Accurately ripped
 06     [921818fc|b89c60c3] (03+07/14) Accurately ripped
 07     [3818f125|7a28c475] (03+07/14) Accurately ripped
 08     [7b4b7832|fb130a3b] (03+07/14) Accurately ripped
 09     [a5a931f0|2843046a] (03+07/14) Accurately ripped
 10     [1639d56c|fb2768be] (03+07/14) Accurately ripped
 11     [e091c0bb|226a1e4b] (03+07/14) Accurately ripped
 12     [abaf0668|8159a226] (03+07/14) Accurately ripped
 13     [cd37671a|282dc383] (03+07/14) Accurately ripped
 14     [71adad4d|36853a56] (03+07/14) Accurately ripped
 15     [b213e077|f71e7d40] (03+07/14) Accurately ripped
 16     [2af8909b|2caed578] (03+07/14) Accurately ripped
Offsetted by 1301:
 01     [78b4d38a] (02/13) Accurately ripped
 02     [9fab7226] (02/14) Accurately ripped
 03     [93cd1863] (02/14) Accurately ripped
 04     [214675ff] (02/14) Accurately ripped
 05     [4d217ce0] (02/14) Accurately ripped
 06     [13137c7c] (02/14) Accurately ripped
 07     [be8b7c78] (02/14) Accurately ripped
 08     [a8ac5d32] (02/14) Accurately ripped
 09     [27576fc3] (02/14) Accurately ripped
 10     [37a4fab4] (02/14) Accurately ripped
 11     [3e0aed32] (02/14) Accurately ripped
 12     [0344c84d] (02/14) Accurately ripped
 13     [af714d23] (02/14) Accurately ripped
 14     [a13dfaed] (02/14) Accurately ripped
 15     [60b24732] (02/14) Accurately ripped
 16     [6ad91e4b] (02/14) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --   93.6 [4F6A682A] [49291658]           
 01   79.0 [759C9433] [7DCC4C29]           
 02   87.0 [F72B2DFD] [2A66FA8F]           
 03   48.4 [A73D891A] [5F5F758F]           
 04   90.6 [369B38BE] [41EF6AA8]           
 05   91.1 [2DB12D9D] [8F1C9E06]           
 06   87.2 [36833A40] [0E3C0A9B]           
 07   91.3 [58B861F9] [09A239BE]           
 08   78.6 [53FC97E7] [CAF63B1F]           
 09   41.2 [27CEADD4] [232D4AF6]           
 10   31.8 [1F0A79F7] [83D34A41]           
 11   37.4 [0AB27D00] [6E4CD085]           
 12   44.6 [07F65FFB] [72232939]           
 13   41.9 [3C05B6C9] [2A3B9331]           
 14   93.1 [8492238F] [7A3E3C88]           
 15   72.0 [8DEDD017] [40E40F75]           
 16   93.6 [85546720] [BEB500F1]          

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #1 –
Quote from: BrassDude on
If it has a confidence of 16 I would simply expect it to see under the "< 20" folder.
CTDBID f1ca47f9 has a confidence of 16. You rip accurately matched all tracks but was not a match to CTDBID f1ca47f9 because of the lack of pregap. The CTDBID for a rip without a pregap would have been different if it existed. It doesn't exist so confidence is zero. If your rip were added to the CTDB as it is without a pregap the confidence would be one (it would not be confirmed and added to the confidence of CTDBID f1ca47f9)
korth

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #3 –
A bit more context: I use EAC to rip my CDs and store my music files on a per track basis (no CD image). So the pregap info is "lost".

Once every 6 months or so I scan my music collection with CUETools and verify my rips. In this situation I see scenarios as mentioned before.

Just to be clear: I'm only asking why a CD rip that clearly has a confidence of, for example, 16 is listed under 0 confidence. This is really just about the display & grouping of the info in the "By CTDB Confidence" folder in CUETools.

At the end of the day, what I want to quickly see is which of my rips are ok and which ones are not ok. Now my rip of the Berliner Philharmoniker - Peer Gynt Suites CD looks like it would be not ok even though it is actually perfectly fine.

Also CUETools is pretty good in figuring out the pregap. So why not applying it automatically (maybe as an option?) for the AccurateRip verification?

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #4 –
Quote from: BrassDude on
A bit more context: I use EAC to rip my CDs and store my music files on a per track basis (no CD image). So the pregap info is "lost".
The pregap isn't lost, it's in the CUE sheet.
AccurateRip was built to match to individual disc pressings and the pregap is paramount to that, so nothing should be inferred where the values can't be guaranteed.

Quote from: BrassDude on
Also CUETools is pretty good in figuring out the pregap. So why not applying it automatically (maybe as an option?) for the AccurateRip verification?
I've tried verifying discs without the CUE sheet (that contains the pregap information) and I don't see this at all, I'm assuming the offset is given in this instance because you used CUERipper to rip it and it's stored in the cache somewhere, is that correct?

I rip to tracks just as you do and also run CUETools verify passes from time to time. When I rip a disc that has a pre-gap, or a track in the pregap, or is a data cd I'll create a CUE sheet that contains this metadata for verfication purposes. I have about 1300 albums and just under 300 CUE sheets, but they're trivial to create and will enable your discs to verify against both databases.

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #5 –
I throw away the CUE sheet after I rip my CDs with EAC. So I definitely do not have these around anymore.

But that is not my point at all. As I said before: Why does CUETools list something that CUETools verifies with a non-zero confidence under 0 confidence in the "By CTDB confidence" view in CUETools?

This only happens for CDs with a pregap (see my examples) and this does not really make sense to me.

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #6 –
Okay I'll try again.
The CTDB confidence in the local database is based on the full image and not the individual tracks. The full image includes the length of a disc pregap (if any exist), the audio data (all tracks combined excluding some frames from the beginning of the first track and the end of the last track), and the length of any data tracks (if any exist).

The first log is telling you that there is a CTDBID with a pregap length of 00:00:32 and that all the tracks from your rip are a match. It is not telling you that your rip matched the image in the database exactly with a non-zero confidence. It's telling you that your rip was different by a length of 32 frames.

The second log (after you applied the pregap) was an exact match with a non-zero confidence. There are no additional notes in the CTDBID stating that there was a difference.
korth

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #7 –
Quote from: BrassDude on
A bit more context: I use EAC to rip my CDs and store my music files on a per track basis (no CD image). So the pregap info is "lost".
[...]
At the end of the day, what I want to quickly see is which of my rips are ok and which ones are not ok. Now my rip of the Berliner Philharmoniker - Peer Gynt Suites CD looks like it would be not ok even though it is actually perfectly fine.
CUETools can identify a CD from
* cuesheet, or
* EAC log, or
* CDTOC tag, or
* ACCURATERIPID tag
(possibly also dBpoweramp's "AccurateRipDiscID, I don't remember).

If you run CUETools with with the option to write tags upon verification, it will write CDTOC and ACCURATERIPID. Don't throw away EAC logs or cuesheets until you have done that.

Meanwhile, you can try https://www.dbpoweramp.com/perfecttunes.htm for verification, and to get out an AccurateRip identification for (manual) tagging.

What you can try to: Create a 32-frames

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #8 –
Another thing to note is that the "pregap" before track one sometimes contains audio. Even if it is only one sample, replacing it with silence will produce a different result. Rarely, there can be whole songs hidden before the track one marker.

Re: Listing accurate Rips under 0 Confidence due to Pregap

Reply #9 –
I understand that if I only store the individual tracks without the cuesheet it will never exactly match and the best I can get is that all the tracks from my rip are a match to CTDBID with a pregap (in my example 00:00:32). If I'm not mistaken this is called a pressing match. In my case the pressing match would have a confidence of 16.

Let me then rephrase this as a feature request: It would be great to additionally have a view in CUETools where the CDs are listed by CTDB pressing match confidence.