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: ARCue.exe - Check whole CD rips with AccurateRip (Read 22362 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ARCue.exe - Check whole CD rips with AccurateRip

I have ported ARCue.pl to C++ and it works much faster than the Perl version. You can find an executable Win32 binary - arcue.exe  - and the source code (a Visual Studio 2003 project) -  arcue.rar. And, yes, I got an approval from Mr Spoon.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #1 –
Thank you whitehobbit! That's definitely an immense speed improvement. Works great so far.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #2 –
I have completely forgot to mention that you need MFC71.dll. You can download it from here. Copy it to your C:\windows\system32\ folder and everything should work fine.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #3 –
Works great!  And much faster.

I'm 60% through all my CD's since I started this Summer and this will help great with the rest.  I've been using REACT2 and ARCue.  Thanks!

-Robert

ARCue.exe - Check whole CD rips with AccurateRip

Reply #4 –
arcue.exe  - Win32 binary
arcue.zip - source code

I have fixed a few issues in ARCUE.exe:

- fixed trackConfidence type (sometimes confidence was shown as a negative number);
- now CUE/WAV can be in a folder different from the current one; when you call arcue.exe just speicify whole path to CUE and this path will be used to open WAV too;
- ported from GRETA to PCRE regular expression library. Now you can build it with both VS 2003 and VS 2005 (but release configuration only, debug config has some build problems I was to lazy to fix).

ARCue.exe - Check whole CD rips with AccurateRip

Reply #5 –
Thank you.

Unfortunately it seems the problem with negative numbers still persists:

Code: [Select]
Pink Floyd - Dark Side of the Moon.cue:

Checking AccurateRip database

Track	Ripping Status		[Disc ID: 000f82ac-700a0f09]

 1	Accurately Ripped    (confidence -113)     [1ba21a87]
 2	Accurately Ripped    (confidence -117)     [76ffd972]
 3	Accurately Ripped    (confidence -119)     [b999e41b]
 4	Accurately Ripped    (confidence -120)     [86fed59c]
 5	Accurately Ripped    (confidence -118)     [296a9c2b]
 6	Accurately Ripped    (confidence -118)     [166151d2]
 7	Accurately Ripped    (confidence -119)     [7745d608]
 8	Accurately Ripped    (confidence -124)     [5b7408c2]
 9	Accurately Ripped    (confidence -122)     [3af089e0]

_______________________

All Tracks Accurately Ripped.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #6 –
@verbajim: I changed line 303 to this:
Code: [Select]
unsigned char* arCrcData = sz;

Before that arCrcData was still signed.

Now try it again with the latest version:

Updates
  • fixed wrong confidence error (hopefully for good)
  • arcue exits with an error level if the file is not WAVE now. Before that it attempted to calculate the CRCs regardlessly.
Bin and Src packages can be downloaded from this thread: http://www.hydrogenaudio.org/forums/index....showtopic=59423

PS: You'll need the Microsoft Visual C++ 2005 SP1 Redistributable Package for it to run. Otherwise you'll get the error message "The system cannot execute the specified program."

ARCue.exe - Check whole CD rips with AccurateRip

Reply #7 –
Thanks, that did the trick. No negative numbers this time.

Code: [Select]
Pink Floyd - Dark Side of the Moon.cue:

Checking AccurateRip database

Track   Ripping Status          [Disc ID: 000f82ac-700a0f09]

 1      Accurately Ripped    (confidence 143)     [1ba21a87]
 2      Accurately Ripped    (confidence 139)     [76ffd972]
 3      Accurately Ripped    (confidence 137)     [b999e41b]
 4      Accurately Ripped    (confidence 136)     [86fed59c]
 5      Accurately Ripped    (confidence 138)     [296a9c2b]
 6      Accurately Ripped    (confidence 138)     [166151d2]
 7      Accurately Ripped    (confidence 137)     [7745d608]
 8      Accurately Ripped    (confidence 132)     [5b7408c2]
 9      Accurately Ripped    (confidence 134)     [3af089e0]

_______________________

All Tracks Accurately Ripped.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #8 –
FYI, previous post was updated while you replied, verbajim. Added exit error code when file is not WAVE, so arcue doesn't attempt to CRC check non-WAVE files anymore...

ARCue.exe - Check whole CD rips with AccurateRip

Reply #9 –
Hello,

I am unable to run the latest version of Arcue.exe.
Do you need some external dll's? I already have MFC71.dll installed.
Hope you can help me,

greetz ben

ARCue.exe - Check whole CD rips with AccurateRip

Reply #10 –
For the latest version of arcue.exe you need MFC80.DLL.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #11 –
Thank you for your reply.
After I installed MFC80.dll Arcue did not run either.
The solution was to install microsoft Microsoft Visual C++ 2005 SP1 Redistributable.
Now it is working perfectly.
Thank you for this great proggie.

Microsoft Visual C++ 2005 SP1 Redistributable is available at:
http://www.microsoft.com/downloads/details...;DisplayLang=en

greetz Ben

ARCue.exe - Check whole CD rips with AccurateRip

Reply #12 –
Yep, my latest compile is made with Visual Studio 2005 SP1...  sorry, I forgot to mention that you need its runtime libraries.
 

ARCue.exe - Check whole CD rips with AccurateRip

Reply #13 –
whitehobbit and Fandango: Thank you so much for this program.

In a test I did now, the elapsed time was just over 58 seconds versus almost 3 minutes and 33 seconds with the Perl-based program. As well, my CPU usage is now between 4% and 20% (usually around 10%) versus hovering around 100% all the time with the Perl-based program.

And Fandango, your download post was updated on December 2nd -- my birthday. Thank you so much for such a great birthday present. 

ARCue.exe - Check whole CD rips with AccurateRip

Reply #14 –
Quote from: NightOwl on
In a test I did now, the elapsed time was just over 58 seconds versus almost 3 minutes and 33 seconds with the Perl-based program. As well, my CPU usage is now between 4% and 20% (usually around 10%) versus hovering around 100% all the time with the Perl-based program.

The bandwidth of the hard disc is probably the bottleneck here now.

ARCue.exe - Check whole CD rips with AccurateRip

Reply #15 –
with the C runtimes it smokes here, mear seconds for a verification.
2 gig of mem and fast cpu really help.
tried everything I could read about the pearl and couldn't get it to work and this happens along.
never mind xmas. Thanks

ARCue.exe - Check whole CD rips with AccurateRip

Reply #16 –
The utility has small but annoying inconvenience, I would even call it a bug.
It doesn't work with cue files formatted not strictly by standard, i.e. if some index position in a file has spaces after the timestamp (i.e. "INDEX 01 05:30:00 ") arcue.exe doesn't work properly (while foobar2000 does).
Most annoying is the fact, that if the cue file has, say, "INDEX 01 31:36:12" at the end, there MUST be a "line feed" after this string or arcue.exe will compute wrong CRCs for at least one track (counting from the end).
You can see this in work here (it's of Sigur ros - Takk...):
On the right we are processing "normal" cue file, on the left the last "character" (CRLF, 0x0D 0x0A in Windows, 0x0A in Unix) of the cue file is deleted.

This happens because of this code:
Code: [Select]
while (fgets(str, MAX_STR_SIZE, fh))
{
str[strlen(str)-1 = 0;

So the code "thinks" there is always a character after the last "INDEX 01 ..." string and replaces that character by 0. So if I feed it some
Code: [Select]
    INDEX 01 31:36:12<CRLF>
it is transformed to
Code: [Select]
    INDEX 01 31:36:12
, which is expected, and if I feed
Code: [Select]
    INDEX 01 31:36:12
it returns
Code: [Select]
    INDEX 01 31:36:1
which is unexpected - that's why wrong CRCs are computed.

Yes, I know that each and every program-created cue file has a line feed caracter at the end. In notepad you can see an empty line at the end of any cue produced by EAC, CUETools, Foobar plugin, etc. But manual editing of cue files is done quite often. Personally, I've always deleted that annoying empty lines before I found this bug in arcue.exe.

So this inconvenience is eliminated by either of the three ways:
  • Always check if there is an empty line at the end of the cue file
  • Insert this code:
    Code: [Select]
    if (str[strlen(str)-1]==0x0A) str[strlen(str)-1]=0;
    instead of
    Code: [Select]
    str[strlen(str)-1] = 0;
  • Insert this code:
    Code: [Select]
    for(char *pc = str;*pc;)
    {
        if(*++pc == 0x0A)
        {
            *pc = 0x00;
        }
    }
    instead
    Code: [Select]
    str[strlen(str)-1] = 0;
Each provided code parts work because function fgets (which is called before these code parts) transforms Windows CRLFs to Unix format.

PS1: I found the bug, but I was not the one who studied the code.
PS2: anyway since there soon will be a good foobar related utility with arcue functionality, the corrections I provided may be left unnoticed =)

ARCue.exe - Check whole CD rips with AccurateRip

Reply #17 –
oh I am sure your efforts will be of deep interest - not only for the makers of arcue.

thanks for the head ups with the endl thing
All tracks accurately ripped

End of status report