reference post: http://www.hydrogenaudio.org/forums/index....st&p=528988 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=60440&view=findpost&p=528988)
May need Microsoft Visual C++ 2005 SP1 Redistributable Package (http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en).
Download the most recent ARCue C++ (2nd Plus version by Gregory S. Chudov):
[attachment=4680:attachment](binary + source difference, old source still needed)
more info: http://www.hydrogenaudio.org/forums/index....st&p=591374 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=59423&view=findpost&p=591374)
Old ARCue++, not recommended anymore:
[attachment=4053:attachment][attachment=4054:attachment](you will still need this source to compile the new version)
Thank you for ARCue upgrading.
I use it very often now. It helps a lot.
Thank You for Your software.
Thank You for Sources....
Same functionality added to CUETools (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=66233&view=findpost&p=591203).
Upgrade for arcue:
[attachment=4677:attachment]
New feature: search for offset correction.
Usage: arcue --find-offset 700 some.cue
700 is enough for most images, but 2000 is required for some. Takes more time though.
Nice! I never could have done that myself. You also added some other improvements to the program, thanks!
BTW, the option "--find-offset" doesn't work. It should be "--auto-offset".
Nice! I never could have done that myself. You also added some other improvements to the program, thanks!
BTW, the option "--find-offset" doesn't work. It should be "--auto-offset".
Oops Yep, sorry. --auto-offset detects offset, and --read-offset checks a single offset.
Thanks to you too
Can somebody please add an article about ARCue in the KB? Currently, it is quite painful to find a post like this and not know what ARCue actually does. I still don't know! Going by the name, it sounds like a tool that can check a CUESheet-image album for a match in the AccurateRip database without having to re-rip the album. If this is indeed true, this is a very useful tool indeed.
I would have done this myself, but I don't know anything about it. Hence, this request. Thanks.
Can somebody please add an article about ARCue in the KB? Currently, it is quite painful to find a post like this and not know what ARCue actually does. I still don't know! Going by the name, it sounds like a tool that can check a CUESheet-image album for a match in the AccurateRip database without having to re-rip the album. If this is indeed true, this is a very useful tool indeed.
This is exactly what it does.
Another update.
[attachment=4680:attachment]
Finds offsets by default now without any command line switches, because it works magicaly fast.
C:\arcue.exe "Mr Brown - Mellan Tre Ogon.cue"
Mr Brown - Mellan Tre Ogon.cue:
Checking AccurateRip database
Track Ripping Status [Disc ID: 000e63ce-5a095e08]
1 ** Rip offset: 492 ** (confidence 1) [61338968]
2 ** Rip not accurate ** (confidence 1) [44a3677d] [40e002d6]
3 ** Rip offset: 492 ** (confidence 1) [919111b4]
4 ** Rip offset: 492 ** (confidence 1) [33a53295]
5 ** Rip offset: 492 ** (confidence 1) [958dd520]
6 ** Rip offset: 492 ** (confidence 1) [11f1baa2]
7 ** Rip offset: 492 ** (confidence 1) [8eaacae7]
8 ** Rip offset: 492 ** (confidence 1) [8e0d8dda]
_______________________
Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 1 ****
Track(s) Not in Database: 0
Finds offsets by default now without any command line switches, because it works magicaly fast.
Cool! It does find the correct offset much faster now indeed, nice job. I've added your current version to the first post, but also left the older versions especially because of rest of the source code is still needed to compile your improved version. I hope people will get it and won't download the old version anymore for checking their non-offset-corrected rips.
Now, I got two questions for you:
1. What compiler did you use? I mean is it still necessary to install any C++ runtime redistributables on a vanilla XP SP3 for your binary?
2. There's a bug in the old ARCue++ which I didn't care to fix, since I had and have no IDE installed back then and at the moment: http://www.hydrogenaudio.org/forums/index....st&p=579695 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=60440&view=findpost&p=579695)
My old version gives me a "read failed.", but yours crashes, if there's whitespace at the end of a INDEX 01 line... I know it would normally never occur unless someone deliberately adds a space before the end of these lines, I know no program that handles CUE sheets that does that on its own, but still it's a nasty bug.
PS: The log output looks great, too: "** Rip offset: 492 **"
1. What compiler did you use? I mean is it still necessary to install any C++ runtime redistributables on a vanilla XP SP3 for your binary?
2. There's a bug in the old ARCue++ which I didn't care to fix, since I had and have no IDE installed back then and at the moment: http://www.hydrogenaudio.org/forums/index....st&p=579695 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=60440&view=findpost&p=579695)
My old version gives me a "read failed.", but yours crashes, if there's whitespace at the end of a INDEX 01 line... I know it would normally never occur unless someone deliberately adds a space before the end of these lines, I know no program that handles CUE sheets that does that on its own, but still it's a nasty bug.
1. Same compiler, same runtime i guess.
2. Probably will look into it when i have time.
C:\arcue.exe "Mr Brown - Mellan Tre Ogon.cue"
Mr Brown - Mellan Tre Ogon.cue:
Checking AccurateRip database
Track Ripping Status [Disc ID: 000e63ce-5a095e08]
1 ** Rip offset: 492 ** (confidence 1) [61338968]
2 ** Rip not accurate ** (confidence 1) [44a3677d] [40e002d6]
3 ** Rip offset: 492 ** (confidence 1) [919111b4]
4 ** Rip offset: 492 ** (confidence 1) [33a53295]
5 ** Rip offset: 492 ** (confidence 1) [958dd520]
6 ** Rip offset: 492 ** (confidence 1) [11f1baa2]
7 ** Rip offset: 492 ** (confidence 1) [8eaacae7]
8 ** Rip offset: 492 ** (confidence 1) [8e0d8dda]
_______________________
Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 1 ****
Track(s) Not in Database: 0
Why does Track(s) Accurately Ripped: equal 0 ?
nitpicking: Because if the offset wasn't corrected during extraction, it's not ripped accurately...
@Gregory: Thanks. Btw, XPEHOPE3 already provided two alternative patches in his post...
Because if the offset wasn't corrected during extraction, it's not ripped accurately...
NONSENSE!!!
It could just as easily be a pressing that isn't in the database.
It was a joke. And if it were a different pressing and this different pressing is not in the database... then what? AR version 1 does not support different pressings officially.
PS: accurate != error free "accurate" means in the sense of the current implentation of AR, that the ripped track's CRC will give a match, and if does not due to a offset skew, well it's not accurate according to AR. Of course it's nonsense, but that's why I said I'd be nitpicking. Meaning I'd endorse a fix for the somewhat misleading message.
It can be checked with a different offset to verify. I've been doing this for a couple of years now; well before these tools have been out. I had to do this with a title I ripped just yesterday. It's a disc by Judas Priest that I've owned for at least 8 years.
EDIT: When you said "nitpicking" I couldn't tell if you were talking about the message in the log or the comment by bilbo; you weren't exactly clear. Furthermore, your statement didn't leave room for the possibility that the disc was ripped with the proper offset, you know, the one for the drive??? There are plenty of people reading the board who know next to nothing about the nature of pressings and I think people like yourself who do understand ought to be careful in not presenting misleading information or relying on numskulls like me to make proper sense of your winking smiley.
I'm glad to see your endorsement of a better worded message. Your assistance in EAC's messaging after V0.99pb1 was invaluable.
But that's cheating...
Anyway, aren't there different pressings out there that have a different offset
but also one or more differing tracks? In that case a feature like the one newly added to ARCue could lead people to believe they have a different pressing but also that their rip was not accurate for those tracks, but in fact the difference is not caused by an extraction error but due to different CD mastering of the pressings or a manufacturing defect.
PS: I just discovered another feature of ARCue "Plus" somewhat related to different pressings:
PJ Harvey - 2007 - White Chalk (UK Issue).cue:
Checking AccurateRip database
Track Ripping Status [Disc ID: 000daddc-8c07f50b]
1 ** Rip offset: 12 ** (confidence 33) [44ddbfe3]
1 Accurately Ripped (confidence 10) [87304a8f]
2 ** Rip offset: 12 ** (confidence 33) [9f5c966e]
2 Accurately Ripped (confidence 11) [29d440ca]
3 ** Rip offset: 12 ** (confidence 33) [70e1a31a]
3 Accurately Ripped (confidence 10) [3a67d5c6]
4 ** Rip offset: 12 ** (confidence 33) [effac918]
4 Accurately Ripped (confidence 11) [2e532c80]
5 ** Rip offset: 12 ** (confidence 33) [afd7ce6b]
5 Accurately Ripped (confidence 11) [9863b65b]
6 ** Rip offset: 12 ** (confidence 33) [7f11946d]
6 Accurately Ripped (confidence 11) [c56f3f05]
7 ** Rip offset: 12 ** (confidence 33) [abec05f5]
7 Accurately Ripped (confidence 11) [50372b4d]
8 ** Rip offset: 12 ** (confidence 33) [b008bf56]
8 Accurately Ripped (confidence 11) [e2c2a632]
9 ** Rip offset: 12 ** (confidence 32) [727fd8b3]
9 Accurately Ripped (confidence 11) [3f670eb7]
10 ** Rip offset: 12 ** (confidence 32) [80fe4fc8]
10 Accurately Ripped (confidence 11) [9f7bfa78]
11 ** Rip offset: 12 ** (confidence 32) [1d89a664]
11 Accurately Ripped (confidence 11) [17194990]
_______________________
All Tracks Accurately Ripped.
Anyway, aren't there different pressings out there that have a different offset but also one or more differing tracks?
Certainly.
This goes back to the underlying premise: AR cannot be implicitly trusted to tell you a track is bad.
Sure it can be trusted in some cases with reasonable certainty, especially when the drive and ripping program shows signs that there may be wrong, but this isn't always the case. I could go into the rare situation where it can identify a bad track is good, but that's another discussion which has already been had.
I wonder... I made a rip of a CD, the logfile says "Accurately ripped (confidence 4)". I rip to seperate tracks. Then I want to verify that my rip is accurate, so I use foobar2000 to convert to album images with cuesheet and verify it with ARcue plus. Then I get "** Rip offset: 54 ** (confidence 6)"
Why doesn't it find it accurate identical to the rip??
I wonder... I made a rip of a CD, the logfile says "Accurately ripped (confidence 4)". I rip to seperate tracks. Then I want to verify that my rip is accurate, so I use foobar2000 to convert to album images with cuesheet and verify it with ARcue plus. Then I get "** Rip offset: 54 ** (confidence 6)"
Why doesn't it find it accurate identical to the rip??
What does arcue have to say about the original rip, if you are able to rerip it?
I wouldn't use foobar to convert to album images, because it destroys the gaps between tracks, often making it a different disk as far as AccurateRip is concerned, not only a different pressing. You can now use CUETools for this instead
I wouldn't use foobar to convert to album images, because it destroys the gaps between tracks
Where on earth did you come up with this bogus information?
Yes, fb2k ignores the pregap before the first track, but it certainly doesn't do anything with the gaps between tracks as far as the audio data is concerned. Sure it drops any and all non-01 indices but they have no bearing on the AR disc ID or its checksums, except (again) for the gap before the first track, since it will offset the start addresses of all the tracks if it is greater than 150 frames.
I wouldn't use foobar to convert to album images, because it destroys the gaps between tracks
Where on earth did you come up with this bogus information?
Yes, fb2k ignores the pregap before the first track, but it certainly doesn't do anything with the gaps between tracks as far as the audio data is concerned. Sure it drops any and all non-01 indices but they have no bearing on the AR disc ID or its checksums, except (again) for the gap before the first track, since it will offset the start addresses of all the tracks if it is greater than 150 frames.
Yep, that's what i meant This leads to a different AR disc id. You can only restore the disc structure if you have an original cuesheet in your posession.
The result is exactly the same if I use img-mode from EAC... In the cuesheet I don't see that it has any pregap.
REM GENRE Pop
REM DATE 2004
REM DISCID AE10010C
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Saybia"
TITLE "These Are The Days"
FILE "Saybia - These Are The Days.wav" WAVE
TRACK 01 AUDIO
TITLE "Brilliant Sky"
PERFORMER "Saybia"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Bend The Rules"
PERFORMER "Saybia"
INDEX 00 03:45:24
INDEX 01 03:46:30
TRACK 03 AUDIO
TITLE "I Surrender"
PERFORMER "Saybia"
INDEX 00 06:55:47
INDEX 01 07:13:10
TRACK 04 AUDIO
TITLE "Guardian Angel"
PERFORMER "Saybia"
INDEX 01 10:52:10
TRACK 05 AUDIO
TITLE "We Almost Made It"
PERFORMER "Saybia"
INDEX 00 15:02:45
INDEX 01 15:04:67
TRACK 06 AUDIO
TITLE "Soul United"
PERFORMER "Saybia"
INDEX 01 18:57:62
TRACK 07 AUDIO
TITLE "Flags"
PERFORMER "Saybia"
INDEX 01 23:30:05
TRACK 08 AUDIO
TITLE "The Haunted House On The Hill"
PERFORMER "Saybia"
INDEX 00 27:34:69
INDEX 01 27:35:17
TRACK 09 AUDIO
TITLE "Stranded"
PERFORMER "Saybia"
INDEX 01 32:26:65
TRACK 10 AUDIO
TITLE "It's Ok Love"
PERFORMER "Saybia"
INDEX 00 37:52:05
INDEX 01 37:52:57
TRACK 11 AUDIO
TITLE "Hidden track"
PERFORMER "Saybia"
INDEX 00 42:34:53
INDEX 01 42:37:60
I wonder... I made a rip of a CD, the logfile says "Accurately ripped (confidence 4)". I rip to seperate tracks. Then I want to verify that my rip is accurate, so I use foobar2000 to convert to album images with cuesheet and verify it with ARcue plus. Then I get "** Rip offset: 54 ** (confidence 6)"
Why doesn't it find it accurate identical to the rip??
Maybe that's because ARcue returns only result with the highest number of confidences?
Try using TripleFlac! to see all the possible offsets for this album.
Try using TripleFlac! to see all the possible offsets for this album.
Same thing
Try using TripleFlac! to see all the possible offsets for this album.
Same thing
Do you mean that TripleFlac shows only one found offset which equals "54"?
Then it's really interesting...
odyssey, I am not sure if your question is answered or not, but when you get something like
Tr1 ** Rip offset: z ** (confidence y)
Tr1 Accurately Ripped (confidence x)
it means that your rip is accurate with X confidence, and there is another set for this CD in the database with an offset difference of Z and a confidence of y.
so for you it means all is fine, ripping finished.
on the other hand, if you have a bad rip and not the log file anymore, just the cue, you can get replies like this one
1 ** Rip offset: 2646 ** (confidence 30)
1 ** Rip offset: 1454 ** (confidence 23)
1 ** Rip offset: 950 ** (confidence 43)
1 ** Rip offset: 681 ** (confidence 48)
so its up to you to pick a pressing set for offset shifting. what you need to do here is looking for the highest confidence with the IDENTICAL offset value for ALL tracks.
(the codebox above shows the output for only one track)
In the cuesheet I don't see that it has any pregap.
I see lot's of different pregaps lengths in that cue sheet.
Well, let me do a recapitulation here:
I made a rip of a CD, the logfile says "Accurately ripped (confidence 4)". I rip to seperate tracks.
Can you show us the log? Did you create a non-compliant cue sheet, too?
Then I want to verify that my rip is accurate, so I use foobar2000 to convert to album images with cuesheet and verify it with ARcue plus.
Please use the original CUETools (http://www.hydrogenaudio.org/forums/index.php?showtopic=50113) or the new CUETools (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233) instead of fb2k, but make sure you leave the "AccurateRip" setting at "Don't verify" for the new version. Load the
non-compliant cue sheet to create a "Single File" (CUETools 1.9.1) or "Single File + CUE" (CUETools 1.9.2) respectively.
Then copy the non-compliant cue sheet to a new file and from that remove all lines that begin with "INDEX 00".
Now, use arcueplus on both CUE sheets to see if the result is different. It should be the same for both cue sheets. Compare the arcueplus output of those two single file rips created by CUETools, with the arcueplus output of the single file created with foobar2000.
@Gregory: maybe it's generally a good idea to add a command line switch "--verbose" to ARCue that will give the user some more information. For example the AccurateRip ID, and the track CRCs + confidence of the other entries if there are any, and maybe some other stuff that might help identify problems.
Problem found: The CD has a data track. If i'm not terribly mistaken, this track is included when AR calculates the CD checksum - Sucky!!!
Fandango: First of all, I have no idea who the hell invented "Leave out gaps" rip mode, but I wouldn't touch such a thing EVER! Secondly, the gap I were reffering to is the pregap before track01 - This is likely to cause problems, because it's not prepended when you rip seperate tracks in EAC (and it shouldn't!). Third - There's NO pregap before track 01, which is actually somewhat odd - I believe most CD's have a small pregap.
Maybe there is a non-audio (data) track on this CD? If there is, EAC knows it and computes DiscID with this in mind. But then when you use arcue, it doesn't know of the extra track and computes a different DiscID, so you compare your rip with the other pressing, which doesn't have a data track.
I wish this could be solved, but I can't imagine how...
I wish this could be solved, but I can't imagine how...
Maybe we could calculate datatrack's length from TOC stored in log by EAC and feed it to ARCue as a command line switch to generate dummy track?
I wish this could be solved, but I can't imagine how...
Maybe we could calculate datatrack's length from TOC stored in log by EAC and feed it to ARCue as a command line switch to generate dummy track?
If I had the log in each album dir, I could simply write a script to get these AR values - no need to check files that are already logged?
And I think I have most log files, but they are all just smashed into a messy folder. Would be quite trivial to find the correct log for each album.
CUETools can now work with rips from enhanced CDs (with data track). Moitah made it so it can take the length of the data track from a comment in cue sheet, and i added a code to calculate the length from EAC log file. Would be great if somebody ported it to arcue, i don't have time to do everything twice
I downloaded the most recent ARCue and it doesn't work
Runtime package is installed.
I just see "Not found in AR database" then comes Send error report screen.
OS: WinXP Pro (german)
I have a CD image with a cue, so I check it against AR with the arcue.exe from the arcue.rar (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=4680) archive and the arcue.exe from the arcueplus.rar (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=4677) archive.
The first says all tracks are accurately ripped:
...
15 Accurately Ripped (confidence 1) [d4182119]
16 Accurately Ripped (confidence 1) [c6bfff13]
The second says all but one are accurate:
...
15 Accurately Ripped (confidence 1) [d4182119]
16 ** Rip not accurate ** (confidence 1) [c6bfff13] [80bc57f4]
Which one should I trust?
Thank you.
P.S. EAC says all are accurate.
The first one. ARCue++ is buggy.
This project is dead, I guess. Use CUE Tools v2 instead.
The first one. ARCue++ is buggy.
This project is dead, I guess. Use CUE Tools v2 instead.
Thanks.
In case you really need a command line AR checker, you can use ArCueDotNet.exe, it is included in the CUE Tools v2 release.
http://www.hydrogenaudio.org/forums/index....showtopic=66233 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66233)
It needs .NET 2.0(?) installed.