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 1894822 times) previous topic - next topic
0 Members and 5 Guests are viewing this topic.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2800
I have the 'passthrough' box checked in VirtualBox. I'm not sure if it's possible for it to work properly through a VM, though I'm hoping it is. Was just wondering if anyone had tried this before or had any ideas.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2801
Hi, I noticed that this rip, which includes silent tracks (Tool - 1993 - Undertow), is reported as "no match" in .accurip log+"not accurate" in batch while it should report "silent track" in .accurip log and "accurate" in batch. (Edit: I erased the irrelevant part of the log as it exceeded HA character limit)

Code: [Select]
[CUETools log; Date: 13/04/16 12:57:57; Version: 2.1.6]
Pregap length 00:00:32.
[CTDB TOCID: 46Yj4k_u4vklxp6jffKA7XTpdz8-] found.
        [ CTDBID ] Status
        [799328b1] (47/56) Accurately ripped
        [ae45bea5] (05/56) No match
        [9f7ef995] (01/56) No match
        [beb370ec] (01/56) No match
        [4a3da3b1] (01/56) No match
        [d78732a7] (01/56) No match
Track | CTDB Status
  1   | (55/56) Accurately ripped
  2   | (55/56) Accurately ripped
  3   | (55/56) Accurately ripped
  4   | (50/56) Accurately ripped
  5   | (51/56) Accurately ripped
  6   | (51/56) Accurately ripped
  7   | (50/56) Accurately ripped
  8   | (50/56) Accurately ripped
  9   | (50/56) Accurately ripped
 10   | (56/56) Accurately ripped
 11   | (56/56) Accurately ripped
 12   | (56/56) Accurately ripped
 13   | (56/56) Accurately ripped
 14   | (56/56) Accurately ripped
 15   | (56/56) Accurately ripped
 16   | (56/56) Accurately ripped
 17   | (56/56) Accurately ripped
 18   | (56/56) Accurately ripped
 19   | (56/56) Accurately ripped
 20   | (56/56) Accurately ripped
 21   | (56/56) Accurately ripped
 22   | (56/56) Accurately ripped
 23   | (56/56) Accurately ripped
 24   | (56/56) Accurately ripped
 25   | (56/56) Accurately ripped
 26   | (56/56) Accurately ripped
 27   | (56/56) Accurately ripped
 28   | (56/56) Accurately ripped
 29   | (56/56) Accurately ripped
 30   | (56/56) Accurately ripped
 31   | (56/56) Accurately ripped
 32   | (56/56) Accurately ripped
 33   | (56/56) Accurately ripped
 34   | (56/56) Accurately ripped
 35   | (56/56) Accurately ripped
 36   | (56/56) Accurately ripped
 37   | (56/56) Accurately ripped
 38   | (56/56) Accurately ripped
 39   | (56/56) Accurately ripped
 40   | (56/56) Accurately ripped
 41   | (56/56) Accurately ripped
 42   | (56/56) Accurately ripped
 43   | (56/56) Accurately ripped
 44   | (56/56) Accurately ripped
 45   | (56/56) Accurately ripped
 46   | (56/56) Accurately ripped
 47   | (56/56) Accurately ripped
 48   | (56/56) Accurately ripped
 49   | (56/56) Accurately ripped
 50   | (56/56) Accurately ripped
 51   | (56/56) Accurately ripped
 52   | (56/56) Accurately ripped
 53   | (56/56) Accurately ripped
 54   | (56/56) Accurately ripped
 55   | (56/56) Accurately ripped
 56   | (56/56) Accurately ripped
 57   | (56/56) Accurately ripped
 58   | (56/56) Accurately ripped
 59   | (56/56) Accurately ripped
 60   | (56/56) Accurately ripped
 61   | (56/56) Accurately ripped
 62   | (56/56) Accurately ripped
 63   | (56/56) Accurately ripped
 64   | (56/56) Accurately ripped
 65   | (56/56) Accurately ripped
 66   | (56/56) Accurately ripped
 67   | (56/56) Accurately ripped
 68   | (56/56) Accurately ripped
 69   | (47/56) Accurately ripped
[AccurateRip ID: 00ec3b4e-235f416b-f5103945] found.
Track   [  CRC   |   V2   ] Status
 01     [c0c34995|09769895] (116+115/264) Accurately ripped
 02     [aeb6547d|96b02e49] (115+115/263) Accurately ripped
 03     [13b8ed3c|7470b6ad] (115+117/265) Accurately ripped
 04     [6762b4e4|afc5e9d6] (112+114/259) Accurately ripped
 05     [a0624b25|98a367e3] (115+112/259) Accurately ripped
 06     [06771493|83cb0d49] (116+112/260) Accurately ripped
 07     [489e30f0|ee728ba7] (116+112/260) Accurately ripped
 08     [a008a206|df0d3415] (115+111/258) Accurately ripped
 09     [9cd0ce0f|4cb7d730] (115+111/258) Accurately ripped
 10     [00000000|00000000] (000+000/001) No match
 11     [00000000|00000000] (000+000/001) No match
 12     [00000000|00000000] (000+000/001) No match
 13     [00000000|00000000] (000+000/001) No match
 14     [00000000|00000000] (000+000/001) No match
 15     [00000000|00000000] (000+000/001) No match
 16     [00000000|00000000] (000+000/001) No match
 17     [00000000|00000000] (000+000/001) No match
 18     [00000000|00000000] (000+000/001) No match
 19     [00000000|00000000] (000+000/001) No match
 20     [00000000|00000000] (000+000/001) No match
 21     [00000000|00000000] (000+000/001) No match
 22     [00000000|00000000] (000+000/001) No match
 23     [00000000|00000000] (000+000/001) No match
 24     [00000000|00000000] (000+000/001) No match
 25     [00000000|00000000] (000+000/001) No match
 26     [00000000|00000000] (000+000/001) No match
 27     [00000000|00000000] (000+000/001) No match
 28     [00000000|00000000] (000+000/001) No match
 29     [00000000|00000000] (000+000/001) No match
 30     [00000000|00000000] (000+000/001) No match
 31     [00000000|00000000] (000+000/001) No match
 32     [00000000|00000000] (000+000/001) No match
 33     [00000000|00000000] (000+000/001) No match
 34     [00000000|00000000] (000+000/001) No match
 35     [00000000|00000000] (000+000/001) No match
 36     [00000000|00000000] (000+000/001) No match
 37     [00000000|00000000] (000+000/001) No match
 38     [00000000|00000000] (000+000/001) No match
 39     [00000000|00000000] (000+000/001) No match
 40     [00000000|00000000] (000+000/001) No match
 41     [00000000|00000000] (000+000/001) No match
 42     [00000000|00000000] (000+000/001) No match
 43     [00000000|00000000] (000+000/001) No match
 44     [00000000|00000000] (000+000/001) No match
 45     [00000000|00000000] (000+000/001) No match
 46     [00000000|00000000] (000+000/001) No match
 47     [00000000|00000000] (000+000/001) No match
 48     [00000000|00000000] (000+000/001) No match
 49     [00000000|00000000] (000+000/001) No match
 50     [00000000|00000000] (000+000/001) No match
 51     [00000000|00000000] (000+000/001) No match
 52     [00000000|00000000] (000+000/001) No match
 53     [00000000|00000000] (000+000/001) No match
 54     [00000000|00000000] (000+000/001) No match
 55     [00000000|00000000] (000+000/001) No match
 56     [00000000|00000000] (000+000/001) No match
 57     [00000000|00000000] (000+000/001) No match
 58     [00000000|00000000] (000+000/001) No match
 59     [00000000|00000000] (000+000/001) No match
 60     [00000000|00000000] (000+000/001) No match
 61     [00000000|00000000] (000+000/001) No match
 62     [00000000|00000000] (000+000/001) No match
 63     [00000000|00000000] (000+000/001) No match
 64     [00000000|00000000] (000+000/001) No match
 65     [00000000|00000000] (000+000/001) No match
 66     [00000000|00000000] (000+000/001) No match
 67     [00000000|00000000] (000+000/001) No match
 68     [a8085b8e|ac846cd4] (013+020/037) Accurately ripped
 69     [c3558d24|c3b05552] (105+105/239) Accurately ripped
 

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2802
Different version of the above CD for comparison. Log file also edited for length. Note: Had read errors in the last track so it naturally has No match.
Code: [Select]
[CUETools log; Date: 5/18/2016 6:21:33 AM; Version: 2.1.6]
[CTDB TOCID: y3qHzcML6GUxunmLkD8GswohIa8-] found.
Track | CTDB Status
  1   | (202/204) Accurately ripped
  2   | (198/204) Accurately ripped
  3   | (200/204) Accurately ripped
  4   | (196/204) Accurately ripped, or (4/204) differs in 6 samples @04:09:15
  5   | (199/204) Accurately ripped
  6   | (194/204) Accurately ripped
  7   | (194/204) Accurately ripped
  8   | (195/204) Accurately ripped
  9   | (192/204) Accurately ripped
 10   | (204/204) Accurately ripped
 11   | (204/204) Accurately ripped
 12   | (204/204) Accurately ripped
 13   | (204/204) Accurately ripped
 14   | (204/204) Accurately ripped
 15   | (204/204) Accurately ripped
 16   | (204/204) Accurately ripped
 17   | (204/204) Accurately ripped
 18   | (204/204) Accurately ripped
 19   | (204/204) Accurately ripped
 20   | (204/204) Accurately ripped
 21   | (204/204) Accurately ripped
 22   | (204/204) Accurately ripped
 23   | (204/204) Accurately ripped
 24   | (204/204) Accurately ripped
 25   | (204/204) Accurately ripped
 26   | (204/204) Accurately ripped
 27   | (204/204) Accurately ripped
 28   | (204/204) Accurately ripped
 29   | (204/204) Accurately ripped
 30   | (204/204) Accurately ripped
 31   | (204/204) Accurately ripped
 32   | (204/204) Accurately ripped
 33   | (204/204) Accurately ripped
 34   | (204/204) Accurately ripped
 35   | (204/204) Accurately ripped
 36   | (204/204) Accurately ripped
 37   | (204/204) Accurately ripped
 38   | (204/204) Accurately ripped
 39   | (204/204) Accurately ripped
 40   | (204/204) Accurately ripped
 41   | (204/204) Accurately ripped
 42   | (204/204) Accurately ripped
 43   | (204/204) Accurately ripped
 44   | (204/204) Accurately ripped
 45   | (204/204) Accurately ripped
 46   | (204/204) Accurately ripped
 47   | (204/204) Accurately ripped
 48   | (204/204) Accurately ripped
 49   | (204/204) Accurately ripped
 50   | (204/204) Accurately ripped
 51   | (204/204) Accurately ripped
 52   | (204/204) Accurately ripped
 53   | (204/204) Accurately ripped
 54   | (204/204) Accurately ripped
 55   | (204/204) Accurately ripped
 56   | (204/204) Accurately ripped
 57   | (204/204) Accurately ripped
 58   | (204/204) Accurately ripped
 59   | (204/204) Accurately ripped
 60   | (204/204) Accurately ripped
 61   | (204/204) Accurately ripped
 62   | (204/204) Accurately ripped
 63   | (204/204) Accurately ripped
 64   | (204/204) Accurately ripped
 65   | (204/204) Accurately ripped
 66   | (204/204) Accurately ripped
 67   | (204/204) Accurately ripped
 68   | (204/204) Accurately ripped
 69   | (172/204) Differs in 7035 samples @02:00:16,02:00:35-02:00:36,02:00:55-02:00:56,02:00:74-02:01:00,02:01:19-02:01:20,02:01:39-02:01:40,02:01:58-02:01:59,02:02:03-02:02:04,02:02:23-02:02:24,02:02:42-02:02:43,02:02:62-02:02:63,02:03:07-02:03:08,02:03:26-02:03:27,02:03:46-02:03:47,02:03:66-02:03:67,02:04:10-02:04:11,02:04:30-02:04:31,02:04:50-02:04:51,02:04:69-02:04:70,02:05:14-02:05:15,02:05:34-02:05:35,02:05:53-02:05:54,02:05:73-02:05:74,02:06:18-02:06:19,02:06:37-02:06:38,02:06:57-02:06:58,02:07:21-02:07:22,02:07:41-02:07:42,02:08:45-02:08:46, or (4/204) differs in 7035 samples @02:00:16,02:00:35-02:00:36,02:00:55-02:00:56,02:00:74-02:01:00,02:01:19-02:01:20,02:01:39-02:01:40,02:01:58-02:01:59,02:02:03-02:02:04,02:02:23-02:02:24,02:02:42-02:02:43,02:02:62-02:02:63,02:03:07-02:03:08,02:03:26-02:03:27,02:03:46-02:03:47,02:03:66-02:03:67,02:04:10-02:04:11,02:04:30-02:04:31,02:04:50-02:04:51,02:04:69-02:04:70,02:05:14-02:05:15,02:05:34-02:05:35,02:05:53-02:05:54,02:05:73-02:05:74,02:06:18-02:06:19,02:06:37-02:06:38,02:06:57-02:06:58,02:07:21-02:07:22,02:07:41-02:07:42,02:08:45-02:08:46
[AccurateRip ID: 00ec19db-235aab21-08103745] found.
Track   [  CRC   |   V2   ] Status
 01     [37667aca|aed4aa3d] (022+012/848) Accurately ripped
 02     [531eadc3|3f939eea] (022+013/845) Accurately ripped
 03     [0a63287a|4b20ed3b] (023+013/849) Accurately ripped
 04     [f1bb9db9|aa7f2a57] (021+012/839) Accurately ripped
 05     [5dd8484a|ba24c768] (022+012/837) Accurately ripped
 06     [19bdbb8e|22051284] (021+012/839) Accurately ripped
 07     [1395eb33|68e19bfe] (020+013/822) Accurately ripped
 08     [2d9badd4|024075e0] (022+012/829) Accurately ripped
 09     [0673a775|26ea1976] (020+012/801) Accurately ripped
 10     [00000000|00000000] (000+000/001) No match
 11     [00000000|00000000] (000+000/001) No match
 12     [00000000|00000000] (000+000/000) Silent track
 13     [00000000|00000000] (000+000/000) Silent track
 14     [00000000|00000000] (000+000/000) Silent track
 15     [00000000|00000000] (000+000/000) Silent track
 16     [00000000|00000000] (000+000/000) Silent track
 17     [00000000|00000000] (000+000/000) Silent track
 18     [00000000|00000000] (000+000/000) Silent track
 19     [00000000|00000000] (000+000/000) Silent track
 20     [00000000|00000000] (000+000/000) Silent track
 21     [00000000|00000000] (000+000/000) Silent track
 22     [00000000|00000000] (000+000/000) Silent track
 23     [00000000|00000000] (000+000/000) Silent track
 24     [00000000|00000000] (000+000/000) Silent track
 25     [00000000|00000000] (000+000/000) Silent track
 26     [00000000|00000000] (000+000/000) Silent track
 27     [00000000|00000000] (000+000/000) Silent track
 28     [00000000|00000000] (000+000/000) Silent track
 29     [00000000|00000000] (000+000/000) Silent track
 30     [00000000|00000000] (000+000/000) Silent track
 31     [00000000|00000000] (000+000/000) Silent track
 32     [00000000|00000000] (000+000/000) Silent track
 33     [00000000|00000000] (000+000/000) Silent track
 34     [00000000|00000000] (000+000/000) Silent track
 35     [00000000|00000000] (000+000/000) Silent track
 36     [00000000|00000000] (000+000/000) Silent track
 37     [00000000|00000000] (000+000/000) Silent track
 38     [00000000|00000000] (000+000/000) Silent track
 39     [00000000|00000000] (000+000/000) Silent track
 40     [00000000|00000000] (000+000/000) Silent track
 41     [00000000|00000000] (000+000/000) Silent track
 42     [00000000|00000000] (000+000/000) Silent track
 43     [00000000|00000000] (000+000/000) Silent track
 44     [00000000|00000000] (000+000/000) Silent track
 45     [00000000|00000000] (000+000/000) Silent track
 46     [00000000|00000000] (000+000/000) Silent track
 47     [00000000|00000000] (000+000/000) Silent track
 48     [00000000|00000000] (000+000/000) Silent track
 49     [00000000|00000000] (000+000/000) Silent track
 50     [00000000|00000000] (000+000/000) Silent track
 51     [00000000|00000000] (000+000/000) Silent track
 52     [00000000|00000000] (000+000/000) Silent track
 53     [00000000|00000000] (000+000/000) Silent track
 54     [00000000|00000000] (000+000/000) Silent track
 55     [00000000|00000000] (000+000/000) Silent track
 56     [00000000|00000000] (000+000/000) Silent track
 57     [00000000|00000000] (000+000/000) Silent track
 58     [00000000|00000000] (000+000/000) Silent track
 59     [00000000|00000000] (000+000/000) Silent track
 60     [00000000|00000000] (000+000/000) Silent track
 61     [00000000|00000000] (000+000/000) Silent track
 62     [00000000|00000000] (000+000/000) Silent track
 63     [00000000|00000000] (000+000/000) Silent track
 64     [00000000|00000000] (000+000/000) Silent track
 65     [00000000|00000000] (000+000/000) Silent track
 66     [00000000|00000000] (000+000/000) Silent track
 67     [00000000|00000000] (000+000/000) Silent track
 68     [00000000|00000000] (000+000/000) Silent track
 69     [abdb91db|38dc7670] (000+000/724) No match
korth

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2803
I think it's the second time that I encounter this issue. If I recall correctly I had the same issue with a Marilyn Manson CD (Edit: just checked it's on Marilyn Manson - 1996 - Antichrist Superstar), the difference between yours and mine lies in (000+000/001) Vs. (000+000/000) ... seems like CUETools tries to compare silence against some garbage in the database ... maybe it would be easier to report as "Silent track" in log & "Rip Accurate" in batch as soon as the CRC are [00000000|00000000] no matter what's in the database (providing the other real tracks are OK indeed).

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2804
Request: It would be nice & save me some time if in the "input/folder browser/By AccurateRip Confidence" tree view, Cuetools would automatically sorts rips between: on one hand, rips that are not in the AR database at all, and on the other hand, rips that are not accurate. As of now, both are mixed in the Confidence 0 category, so it's a mess & I have to check manually.

Edit: The addition of "not accurate+differs" category would be nice too, in order to detect, in a blink of an eye, rips that you can potentially repair.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2805
Hey.

I've just wondered,... how can one find out the ID of one's system that is used for CTDB?
I'd assume there has to be something in order to identify a submitter in order to prevent multiple submissions, just like AccurateRip has its ID and it would be handy to know this ID should one need to reinstall the system or so.

Cheers,
Chris.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2806
If i recall correctly, it's just a hash of some windows system IDs that are based on motherboard serial number i think. Unfortunately you cannot change it.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2807
Aren't you upstream?! It should be possible to set any ID one likes in the respective client, regardles of whatwindows does and says…

At least it would be a bad idea, that the ID changes, just because of .eg. a new mainboard,...that would IMHO also kinda spoil the DB with wrong data, if people re-rip the same CDs but just on different hardware.

Cheers.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2808
btw, while I don't know the exact implementation,... using some system serial numbers or CPUID, instead of e.g. a randomly generated UUID, may be quite harmful as well,… consider e.g. if people would run their ripper from a VM, and those serial numbers would be the same there…

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2809
It's not that critical that those be unique. It's also not that critical that those don't change for a person. A dedicated enough person can always inject a little garbage into database, but that's not likely to happen and not likely to affect much. So, the way i see it, hash of windows system/motherboard id is good enough for the purpose of blocking accidental multiple submissions from the same user.

I debated introducing actual user accounts, but thought better of it.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2810
It's an old argument that has been long settled.

Multiple submissions of the same bad data are inconsequential when good data exists while you're checking the rips of your own legally distributed physical media.  Instances where the bad data comes from a faulty pressing (which are quite plentiful) cannot be helped by making user IDs more tamper-proof.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2811
Well my point here was rather that prefectionsists that rip their CDs multiple times (e.g. with different programs, EAC,CUERipper,...) may get more easily wrong confidence values, which doesn't matter for CDs with very high submissions, but does for such which are very very rare and where one is e.g. the only submitter.

In fact I've noticed that different programs (eac, plextools, dbpoweramp, cuetools) find different errors in some special cases,...

CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
AccurateRip doesn't seem to have that problem.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2812

Oh and another issue I've noticed:
All these programs seem to be pretty unreliable in determining ISRC and CATALOGUE.
I have ripped some 800 CDs now, Plextools and EAC give ISRC/CATALOGUE in the cue files for roughly ~360, but they already differ (i.e. for some CDs Plextools finds ISRC/CATALOGUE, where EAC doesn't… for a few cases less it's vice-versa).
CUERipper performs worst, it finds ISRC/CATALOGUE only for some ~50 CDs.
Interestingly I even had cases, where it did found both and on a later re-rip it no longer found them.

All the same hardware, Plextor PX-760A ripper…
Any ideas?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2813
CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
Please provide log files.
korth

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2814
CTBD (or at least the EAC plugin) seems to have the additional problem, that it submits the same results at least twice (on the same hardware):
When I first rip in image mode (without C2-error detection) I get a submission, when I then rip in tracks mode, I get a further one per track... when I then rip again in image mit (with C2) I don't get another one.
Please provide log files.

Attached are the logfiles/CUE/etc. from the rip of the Back To The Future 3, Varese Sarabande Edition, Disc 2 in question.

*.old.* is a rip made November 2015
*.new.* is a rip made today
All CUETools version 2.1.6, same drive (Plextor PX760) and other hardware.
The only difference is, that I've upgraded from Windows 8.1 to 10 in the meantime (including other windows updates).

You'll notice that everything is effectively the same, except the missing CATALOGUE, ISRC and additional INDEX 00 from the CUE file.

Any ideas?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2815
And another issue (same hardware, versions as right above):

This happens with on CD only (which rips fine in EAC and plextools), it's the Elisabeth 10th Anniversary Concert, ripping with Paranoid and Test&Copy.

Test mode rips "fine", i.e. it continues with the copy run,... but at the very end of it (presumably exactly at the end), I get the error as shown on the screenshot.
The only written file (i.e. not auto-deleted-by-cueripper) is the also attached CUE file. Also attached are the CUE files for that CD as generated by plextools and EAC.

Notice the different DISCIDs, EAC and CUERipper detect (plextools doesn't store that at all).
And of course also the "INDEX 01 954437:10:45" which CUERipper "detects" and is obviously bogus.

Any ideas here?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2816
Update: oops, sorry, found the duplicate submission. It was from before, Novermber the 10th 2015. Yeah, you are right, that's weird.

Code: [Select]
ctdb=> select * from submissions where userid = 'kdSFOVwG5dQl3KIWovI_qfAJZBY-' and entryid=3241650;
  subid  | entryid |            userid            |                                              agent                                              |        time        |      ip      |        drivename        | barcode | quality
----------+---------+------------------------------+-------------------------------------------------------------------------------------------------+---------------------+----------------+---------------------------+---------+---------
 12202098 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - DVDR  PX-708A) | 2015-12-20 15:00:29 | xx.xxx.xxx.241 | PLEXTOR  - DVDR  PX-708A |        |    100
 11430957 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - CD-R  PREMIUM) | 2015-11-10 18:04:07 | xx.xxx.xxx.239 | PLEXTOR  - CD-R  PREMIUM |        |    100
(2 rows)


So the reason it accepted the second submission is that the drive name has changed.
CUETools 2.1.6


Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2818
So the reason it accepted the second submission is that the drive name has changed.
Ah,.. well I didn't actually mean that, though it's also questionable whether this should happen or not.
I really have no strong opinion towards yes or no,... using a different drive may give different "info" and thus confidentiality, OTOH using the same medium and counting up the numbers is probably bad.

This of course doesn't matter for CDs whit many submissions from different users,... but if there's only one or two entries, perhaps from the same guy then, confidentiality get's quite low, even though the numbers are "high".


I actually wanted to see logs showing the EAC plugin submitting twice.
Sorry, I haven't read closely enough.
And I must apologise myself,... as I've had described the problem wrongly...
The problem isn't double submission, but rather that it CTDB implementations seem to count my own submission as confidence, which is IMHO quite bad.
Imagine I scan a very rare CD (and I have a few of those ;) )... there may be 0 or perhaps 1 submissions from other people.
I do the first rip, it gets submitted... and following that (in further rips) I'll already have a confidence of 1 (even though it's just my own which may be wrong).
Worse, when there was already one, and that differed from mine, I'll then still get a confidence of 1 (with one differing).
Even if I then clean the CD or so, and would get the other guy's result, I couldn't easily tell anymore whether I have now mine or his.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2819
But as I've just greped through all my logs, I noticed the following:
Every 1st time I rip a CD, the following lines appear:
>Submit result: VNthXYlxsQjeoXX1Qk7C1us7JF8- has been uploaded
I'd assume lines like these are, when I'm the first one submitting this CD, right?

>Submit result: Vlgp9wXAHMFYlROkdp89y5BtuQc- has been confirmed
I'd assume "confirm" is actually submit (my result) and it matched already submitted results, right?

There are a few like these
>Submit result: 3.mlBuCaBRtWb8JiBFXgryK1upQ- has been confirmed, 3.mlBuCaBRtWb8JiBFXgryK1upQ- has been confirmed
>Submit result: ny2wN9e1DSAA_c3wuEbkSeWY7_k- has been confirmed, ny2wN9e1DSAA_c3wuEbkSeWY7_k- has been confirmed
>Submit result: vmFQ.yhg.oBoKe.XSEuPA9l7xwk- has been confirmed, vmFQ.yhg.oBoKe.XSEuPA9l7xwk- has been confirmed
Why writing it twice?

a few:
>Submit result: already submitted
>Submit result: already submitted, already submitted
appear as well, but I cannot tell anymore, whether my data on whether this was the 1st rip is just bogus.

Every 2nd time I rip a CD, the following lines appear:
>Submit result: already submitted
>Submit result: already submitted, already submitted

Any ideas?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2820
Code: [Select]
 12202098 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - DVDR  PX-708A) | 2015-12-20 15:00:29 | xx.xxx.xxx.241 | PLEXTOR  - DVDR  PX-708A |        |    100
 11430957 | 3241650 | kdSFOVwG5dQl3KIWovI_qfAJZBY- | EACv1.0b3 CTDB 2.1.3 (Microsoft Windows NT 6.1.7601 Service Pack 1) (PLEXTOR  - CD-R  PREMIUM) | 2015-11-10 18:04:07 | xx.xxx.xxx.239 | PLEXTOR  - CD-R  PREMIUM |        |    100
(2 rows)

btw: That one is not from myself, though I likely generated a few of these… I always have either PX760-A and in few cases there may be an additional Plextor Premium.

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2821
Oops. I thought this was the one because it's the only one that matched the date from the log (Dec 20). So it had to be this one then - and there's only one:
Code: [Select]
ctdb=> select * from submissions where userid = '1utddNLiRo8.nJYL3jttLDFJ4fE-' and entryid=3241650;
  subid  | entryid |            userid            |                                      agent                                        |        time        |      ip      |        drivename        | barcode | quality
----------+---------+------------------------------+------------------------------------------------------------------------------------+---------------------+---------------+---------------------------+---------+---------
 11713428 | 3241650 | 1utddNLiRo8.nJYL3jttLDFJ4fE- | EACv1.0b6 CTDB 2.1.6 (Microsoft Windows NT 6.2.9200.0) (PLEXTOR  - DVDR  PX-760A) | 2015-11-26 05:56:47 | xx.xxx.xxx.99 | PLEXTOR  - DVDR  PX-760A |        |    100
The rest were denied:
Code: [Select]
ctdb=> select time,ip,drivename,barcode,quality,reason from failed_submissions where userid = '1utddNLiRo8.nJYL3jttLDFJ4fE-' and barcode='0030206115987';
        time         |      ip       |         drivename         |    barcode    | quality |      reason
---------------------+---------------+---------------------------+---------------+---------+-------------------
 2015-12-20 03:21:26 | xx.xxx.xxx.99 | PLEXTOR  - DVDR   PX-760A | 0030206115987 |     100 | already submitted
 2015-12-20 03:39:26 | xx.xxx.xxx.99 | PLEXTOR  - DVDR   PX-760A | 0030206115987 |     100 | already submitted
This only shows the ones where barcode (CATALOG) was read correctly. There are plenty more.
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2822
Your missing CATALOGUE, ISRC and additional INDEX 00 from the CUE file
http://www.cuetools.net/wiki/CUERipper_Options
Do you have Detect Indexes set to False?
Forgot to answer that:
No, DetectGaps=1 in settings.txt. So that should be True.

Code: [Select]
 11713428 | 3241650 | 1utddNLiRo8.nJYL3jttLDFJ4fE- | EACv1.0b6 CTDB 2.1.6 (Microsoft Windows NT 6.2.9200.0) (PLEXTOR  - DVDR  PX-760A) | 2015-11-26 05:56:47 | xx.xxx.xxx.99 | PLEXTOR  - DVDR  PX-760A |        |    100
Given on the IP address you've had there before the edit, I'd say that's me… so this is my UID then!?

The rest were denied:
As I wrote above, I just wrongly described the problem... it's not multiple times submitted, but the plugin shows me my own submission as confidence=1, while I think my own shouldn't count (as it's e.g. the case with AccurateRip).


This only shows the ones where barcode (CATALOG) was read correctly. There are plenty more.
What exactly do you mean here? Aren't submissions made when CATALOG is not read correctly?

btw: have you seen the other issues I've described above?

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2823
It's hard to reliably say that a particular submission was yours. I'd rather not have people rely on database being able to detect that - too many ways this can be misleading. In the end, confidence only matters when it's "large enough" and your one or two submissions are not significant then.

CATALOG is not very relevant here. Yes, submissions are made whether or not CATALOG is read. It's just an artefact of how failed_submissions table works that this was the only way i could figure out which ones relate to this particular CD - i don't store discid in the failed_submissions table, perhaps a mistake.

I'm too sleepy to reply to the rest at the moment ;)
CUETools 2.1.6

Re: CUETools versions 1.9.5 through 2.1.5 (current)

Reply #2824
It's hard to reliably say that a particular submission was yours. I'd rather not have people rely on database being able to detect that
Shouldn't that be rather simple? Either based on the submitting user's ID (as e.g. Accurate Rip does it),... or at least by storing the discIDs of ripped discs locally and not counting those that have been submitted before?

- too many ways this can be misleading. In the end, confidence only matters when it's "large enough" and your one or two submissions are not significant then.
Well I wouldn't necessarily say that,… if confidence is only 1, but that is from another person, than it's still pretty likely that one's version is correct... simply because it's rather unlikely that both have had errors in the very same places.

And for rare CDs you often don't get more than a confidence of 1 or 2 - it would be nice if this use case is covered as well, which would IMHO be easy, by simply not counting one's own submissions.


CATALOG is not very relevant here. Yes, submissions are made whether or not CATALOG is read. It's just an artefact of how failed_submissions table works that this was the only way i could figure out which ones relate to this particular CD - i don't store discid in the failed_submissions table, perhaps a mistake.
Ah I see :)

I'm too sleepy to reply to the rest at the moment ;)
Already looked at the other issues? Well as soon as you do, just tell me if you need more information.

Cheers,
Chris