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

AccurateRip

We have re-written the backend of AccurateRip from scratch, this was done because:

The database has been improved for speed, previously the database had grown over the 4 years AccurateRip has been running and the design was breaking - this was detected in Feb 2009 and we have held off updating the online database because of high chances of corruption. The new routines / hardware is x100 faster (we use an x64 OS and fill with memory to run the database in memory). Also we scrapped the old database - and re-ran everyones submissions (going back to 2005) into the new database. The design of the database is custom, as SQL will not 'hack' 40 Million submissions in a reasonable turn of speed.

Better Administration - the back end tools are imprved for managing users / drives

Better user tracking - we have relaxed the internal rules of submission, as we now take a users submission as a whole rather than on individual track basis - this allows for more submissions in the database - this new database is 3x larger than the old one - so there are 3x more discs in the database....

AccurateRip

Reply #1 –
Good to hear, congratulations for the achieved speedup!

Quote from: spoon on
The design of the database is custom, as SQL will not 'hack' 40 Million submissions in a reasonable turn of speed.


I would have thought that AccurateRip is a perfect match for a relational db. It's more ore less a tree of checksums. And 40 million isn't that much when you usually need only a fraction of this dataset (just counts instead of whole submissions). But if you have enough memory for the whole dataset now anyway I can imagine what rocket speeds can be achieved by a custom solution. I don't think that you can store your data much smarter than a mature db, but at least you can save the inter process communication overhead, which can be substantial for very small and fast queries like AccurateRip results.

What language have you used?

AccurateRip

Reply #2 –
"there are 3x more discs in the database" ==> great news

does the "new users/drives management" & "submission as a whole" improve the cuetools "tangled results issue" from the old "track basis design" in any way?
Edit: seems not "Immune to different CD pressings" will come later

also, the database being easier to rebuild does this mean that we could expect more regular database update ? How long does it takes to rebuild the new database now ? Having something like an official public version for the database would help a lot to recheck "Disk not present in database." ... something like AccurateRip Database V1.5 (21-04-09) posted on somewhere on AccurateRip Frontpage that you could update when the database will be rebuild & that could be included in cuetools/eac/dbpoweramp logs/results would be very nice.

AccurateRip

Reply #3 –
>improve the cuetools "tangled results issue" from the old "track basis design" in any way?

No, if anything the new database might be worse, but the design of AccurateRip is that the order of stored results are not important - just the end result.

It used to take 2 days to rebuild the database, now it takes 2 hours.

c++ is used for the backend.

AccurateRip

Reply #4 –
Is it possible that some results have been removed/lost in the process, I just re-check a rip with "confidence 1", instead of increasing I got a "No matches" result now. I noticed it usually goes up, but not this one.

Code: [Select]
[Verification date: 26/03/2009 20:31:45]
[Disc ID: 000dbccc-0065b397-5b09d009]
Track    [ CRC    ] Status
 01    [383823dd] (01/01) Accurately ripped as in pressing(s) #1
 02    [beadb63f] (01/01) Accurately ripped as in pressing(s) #1
 03    [73b73037] (01/01) Accurately ripped as in pressing(s) #1
 04    [d90ea871] (01/01) Accurately ripped as in pressing(s) #1
 05    [05e97dc6] (01/01) Accurately ripped as in pressing(s) #1
 06    [c46dca16] (01/01) Accurately ripped as in pressing(s) #1
 07    [ff88179b] (01/01) Accurately ripped as in pressing(s) #1
 08    [02f53578] (01/01) Accurately ripped as in pressing(s) #1
 09    [8fb25d33] (01/01) Accurately ripped as in pressing(s) #1

Track    [ CRC32  ]    [W/O NULL]    
 --    [671F34B5]    [64DBDC33]    
 01    [CC455F0F]    [3BD2EB2F]    
 02    [5AA36916]    [1754F5BD]    
 03    [9CE3D596]    [ECCA92F4]    
 04    [15B76A28]    [4B2857A7]    
 05    [4282A76F]    [72891D1C]    
 06    [F6205E56]    [A6F09828]    
 07    [DF03A4D1]    [47115FE2]    
 08    [28119067]    [1CAB83CD]    
 09    [7BF8163F]    [642D61D7]


Code: [Select]
[Verification date: 21/04/2009 15:11:26]
[Disc ID: 000dbccc-0065b397-5b09d009]
Track    [ CRC    ] Status
 01    [383823dd] (00/00) No matches
 02    [beadb63f] (00/00) No matches
 03    [73b73037] (00/00) No matches
 04    [d90ea871] (00/00) No matches
 05    [05e97dc6] (00/00) No matches
 06    [c46dca16] (00/00) No matches
 07    [ff88179b] (00/00) No matches
 08    [02f53578] (00/00) No matches
 09    [8fb25d33] (00/00) No matches

Track    [ CRC32  ]    [W/O NULL]    
 --    [671F34B5]    [64DBDC33]    
 01    [CC455F0F]    [3BD2EB2F]    
 02    [5AA36916]    [1754F5BD]    
 03    [9CE3D596]    [ECCA92F4]    
 04    [15B76A28]    [4B2857A7]    
 05    [4282A76F]    [72891D1C]    
 06    [F6205E56]    [A6F09828]    
 07    [DF03A4D1]    [47115FE2]    
 08    [28119067]    [1CAB83CD]    
 09    [7BF8163F]    [642D61D7]

AccurateRip

Reply #5 –
Also the variation on last track for this one:

Before
11   [29997b97] (09/09) Partial match to pressing(s) #1,2
After
11   [29997b97] (05/08) Partial match to pressing(s) #1

Does this means that before the update both #1 & #2 didn't agree with me (with #1 being 5/9 & #2 being 4/9), & now with the update 1 result was lost/removed & only "so called" pressing #1 is counted as didn't agree (as it seems 3/8 results from "so called" pressing #2 are "lost" or not displayed anymore too) or is there any other explanation.

Code: [Select]
[code][Verification date: 26/03/2009 20:33:23]
[Disc ID: 001e567e-010a0895-9112820b]
Track    [ CRC    ] Status
 01    [f9943bc6] (05/11) Accurately ripped as in pressing(s) #1
 02    [fcf32552] (05/11) Accurately ripped as in pressing(s) #1
 03    [708357bc] (05/11) Accurately ripped as in pressing(s) #1
 04    [ac29fbc0] (05/11) Accurately ripped as in pressing(s) #1
 05    [a1efa42d] (05/11) Accurately ripped as in pressing(s) #1
 06    [35d8b4a7] (05/11) Accurately ripped as in pressing(s) #1
 07    [2458a77e] (05/11) Accurately ripped as in pressing(s) #1
 08    [89bf1f8e] (05/10) Accurately ripped as in pressing(s) #1
 09    [72f3bb79] (05/10) Accurately ripped as in pressing(s) #1
 10    [5c56df46] (05/10) Accurately ripped as in pressing(s) #1
 11    [29997b97] (09/09) Partial match to pressing(s) #1,2 

Track    [ CRC32  ]    [W/O NULL]    
 --    [ABA32B53]    [525B0117]    
 01    [DB119DE3]    [EC9AB035]    
 02    [3956494D]    [835147A3]    
 03    [6773022D]    [449B5D76]    
 04    [9BD29682]    [9A82D175]    
 05    [8699357D]    [31997476]    
 06    [10F4FEF2]    [6504A4DA]    
 07    [9FB5B2D3]    [3EB70A19]    
 08    [C84C4CD5]    [9F7DF5AB]    
 09    [9391F598]    [7A3B9664]    
 10    [B747D5B4]    [5F0F33C4]    
 11    [F2BDABE9]    [F10A4F47]
[/code]

Code: [Select]
[Verification date: 21/04/2009 15:37:15]
[Disc ID: 001e567e-010a0895-9112820b]
Track    [ CRC    ] Status
 01    [f9943bc6] (05/10) Accurately ripped as in pressing(s) #1
 02    [fcf32552] (05/10) Accurately ripped as in pressing(s) #1
 03    [708357bc] (05/10) Accurately ripped as in pressing(s) #1
 04    [ac29fbc0] (05/10) Accurately ripped as in pressing(s) #1
 05    [a1efa42d] (05/10) Accurately ripped as in pressing(s) #1
 06    [35d8b4a7] (05/10) Accurately ripped as in pressing(s) #1
 07    [2458a77e] (05/10) Accurately ripped as in pressing(s) #1
 08    [89bf1f8e] (05/09) Accurately ripped as in pressing(s) #1
 09    [72f3bb79] (05/09) Accurately ripped as in pressing(s) #1
 10    [5c56df46] (05/09) Accurately ripped as in pressing(s) #1
 11    [29997b97] (05/08) Partial match to pressing(s) #1 

Track    [ CRC32  ]    [W/O NULL]    
 --    [ABA32B53]    [525B0117]    
 01    [DB119DE3]    [EC9AB035]    
 02    [3956494D]    [835147A3]    
 03    [6773022D]    [449B5D76]    
 04    [9BD29682]    [9A82D175]    
 05    [8699357D]    [31997476]    
 06    [10F4FEF2]    [6504A4DA]    
 07    [9FB5B2D3]    [3EB70A19]    
 08    [C84C4CD5]    [9F7DF5AB]    
 09    [9391F598]    [7A3B9664]    
 10    [B747D5B4]    [5F0F33C4]    
 11    [F2BDABE9]    [F10A4F47]

AccurateRip

Reply #6 –
Also why are some result tagged as pressing(s) #2 before now called pressing(s) #1 now ??? I know these numbers means nothing but why did it change ? Maybe because some results were removed & now the first submission date order has changed ? One more good argument to remove these stupid #numbers from cuetools ?

Code: [Select]
[Verification date: 21/04/2009 15:37:56]
[Disc ID: 001125a1-007bc413-850b0f09]
Track    [ CRC    ] Status
 01    [d60bb509] (00/47) No matches
 02    [146d338f] (00/43) No matches
 03    [826087d8] (00/46) No matches
 04    [9ee22907] (00/46) No matches
 05    [62172bee] (00/46) No matches
 06    [63a32cce] (00/46) No matches
 07    [ef8a3bf1] (00/47) No matches
 08    [a49ec53f] (00/46) No matches
 09    [e36e3c1d] (00/46) No matches
Offsetted by -2063:
 01    [2c7ab3ad] (04/47) Accurately ripped as in pressing(s) #3
 02    [a05501c5] (04/43) Accurately ripped as in pressing(s) #3
 03    [8c164789] (04/46) Accurately ripped as in pressing(s) #3
 04    [1be81fa7] (04/46) Accurately ripped as in pressing(s) #3
 05    [6238fc93] (04/46) Accurately ripped as in pressing(s) #3
 06    [f91d7063] (04/46) Accurately ripped as in pressing(s) #3
 07    [15ef4d9d] (04/47) Accurately ripped as in pressing(s) #3
 08    [06594412] (04/46) Accurately ripped as in pressing(s) #3
 09    [65189aa6] (04/46) Partial match to pressing(s) #3 
Offsetted by -466:
 01    [92d47e01] (13/47) Accurately ripped as in pressing(s) #2
 02    [93748483] (10/43) Accurately ripped as in pressing(s) #2
 03    [b7f1b286] (13/46) Accurately ripped as in pressing(s) #2
 04    [8a7b05c7] (13/46) Accurately ripped as in pressing(s) #2
 05    [df73cff4] (12/46) Accurately ripped as in pressing(s) #2
 06    [8a9d29f4] (13/46) Accurately ripped as in pressing(s) #2
 07    [ddc80759] (13/47) Accurately ripped as in pressing(s) #2
 08    [2cdc01c9] (13/46) Accurately ripped as in pressing(s) #2
 09    [2ea23e9b] (13/46) Partial match to pressing(s) #2 
Offsetted by 12:
 01    [d7c6cfb9] (30/47) Accurately ripped as in pressing(s) #1
 02    [8b1cce97] (29/43) Accurately ripped as in pressing(s) #1
 03    [c750b4e4] (29/46) Accurately ripped as in pressing(s) #1
 04    [27a63087] (29/46) Accurately ripped as in pressing(s) #1
 05    [f562cb6a] (30/46) Accurately ripped as in pressing(s) #1
 06    [789ba38a] (29/46) Accurately ripped as in pressing(s) #1
 07    [3769e101] (30/47) Accurately ripped as in pressing(s) #1
 08    [76431963] (29/46) Accurately ripped as in pressing(s) #1
 09    [8ab21d49] (29/46) Partial match to pressing(s) #1 

Track    [ CRC32  ]    [W/O NULL]    
 --    [27E0ADCF]    [F13A4527]    
 01    [9D68FCFE]    [3C0C10E4]    
 02    [8DD00747]    [0E9B0356]    
 03    [3B415E14]    [128D27D9]    
 04    [57BD0A7B]    [A336CC9C]    
 05    [FDABBD6E]    [69141986]    
 06    [D1C1DCC9]    [C426D303]    
 07    [7B7507F6]    [D9236524]    
 08    [FD7F3400]    [F02B0D6F]    
 09    [FA7D9FE9]    [3277A385]


Code: [Select]
[Verification date: 26/03/2009 20:34:01]
[Disc ID: 001125a1-007bc413-850b0f09]
Track    [ CRC    ] Status
 01    [d60bb509] (00/33) No matches
 02    [146d338f] (00/31) No matches
 03    [826087d8] (00/33) No matches
 04    [9ee22907] (00/33) No matches
 05    [62172bee] (00/34) No matches
 06    [63a32cce] (00/33) No matches
 07    [ef8a3bf1] (00/34) No matches
 08    [a49ec53f] (00/33) No matches
 09    [e36e3c1d] (00/33) No matches
Offsetted by -2063:
 01    [2c7ab3ad] (04/33) Accurately ripped as in pressing(s) #3
 02    [a05501c5] (04/31) Accurately ripped as in pressing(s) #3
 03    [8c164789] (04/33) Accurately ripped as in pressing(s) #3
 04    [1be81fa7] (04/33) Accurately ripped as in pressing(s) #3
 05    [6238fc93] (04/34) Accurately ripped as in pressing(s) #3
 06    [f91d7063] (04/33) Accurately ripped as in pressing(s) #3
 07    [15ef4d9d] (04/34) Accurately ripped as in pressing(s) #3
 08    [06594412] (04/33) Accurately ripped as in pressing(s) #3
 09    [65189aa6] (04/33) Partial match to pressing(s) #3 
Offsetted by -466:
 01    [92d47e01] (08/33) Accurately ripped as in pressing(s) #1
 02    [93748483] (06/31) Accurately ripped as in pressing(s) #1
 03    [b7f1b286] (08/33) Accurately ripped as in pressing(s) #1
 04    [8a7b05c7] (08/33) Accurately ripped as in pressing(s) #1
 05    [df73cff4] (08/34) Accurately ripped as in pressing(s) #1
 06    [8a9d29f4] (08/33) Accurately ripped as in pressing(s) #1
 07    [ddc80759] (08/34) Accurately ripped as in pressing(s) #1
 08    [2cdc01c9] (08/33) Accurately ripped as in pressing(s) #1
 09    [2ea23e9b] (08/33) Partial match to pressing(s) #1 
Offsetted by 12:
 01    [d7c6cfb9] (21/33) Accurately ripped as in pressing(s) #2
 02    [8b1cce97] (21/31) Accurately ripped as in pressing(s) #2
 03    [c750b4e4] (21/33) Accurately ripped as in pressing(s) #2
 04    [27a63087] (21/33) Accurately ripped as in pressing(s) #2
 05    [f562cb6a] (22/34) Accurately ripped as in pressing(s) #2
 06    [789ba38a] (21/33) Accurately ripped as in pressing(s) #2
 07    [3769e101] (22/34) Accurately ripped as in pressing(s) #2
 08    [76431963] (21/33) Accurately ripped as in pressing(s) #2
 09    [8ab21d49] (21/33) Partial match to pressing(s) #2 

Track    [ CRC32  ]    [W/O NULL]    
 --    [27E0ADCF]    [F13A4527]    
 01    [9D68FCFE]    [3C0C10E4]    
 02    [8DD00747]    [0E9B0356]    
 03    [3B415E14]    [128D27D9]    
 04    [57BD0A7B]    [A336CC9C]    
 05    [FDABBD6E]    [69141986]    
 06    [D1C1DCC9]    [C426D303]    
 07    [7B7507F6]    [D9236524]    
 08    [FD7F3400]    [F02B0D6F]    
 09    [FA7D9FE9]    [3277A385]

AccurateRip

Reply #7 –
Checked the staging db and there are now no submissions for that one disc (post 5), it is possible that the user was purged from the system for submitting from a virtual drive.

The order is on user submitted date - in that a pressing appears the first time one person submits and others are tagged onto that, now the database was cleared and refilled from no particular order, the pressing numbers are all changed (but they never stood for anything).

AccurateRip

Reply #8 –
Ok, well a drop of 14 results on the third log, don't purge to much I need at last 2 results by disk

"they never stood for anything"
would be nicer if they didn't existed at all, I hope Gregory will stop displaying these numbers, the update clearly shows how useless it is.

AccurateRip

Reply #9 –
People submitting from Virtual Drives became a real problem...and they were a relatively high % and were difficult to deal with because they would get a new drive name each time (the virual drives would mount a random name each time).

AccurateRip

Reply #10 –
Quote from: spoon on
People submitting from Virtual Drives became a real problem...and they were a relatively high % and were difficult to deal with because they would get a new drive name each time (the virual drives would mount a random name each time).


I wouldn't publish too much detail about your purging policies. AccurateRip is already being used to prove the authenticity of lossless 'scene' releases (which are very often just transcodes of earlier lossy releases) and they shouldn't be given the info to fake it even more. These releases can spam your database with hundreds of identical results later on. Same with accepting rips of recordables into your db. I would make it mandatory to have ripping tools submit a medium's ATIP, if it exists.

PS You should see the transcoding tool chain of some of these noobs. Cuesheet and lossless files are mounted Daemon Toos, to be then ripped by EAC which pipes to LAME to produce 320 kbit/s MP3s including a 'proper' secure ripping log to be posted on other scene release sites.

AccurateRip

Reply #11 –
"very often just transcodes" personnaly I think that very often it is not "just transcodes"

I don't really understand your fear of the database being spammed by re-burned rip, first I think (I may be wrong, it's a long time I didn't burn anything, I don't even have any CD-R at home) that reburning will re-introduce an offset so all results will be different from the official throught the offset (even if CRC matches) & anyway the offset has never meant anything about audio quality. Then results from cuetools are not added, only rips from EAC & dbpoweramp, which means that the guy has 1: re-burn the rip 2: set-up accuraterip with 3 key disks ... it makes a lot of "if" & in the end it is very unlikely that a "noob" does all this & also that hundreds of people using lossless would burn hundreds of donwloaded rips, because once you stop using CD you don't go back to burning, you go all HDD because CD becomes slow/expensive/useless. For all these reasons I think your fear of the database being spammed by hundreds of re-burned downloaded rip is pure paranoia ... why would someone burn from flac & re-rip to flac the CD if he already have the lossless files at hand ? I don't say it cannot happen for someone who would have lost/deleted his lossless files, but I can't think of a logic way this would happen in a large scale.

& if your fear comes from burned CD, well if the CD is burned correctly it will match & if it is not, it will just be noise in the database. Noise is not supposed to be checked. Noise is noise, there will always be noise, accuraterip is designed to deal with this noise, so it is not a problem.

Maybe I didn't understund why you're so worried ... but the way I understand it, it seems irrationnal ... it is not fake, it is noise & noise is normal. With or without all this noise, there is no way to tell which offset is the official one (or if a lonely submitted CRC is corrupted), because there is several official offset/pressing. So stop worrying about offset, only count the CRC match. It is very unlikely that hundreds of bad CRC would slip through the database, & even if it would happen, if you are sure that your CD is official then it will match somewhere if someone ripped the same CD & it will avoid all the noise.

To be short don't count the missmatch, count the match, that's all that matters.

Yes it is possible that a damaged copy from CD ripped with accuraterip to flac by guy N°1 & posted on P2P would matched with guy N°2 who illegally downloaded the damaged rip from guy n°1, if you're guy N°3 ripping a official CD then your rip will not match the damaged rip from guy N°1. Everything is fine for you. Who cares if guy N°2 is f*cked, accuraterip wasn't made to check illegally downloaded CD & furthermore guy N°2 is an idiot for trusting a result with only confidence 1. It is almost impossible that confidence would rise higher than 1 anyway, so even for illegal rip accuraterip is very efficient, even is there is a small hole.

AccurateRip

Reply #13 –
As far as I understund it is a problem because it spams the database with several fake offset/pressings, but not with fake CRC. It is a problem for Spoon to manage the database, but it shouldn't be a problem for you. (unless I missed something ...)

AccurateRip

Reply #14 –
A high percentage of virtual drives means that exactly that is happening what you claim is highly unlikely.

Virtual drives also aren't EACs inside virtual machines. Virtual machines only emulate the bus adapter and grant full access to the physical drive's hardware. A high percentage of virtual drives inside the db means exactly that there is a disturbingly high percentage of weirdos mounting cuesheets and even submitting their 'ripping' results.

Regarding omitting ATIP media. I used to rip a lot of my friends' CDs during my university time and share mine. For private purpose this used to be legal here. A lot has been lost at different parties. Much of this stuff is out of production today and pretty rare. Getting 1 or 2 hits from AccurateRip through an offset ignorant verifier (as CueTools) would make me very happy and mean that I still own a perfect rip. An AccurateRip DB that also includes results from recordables could mean that a former dormitory neighbour submitted the same result for a rip he has once copied from me.

AccurateRip

Reply #15 –
Well the percentage being higher than expected means that obviously I was under-estimating the stupidity of people in the scene  but still why would you care about noise.

For me this is most likely not specially people who check downloaded rip, but people who checked their own rips (downloaded or not). Remember that before we had cuetool, mounting your own rip to check with accuraterip could have been a trick to check for accuracy... so the people who did that are not stupid, but are selfish, they polluted the database just to check their own rips. Now that cuetools exist this kind of evil behavior should decrease if it happened that way.

My miss-understanding with you wasn't with virtual drives as I agree that virtual drive must have been purged, but with your fear of burned CD in the database. Burned CD, offset & noise overall is not a problem, only matching CRC matters & even the evil virtual drive adds some matching CRC despite adding mutiple offsets.
 

AccurateRip

Reply #16 –
The only issue with the virtual drives is - often the offset of the virtual drive is wrong, for what ever reason (was ripped using a ripper with no offset?), now these virtual submissions could spam the database as much as they wanted to, it would not effect the real results, only though if someone wants to key a new drive off the offset of this virtual drive - that is why they are purged (and any other results from that person).

AccurateRip

Reply #17 –
I have a question but I am not sure weither it's an accuraterip problem or a cuetools problem, with the purge I have noticed that several rip of mine have decreased to zero result, but instead of showing "Disk not present in database." it shows "(00/00) No matches", it seems to means that the CRC were purged but that the empty Disk ID wasn't purged (Edit: ... well maybe the CRC weren't purged at all as it's still displayed), could you purge the empty disk ID too so that I get a "Disk not present in database." result. I mean several of these Disk ID might never return, so it might be useless to keep them. Keeping them will just make the database slower, no?

Code: [Select]
[Verification date: 22/04/2009 10:42:48]
[Disc ID: 000d42bd-004cf8b1-5609fd07]
Track    [ CRC    ] Status
 01    [532ea95c] (00/00) No matches
 02    [6044e0d0] (00/00) No matches
 03    [35bbdec2] (00/00) No matches
 04    [fdda2dca] (00/00) No matches
 05    [31b13382] (00/00) No matches
 06    [39423732] (00/00) No matches
 07    [fc205dc6] (00/00) No matches

Track    [ CRC32  ]    [W/O NULL]    
 --    [24794B96]    [6D42422A]    
 01    [42BD445C]    [807069B1]    
 02    [0FF6F98D]    [0D28BEAF]    
 03    [318D7F0F]    [B2C07140]    
 04    [5D68E866]    [9C59F6CD]    
 05    [A29D1759]    [151A2232]    
 06    [02517BA4]    [4AC2AA19]    
 07    [0C364C71]    [9BE53E27]


This log should be returned like this, no ? (Maybe I missed something ?)

Code: [Select]
[Verification date: 22/04/2009 10:42:48]
[Disc ID: 000d42bd-004cf8b1-5609fd07]
Disk not present in database.


Furthermore it seems it is slower to check because with a "Disk not present in database." cuetools instantly stop, while with a "(00/00) No matches" I think it still calculates the CRC for nothing ... (I might be wrong there, I didn't verify ... but it's likely)

AccurateRip

Reply #18 –
Cuetools would need updating, the new database can have 0 byte entries.

AccurateRip

Reply #19 –
Quote from: spoon on
The only issue with the virtual drives is - often the offset of the virtual drive is wrong, for what ever reason (was ripped using a ripper with no offset?)

...trying to match a different pressing in the database because a good set of CRCs from your original disc doesn't exist in the record.

I've been doing this for a very long time now; far longer than either ARCue, TripleFlac, or CUETools w/AR support have been around.

Rest assured, I have never once tried to submit results to the database from a virtual drive.  This was not due to fear of the consequences [1) removing one's ability to submit actually mitigates the fear that they're only checking against their own submissions, 2) making changes so that you can submit once again after a ban is quite trivial], but because such information is as was very aptly put: noise.

AccurateRip

Reply #20 –
There are about 1000 individuals who are using virtual drives and submit, there must be a guide somewhere - which needs updating and pointing to ARCue, TrippleFLAC, CUETools, etc...

AccurateRip

Reply #21 –
>there must be a guide somewhere

You're probably right.

I've made an effort not to make public announcements about how to do it and have argued strongly against submitting results from virtual drives but I would be giving myself too much credit to think that my words (or lack of words) would make a difference.

AccurateRip

Reply #23 –
I am beginning to think that AR2 is not required, tools such as CueTools show that different pressings can be handled, and they are not using the Offset calculation CRC, which can detect the offset within the track also. It is likely that AR2 will be dBpoweramp R14 (actually built into the ripper), as the implementation in the AR DLLs would require the application to be changed in any case.

AccurateRip

Reply #24 –
From my understanding yes, it's something like Accuraterip 1.5. It's a cleaning of the database N°1, before starting the work on database N°2. We're in the middle of the path. See Post 5 & 6 (specially the end of post 5)

Edit: Spoon was faster.