IPB

Welcome Guest ( Log In | Register )

103 Pages V  « < 79 80 81 82 83 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
DT5
post Oct 10 2012, 17:02
Post #2001





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



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%
Go to the top of the page
+Quote Post
DT5
post Oct 10 2012, 22:16
Post #2002





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



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
Go to the top of the page
+Quote Post
korth
post Oct 11 2012, 04:39
Post #2003





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
DT5
post Oct 11 2012, 18:57
Post #2004





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



QUOTE (korth @ Oct 11 2012, 04:39) *
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?
Go to the top of the page
+Quote Post
korth
post Oct 11 2012, 22:29
Post #2005





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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.

This post has been edited by korth: Oct 11 2012, 22:34


--------------------
korth
Go to the top of the page
+Quote Post
Corwin
post Oct 12 2012, 02:17
Post #2006





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



Here's another example of the CTDB numbers not adding up:
CODE
[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
....

Go to the top of the page
+Quote Post
PlexCSI
post Oct 12 2012, 07:00
Post #2007





Group: Members
Posts: 3
Joined: 31-July 11
Member No.: 92675



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?
Go to the top of the page
+Quote Post
korth
post Oct 12 2012, 13:34
Post #2008





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
PlexCSI
post Oct 12 2012, 17:13
Post #2009





Group: Members
Posts: 3
Joined: 31-July 11
Member No.: 92675



QUOTE (korth @ Oct 12 2012, 14:34) *
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
$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!

Go to the top of the page
+Quote Post
korth
post Oct 12 2012, 19:31
Post #2010





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
DT5
post Oct 14 2012, 10:25
Post #2011





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



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?

This post has been edited by DT5: Oct 14 2012, 10:47
Go to the top of the page
+Quote Post
DT5
post Oct 14 2012, 11:32
Post #2012





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



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
...


This post has been edited by DT5: Oct 14 2012, 11:50
Go to the top of the page
+Quote Post
korth
post Oct 14 2012, 15:39
Post #2013





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



Too many questions blink.gif
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.

This post has been edited by korth: Oct 14 2012, 15:40


--------------------
korth
Go to the top of the page
+Quote Post
korth
post Oct 14 2012, 18:34
Post #2014





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
DT5
post Oct 14 2012, 19:07
Post #2015





Group: Members
Posts: 24
Joined: 9-October 12
Member No.: 103738



QUOTE (korth @ Oct 14 2012, 15:39) *
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.
Go to the top of the page
+Quote Post
jayess
post Oct 19 2012, 20:26
Post #2016





Group: Members
Posts: 84
Joined: 18-August 12
Member No.: 102432



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 post has been edited by jayess: Oct 19 2012, 20:27
Go to the top of the page
+Quote Post
Gjorgjevski
post Oct 19 2012, 20:35
Post #2017





Group: Members
Posts: 6
Joined: 17-October 12
Member No.: 103913



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.
Go to the top of the page
+Quote Post
jayess
post Oct 19 2012, 20:38
Post #2018





Group: Members
Posts: 84
Joined: 18-August 12
Member No.: 102432



QUOTE (Gjorgjevski @ Oct 19 2012, 13:35) *
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.
Go to the top of the page
+Quote Post
Porcus
post Oct 19 2012, 20:58
Post #2019





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (jayess @ Oct 19 2012, 21:26) *
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



--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
nerdyluke
post Oct 20 2012, 18:27
Post #2020





Group: Members
Posts: 11
Joined: 5-June 12
Member No.: 100433



QUOTE (Corwin @ Sep 7 2012, 01:00) *
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 ?
Go to the top of the page
+Quote Post
Rollin
post Oct 21 2012, 10:45
Post #2021





Group: Members
Posts: 193
Joined: 5-March 08
Member No.: 51815



QUOTE (nerdyluke @ Oct 20 2012, 21:27) *
QUOTE (Corwin @ Sep 7 2012, 01:00) *

#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.
Go to the top of the page
+Quote Post
nerdyluke
post Oct 21 2012, 13:44
Post #2022





Group: Members
Posts: 11
Joined: 5-June 12
Member No.: 100433



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 wacko.gif

This post has been edited by nerdyluke: Oct 21 2012, 13:46
Go to the top of the page
+Quote Post
korth
post Oct 21 2012, 15:08
Post #2023





Group: Members
Posts: 436
Joined: 13-March 11
Member No.: 88969



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"

This post has been edited by korth: Oct 21 2012, 15:50


--------------------
korth
Go to the top of the page
+Quote Post
a3aan
post Oct 21 2012, 15:42
Post #2024





Group: Members
Posts: 80
Joined: 23-December 06
Member No.: 38930



Do plans exist for supporting tagging with CTDB Accuracy values? Chaars, Adriaan.
Go to the top of the page
+Quote Post
Porcus
post Oct 27 2012, 14:52
Post #2025





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post

103 Pages V  « < 79 80 81 82 83 > » 
Reply to this topicStart new topic
2 User(s) are reading this topic (2 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st September 2014 - 07:57