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 DB (Read 325302 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

CUETools DB

Reply #50 –
Quote from: sauvage78 on
The fact that CTDB ignores 10 frames instead of 5 like AR is a "much bigger" (I know some people people might not consider 5 frames "big" but I disagree) design flaw IMHO, I already have 3 rips which are not AR but are CTDB OK ... even if AR & CTDB doesn't serve the same purpose, it is a little weird to have them conflicting.

The issue is actually quite complicated.

Let's imagine a simple scenario, a simple CD with one track, no pregaps, no datatracks, with total length of 100 sectors. Let's also assume we're submitting with CUETools, no ripping involved.

Suppose AR verification shows a total confidence of 10, offset 0;
That means that sectors 5..95 are verified and we can upload recovery record for them to CTDB with confidence 10.

But suppose AR verification shows offset = 4 sectors.
That means that sectors 9..99 are verified and we can upload recovery record for them to CTDB with confidence 10.

More complicated case: AR verification shows offset = 4 sectors, confidence = 10 and offset = -4 sectors, confidence = 5;
Then sectors 1..8 have confidence 5, sectors 9..91 have confidence 15 and sectors 92..99 have confidence 10.

What shall we upload? Sectors 9..91 with confidence 15 or sectors 1..99 with confidence 5?

Other part of the problem is that if the boundaries of processed segment depend on AR verification results, submitting will require two passes.
CUETools 2.1.6

CUETools DB

Reply #51 –
Well the two problems cases are very different:

- in the first problem case the AR database detects nothing wrong while the full checksum for the first track are different within the same pressing, this means that the problem is located inside the 5 frames ignored by AR.
This case have nothing to do with CTDB, I haven't tried CTDB on it, but I have deleted the bad doublons so I can't test anymore. Within all logic CTDB would have been of no help here because the difference being located ouside of the reach of the AR checksum it can only be located outside of the reach of the CTDB checksum (As CTDB ignores 5 added frames compared to AR.)

In this first problem case, I have only losslessly splitted the 5 first frames (as you've noticed it was painfull) & compared the Flac MD5 checksum which was different (The EAC wav comparator also detected differences). I cannot hear any difference (5 frames too too short to ABX anyway) & when I zoom on the 5 frames with any audio editor all I see is flat.

My first idea was naturally to think about a scratch, but I wasn't sure so I asked for advice & you told me that this was possibly due to an  -472 offset problem due to overread. My skill with an audio editor to obtain the same result were too weak. But I think that the explanation is logic & I know how serious you can be so I tend to trust you.

But IMHO this second case is slightly different, maybe you're right & maybe this is an even bigger overread into the lead-in problem ... but as far as I understund the 5 frames ignored by AR are already there to avoid this kind of problem. So the problem is beyond the safety margin which means that this time it is more likely to be a simple scratch. I have already deleted the un-corrected file so I cannot verify (but even if I would still have it the first problem case showed that I didn't knew how to do)

Anyway all this doesn't really matter what I wanted to illustrate is that it is possible to have a scratch detected by AR by that cannot be corrected by CTDB because of the difference between the length of ignored frames.

Quote
Differences between pressings can vary by more than just the offset at the edges. For this reason, extending the area of what is ignored can actually be a good thing.


I know that pressings can vary by a lot more than just the offset, but I don't understand the second part of the sentence, I don't see why it would be a good thing to extend the ignored area when this area is already enougth. There is not offset bigger than 5 frames in the database & I even think that 4 frames is already enougth if you only judge by drive in the AR database. 1 frame is not a big deal & I know Spoon chosen 5 frames back when there was virtual drive with big offset in his database which have been purged. A 1 frame margin is also eventually good as an added margin. But Greg adds 5 more frames this sounds enormous to me, he simply doubled the margin of Spoon. I don't understand why so I just ask. Maybe I am wrong.

I admit I haven't investigated the EAC bug, but from what I understand of it, if it's just 2 reapeated frames at the end, it only pushes the margin down to 3 frames at the beginning, even in this case you really need an offset higher than 3 frames to get in trouble. Even with this bug I can understand a choice of 5+2=7 ... but going up to 10 is overkill. Even so, I don't think that bug should affect the technical choice behind CTDB.

I admit, it's easier to attribute it to a scratch , but in this case it has a big chance of being a scratch IMHO.

CUETools DB

Reply #52 –
Offset differences between pressings can be far greater than just five frames.  EAC's bug is not limited to the last five frames either.

Until you can rule out other far more likely possibilities, I would avoid these hasty conclusions.  Like with the case involving a lack of overreading, it doesn't seem that you're fully grasping the whole picture.  Discarding your data without carefully inspecting it doesn't help.    When you see things like different fade-ins and fade-outs between pressings with your wave editor you will gain a greater appreciation of what Gregory is trying to do; if not a better understanding.

CUETools DB

Reply #53 –
Quote from: sauvage78 on
but going up to 10 is overkill.

You are forgetting that CTDB stores only one record for all pressings. Pressing offset adds to drive offset, and pressing offsets can be quite large. Even if drive offsets are limited to 4 sectors, pressing offsets of 6 sectors are not uncommon.
CUETools 2.1.6

CUETools DB

Reply #54 –
Yes, your exemple made me realize that the more there are existing pressings with different offset in the AR database, the bigger the margin of CTDB must be in order to still have a core/heart of sectors to calculate the correction checksum from (if you only want to do 1 pass & not rely on AR offsets) which would still work with all pressings.

So if I understund correctly CTDB is not really suited to correct scratches which happens at the beginning & at the end ... it's a pity.

I had to read the exemple 3 times, & spend 5 min to think about the consequences but it was usefull
I was completely wrong with how I thought CTDB would work & about the "flaw" of not behaving like the AR database. My way of thinking was too tied to AR.

It must have been a real engineering nightmare ...

Edit: Thks for the explanation, Greg & thks ... for your patience Greynol ... I do tell bullshits sometimes ...

CUETools DB

Reply #55 –
Quote from: sauvage78 on
So if I understund correctly CTDB is not really suited to correct scratches which happens at the beginning & at the end ... it's a pity.

While this is true, scratches that are so localized to cause problems only in these extremely small areas will be very very rare.  I doubt that you have any.

CUETools DB

Reply #56 –
Is CTDB able to identify null sample tracks? AR fails to store these tracks in the database, I guess because its CRC is giving the same value for all totally silent tracks no matter how long their duration is.

I have one CD with three silent tracks at the end which fails to AR-verify in CUE Tools because of that. Although this is only a cosmetic issue of the log, will CTDB circumvent this problem? I mean even if a silent track is not much to listen to, if there was to be a read error, it may become audible and I think therefore it should be detectable by a verification database.

CUETools DB

Reply #57 –
CTDB doesn't care about tracks and it doesn't care about null samples, so yes, it is able to repair noise to silence.
CUETools 2.1.6

CUETools DB

Reply #58 –
Quote from: Fandango on
I mean even if a silent track is not much to listen to, if there was to be a read error, it may become audible

Doubtful since interpolation between silence gives silence.  Errors so bad that cannot be interpolated are generally replaced by silence.  Perhaps a held DC value from an errant sample, but this seems unlikely.

CUETools DB

Reply #59 –
I have found one more strange log:
An AR3 rip with CTDB differences but with a confidence of 0. Any idea of why such thing can happen ? Has there already been a purge in the young CTDB ? Even if it was a purge the thing I don't understand is that if there is a checksum stored (there is obviously 1 as a differences are calculated) It should necessarily means a CTDB confidence of 1 ... so how can there be an existing checksum without any confidence level ? Specially on an AR3 rip ? Is it a CTDB bug ?

Code: [Select]
[Verification date: 11/05/2010 14:44:48]
[AccurateRip ID: 000d34c3-006c99e1-8609110a] found.
[CTDB TOCID: DKLLUM1E6Nrp_tsCx8Bqg4iloPk-] found.
        [ CTDBID ] Status
        [52f7fda3] (0/0) Differs in 29399 samples @08:25:08-08:25:33
Track	[ CRC    ] Status
 01	[ca629bd7] (03/03) Accurately ripped
 02	[7f084dd2] (03/03) Accurately ripped
 03	[9e1e1f5f] (03/03) Accurately ripped
 04	[fd880f87] (03/03) Accurately ripped
 05	[15949383] (03/03) Accurately ripped
 06	[db667438] (03/03) Accurately ripped
 07	[f1b1d28d] (03/03) Accurately ripped
 08	[e91e2258] (03/03) Accurately ripped
 09	[fb7981e3] (03/03) Accurately ripped
 10	[07ad5387] (03/03) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --  100,0 [7E17A9CC] [704C81CF]   CRC32   
 01  100,0 [9C8BFCDE] [5B747295]           
 02   96,8 [C8C2FC04] [A024B381]           
 03   96,4 [E083B51F] [E98ADF35]           
 04  100,0 [3E2F0464] [6C1251DB]           
 05  100,0 [E9DEF500] [DECB891C]           
 06   98,1 [E5E4A5E6] [83DBB535]           
 07   80,0 [0A5A0CCF] [61ABEEC0]           
 08   99,8 [579624EE] [4D2FD443]           
 09   94,2 [61CC98E3] [FA1F8E92]           
 10   96,8 [0FE9DA58] [8242B8EA]         


CUETools DB

Reply #60 –
I was actually testing CUERipper on that disc  My CD is scratched, so i couldn't get an accurate rip, and i just manually purged this entry afterwards. Would be nice if you could submit it
CUETools 2.1.6

CUETools DB

Reply #61 –
Ok, Thks

I have submitted this CD so that you can fix yours.
Quote
CDImage.cue: DKLLUM1E6Nrp_tsCx8Bqg4iloPk- has been updated.

CUETools DB

Reply #62 –
Thanks
CUETools 2.1.6

CUETools DB

Reply #63 –
I just re-checked this CD, now the reverse is happening, it has jumped directly to CTDB confidence 3 ? I thought it would have become CTDB confidence 1+AR3 after my submission. I am understanding the meaning of CTDB (3/3) wrongly (is it related to AR3 maybe, I thought it wasn't? I thought it was just the number of match/the number of CTDB submissions) or is there any other explanation ?

Code: [Select]
[Verification date: 12/05/2010 06:29:45]
[AccurateRip ID: 000d34c3-006c99e1-8609110a] found.
[CTDB TOCID: DKLLUM1E6Nrp_tsCx8Bqg4iloPk-] found.
        [ CTDBID ] Status
        [cedd9f43] (3/3) Accurately ripped
Track	[ CRC    ] Status
 01	[ca629bd7] (03/03) Accurately ripped
 02	[7f084dd2] (03/03) Accurately ripped
 03	[9e1e1f5f] (03/03) Accurately ripped
 04	[fd880f87] (03/03) Accurately ripped
 05	[15949383] (03/03) Accurately ripped
 06	[db667438] (03/03) Accurately ripped
 07	[f1b1d28d] (03/03) Accurately ripped
 08	[e91e2258] (03/03) Accurately ripped
 09	[fb7981e3] (03/03) Accurately ripped
 10	[07ad5387] (03/03) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --  100,0 [7E17A9CC] [704C81CF]           
 01  100,0 [9C8BFCDE] [5B747295]           
 02   96,8 [C8C2FC04] [A024B381]           
 03   96,4 [E083B51F] [E98ADF35]           
 04  100,0 [3E2F0464] [6C1251DB]           
 05  100,0 [E9DEF500] [DECB891C]           
 06   98,1 [E5E4A5E6] [83DBB535]           
 07   80,0 [0A5A0CCF] [61ABEEC0]           
 08   99,8 [579624EE] [4D2FD443]           
 09   94,2 [61CC98E3] [FA1F8E92]           
 10   96,8 [0FE9DA58] [8242B8EA]         

Also why does CTDB reports (6/6) No match instead of (0/6) No match in this log

Code: [Select]
[Verification date: 28/04/2010 15:56:02]
[AccurateRip ID: 000b5e1b-00460ba6-560aaa07] found.
Pregap length 00:00:33.
[CTDB TOCID: SrqfChprJfQaVZ.K2a_V4AalfcE-] found.
        [ CTDBID ] Status
        [c6cfb022] (6/6) No match
Track	[ CRC    ] Status
 01	[c8243388] (00/39) No match
 02	[62d8c057] (00/40) No match
 03	[9a178a8a] (00/40) No match
 04	[3c9ae5bc] (00/39) No match
 05	[160e691c] (00/38) No match
 06	[f391b6f2] (00/39) No match
 07	[5e0f5ea5] (00/40) No match
Offsetted by -579:
 01	[ca0690bf] (05/39) Accurately ripped
 02	[b23d8e96] (05/40) Accurately ripped
 03	[9fbd6b42] (05/40) Accurately ripped
 04	[2cf80293] (05/39) No match but offset
 05	[53fbbb74] (05/38) Accurately ripped
 06	[298d69df] (05/39) Accurately ripped
 07	[07de6a7b] (05/40) Accurately ripped
Offsetted by -99:
 01	[9368165f] (00/39) No match
 02	[0e442f36] (07/40) No match but offset
 03	[5cb73842] (00/40) No match
 04	[c534c433] (00/39) No match
 05	[1f518474] (06/38) No match but offset
 06	[de4aadbf] (07/39) No match but offset
 07	[f7c754bb] (00/40) No match
Offsetted by -97:
 01	[bdd87e65] (00/39) No match
 02	[a0c87a8c] (00/40) No match
 03	[b0b3fe72] (00/40) No match
 04	[ab2c7c79] (06/39) No match but offset
 05	[8690cee4] (00/38) No match
 06	[7f0b77a1] (00/39) No match
 07	[a482f7d7] (00/40) No match
Offsetted by -96:
 01	[d310b268] (00/39) No match
 02	[ea0aa037] (00/40) No match
 03	[dab2618a] (07/40) No match but offset
 04	[1e28589c] (00/39) No match
 05	[ba30741c] (00/38) No match
 06	[cf6bdc92] (00/39) No match
 07	[fae0c965] (00/40) No match
Offsetted by -95:
 01	[e848e66b] (00/39) No match
 02	[334cc5e2] (00/40) No match
 03	[04b0c4a2] (00/40) No match
 04	[912434bf] (00/39) No match
 05	[edd01954] (00/38) No match
 06	[1fcc4183] (00/39) No match
 07	[513e9af3] (07/40) No match but offset
Offsetted by -94:
 01	[fd811a6e] (06/39) No match but offset
 02	[7c8eeb8d] (00/40) No match
 03	[2eaf27ba] (00/40) No match
 04	[042010e2] (00/39) No match
 05	[216fbe8c] (00/38) No match
 06	[702ca674] (00/39) No match
 07	[a79c6c81] (00/40) No match
Offsetted by 84:
 01	[be954484] (07/39) Accurately ripped
 02	[6c8d1c73] (07/40) Accurately ripped
 03	[61900e6a] (07/40) Accurately ripped
 04	[f73f2138] (07/39) No match but offset
 05	[06709f7c] (07/38) Accurately ripped
 06	[5332d606] (07/39) Accurately ripped
 07	[b4d8213d] (07/40) Accurately ripped
Offsetted by 102:
 01	[3c88ecba] (17/39) Accurately ripped
 02	[9333c279] (17/40) Accurately ripped
 03	[5573061a] (17/40) Accurately ripped
 04	[0cf49bae] (17/39) No match but offset
 05	[a7aa3d6c] (17/38) Accurately ripped
 06	[f9f9eef8] (17/39) Accurately ripped
 07	[c770dd39] (17/40) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] 
 --   97,7 [8147D7CD] [553022C2]           
 01   97,7 [A8AC93F2] [1E768B56]           
 02   97,7 [BB22369D] [00143B9D]           
 03   97,7 [E189EB05] [32995898]           
 04   97,7 [7D38D94A] [8B6086CE]           
 05   97,7 [454CAF56] [EF251649]           
 06   97,7 [2C6E28C5] [723271B1]           
 07   97,7 [6B0CCFA5] [1D31FE76]         

I begin to have doubt about my understanding about what CTDB is reporting.

CUETools DB

Reply #64 –
I purged the second entry completely. Before i did, it looked like this:
Code: [Select]
        [ CTDBID ] Status
        [cedd9f43] (3/3) Accurately ripped
        [52f7fda3] (0/3) Differs in 29399 samples @08:25:08-08:25:33


CTDB confidence comes from AR confidence + number of rips done using CUERipper. In this case AR confidence = 3, number of rips done using CUERipper = 0, so the total is 3.

As for "(6/6) No match", it might be a bit confusing because it's different from AR log, but in fact it's very simple.
The first number is just a confidence value of this CTDB record, regardless of whether or not it matches your copy.
The second number is a sum of confidence values for all CTDB records with this TOCID.
So those numbers only tell us how authoritative this record is, not how well it matches the data.

UPD: fixed typo
CUETools 2.1.6

CUETools DB

Reply #65 –
Ok, once more I was completly wrong about CTDB

It's a little artificial to put "(3/3)+Accurately ripped" on the same line when "(3/3)" has nothing to do with the conclusion "Accurately ripped", specially compared to how the AR part of the log works but it has the advantage of being shorter ... I guess people will have to learn what it means because if it's short it is not intuitive.

Also I never tried CUERipper so far but I hope that at some point CUERipper will get swallowed by AR so that the CTDB confidence can become AR only & not AR+CUERipper.

Overall these (X/Y) numbers are not very interesting because X will sooner or later become the same as the AR confidency & Y is (actually) useless because there are so many more entries in the AR database than in the CTDB, that if you want an idea of how authoritative your pressing is you'd better have a look at AR database. These numbers seems only interesting when the AR log is not accurate, because when it's accurate it should be doublons (specially X) with the AR info. Y & the supposed authoritative information is actually rather random with so few entries.

Maybe it is usefull for you as an ID to store different checksums ? Also is there any link between those numbers & the conclusion that I wouldn't have seen?

CUETools DB

Reply #66 –
Quote from: Gregory S. Chudov on
I don't store pregaps exactly because they are too inconsistent. There'll be too many different gap detection results for each CD, and hard to tell which ones are correct.

Drive models are stored: http://db.cuetools.net/?agent=CUERipper%20...20RW%20AD-7203S


Gregory, Hello!

First, I wanted to thank you for the initiative of creating the CTDB! This is the Holy Grail I was waiting for, since I wasn't happy enough with Spoon's AccurateRip DB.

- Check on the whole CD and not track based (I hate multiple files for CD archival...)
- Possibility to repair an inaccurate rip

That was enough to convince me. I completely understand you about the difficulty of implementing the pregap informations in your CTDB because of its random results. However, IMHO, the pregaps are as much important as the audio stream itself for an Audio CD archival purpose!

Moreover (I'm sure you aware of this, but not everybody are) TOC and pregaps are not enough informations neither! In a very few CDs (I've encountered only two so far) some of their tracks were divided into parts or "chapters" (I don't know the right term for this, I should check my Red Book copy ). On the oldest CD players, there was a "chapter" counter next to the track counter.

The result in the cue sheet file, is multiple indexes. I pasted you an example here:

Code: [Select]
TITLE "2112"
PERFORMER "Rush"
REM REPLAYGAIN_ALBUM_GAIN -7.24 dB
REM REPLAYGAIN_ALBUM_PEAK 0.977356
FILE "1976 • Rush - 04 - 2112 • Remaster Mercury P2B-34626.flac" WAVE
  TRACK 01 AUDIO
    TITLE "2112: I. Overture / II. The Temples of Syrinx / III. Discovery / IV. Presentation / V. Oracle: The Dream / VI. Soliloquy / VII. Grand Finale"
    REM REPLAYGAIN_TRACK_GAIN -7.43 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977356
    INDEX 01 00:00:00
    INDEX 02 04:32:40
    INDEX 03 06:46:00
    INDEX 04 10:15:22
    INDEX 05 13:57:27
    INDEX 06 15:57:35
    INDEX 07 18:18:45
  TRACK 02 AUDIO
    TITLE "A Passage To Bangkok"
    REM REPLAYGAIN_TRACK_GAIN -6.87 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977356
    INDEX 00 20:32:67
    INDEX 01 20:33:35
  TRACK 03 AUDIO
    TITLE "The Twilight Zone"
    REM REPLAYGAIN_TRACK_GAIN -5.87 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977356
    INDEX 00 24:07:47
    INDEX 01 24:08:30
  TRACK 04 AUDIO
    TITLE "Lessons"
    REM REPLAYGAIN_TRACK_GAIN -7.62 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977356
    INDEX 00 27:25:70
    INDEX 01 27:27:57
  TRACK 05 AUDIO
    TITLE "Tears"
    REM REPLAYGAIN_TRACK_GAIN -5.09 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977325
    INDEX 00 31:18:05
    INDEX 01 31:20:20
  TRACK 06 AUDIO
    TITLE "Something For Nothing"
    REM REPLAYGAIN_TRACK_GAIN -7.35 dB
    REM REPLAYGAIN_TRACK_PEAK 0.977356
    INDEX 00 34:50:55
    INDEX 01 34:54:40


You will tell me that all the cue/CDimage players don't bother with pregaps and "chapters" and that is so far irrelevant to take them into account, but I have a project of creating a player that will simulate the display of the old-fashioned Hi-Fi CD players. It's just a project in this state, however

In my opinion, I think we have to find a solution to implement this in the future in your DB. Perhaps a separated DB where people can compare the different cue for each CD ID entry? I know that's not easy at all...

CUETools DB

Reply #67 –
Quote from: Saxo on
I have a project of creating a player that will simulate the display of the old-fashioned Hi-Fi CD players. It's just a project in this state, however

Also as a default user interface component for foobar2000? That would be nice eye-candy!

CUETools DB

Reply #68 –
Quote from: Fandango on
Quote from: Saxo on
I have a project of creating a player that will simulate the display of the old-fashioned Hi-Fi CD players. It's just a project in this state, however

Also as a default user interface component for foobar2000? That would be nice eye-candy!


Well... I think I'm going to disappoint you. First, I want to simulate the behavior of the old CD players more than their appearance  Secondly, I'm writing it in Objective-C using the Cocoa framework. Mac OS X lacks of cue/CDimage player, when Windows have foobar2000.

But since I'm still learning and very lazy, don't expect anything anytime soon.

CUETools DB

Reply #69 –
Quote from: Saxo on
In my opinion, I think we have to find a solution to implement this in the future in your DB. Perhaps a separated DB where people can compare the different cue for each CD ID entry? I know that's not easy at all...

A repository of cue sheets is not very difficult to set up, i'm sure someone will do this someday.
The problem with it is not that it's difficult, but it's boring  Much less challenging than CTDB's idea.
And much less useful. You can re-rip a cuesheet from a CD in a matter of seconds.
CUETools 2.1.6

CUETools DB

Reply #70 –
Well maybe the biggest use would be for protected CD ... I think that there is a bunch of CDImage with broken  INDEX 00 in the wild, most often the INDEX 00 is frozen & sometimes INDEX 00 is after the end of the whole CD range too ... I don't know if these are really related to CD protection breaking the Red Book or if it's just related to bad drives/settings but I guess it would maybe help with these rips ... the problem is that where it may help the database will probably get very random results. (I am only guessing)

In the end such a database would be really oriented toward piracy because if you own the CD you obviously will have no use of it except in really rare cases IMHO.

The paradox is that in case of real life HDD crash, a cue sheet database might be more usefull than the actual CTDB ... here experience is speaking ... I already had a crash several year ago, after a full Getdatataback recovery, I had more broken cue sheet with random data inside than broken CDImage.flac, the explanation seems to be that it is easier for recovery algorithms to recover bigger files with lot of HDD links (clusters) than to recover very small files with only 1 HDD link. I am not saying that CTDB would be useless, I had several broken flac too, so back then I would have liked CTDB to exist, it's just that I had around twice more broken cuesheet then broken flac (rounded up) which was a surprise to me.

CUETools DB

Reply #71 –
Quote from: sauvage78 on
In the end such a database would be really oriented toward piracy because if you own the CD you obviously will have no use of it except in really rare cases IMHO.

The first use of the cue sheet is to archive a CD on a HDD. The INDEX tags keeps informations that allow anyone to have the whole original CD experience without touching the physical media. Personally, I rip a CD and don't put my hand on it anymore. I don't use different files for each track neither and I like to play a CD by opening its cue sheet in a player. I suspect that other peoples have the same opinion on this than me. So we use cue sheets all the time and not only in rare occasions. I understand the piracy problem point of view, but since CTDB give access to the track-only TOC, that won't be any different.

Quote from: Gregory S. Chudov on
A repository of cue sheets is not very difficult to set up, i'm sure someone will do this someday.
The problem with it is not that it's difficult, but it's boring  Much less challenging than CTDB's idea.
And much less useful. You can re-rip a cuesheet from a CD in a matter of seconds.

I know that I could try reproducing more accurate cue sheet files with CUERipper if the previous ripper I used wasn't very good. The trick is that we don't talk about checking 10 CDs... but hundreds of them and a batch process could be very helpful! IMHO, it could also be very interesting to have the results of different persons, using different drives, and different rippers.

Of course, I'm talking about a general database here, that won't be specifically linked to CUERipper. I completely understand that you don't want to bother with that. I imagine a database where EAC, CUERipper and other rippers could access with write permission and I could try to do something about it myself. Your CTDB is already a marvelous gift to us

CUETools DB

Reply #72 –
Saxo:
I am not arguing about the usefullness of cuesheets, I am arguing about the usefullness (& honesty) of a database created in order to fix broken cuesheets.
The case were cuesheets can be broken are so rare (except broken drives & maybe bad settings), that the most obvious use of such a database would not actually be to repair bad cuesheets (like CTDB is doing for damaged audio), but obviously to create cuesheets for people without cuesheets at all ... which means that this people wouldn't physically own the CD but only a cheap pirated separate tracks copy. (If they cannot just re-create the cuesheet in a few sec from the CD)

Don't get me wrong: as a user I would indeed enjoy it if such a database would exist (who wouldn't except RIAA & Co?) but it is obvious to that this database would be used 99% of time to create a cuesheets for pirated files & 1% of time to actually repair broken cuesheets ... so I am only sarcastic about the true utility of such a database. I am even more sarcatic as over the year I have meet many people which were teaching me that cuesheets were not usefull ... thks god I never listened to them.

You can argue that the AR & CTDB databases can be miss-used for piracy too, & with that I totally agree, but the proportion between legal use & abuse is much lesser with AR & CTDB than with a cuesheet database ... simply because scratches happens way more often than broken INDEX.

Maybe the existence of such a database would prove that I am completely wrong & that cue sheet variations happens all the time ... afterall no-one (even Spoon I think & at last not me) suspected that there were so many pressings with offset difference before the creation of the AR database. Personnaly I would be more curious about such a database in order to learn about the robustness/consistency of cuesheets than just in order to fix cuesheets.

CUETools DB

Reply #73 –
Hi Greg,
In a discussion (that took a bad direction because I was making a lot of assumptions about CTDB which ended to be erroneous, sorry if it is painfull to read), it appeared that CTDB seems to accept non accurate submissions as long as it is done with cueripper (I didn't test it myself). The so-called AR(1) entries.

I am now worried about this, as from my un-educated point of view it seems that it means that you possibly admit entries to CDTB that might be damaged. The proportion of bad submissions should be low & even in this case it is up to the user to verify that once "fixed" the rip is more accurate than before trying to fix it. ... still even if I think that I know how to avoid "fixing" damaged rips with damaged CTDB submissions, I don't like idea that such non accurate CTDB entries will appear in my .accurip.

So, without resurecting this thread, I wanted to simply ask you: Why you are doing this & why you think that this is a non-issue ? I ask because most of the reason why the linked thread derailed is that I couldn't believe myself that CTDB was behaving like this.

I don't understand the logic of being AR(2) dependent if the rip comes from EAC or dbpoweramp & in the same time not dependent of the accuracy at all if the rip comes from cueripper.

Is there any rationnal explanation ? Is it just that you wanted to populate the database quickly ? (too quickly ...) Have you stored any additionnal informations that would allow you to re-check the accuracy of these suspicious submissions later ? (& purge them ...) Do you think that this is a minor issue ?

I don't understand why you store submissions that might be damaged & which does take some space on your database/hardrive when I think I recall that you said that you couldn't store a stronger correction file to keep the database small.

As I don't want to make assumptions about CTDB anymore (I get trouble with Greynol when I do so), I thought that I'd rather ask you directly, sorry ... Am i just completely wrong once again ?

Thks for any answers & all apologies if this is a non-issue.