Skip to main content

Topic: ARCue C++ compiles and source (Read 36713 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
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):

[ Specified attachment is not available ](binary + source difference, old source still needed)

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



Old ARCue++, not recommended anymore:
[ Specified attachment is not available ] [ Specified attachment is not available ](you will still need this source to compile the new version)
  • Last Edit: 03 October, 2008, 09:38:08 AM by Fandango

ARCue C++ compiles and source
Reply #1
Thank you for ARCue upgrading.
I use it very often now. It helps a lot.
Listen to WMRI...

  • dmvn
  • [*]
ARCue C++ compiles and source
Reply #2
Thank You for Your software.
Thank You for Sources....

ARCue C++ compiles and source
Reply #3
Same functionality added to CUETools.
CUETools 2.1.4

ARCue C++ compiles and source
Reply #4
Upgrade for arcue:

[ Specified attachment is not available ]

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.
  • Last Edit: 02 October, 2008, 12:24:10 PM by Gregory S. Chudov
CUETools 2.1.4

  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #5
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". 
  • Last Edit: 02 October, 2008, 05:05:57 PM by Fandango

ARCue C++ compiles and source
Reply #6
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
  • Last Edit: 02 October, 2008, 11:14:02 PM by Gregory S. Chudov
CUETools 2.1.4

  • rohangc
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #7
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.

ARCue C++ compiles and source
Reply #8
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.
[ Specified attachment is not available ]
Finds offsets by default now without any command line switches, because it works magicaly fast.

Code: [Select]
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
CUETools 2.1.4

  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #9
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 **"
  • Last Edit: 03 October, 2008, 09:46:16 AM by Fandango

ARCue C++ compiles and source
Reply #10
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.
CUETools 2.1.4

  • bilbo
  • [*][*][*]
ARCue C++ compiles and source
Reply #11
Quote
Code: [Select]
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 ?
Glass half full!

  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #12
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...
  • Last Edit: 03 October, 2008, 10:27:23 AM by Fandango

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
ARCue C++ compiles and source
Reply #13
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.
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #14
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.
  • Last Edit: 03 October, 2008, 11:18:08 AM by Fandango

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
ARCue C++ compiles and source
Reply #15
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.
  • Last Edit: 03 October, 2008, 11:37:38 AM by greynol
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • Fandango
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #16
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: [Select]
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.
  • Last Edit: 03 October, 2008, 11:45:10 AM by Fandango

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
ARCue C++ compiles and source
Reply #17
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.
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • odyssey
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #18
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??
Can't wait for a HD-AAC encoder :P

ARCue C++ compiles and source
Reply #19
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
CUETools 2.1.4

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
ARCue C++ compiles and source
Reply #20
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.
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

ARCue C++ compiles and source
Reply #21
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.
  • Last Edit: 04 October, 2008, 10:10:47 AM by Gregory S. Chudov
CUETools 2.1.4

  • odyssey
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #22
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: [Select]
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
  • Last Edit: 04 October, 2008, 10:32:47 AM by odyssey
Can't wait for a HD-AAC encoder :P

  • No Fun
  • [*]
ARCue C++ compiles and source
Reply #23
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
  • [*][*][*][*][*]
ARCue C++ compiles and source
Reply #24
Try using TripleFlac! to see all the possible offsets for this album.

Same thing
Can't wait for a HD-AAC encoder :P