Skip to main content

Topic: CUETools versions 1.9.5 through 2.1.5 (current) (Read 1314283 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2000
Still another question:
When release dates are retrieved then the months January till September appear as one digit (1..9). Is it possible to change it automatically to a 2-digit-date with a leading 0?

first of all for %releasedateandlabel%

  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2001
I know that I ripped the CD accurately. But why there are 2 different CTDBIDs who confirm this?
Is it possible that 'Has no data track' is missing for the 1st one?


Quote
[CUETools log; Date: 10.10.2012 23:11:13; Version: 2.1.4]
CD-Extra data track length 07:33:60.
[CTDB TOCID: nd2_lfG342KoooYh.9YZYju3Ywo-] found.
        [ CTDBID ] Status
        [9f992239] (02/14) , Accurately ripped
        [cde4cd51] (08/14) Accurately ripped
        [a0061e98] (02/14) No match
        [c5d25191] (01/14) Has no data track, No match
        [0d1f3470] (01/14) No match
Track | CTDB Status
  1  | (10/14) Accurately ripped
  2  | (10/14) Accurately ripped
  3  | (11/14) Accurately ripped
  4  | (11/14) Accurately ripped
  5  | (11/14) Accurately ripped
  6  | (11/14) Accurately ripped
  7  | (11/14) Accurately ripped
  8  | (11/14) Accurately ripped
  9  | (11/14) Accurately ripped
10  | (11/14) Accurately ripped
11  | (14/14) Accurately ripped
12  | (14/14) Accurately ripped

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2002
The first one should say something like "has data track length 08:05:15," (link).
I'm sure Gregory will address in the next build.
korth

  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2003
The first one should say something like "has data track length 08:05:15," (link).
I'm sure Gregory will address in the next build.


I still do not really understand. Does the CD exist with 2 different data track length or why a length of 07:33:60 is reported in my report?

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2004
Nothing is actually stored about the data track in the CTDB except for the length. The length is more important when calculating the correct AccurateRip ID than for verifying within the CTDB. Entries under the same CTDB TOCID can include different pressings which may have different CD-Extra data track lengths or no CD-Extra data track at all. 

CD-Extra data track length 07:33:60.
[CTDB TOCID: nd2_lfG342KoooYh.9YZYju3Ywo-] found.
[ CTDBID ] Status
[9f992239] (02/14) Has data track length 08:05:15, Accurately ripped
(added corrected text)
There are two database entries with a CD-Extra data track length 08:05:15. All 12 audio tracks match your rip.
[cde4cd51] (08/14) Accurately ripped
There are  eight database entries with a CD-Extra data track length 07:33:60. Data track length and all 12 audio tracks match your rip. 
[a0061e98] (02/14) No match
There are two database entries with a CD-Extra data track length 07:33:60. Data track length matches but one or more tracks don't match.
[c5d25191] (01/14) Has no data track, No match
There is one database entry without a data track. One or more tracks don't match.
[0d1f3470] (01/14) No match
There is one database entry with a CD-Extra data track length 07:33:60. Data track length matches but one or more tracks don't match.

CUETools log wiki page.
  • Last Edit: 11 October, 2012, 05:34:34 PM by korth
korth

  • Corwin
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2005
Here's another example of the CTDB numbers not adding up:
Code: [Select]
[CUETools log; Date: 10/11/2012 3:18:51 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: bjRBzVtEMk2_s9NYv_2Zbcz7LTI-] found.
        [ CTDBID ] Status
        [1fc0dcb6] (1/2) Accurately ripped
        [061116fa] (1/2) No match
Track | CTDB Status
  1   | (2/2) Accurately ripped
  2   | (2/2) Accurately ripped
  3   | (2/2) Accurately ripped
  4   | (2/2) Accurately ripped
  5   | (2/2) Accurately ripped
  6   | (2/2) Accurately ripped
[AccurateRip ID: 000e3fb7-0048d2c6-490d3306] found.
Track   [  CRC   |   V2   ] Status
01     [cc741c29|0af09c97] (02+00/21) Accurately ripped
02     [dfb97852|053ed17d] (02+00/21) Accurately ripped
....


  • PlexCSI
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2006
If I leave the track naming to the default in CueTools (%tracknumber%. %title%) and do a conversion, my track number tags come out correct.

However, if I modify the track naming to look more like Picard (%discnumber%-%tracknumber%. ...), all tracks on disc 1 are tagged as track 1, and all tracks on disc 2 are tagged as 2. CueTools seems to be extracting part of the filename to insert as the track tag? Is there a way to change this behavior?

I've got the code checked out and I've got functional builds, so I might look at fixing it myself. Is there any particular reason it behaves this way at present?

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2007
Could not duplicate your result using "Audio Filenames: Track format: %discnumber%-%tracknumber%. %title%" and converting with flac input/output in windows.
All CUE file text, audio file tags and file names output as expected. Perhaps some additional information needed that you did not disclose?

BTW, I would use "[%discnumber%-]%tracknumber%. %title%" making "%discnumber%-" conditional.
korth

  • PlexCSI
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2008
Could not duplicate your result using "Audio Filenames: Track format: %discnumber%-%tracknumber%. %title%" and converting with flac input/output in windows.
All CUE file text, audio file tags and file names output as expected. Perhaps some additional information needed that you did not disclose?

BTW, I would use "[%discnumber%-]%tracknumber%. %title%" making "%discnumber%-" conditional.


Thanks for the quick response. I guess I may have oversimplified the problem.

I went back and looked, and here is the exact string I was using in the Filename field in the options box:

Code: [Select]
$ifgreater($max(%discnumber%,%totaldiscs%),1,%discnumber%-,)%tracknumber%. %artist% - %title%


Which does the same thing as the conditional notation you suggested (which I was unaware of previously -- thanks for that)

I had also unchecked "Write basic tags from CUE data." Enabling this seems to cause the issue to stop. Which tags does this copy? Sometimes artist, trackname, etc, is changed in the files and I would rather copy those tags from the tracks than from the CUE. Either way, this should work around the issue I have for now!


  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2009
Quote
Which does the same thing as the conditional notation you suggested
Not exactly. The conditional [%discnumber%-] will exclude if placeholder is blank so if %discnumber% = 1, the value is still written. The function $ifgreater($max(%discnumber%,%totaldiscs%),1,%discnumber%-,) requires %discnumber% or %totaldiscs% to be greater than 1 so if both are = 1 or blank, nothing is written.
Quote
I had also unchecked "Write basic tags from CUE data."
Should have thought of that. Needs to be checked for TRACKNUMBER tag.
korth

  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2010
I ripped a CD with EAC & CUEripper:

Quote
Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 13. October 2012, 23:00

Texas / The Hush

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 3  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : No
Make use of C2 pointers : No

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : Yes
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000


Range status and errors

Selected range

    Range quality 100.0 %
    Copy CRC 09BA44B4
    Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 153)  [DE6C07CB], AccurateRip returned [9250BCF3]  (AR v2)
Track  2  cannot be verified as accurate (confidence 156)  [F2A6AF28], AccurateRip returned [1D8AF52A]  (AR v2)
Track  3  cannot be verified as accurate (confidence 159)  [D1637C4C], AccurateRip returned [64FD9888]  (AR v2)
Track  4  cannot be verified as accurate (confidence 155)  [D879924D], AccurateRip returned [476B85B9]  (AR v2)
Track  5  cannot be verified as accurate (confidence 155)  [A37502B4], AccurateRip returned [350B04D2]  (AR v2)
Track  6  cannot be verified as accurate (confidence 159)  [12AEBE11], AccurateRip returned [61FC51CA]  (AR v2)
Track  7  cannot be verified as accurate (confidence 156)  [85C9B051], AccurateRip returned [45EA6F35]  (AR v2)
Track  8  cannot be verified as accurate (confidence 157)  [1E1057B5], AccurateRip returned [6AF9FCFA]  (AR v2)
Track  9  cannot be verified as accurate (confidence 155)  [CFE693C0], AccurateRip returned [EB88AAA3]  (AR v2)
Track 10  cannot be verified as accurate (confidence 154)  [BBF9D902], AccurateRip returned [C2BF949A]  (AR v2)
Track 11  cannot be verified as accurate (confidence 153)  [02C53E65], AccurateRip returned [B53BAE1E]  (AR v2)
Track 12  cannot be verified as accurate (confidence 154)  [2022F381], AccurateRip returned [210F4576]  (AR v2)

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: .9SXrH02amvrI2s1GhjWPYvMaac-] found, Submit result: .9SXrH02amvrI2s1GhjWPYvMaac- has been confirmed
[c3e9138d] (344/348) Accurately ripped
[908c9bc8] (001/348) No match
[770a7501] (001/348) No match
[fcbe9131] (001/348) No match
[344df97a] (001/348) No match


############################################


CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 14. October 2012, 8:18

Texas / The Hush

Used drive  : PLEXTOR DVDR  PX-716A  Adapter: 1  ID: 0

Read mode              : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 30
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks  : No
Null samples used in CRC calculations      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000


Range status and errors

Selected range
    Peak level 99.2 %
    Range quality 100.0 %
    Copy CRC 09BA44B4
    Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 353)  [38B33BA2], AccurateRip returned [9250BCF3]
Track  2  cannot be verified as accurate (confidence 352)  [A2601080], AccurateRip returned [1D8AF52A]
Track  3  cannot be verified as accurate (confidence 354)  [2419DB0C], AccurateRip returned [64FD9888]
Track  4  cannot be verified as accurate (confidence 353)  [ADA913C3], AccurateRip returned [476B85B9]
Track  5  cannot be verified as accurate (confidence 352)  [91C83AF1], AccurateRip returned [350B04D2]
Track  6  cannot be verified as accurate (confidence 356)  [99A95E3D], AccurateRip returned [61FC51CA]
Track  7  cannot be verified as accurate (confidence 351)  [887BD1E2], AccurateRip returned [45EA6F35]
Track  8  cannot be verified as accurate (confidence 355)  [AC37DA17], AccurateRip returned [6AF9FCFA]
Track  9  cannot be verified as accurate (confidence 351)  [F8892BE4], AccurateRip returned [EB88AAA3]
Track 10  cannot be verified as accurate (confidence 350)  [6420CF02], AccurateRip returned [C2BF949A]
Track 11  cannot be verified as accurate (confidence 350)  [BC0874C2], AccurateRip returned [B53BAE1E]
Track 12  cannot be verified as accurate (confidence 348)  [D2FBFA4A], AccurateRip returned [210F4576]

No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

End of status report


1) Why do they report 2 different adapters (1 and 3)? Which program is wrong?
2) Why do I get one time a confidence of about 150 and another of 350? EAC says ARv2 - does CUEripper not support it?
3) Why do have so many CDs a pregap of 0:33? I mean why 0:33 - I think that more than 95% of my CDs with a pregap had a pregap of 0:33. Is this only an accident?
  • Last Edit: 14 October, 2012, 05:47:40 AM by DT5

  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2011
Too late to edit:

And a report from another CD. A CD with pregap - so I ripped with CUEripper first and then with EAC:

Quote
[CUETools log; Date: 14.10.2012 11:45:23; Version: 2.1.4]
Pregap length 00:00:33.
[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] disk not present in database.


Quote
---- CUETools DB Plugin V2.1.3

[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] found, Submit result: discs with pregaps not supported in this protocol version
[314aa017] (32/32) Differs in 0 samples @
You can use CUETools to repair this rip.


Where does the 32/32 come from? I thought that the disc was not present? Or is the plug-in too old ( i saw 2.1.3 only now while writing this post).

Edit:
So it was certainly the old-Plugin:

Quote
---- CUETools DB Plugin V2.1.4

[CTDB TOCID: laDRh4eiGdmrlUa9aDSXWLcpY_U-] found
Submit result: already submitted
Track | CTDB Status
  1  | (1/1) Accurately ripped
  2  | (1/1) Accurately ripped
  3  | (1/1) Accurately ripped
  4  | (1/1) Accurately ripped
  5  | (1/1) Accurately ripped
  6  | (1/1) Accurately ripped
  7  | (1/1) Accurately ripped
  8  | (1/1) Accurately ripped
  9  | (1/1) Accurately ripped
10  | (1/1) Accurately ripped
11  | (1/1) Accurately ripped


Quote
1) Why do they report 2 different adapters (1 and 3)? Which program is wrong?

Windows device manager reports channel 1 (if this is meant)

Why do I get 2 different CUE-Sheets? (to shorten it i cut out all tracks > 5)

Quote
REM DISCID 910AD50B
PERFORMER "The Mighty Lemon Drops"
TITLE "World Without End"
REM DATE 1988
REM DISCNUMBER 1
REM TOTALDISCS 1
REM COMMENT "CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov"
FILE "The Mighty Lemon Drops - World Without End.flac" WAVE
  TRACK 01 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "Inside Out"
    INDEX 00 00:00:00
    INDEX 01 00:00:33
  TRACK 02 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "One By One"
    INDEX 01 03:23:50
  TRACK 03 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "In Everything You Do"
    INDEX 01 06:56:10
  TRACK 04 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "Hear Me Call"
    INDEX 01 12:03:00
  TRACK 05 AUDIO
    PERFORMER "The Mighty Lemon Drops"
    TITLE "No Bounds"
    INDEX 01 16:20:45
...


Quote
REM GENRE Rock
REM DATE 1988
REM DISCID 910AD50B
REM COMMENT "ExactAudioCopy v1.0b3"
CATALOG 0075992570121
PERFORMER "The Mighty Lemon Drops"
TITLE "World Without End"
FILE "The Mighty Lemon Drops - World Without End.flac" WAVE
  TRACK 01 AUDIO
    TITLE "Inside Out"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 00:00:00
    INDEX 01 00:00:33
  TRACK 02 AUDIO
    TITLE "One By One"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 03:23:18
    INDEX 01 03:23:50
  TRACK 03 AUDIO
    TITLE "In Everything You Do"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 06:54:08
    INDEX 01 06:56:10
  TRACK 04 AUDIO
    TITLE "Hear Me Call"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 12:02:65
    INDEX 01 12:03:00
  TRACK 05 AUDIO
    TITLE "No Bounds"
    PERFORMER "The Mighty Lemon Drops"
    INDEX 00 16:20:03
    INDEX 01 16:20:45
...
  • Last Edit: 14 October, 2012, 06:50:37 AM by DT5

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2012
Too many questions 
Quote
Why do I get one time a confidence of about 150 and another of 350?
CUERipper is combining records at all offsets. EAC doesn't do that. Examine the AccurateRip results in the accurip file from the CUERipper rip.
Quote
EAC says ARv2 - does CUEripper not support it?
CUERIpper 2.1.2-2.1.4 support ARv2.
Quote
Why do have so many CDs a pregap of 0:33?
According to the CTDB statistics, 33 ranks 2nd after 32 for discs with pregap.
Quote
Why do I get 2 different CUE-Sheets?
You mean the "Index 00" values? Index [gap] detection is another feature of the 'original' Plextor manufactured drives that might require additional read commands in CUERipper to work properly. My Plextor doesn't work correctly either. Gregory said he didn't add "Overread into Lead-In and Lead-Out" for these drives because he didn't have a drive for testing. The reason may be similar for the other features as CUERipper came about after these drives were no longer manufactured.
  • Last Edit: 14 October, 2012, 10:40:44 AM by korth
korth

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2013
Skipped your adapter question.
Quote
Why do they report 2 different adapters (1 and 3)? Which program is wrong?
CUERipper doesn't need so doesn't detect this information but because the log is an emulation of the EAC log this text is expected. CUERipper adds Adapter: 1 ID: 0 for any drive rather than omit the text in the log.
EAC interprets this information from windows and adjusts as needed for use within EAC and EAC profile .cfg files.
korth

  • DT5
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2014
Quote
Why do have so many CDs a pregap of 0:33?
According to the CTDB statistics, 33 ranks 2nd after 32 for discs with pregap.


I see only 33. But my CDs were published mainly between 85 and 95. would be curious to know whether the pregap ranking is also depending on the release year.

  • jayess
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2015
Korth, a question for you. Stuff I've ripped with DbPoweramp using the HDCD plugin gives an error message when I try to verify it with CueTools.

Does ripping stuff with the HDCD plugin make the files incompatible?

I've quit ripping with it because of this and volume problems when playing mixed tracks.
  • Last Edit: 19 October, 2012, 03:27:01 PM by jayess

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2016
As far as I know, dBpoweramp’s HDCD plug-in outputs 24-bit files (with 4 bits being padded)… and you can’t really verify those with AccurateRip or the CUETools database.

  • jayess
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2017
As far as I know, dBpoweramp’s HDCD plug-in outputs 24-bit files (with 4 bits being padded)… and you can’t really verify those with AccurateRip or the CUETools database.


I would agree with that and as stated that's why I no longer rip with that plugin. I went back and ripped stuff again that I had used it on, so it was a pain.

  • Porcus
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2018
Korth, a question for you. Stuff I've ripped with DbPoweramp using the HDCD plugin gives an error message when I try to verify it with CueTools.

Does ripping stuff with the HDCD plugin make the files incompatible?

I've quit ripping with it because of this and volume problems when playing mixed tracks.


This is not CUETools related; HDCD.exe changes the audio (provided it finds a HDCD, that is), and you will never get an AccurateRip match afterwards.

I did unfortunately rip a bit of my collection with the HDCD plugin. There is no reason to do so if you rip to a lossless format, and many reasons not to. The volume issue is one. I posted a few others here: http://forum.dbpoweramp.com/showthread.php...ll=1#post119732


  • nerdyluke
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2019
I have a few questions regarding s a CUETools (GUI) Verify log:

[CUETools log; Date: 9/7/2012 2:13:59 AM; Version: 2.1.4]
[CTDB TOCID: 3oyAwpWTUNxhhoGNcmgBa3GoPH4-] found.
Track | CTDB Status
  1  | (2/2) Accurately ripped
  2  | (2/2) Accurately ripped
  3  | (2/2) Accurately ripped
  4  | (2/2) Accurately ripped
  5  | (2/2) Accurately ripped
  6  | (2/2) Accurately ripped
  7  | (2/2) Accurately ripped
  8  | (2/2) Accurately ripped
  9  | (2/2) Accurately ripped
[AccurateRip ID: 0013b09d-009109a0-700d6d09] found.
Track  [  CRC  |  V2  ] Status
01    [a1fc6808|677ad65d] (4+0/4) Accurately ripped
02    [527deaee|532e0924] (4+0/4) Accurately ripped
03    [8f485bb2|30f27910] (4+0/4) Accurately ripped
04    [06692c20|6a3b2800] (4+0/4) Accurately ripped
05    [180343e7|8c2a774b] (4+0/4) Accurately ripped
06    [5c269cd6|f6fff705] (4+0/4) Accurately ripped
07    [4ef738f2|069dbe9a] (4+0/4) Accurately ripped
08    [decdd0f7|eeb83fcd] (4+0/4) Accurately ripped
09    [5e24a32a|9d5e0ae1] (0+0/4) No match

...


#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?


I have the same situation as #1 for one of my logs (last track accurate in CTDB and not accurate in AR. Can anyone please explain this ?

  • Rollin
  • [*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2020

#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?


I have the same situation as #1 for one of my logs (last track accurate in CTDB and not accurate in AR. Can anyone please explain this ?

AR ignores 5 first and 5 last frames of CD, CTDB ignores 10 first and 10 last frames of CD.

  • nerdyluke
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2021
so the last track contains errors and those are located in the frames ignored by CTDB but taken into account by AR ?
also why does AR say no match instead of 'NOT ACCURATE' then ?

im confused 
  • Last Edit: 21 October, 2012, 08:46:47 AM by nerdyluke

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2022
You could interpret that the differences are located in the last 6-10 sectors of the track. Not enough info to determine if from read errors, padding or a different pressing than the one in the AR database.
In the CUETools log, "No Match" = "Not Accurate"
  • Last Edit: 21 October, 2012, 10:50:39 AM by korth
korth

  • a3aan
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2023
Do plans exist for supporting tagging with CTDB Accuracy values? Chaars, Adriaan.

  • Porcus
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2024
Re CD-extras:
I do lookups using the AccurateRip ID (dBpoweramp tags with those, I extract an ACCURATERIPID tag from that). However, CUETools then returns the error “Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.”

when I check the CUEToolsDB box. And then the log ends abruptly.

If I uncheck that and only attempt verifying by AccurateRip, I get a proper log (at least this far), so it is only a minor nuissance though.


An unrelated question: what is current status on how submissions to CTDB are done? I sometimes get differences in tracks which are AR verified, making me wonder whether some upload (with a ripping error) has been downloaded, attempted verified, and ... submitted? I don't pity the downloaders, but I certainly don't trust them with repairing my rips :-o