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: CUETools versions 1.9.5 through 2.1.6 (Read 1906496 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2650 –
Quote from: ChronoSphere on
why was .NET chosen for CUETools' implementation? Wouldn't it have been better to use something that is portable more easily (or rather, being multi-platform from the start)?  Qt/GTK come to mind.

Heh, no one would ever complain about Qt or gtk!

CUETools was started as a .NET project by Moitah in early 2006, presumably to do stuff he wanted to do, using the programming tools he was familiar with. I don't blame him for not having your needs in mind, nor do I blame Gregory Chudov for not rewriting the whole thing from scratch when he started the fork that everybody uses.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2651 –
Quote from: ChronoSphere on
"The given path's format is not supported".

This has come up [a href='index.php?act=findpost&pid=881421']here[/a] and [a href='index.php?showtopic=107574']here[/a] and may not be limited to linux under wine. Not sure if Gregory looked into this further.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2652 –
The interesting thing is, it can actually write output to it fine, but not browse it.

Quote from: mjb2006 on
CUETools was started as a .NET project by Moitah in early 2006, presumably to do stuff he wanted to do, using the programming tools he was familiar with. I don't blame him for not having your needs in mind, nor do I blame Gregory Chudov for not rewriting the whole thing from scratch when he started the fork that everybody uses.
I'm not blaming anyone either

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2653 –
This is a question about the CueTools DB.
Is there any way to edit my submissions and fix them?

Full info:
Recommended by a friend, I have used the CueRipper CD ripper, but it would always download completely useless data due to mismatching my CDs to more popular ones.
I would frequently correct just the artist and title parameters, because they showed in the file name, and leave the rest as junk data.
Sometimes, I would even just leave all the data and correct the file name alone afterward.
I had no interest in tags or submitting any data, so did not care as the data would never be used or seen by anyone anyway.
Even if I wanted to submit, I did not know what the correct format would be.
(Given 'submit to freeDB' etc. buttons I thought any submissions would have to be made as a manual process.)
But today, I found out that it actually publicly submits tracklists for all CDs you use.
Nearly all the CDs I ripped were labeled as no previous confidence, so my rips are now likely to be shown 100% to others if ever used, junk data and all.
If I knew they would be shown, I would have used more accurate data.
I have looked through what I could understand of the wiki, and through the pages of the DB website.
However, I could not find any way for the users to correct existing submissions.
The CTDB plugin specifically states it does not let you submit metadata, and I could not find any way with CueTools.
Yesterday, I ripped another CD with junk data, and tried correcting it with CueRipper today, but I am told that I have already submitted it, and the data does not change.
I have submitted around 10 unique CDs in the past.
Even if I have to report changes here, is there a way to fix the existing bad data?
One example.
Proper data: Original alphabet (Transliterated version)
Correct title: xxxHOLiC 〜四月一日の十六夜草話〜 四月一日の日本文学独り言CD 〜明治編～ (xxxHOLiC ~Watanuki no Izayoi Souwa~: Watanuki no Nihon Bungaku Hitorigoto CD ~Meiji-hen~)
Correct track title: None specified, but the most fitting part of the title is 明治編 (Meiji-hen)
Artist: None specified, but the voice is 四月一日君尋(CV:福山潤) (Kimihiro Watanuki (CV: Jun Fukuyama))
Release date: 2007/AUGUST/09
Country: 日本 (Japan)
Label: Marvelous Entertainment Inc.
Barcode, DiscName, LabelNo: None exists. (N/A)
It has nothing to do with the Spice Girls, but was autodetected as having them on it.
There should also be other colours of CD submitted, a white, black, blue, red, etc, but I can't find them on the website. They will suffer from the same issue.
They also be discs associated to the wrong album information, but I doubt those are easily fixable at all...
I recall that when completing a rip, the drive would show what appeared to be a base64-encoded string, which appears to be associated with the website entry. However, it does not seem to be written to any logs...

Also, for fixing data, what format should be used for data that does not exist in the latin alphabet/ASCII: the original characters in the original language, or a latin transliteration? Previously I have used latin versions to avoid codepage issues, but am now thinking this may be 'the wrong way' to do it. Also, if provided in the original language, should pronunciation guides be included where non-standard pronunciations are used? (This may be an issue only to Japanese.)

Finally, what is uploaded exactly? I delete logs because of containing full paths, and if they are submitted then I will have to use it offline from now on.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2654 –
Quote
This is a question about the CueTools DB.

Next time, there's a separate thread for the [a href='index.php?showtopic=79882']CUETools Database[/a]

Quote
Is there any way to edit my submissions and fix them?

No. The database cannot be edited by the users.

Quote
But today, I found out that it actually publicly submits tracklists for all CDs you use.

No, only the Artist and Album. The track titles displayed in the database are taken from the metadata also stored in the CTDB.

Quote
Yesterday, I ripped another CD with junk data

Couldn't find that rip under the same userid as the example below. The last rip from this userid was 1-6-2015 Detective Conan.

Quote
One example.

This example shows Artist: xxxHOLiC PS2, Album: Beige Preorder Disc
Under http://db.cuetools.net/cd/2100525 the track info is from the stored metadata for 90+ albums. As you click on the different names in the Artist column, you'll see the Artist / Album header, the track Title and the artwork change. If your Artist / Album is not in one of the metadata databases used, you won't find your Track Title here even if you entered it correctly when you ripped the CD. You'll need to submit the CD to one of the databases and it could take up to a month to appear under this record.

Quote
I recall that when completing a rip, the drive would show what appeared to be a base64-encoded string, which appears to be associated with the website entry. However, it does not seem to be written to any logs..

If you mean the CTDB TOCID, that should be in the CUETools log (the *.accurip file).

Quote
Finally, what is uploaded exactly?

What information does the database contain per each CD?

Note: The example you gave above shows you using CUETools v2.1.2. The CUETools Database was upgraded since that version. v2.1.4 and above are more compatible with the current database.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2655 –
Quote from: korth on
Quote
But today, I found out that it actually publicly submits tracklists for all CDs you use.

No, only the Artist and Album. The track titles displayed in the database are taken from the metadata also stored in the CTDB.

I'm confused by that statement. Are you saying that CUERipper submits a partial tracklist, i.e. the TOC (number of tracks and how long each one is), but that the artist & title metadata for each track is never based on info manually entered into CUERipper, and never based on info CUERipper downloaded from other databases based on the TOC? Are CTDB and CUERipper independently fetching track-specific metadata from other databases? i.e. if I submit a new CD and don't have any metadata for it, will its CTDB record have metadata fetched from elsewhere?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2656 –
Now I'm confused.
Along with the other rip info, only the album's artist and title are submitted to the CTDB. Track titles, track artists or other fields are not submitted to the CTDB, manually edited or not. You can manually edit the album's artist and title to be submitted along with the other rip info but they are not stored as metadata.
When you look up a CD on the CTDB web site and see Track Titles listed in the record, they were not submitted with the rip info. The Track Titles are retrieved internally from metadata stored in another part of the database. The CTDB stored metadata is exactly the same metadata available to CUETools and CUERipper.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2657 –
Noted in 2.1.5 and the current build of 2.1.6: the .accurip log file generated after a repair+encode omits the CTDB TOCID/CTDB Status block at the start of the file:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:17:47; Version: 2.1.6]
CUETools DB: corrected 26210 errors.
[AccurateRip ID: 002561a5-01d5a130-070d7811] found.
Track   [  CRC   |   V2   ] Status
 01     [065d1415|7f440f66] (077+053/160) Accurately ripped
 02     [2d870c2d|72ef4b1b] (078+053/162) Accurately ripped
 03     [7e367f83|d1c0c3d8] (068+044/158) Accurately ripped
 04     [b4ce9635|ece1c7d0] (068+045/159) Accurately ripped
 05     [e7c5c5e7|36d2bb76] (067+046/159) Accurately ripped
 06     [d4fa7ccf|1455b26e] (068+045/159) Accurately ripped
 07     [5d6ddb30|c8d636bf] (067+046/160) Accurately ripped
 08     [62b7d595|ae3d11ae] (067+048/161) Accurately ripped
 09     [75db0203|194f3c8c] (068+047/161) Accurately ripped
 10     [d76741dd|8d236cfc] (078+054/162) Accurately ripped
 11     [433fa03d|dfb9b849] (078+055/164) Accurately ripped
 12     [49f3cb61|cad43aa5] (078+054/162) Accurately ripped
 13     [a5d6f8f1|b0d6e209] (067+047/160) Accurately ripped
 14     [a586ee03|8ea9e45a] (074+054/159) Accurately ripped
 15     [a7d339bf|22023d90] (067+047/160) Accurately ripped
 16     [442bbd29|d0adb956] (066+048/160) Accurately ripped
 17     [b101537f|5e1a252f] (074+055/159) Accurately ripped
Offsetted by -664:
 01     [040939ae] (007/160) Accurately ripped
 02     [4c8c6d5b] (008/162) Accurately ripped
 03     [35db0bb4] (006/158) Accurately ripped
 04     [d874ba05] (006/159) Accurately ripped
 05     [89914b17] (006/159) Accurately ripped
 06     [9e8db0a7] (006/159) Accurately ripped
 07     [0b6427a8] (006/160) Accurately ripped
 08     [945d1835] (006/161) Accurately ripped
 09     [6d3412db] (006/161) Accurately ripped
 10     [2113b0fc] (007/162) Accurately ripped
 11     [69c1f62a] (008/164) Accurately ripped
 12     [4dd1960b] (007/162) Accurately ripped
 13     [6d7e99ae] (006/160) Accurately ripped
 14     [9cf4e470] (008/159) Accurately ripped
 15     [29e117fb] (006/160) Accurately ripped
 16     [5a0d6d91] (006/160) Accurately ripped
 17     [f7dcceb4] (007/159) Accurately ripped
Offsetted by -36:
 01     [628ca64f] (000/160) No match (V2 was not tested)
 02     [f259456d] (000/162) No match (V2 was not tested)
 03     [fd9a42a5] (000/158) No match (V2 was not tested)
 04     [d1e9bcb7] (000/159) No match (V2 was not tested)
 05     [4724aad5] (000/159) No match (V2 was not tested)
 06     [de5d74d3] (000/159) No match (V2 was not tested)
 07     [a92c8f24] (000/160) No match (V2 was not tested)
 08     [f1bf4085] (000/161) No match (V2 was not tested)
 09     [ef37bd87] (000/161) No match (V2 was not tested)
 10     [376a1af5] (000/162) No match (V2 was not tested)
 11     [bee8415d] (000/164) No match (V2 was not tested)
 12     [7b0414b6] (000/162) No match (V2 was not tested)
 13     [fb7960f3] (000/160) No match (V2 was not tested)
 14     [c257c9ca] (000/159) No match (V2 was not tested)
 15     [735c305d] (000/160) No match (V2 was not tested)
 16     [0dd6d185] (000/160) No match (V2 was not tested)
 17     [530d91f5] (000/159) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [1D435E99] [758DB2C1] [E47866B8]
 01   92.2 [C6603189] [D3D7F263]           
 02   96.9 [E58E8B03] [AC624979]           
 03   90.6 [CD12F4E8] [7FEA0E00]           
 04   95.9 [FDAFB014] [0D109512]           
 05  100.0 [6A60EEF8] [4593A2D7]           
 06  100.0 [705DB54D] [8B6F7522]           
 07  100.0 [B6A9C753] [E25F9092]           
 08  100.0 [5E61FF1E] [23DED61C]           
 09   98.7 [C9677DD4] [48DC52A6]           
 10  100.0 [5F1FBC57] [49BE50F7]           
 11   99.6 [822D30B0] [B6AB457E]           
 12  100.0 [1621AAF0] [6634998B]           
 13  100.0 [22C47B50] [A8418F42]           
 14  100.0 [EA811FE5] [F782BD8D]           
 15  100.0 [C0D9E7BE] [FA7BD434]           
 16  100.0 [3F0C9AE9] [05CBDC12]           
 17  100.0 [FD346B2F] [990993AC]         
Manually running a verify on the repaired file results in an .accurip log that includes the CTDB info, but is otherwise identical to the first:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:18:50; Version: 2.1.6]
[CTDB TOCID: 7mWblN0RDFC9wZ3HbM8S8VhQD.A-] found.
Track | CTDB Status
  1   | (52/52) Accurately ripped
  2   | (52/52) Accurately ripped
  3   | (42/52) Accurately ripped, or (10/52) differs in 1 samples @00:04:71
  4   | (42/52) Accurately ripped, or (10/52) differs in 26177 samples @00:13:27-00:13:69
  5   | (42/52) Accurately ripped, or (10/52) differs in 4 samples @04:06:36,04:06:48,04:06:58,04:06:74
  6   | (41/52) Accurately ripped, or (10/52) differs in 2 samples @02:43:28-02:43:30
  7   | (41/52) Accurately ripped, or (10/52) differs in 1 samples @04:47:48
  8   | (42/52) Accurately ripped, or (10/52) differs in 19 samples @02:36:50-02:36:52,02:36:60,02:37:12,02:37:40-02:37:44,02:37:51,02:37:63-02:37:65,02:38:03,02:38:41-02:38:46,02:38:53-02:38:59,02:38:66-02:38:69
  9   | (42/52) Accurately ripped, or (10/52) differs in 3 samples @03:22:35,03:22:60,03:23:63
 10   | (52/52) Accurately ripped
 11   | (52/52) Accurately ripped
 12   | (52/52) Accurately ripped
 13   | (42/52) Accurately ripped, or (10/52) differs in 1 samples @00:00:16
 14   | (52/52) Accurately ripped
 15   | (42/52) Accurately ripped, or (10/52) differs in 1 samples @02:29:62
 16   | (42/52) Accurately ripped, or (10/52) differs in 1 samples @02:45:02
 17   | (52/52) Accurately ripped
[AccurateRip ID: 002561a5-01d5a130-070d7811] found.
Track   [  CRC   |   V2   ] Status
 01     [065d1415|7f440f66] (077+053/160) Accurately ripped
 02     [2d870c2d|72ef4b1b] (078+053/162) Accurately ripped
 03     [7e367f83|d1c0c3d8] (068+044/158) Accurately ripped
 04     [b4ce9635|ece1c7d0] (068+045/159) Accurately ripped
 05     [e7c5c5e7|36d2bb76] (067+046/159) Accurately ripped
 06     [d4fa7ccf|1455b26e] (068+045/159) Accurately ripped
 07     [5d6ddb30|c8d636bf] (067+046/160) Accurately ripped
 08     [62b7d595|ae3d11ae] (067+048/161) Accurately ripped
 09     [75db0203|194f3c8c] (068+047/161) Accurately ripped
 10     [d76741dd|8d236cfc] (078+054/162) Accurately ripped
 11     [433fa03d|dfb9b849] (078+055/164) Accurately ripped
 12     [49f3cb61|cad43aa5] (078+054/162) Accurately ripped
 13     [a5d6f8f1|b0d6e209] (067+047/160) Accurately ripped
 14     [a586ee03|8ea9e45a] (074+054/159) Accurately ripped
 15     [a7d339bf|22023d90] (067+047/160) Accurately ripped
 16     [442bbd29|d0adb956] (066+048/160) Accurately ripped
 17     [b101537f|5e1a252f] (074+055/159) Accurately ripped
Offsetted by -664:
 01     [040939ae] (007/160) Accurately ripped
 02     [4c8c6d5b] (008/162) Accurately ripped
 03     [35db0bb4] (006/158) Accurately ripped
 04     [d874ba05] (006/159) Accurately ripped
 05     [89914b17] (006/159) Accurately ripped
 06     [9e8db0a7] (006/159) Accurately ripped
 07     [0b6427a8] (006/160) Accurately ripped
 08     [945d1835] (006/161) Accurately ripped
 09     [6d3412db] (006/161) Accurately ripped
 10     [2113b0fc] (007/162) Accurately ripped
 11     [69c1f62a] (008/164) Accurately ripped
 12     [4dd1960b] (007/162) Accurately ripped
 13     [6d7e99ae] (006/160) Accurately ripped
 14     [9cf4e470] (008/159) Accurately ripped
 15     [29e117fb] (006/160) Accurately ripped
 16     [5a0d6d91] (006/160) Accurately ripped
 17     [f7dcceb4] (007/159) Accurately ripped
Offsetted by -36:
 01     [628ca64f] (000/160) No match (V2 was not tested)
 02     [f259456d] (000/162) No match (V2 was not tested)
 03     [fd9a42a5] (000/158) No match (V2 was not tested)
 04     [d1e9bcb7] (000/159) No match (V2 was not tested)
 05     [4724aad5] (000/159) No match (V2 was not tested)
 06     [de5d74d3] (000/159) No match (V2 was not tested)
 07     [a92c8f24] (000/160) No match (V2 was not tested)
 08     [f1bf4085] (000/161) No match (V2 was not tested)
 09     [ef37bd87] (000/161) No match (V2 was not tested)
 10     [376a1af5] (000/162) No match (V2 was not tested)
 11     [bee8415d] (000/164) No match (V2 was not tested)
 12     [7b0414b6] (000/162) No match (V2 was not tested)
 13     [fb7960f3] (000/160) No match (V2 was not tested)
 14     [c257c9ca] (000/159) No match (V2 was not tested)
 15     [735c305d] (000/160) No match (V2 was not tested)
 16     [0dd6d185] (000/160) No match (V2 was not tested)
 17     [530d91f5] (000/159) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100.0 [1D435E99] [758DB2C1] [E47866B8]
 01   92.2 [C6603189] [D3D7F263]           
 02   96.9 [E58E8B03] [AC624979]           
 03   90.6 [CD12F4E8] [7FEA0E00]           
 04   95.9 [FDAFB014] [0D109512]           
 05  100.0 [6A60EEF8] [4593A2D7]           
 06  100.0 [705DB54D] [8B6F7522]           
 07  100.0 [B6A9C753] [E25F9092]           
 08  100.0 [5E61FF1E] [23DED61C]           
 09   98.7 [C9677DD4] [48DC52A6]           
 10  100.0 [5F1FBC57] [49BE50F7]           
 11   99.6 [822D30B0] [B6AB457E]           
 12  100.0 [1621AAF0] [6634998B]           
 13  100.0 [22C47B50] [A8418F42]           
 14  100.0 [EA811FE5] [F782BD8D]           
 15  100.0 [C0D9E7BE] [FA7BD434]           
 16  100.0 [3F0C9AE9] [05CBDC12]           
 17  100.0 [FD346B2F] [990993AC]         
This is with Advanced Settings > AccurateRip > Log File > Verbose checked.

Also, the straight "verify" in 2.1.6 leaves out the summary block generated by "verify" in 2.1.5:

Code: [Select]
[CUETools log; Date: 4/11/2015 13:43:20; Version: 2.1.5]
[CTDB TOCID: 7mWblN0RDFC9wZ3HbM8S8VhQD.A-] found.
        [ CTDBID ] Status
        [cee53527] (40/52) Accurately ripped
        [5868242b] (10/52) Differs in 26210 samples @07:42:53,11:06:39-11:07:06,18:39:06,18:39:18,18:39:28,18:39:44,21:25:20-21:25:22,26:16:70,28:56:62-28:56:64,28:56:72,28:57:24,28:57:52-28:57:56,28:57:63,28:58:00-28:58:02,28:58:15,28:58:53-28:58:58,28:58:65-28:58:71,28:59:03-28:59:06,32:23:37,32:23:62,32:24:65,43:33:33,51:45:32,54:32:69
        [e764895c] (01/52) No match
        [ff2a9764] (01/52) No match
Track | CTDB Status
  1   | (52/52) Accurately ripped
  2   | (52/52) Accurately ripped
[... rest omitted; identical to previous block ...]
(Thanks for CTDB. It's let me assemble clean rips of some completely-impossible-to-replace discs that I've been fighting with in some cases for years.)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2658 –
The first one, the repair script has always behaved that way.

The last one you need to set
Advanced Settings > Advanced > CTDB > Detailed log = True
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2659 –
Quote from: korth on
The first one, the repair script has always behaved that way.

The last one you need to set
Advanced Settings > Advanced > CTDB > Detailed log = True

For the first, are you saying it's an intentional decision NOT to include the CTDB data for an image in the log after a repair?  If so, what's the rationale for that?

For the second, I already have Detailed Log set to True in the Advanced tab on 2.1.6.  But it's behaving inconsistently -- I just re-ran a verify in 2.1.6 against the same source file as the second code block above and this time it included the four CTDBID entries before the per-track status.  If there's any additional information I can provide if I manage to reproduce it again please let me know.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2660 –
1. CUETools doesn't re-verify after the repair. The AccurateRip confidence levels in the result log are just a projection of what should be. When the CTDB was created, most of the data came from AccurateRip. There was hope for a closer integration which would allow the database to update confidence numbers directly from AccurateRip. When it became clear that there would be no integration, all the confidence levels based on AccurateRip results were removed and the CTDB began storing independent submissions.
It would be nice to have an option to re-verify after repair rather than verifying again as a separate action.

2. Are you using Profiles? (upper left of GUI). If so check the setting in each profile.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2661 –
Hello,


I've just downloaded CUETools (2.1.5) and it just don't run. It only pops window "CUE Tools has encountered a problem and needs to close.  We are sorry for the inconvenience." and nothing else happens. I'm runnin XP SP3, .NET Fw 2.0 installed, also the Visual C 2008. Not sure if I'm missing something or what to do. I've tried 2.1.4, got same result. Same with CUERipper.

Any suggestions? Help please. Thank you

blindmelon

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2662 –
Quote from: blindmelon on
It only pops window "CUE Tools has encountered a problem and needs to close.  We are sorry for the inconvenience." and nothing else happens.


FWIW I get the same thing on one Windows 7 computer. Don't know why. Didn't care enough to find out.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2663 –
I updated my nVidia GT650M drivers, and now when I try to encode to FLAC with CUETools on Windows 7 Professional x64 using FLACCL, I get a "no opencl platforms found" error... What happened?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2664 –
regarding usage of "CUETools.ConsoleRipper.exe" under windows (v2.1.6), a very nice application btw
ripping an audio cd with 'illegal' characters in musicbrainz album title (in my case esp. ':')  throws an error
cuetools has this 'force ansi filenames / remove special characters' option, and cueripper (gui) does this by itself (no config)...

example:

Code: [Select]
Filename    : Nick Warren - Global Underground 028: Nick Warren in Shanghai.wav
MusicBrainz : Nick Warren - Global Underground 028: Nick Warren in Shanghai
[...]
Error: Das angegebene Pfadformat wird nicht unterstützt.
   bei System.Security.Util.StringExpressionSet.CanonicalizePath(String path, Bo
olean needFullPath)
   bei System.Security.Util.StringExpressionSet.CreateListFromExpressions(String
[] str, Boolean needFullPath)
   bei System.Security.Permissions.FileIOPermission.AddPathList(FileIOPermission
Access access, AccessControlActions control, String[] pathListOrig, Boolean chec
kForDuplicates, Boolean needFullPath, Boolean copyPathList)
   bei System.Security.Permissions.FileIOPermission..ctor(FileIOPermissionAccess
 access, AccessControlActions control, String[] pathList, Boolean checkForDuplic
ates, Boolean needFullPath)
   bei System.IO.FileStream.Init(String path, FileMode mode, FileAccess access,
Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions
options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
 FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean
 bFromProxy)
   bei System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
 FileShare share, Int32 bufferSize, FileOptions options)
   bei System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodi
ng, Int32 bufferSize)
   bei System.IO.StreamWriter..ctor(String path)
   bei CUETools.ConsoleRipper.Program.Main(String[] args)


would be nice if that got fixed

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2665 –
Hey:

Three questions:
1) AFAIU, CUE Ripper never reads into lead in/out (even if the drive supports it) and cannot be configured to do so, right?
So it will all always loose some tiny bit of data (depending on the drive's offset)?!


2) The documentation of CUERipper says it would use C2 Errors, but in the EAC-Style log it writes:
""
even though my drive supports C2, errors.
So what's the case now?


3) IIRC, e.g. dBpoweramp's CD Ripper, when AccurateRip is enabled (and the CD found in the DB), it trusts whatever AccruateRip says (possibly ignoring C2 errors?)... so the question is whether CUETools would still give me an error notice when C2 errors occur, even when Accurate Rip and/or CTDB say everything would be fine (which may be wrong).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2666 –
1) Correct. CUERipper does not Overread (as EAC puts it) into Lead-In and Lead-Out. The tiny bit of lost data is usually silence or inaudible.

2) The 'Make use of C2 pointers' in the EAC log shows the condition of the setting (not that the drive actually supports using it). The EAC-style log in CUERipper always shows 'No'. CUERipper does not have the setting like EAC does.

3) The 'Error Correction Progress Bar' will light up red on both read errors and C2 errors (if C2 is detected as supported by the drive). This happens during the extraction process before the track is verified against the databases. If the errors continue after maximum retries, suspicious positions are added to the extraction log. It is possible in some cases that the data read was correct despite the errors and the track will match as accurate in one or both of the databases.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2667 –
Quote from: Pidgeon on
I updated my nVidia GT650M drivers, and now when I try to encode to FLAC with CUETools on Windows 7 Professional x64 using FLACCL, I get a "no opencl platforms found" error... What happened?

Change my videocard nVidia GTS 250 to GTX 560, and still have the same problem.

Cant choose platform in encoding settings.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2668 –
I'm at a loss to explain this behavior.

The first two tracks of this CD won't rip without error; the disc is scratched. If I verify it in CUETools, this is the result, and all looks as expected:

Code: [Select]
[CUETools log; Date: 5/10/2015 2:53:20 AM; Version: 2.1.6]
Pregap length 00:00:33.
[CTDB TOCID: DqV4otplMQna3r1yiIUcO4vTqqw-] found.
Track | CTDB Status
  1   | (0/4) No match
  2   | (0/4) No match
  3   | (4/4) Accurately ripped
  4   | (4/4) Accurately ripped
  5   | (4/4) Accurately ripped
  6   | (4/4) Accurately ripped
  7   | (4/4) Accurately ripped
  8   | (4/4) Accurately ripped
  9   | (4/4) Accurately ripped
 10   | (4/4) Accurately ripped
 11   | (4/4) Accurately ripped
[AccurateRip ID: 00118b1a-009bfbba-790ac80b] found.
Track   [  CRC   |   V2   ] Status
 01     [4b30b38e|582fbdbf] (00+00/42) No match
 02     [39b37393|14c0e4cd] (00+00/44) No match
 03     [f51007bc|7a0c1d87] (26+17/46) Accurately ripped
 04     [57da509b|55140fe1] (26+16/45) Accurately ripped
 05     [24a80837|1b4cd5fb] (26+16/45) Accurately ripped
 06     [9545ee68|5959c1bb] (26+16/45) Accurately ripped
 07     [7eefe863|9726ea17] (25+16/44) Accurately ripped
 08     [7b1fe777|c8d86c1d] (27+16/46) Accurately ripped
 09     [dcfad4f9|5843ac87] (26+16/45) Accurately ripped
 10     [dcca73f3|d8e9d490] (25+16/44) Accurately ripped
 11     [f873119d|b6f136f1] (27+16/46) Accurately ripped
Offsetted by -86:
 01     [b1a7d225] (00/42) No match (V2 was not tested)
 02     [cd78c0a8] (00/44) No match (V2 was not tested)
 03     [a0fac487] (00/46) No match (V2 was not tested)
 04     [ab10cbea] (00/45) No match (V2 was not tested)
 05     [267212e4] (00/45) No match (V2 was not tested)
 06     [0f7f3add] (00/45) No match (V2 was not tested)
 07     [9cf4e464] (00/44) No match (V2 was not tested)
 08     [1b650a39] (00/46) No match (V2 was not tested)
 09     [f54879f4] (00/45) No match (V2 was not tested)
 10     [4f6deaba] (00/44) No match (V2 was not tested)
 11     [cf775937] (00/46) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] 
 --   90.2 [CA318393] [9068CFF3]           
 01   83.8 [85C5F99E] [472CABB2]           
 02   71.4 [0C808900] [70637A5E]           
 03   65.9 [A16B8A7B] [A1A0FF66]           
 04   56.8 [B09FA008] [800D2190]           
 05   56.9 [CFE732AE] [C35DB6F1]           
 06   88.5 [1026E056] [8019D8CF]           
 07   84.9 [1256311D] [BB3F2F03]           
 08   71.3 [78956AFC] [09799AD5]           
 09   72.6 [4BC68E1B] [0BE858FD]           
 10   90.2 [9C7B1032] [585584A0]           
 11   48.4 [1BE9593A] [2CCD1353]         

All is normal... those two tracks are showing as "No Match" in CTDB, ARv1, ARv2.

But if I replace those two tracks with files from someone else's rip (I'm hoping his rip is good) and I verify everything again, the result is bizarre:

Code: [Select]
[CUETools log; Date: 5/10/2015 3:02:52 AM; Version: 2.1.6]
Pregap length 00:00:33.
[CTDB TOCID: DqV4otplMQna3r1yiIUcO4vTqqw-] found.
Track | CTDB Status
  1   | (4/4) Accurately ripped
  2   | (4/4) Differs in 9 samples @00:00:32
  3   | (4/4) Differs in 11 samples @00:00:32
  4   | (4/4) Accurately ripped
  5   | (4/4) Accurately ripped
  6   | (4/4) Accurately ripped
  7   | (4/4) Accurately ripped
  8   | (4/4) Accurately ripped
  9   | (4/4) Accurately ripped
 10   | (4/4) Accurately ripped
 11   | (4/4) Accurately ripped
[AccurateRip ID: 00118b1a-009bfbba-790ac80b] found.
Track   [  CRC   |   V2   ] Status
 01     [bff168d5|d23517ae] (00+00/42) No match
 02     [7e54af3d|59c11c5f] (00+00/44) No match
 03     [f51007bc|7a0c1d87] (26+17/46) Accurately ripped
 04     [57da509b|55140fe1] (26+16/45) Accurately ripped
 05     [24a80837|1b4cd5fb] (26+16/45) Accurately ripped
 06     [9545ee68|5959c1bb] (26+16/45) Accurately ripped
 07     [7eefe863|9726ea17] (25+16/44) Accurately ripped
 08     [7b1fe777|c8d86c1d] (27+16/46) Accurately ripped
 09     [dcfad4f9|5843ac87] (26+16/45) Accurately ripped
 10     [dcca73f3|d8e9d490] (25+16/44) Accurately ripped
 11     [f873119d|b6f136f1] (27+16/46) Accurately ripped
Offsetted by -86:
 01     [9c98b5ee] (00/42) No match (V2 was not tested)
 02     [0791630b] (00/44) No match (V2 was not tested)
 03     [a1e3c3d8] (00/46) No match (V2 was not tested)
 04     [ab10cbea] (00/45) No match (V2 was not tested)
 05     [267212e4] (00/45) No match (V2 was not tested)
 06     [0f7f3add] (00/45) No match (V2 was not tested)
 07     [9cf4e464] (00/44) No match (V2 was not tested)
 08     [1b650a39] (00/46) No match (V2 was not tested)
 09     [f54879f4] (00/45) No match (V2 was not tested)
 10     [4f6deaba] (00/44) No match (V2 was not tested)
 11     [cf775937] (00/46) No match (V2 was not tested)

Track Peak [ CRC32  ] [W/O NULL] 
 --   90.2 [E5AB8A7E] [361E403E]           
 01   83.8 [6259B2FA] [7096D898]           
 02   45.7 [0BD59295] [1E9ED238]           
 03   65.9 [A16B8A7B] [A1A0FF66]           
 04   56.8 [B09FA008] [800D2190]           
 05   56.9 [CFE732AE] [C35DB6F1]           
 06   88.5 [1026E056] [8019D8CF]           
 07   84.9 [1256311D] [BB3F2F03]           
 08   71.3 [78956AFC] [09799AD5]           
 09   72.6 [4BC68E1B] [0BE858FD]           
 10   90.2 [9C7B1032] [585584A0]           
 11   48.4 [1BE9593A] [2CCD1353]         

ARv1 & ARv2 are still saying no match (so at least 1 sample is wrong), but CTDB is saying track 1 is actually OK, while tracks 2 and 3 are slightly wrong.

What's going on? I didn't touch track 3 at all...I only replaced the files for tracks 1 and 2! How can track 3 now be wrong, only in CTDB?

The first 50000 samples in tracks 1 & 2 of my rip are identical to his rip, so how can track 2 go from No Match to being off by only 9 samples, 32 frames in?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2669 –
I know you said the first second or so of the files are identical but maybe something in the imported tracks is throwing the offset-finding checksum off?
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2670 –
It looks suspiciously like my calculations when displaying this log are off by a pregap length (33 frames). Then the bad sectors aren't actually at 0:32, but at -0:01, i.e. in the last sector of the first two tracks.
I'll have to check it. You can go ahead and repair this rip, i'm pretty sure that would work and you'll find that the difference was indeed in the track ends.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2671 –
Ah, you're right. A repair worked, and the difference was indeed at the ends of those tracks.

It was my own fault. The other guy's files were offset by 18 samples, so this is what I attempt to do before the verify:
  • remove 18 samples from the beginning of his copy of track 1
  • move 18 samples from the beginning of his copy of track 2 to the end of his copy of track 1
  • copy 18 samples from the end of my copy of track 2 to the end of his copy of track 2
  • replace my tracks 1 and 2 with the edited versions of his tracks 1 and 2

Something went wrong, though; I must've gotten confused as to which files I was editing. The 18 samples I ended up putting at the end of each track were not the right ones. Oh well, all is fine now after the repair.

Can the log calculation bug affect whether a rip is determined to be repairable? i.e. could a repairable rip be mistakenly determined to be unrepairable?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2672 –
I think this is just a log issue.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2673 –
Recently files I split with CUETools 2.1.6 sometimes have a lower CTDBDISCCONFIDENCE tag than all CTDBTRACKCONFIDENCE tags. The track confidence tags seem to be correct, they're the same as in the .accurip file.

Examples:
1. All tracks have track confidence (and CTDBTRACKCONFIDENCE tag) 2/2, CTDBDISCCONFIDENCE is 1/2.
2. Track confidence is 18/18 or 17/18, CTDBDISCCONFIDENCE is 16/18.
3. Track confidence is 61/61 or 59/61, CTDBDISCCONFIDENCE is 33/61.

Did i misunderstand what the CTDBDISCCONFIDENCE tag is or is this a bug, is there any way i can fix this and can i be sure that the track confidences are correct so i could simply change the CTDBDISCCONFIDENCE tag to the lowest track confidence?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2674 –
Quote from: Krelgprmnkfgszha on
Did i misunderstand what the CTDBDISCCONFIDENCE tag is?
CTDBDISCCONFIDENCE is based on CTDBID matches. Each CTDBID represents the CRC32 ID of the entire disc. To see the CTDBID in the .accurip file, turn on the Detailed log. In the example below the CTDBDISCCONFIDENCE=93 and the CTDBTRACKCONFIDENCE=101

Code: [Select]
[CUETools log; Date: 5/11/2015 3:55:06 AM; Version: 2.1.6]
[CTDB TOCID: be3uqHSr5yJNFuwxxbrlPBIzcOs-] found.
        [ CTDBID ] Status
        [462d2223] (0[b][color=#FF0000]93[/color][/b]/109) Accurately ripped
        [414f70ae] (007/109) Differs in 224 samples @00:17:40,11:45:38
        [a1144bde] (001/109) No match
        [840af95a] (001/109) No match
        [a2f57795] (001/109) No match
        [1905e7ca] (001/109) No match
        [978f5d54] (001/109) No match
        [84f95ab0] (001/109) No match
        [f437dbed] (001/109) No match
        [6ca4da14] (001/109) No match
        [c30f7b29] (001/109) No match
Track | CTDB Status
  1   | ([b][color=#FF0000]101[/color][/b]/109) Accurately ripped, or (7/109) differs in 44 samples @00:17:40
  2   | ([b][color=#FF0000]101[/color][/b]/109) Accurately ripped, or (7/109) differs in 180 samples @07:17:10
  3   | (109/109) Accurately ripped
  4   | (108/109) Accurately ripped
  5   | (109/109) Accurately ripped
  6   | (108/109) Accurately ripped
  7   | (109/109) Accurately ripped
  8   | (109/109) Accurately ripped
  9   | (109/109) Accurately ripped
 10   | (109/109) Accurately ripped
 11   | (109/109) Accurately ripped
 12   | (108/109) Accurately ripped
 13   | (109/109) Accurately ripped
 14   | (107/109) Accurately ripped
 15   | (108/109) Accurately ripped
 16   | (106/109) Accurately ripped
In each of the other CTDBID's, some of the tracks match the rip but the tracks that don't match are not always the same tracks. That's why the CTDBTRACKCONFIDENCE can be higher.

edit: minor changes; added color
korth