ARCue C++ compiles and source Options

[Fandango]

reference post: http://www.hydrogenaudio.org/forums/index....st&p=528988

May need Microsoft Visual C++ 2005 SP1 Redistributable Package.

Download the most recent ARCue C++ (2nd Plus version by Gregory S. Chudov):

 arcue.rar ( 38.14K ) Number of downloads: 2714
(binary + source difference, old source still needed)

more info: http://www.hydrogenaudio.org/forums/index....st&p=591374



Old ARCue++, not recommended anymore:
 arcue_bin.rar ( 33.22K ) Number of downloads: 2605
 arcue_src.rar ( 200.32K ) Number of downloads: 930
(you will still need this source to compile the new version)

This post has been edited by Fandango: Oct 3 2008, 14:38

[Studio 308]

Thank you for ARCue upgrading.
I use it very often now. It helps a lot.

[dmvn]

Thank You for Your software.
Thank You for Sources....

[Gregory S. Chudo...]

Same functionality added to CUETools.

[Gregory S. Chudo...]

Upgrade for arcue:

 arcueplus.rar ( 38.84K ) Number of downloads: 601


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.

This post has been edited by Gregory S. Chudov: Oct 2 2008, 17:24

[Fandango]

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".

This post has been edited by Fandango: Oct 2 2008, 22:05

[Gregory S. Chudo...]

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

This post has been edited by Gregory S. Chudov: Oct 3 2008, 04:14

[rohangc]

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.

[Gregory S. Chudo...]

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.
 arcue.rar ( 38.14K ) Number of downloads: 2714

Finds offsets by default now without any command line switches, because it works magicaly fast.

CODE

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

[Fandango]

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
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 **"

This post has been edited by Fandango: Oct 3 2008, 14:46

[Gregory S. Chudo...]

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
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.

[bilbo]

CODE

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 ?

[Fandango]

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...

This post has been edited by Fandango: Oct 3 2008, 15:27

[greynol]

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.

[Fandango]

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.

This post has been edited by Fandango: Oct 3 2008, 16:18

[greynol]

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.

This post has been edited by greynol: Oct 3 2008, 16:37

[Fandango]

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:

CODE

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.

This post has been edited by Fandango: Oct 3 2008, 16:45

[greynol]

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.

[odyssey]

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??

[Gregory S. Chudo...]

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

[greynol]

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.

[Gregory S. Chudo...]

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.

This post has been edited by Gregory S. Chudov: Oct 4 2008, 15:10

[odyssey]

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.

CODE

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

This post has been edited by odyssey: Oct 4 2008, 15:32

[No Fun]

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.

[odyssey]

Try using TripleFlac! to see all the possible offsets for this album.

Same thing