Help - Search - Members - Calendar
Full Version: ARCue.pl - Check whole CD rips with AccurateRip
Hydrogenaudio Forums > CD-R and Audio Hardware > CD Hardware/Software
Pages: 1, 2, 3
Christopher Key
Hello All,

I've throw together a pure perl script that calculates the track checksums for a cue/wav file pair and then checks them against the AccurateRip database. It's available from:

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue.pl

Simply save it somewhere sensible, and from a command prompt, run:

ARCue.pl file1.cue file2.cue ...


A few points to bear in mind:

1) This is written in pure perl, so is quite slow, maybe 30s per track. If any perl gurus have any tips of speeding it up, they'd be much appreciated.

2) The range of cue files supported is probably very limited. It works with those generated by EAC. If it doesn't work with yours, please let me know.

3) The script relies on 32bit integer arithmetic, so I'm not sure how it'll behave on 64bit systems, any feedback will be gratefully recieved.

4) For reasons I can't fathom, approx 1 in 30 tracks checksums are incorrectly calculated. If a track is reported as inaccurately ripped, try running again before reripping. If anyone can shed any light on what might be going on, I'd be very grateful. So far, I can discern no noticable pattern as to when it happens.


Finally, as noted in the script, please read,

http://www.accuraterip.com/3rdparty-access.htm

before use.


Chris Key
gib
I have not tried it, but it sounds very cool. I suspect a lot of folks can use this tool, especially those that rip to an image+cue, which accuraterip does not support.
bhoar
I agree, very cool. Something I am likely to take a look at using in the future.

-brendan
ssjkakaroto
Sounds very good Christopher. Now AccurateRip can be used with single-wav albums smile.gif
brainsoft
This is exactly what I've been looking for, and at 30sec/track it won't be too much slower than the alternative I was attempting with ripping as tracks and re-combining to lossless image after. Hopefully I can get this rigged up in React for track verification with image ripping!
brainsoft
Do you know if there are any particular settings to use or avoid to create a wav/cue image that can be verified with this script? I'm trying to rip single track wave and cue sheet but I'm not having much luck verifying the image afterwords. The tracks verify with AR when ripping as tracks, but switching to images with the same settings is not yielding the same results. GAP reading related perhaps?

QUOTE(Christopher Key @ Mar 21 2007, 04:39) *

Hello All,

I've throw together a pure perl script that calculates the track checksums for a cue/wav file pair and then checks them against the AccurateRip database. It's available from:

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue.pl

Simply save it somewhere sensible, and from a command prompt, run:

ARCue.pl file1.cue file2.cue ...


A few points to bear in mind:

1) This is written in pure perl, so is quite slow, maybe 30s per track. If any perl gurus have any tips of speeding it up, they'd be much appreciated.

2) The range of cue files supported is probably very limited. It works with those generated by EAC. If it doesn't work with yours, please let me know.

3) The script relies on 32bit integer arithmetic, so I'm not sure how it'll behave on 64bit systems, any feedback will be gratefully recieved.

4) For reasons I can't fathom, approx 1 in 30 tracks checksums are incorrectly calculated. If a track is reported as inaccurately ripped, try running again before reripping. If anyone can shed any light on what might be going on, I'd be very grateful. So far, I can discern no noticable pattern as to when it happens.


Finally, as noted in the script, please read,

http://www.accuraterip.com/3rdparty-access.htm

before use.


Chris Key

gib
I finally got around to installing Perl and gave this script a try. It worked! It did seem perhaps a bit slow, but it steadily chugged along and verified that all the tracks were ripped successfully, displaying both the checksum and confidence level. At this point I've only tried one CD, but with AccurateRip previously being useless to me since I rip to image+cue, this script looks great. Many thanks, Christopher.
wraithdu
For the programming uninitiated, how do you go about installing Perl to use this script?

Oh, and if someone has a good way to integrate this into the REACT2 config for FLAC images, that would be great too.
gib
QUOTE(wraithdu @ Mar 26 2007, 17:28) *

For the programming uninitiated, how do you go about installing Perl to use this script?

Download and install ActivePerl and you're ready to go.
caligae
First of all big thanks. I've started using AccurateRip only recently (and already have ripped lots of CDs). I wanted to write something like this myself but didn't want to go through the hassle and apply for 3rd party access.

I'm on *nix. To parse the file correctly, I need to convert the .cue files to UNIX format and use '/' as path seperator. (No big problem)

edit: Hmm, seems like it only works with a single wave file, not with multiple wavs.

edit 2: I finally got it to work. There were strange errors that didn't happen using ActivePerl. As far as I can tell the default data types seem to be different and so I got integer overflows here (perl v5.8.8 on FreeBSD).

Disclaimer: I've never done anything in perl, so this is probably not the right fix, but at least it works for me and should give a hint what's wrong.

CODE

--- ARCue.pl.orig       Tue Mar 27 17:18:37 2007
+++ ARCue.pl    Tue Mar 27 17:12:24 2007
@@ -140,7 +140,7 @@
                        my $chunkTrackCount = unpack("c",substr($arCrcData,$ptr,1));
                        my $chunkDiscId1 = unpack("l",substr($arCrcData,$ptr+1,4));
                        my $chunkDiscId2 = unpack("l",substr($arCrcData,$ptr+5,4));
-                       my $chunkCddbDiscId = unpack("l",substr($arCrcData,$ptr+9,4));
+                       my $chunkCddbDiscId = unpack("I",substr($arCrcData,$ptr+9,4));
                        $ptr +=13;

                        if ( $chunkTrackCount != $trackCount
@@ -154,7 +154,7 @@
                        # How if it flagged that a track is not in the database?
                        for (my $track = 0; $track < $trackCount; $track++) {
                                my $trackConfidence = unpack("c",substr($arCrcData,$ptr,1));
-                               my $trackCrc = unpack("l",substr($arCrcData,$ptr+1,4));
+                               my $trackCrc = unpack("I",substr($arCrcData,$ptr+1,4));
                                $ptr += 9;

                                if ($arCrcCount == 0){
Christopher Key
QUOTE(brainsoft @ Mar 27 2007, 01:57) *

Do you know if there are any particular settings to use or avoid to create a wav/cue image that can be verified with this script? I'm trying to rip single track wave and cue sheet but I'm not having much luck verifying the image afterwords. The tracks verify with AR when ripping as tracks, but switching to images with the same settings is not yielding the same results. GAP reading related perhaps?



The disc id is generated based upon the length of every track in the album, so this info is required in the cue sheet in order for ARCue to function. I'm not familiar with how single track cue sheets / wav files work. If the info is there, then there's no reason why it can't work. The code was however written with whole album wav files in mind, so will need some updating. Could you send me a copy of the cue sheet you're trying to check, along with a description of exactly what the wav file contains, and I'll see what I can do.

Regards,

Chris
greynol
Besides the lengths of all the tracks, the start point of the first track is also necessary.
caligae
I was able to verify a multiple files rip. First converting the cuesheet using cuetools, then using foobar2000's "convert to single file" functionality.

This failed with other albums. Haven't checked yet, what's the problem. The calculated Disc ID is wrong for some reason.
greynol
Check my previous post.

A data track will influence the Disc ID as well.
caligae
QUOTE(Christopher Key @ Mar 21 2007, 10:39) *

1) This is written in pure perl, so is quite slow, maybe 30s per track. If any perl gurus have any tips of speeding it up, they'd be much appreciated.

Using the String-CRC32 module might speed it up (As stated above, I never used perl.)

QUOTE(greynol @ Mar 27 2007, 20:25) *

Check my previous post.

A data track will influence the Disc ID as well.

I tested some more discs and most of them worked. The one with the data track failed - this one also fails if I use "copy image". While the calculated CRCs seem to match, the Disc ID is wrong.
Christopher Key
QUOTE(caligae @ Mar 27 2007, 11:12) *

edit: Hmm, seems like it only works with a single wave file, not with multiple wavs.


Yes, currently only designed to work with single wav files. I'll update it to work with multiple wav file cue sheets.

QUOTE(caligae @ Mar 27 2007, 11:12) *

edit 2: I finally got it to work. There were strange errors that didn't happen using ActivePerl. As far as I can tell the default data types seem to be different and so I got integer overflows here (perl v5.8.8 on FreeBSD).


The pack documenation is available from
http://perldoc.perl.org/functions/pack.html

I used 'l' as that's exactly 32bits. Did you try it with 'L', I suspect that the problem may be because you're using a 64bit processor, and differences in the way unsigned integers are used.

Now, having looked more closely at the documenation, I've updated the code to use 'V' so that it's no longer architecture dependent, although the result is less than pretty. I've also improved the efficiency a bit. The new script is available from:

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue-new.pl

Could you give this a go and see how it behaves. Once I've got a few reports that this works, I'll replace the older version.

QUOTE(caligae @ Mar 27 2007, 11:12) *

Disclaimer: I've never done anything in perl, so this is probably not the right fix, but at least it works for me and should give a hint what's wrong.

I've been using perl on and off for some time, but still feel something of a novice. I think it's that sort of language!

Regards,

Chris


QUOTE(greynol @ Mar 27 2007, 18:25) *

Check my previous post.

A data track will influence the Disc ID as well.


If anyone has an album with a data track, I'd be grateful if they could send me the cue sheet, along with the correct discids so I can add support.

[quote name='caligae' date='Mar 27 2007, 19:44' post='481388']
Using the String-CRC32 module might speed it up (As stated above, I never used perl.)
[/quote]
The algorithm isn't a CRC unfortunately.

I tested some more discs and most of them worked. The one with the data track failed - this one also fails if I use "copy image". While the calculated CRCs seem to match, the Disc ID is wrong.
[/quote]

Could you send me the cue sheet, along with the correct disc ids, and I'll have a go at adding support.

Regards,

Chris
brainsoft
QUOTE(Christopher Key @ Mar 27 2007, 13:39) *

QUOTE(brainsoft @ Mar 27 2007, 01:57) *

Do you know if there are any particular settings to use or avoid to create a wav/cue image that can be verified with this script? I'm trying to rip single track wave and cue sheet but I'm not having much luck verifying the image afterwords. The tracks verify with AR when ripping as tracks, but switching to images with the same settings is not yielding the same results. GAP reading related perhaps?



The disc id is generated based upon the length of every track in the album, so this info is required in the cue sheet in order for ARCue to function. I'm not familiar with how single track cue sheets / wav files work. If the info is there, then there's no reason why it can't work. The code was however written with whole album wav files in mind, so will need some updating. Could you send me a copy of the cue sheet you're trying to check, along with a description of exactly what the wav file contains, and I'll see what I can do.

Regards,

Chris


I think it may be gap related but I've tried every setting in as many combinations as I can think of all with the same effect. The track CRCs don't match what is reported by EAC when I do TEST AND COPY (verified by AR). Maybe I've just got something screwed up here. Hell, if you "Rip image and create cuesheet" the cue sheet is different from the "create cuesheet > single file" cue. The DiscID is being generated correctly, I recognize the results confidence pattern for this album really well now.

I tested this with a few other albums without much luck, but this is the album I've been using for most of my testing. I'm currently doing fresh application installs to make sure I've not forgotten some setting I changed in the process. I'm going rip in Fb2k as well and see if I atleast get consistant results. And if the new file can check multi-wave files I'll verify that those are coming out right as well. I'll get back with cues when i know a bit more.

caligae
QUOTE(Christopher Key @ Mar 27 2007, 22:22) *

The pack documenation is available from
http://perldoc.perl.org/functions/pack.html

I used 'l' as that's exactly 32bits. Did you try it with 'L', I suspect that the problem may be because you're using a 64bit processor, and differences in the way unsigned integers are used.

Now, having looked more closely at the documenation, I've updated the code to use 'V' so that it's no longer architecture dependent, although the result is less than pretty. I've also improved the efficiency a bit. The new script is available from:

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue-new.pl

Could you give this a go and see how it behaves. Once I've got a few reports that this works, I'll replace the older version.

Thanks, this seems to work (and also is noticeably faster). BTW, I'm using a 32bit processor, but perl was built with -Duse64bitint.

QUOTE(Christopher Key @ Mar 27 2007, 22:22) *

QUOTE(caligae @ Mar 27 2007, 19:44) *

I tested some more discs and most of them worked. The one with the data track failed - this one also fails if I use "copy image". While the calculated CRCs seem to match, the Disc ID is wrong.

Could you send me the cue sheet, along with the correct disc ids, and I'll have a go at adding support.

Regards,

Chris

Here's the cue sheet:
CODE
REM GENRE Rock
REM DATE 1970
REM DISCID 7A0AD30A
REM COMMENT "ExactAudioCopy v0.95b4"
CATALOG 0724352190102
PERFORMER "David Bowie"
TITLE "The Man Who Sold The World"
FILE "Range.wav" WAVE
TRACK 01 AUDIO
TITLE "The Width Of A Circle"
PERFORMER "David Bowie"
ISRC USJT19900014
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "All The Madmen"
PERFORMER "David Bowie"
ISRC USJT19900015
INDEX 00 08:06:22
INDEX 01 08:08:57
TRACK 03 AUDIO
TITLE "Black Country Rock"
PERFORMER "David Bowie"
ISRC USJT19900016
INDEX 00 13:47:52
INDEX 01 13:49:45
TRACK 04 AUDIO
TITLE "After All"
PERFORMER "David Bowie"
ISRC USJT19900017
INDEX 00 17:24:25
INDEX 01 17:25:50
TRACK 05 AUDIO
TITLE "Running Gun Blues"
PERFORMER "David Bowie"
ISRC USJT19900018
INDEX 00 21:19:00
INDEX 01 21:21:10
TRACK 06 AUDIO
TITLE "Saviour Machine"
PERFORMER "David Bowie"
ISRC USJT19900019
INDEX 00 24:34:05
INDEX 01 24:36:20
TRACK 07 AUDIO
TITLE "She Shook Me Cold"
PERFORMER "David Bowie"
ISRC USJT19900020
INDEX 00 29:02:37
INDEX 01 29:05:00
TRACK 08 AUDIO
TITLE "The Man Who Sold The World"
PERFORMER "David Bowie"
ISRC USJT19900021
INDEX 00 33:18:65
INDEX 01 33:21:45
TRACK 09 AUDIO
TITLE "The Supermen"
PERFORMER "David Bowie"
ISRC USJT19900022
INDEX 00 37:19:27
INDEX 01 37:21:40

It obviously can't work since the data track isn't included in the cue sheet. (There is an entry for the data track in the multiple wavs/non-compliant cue sheet, but I think its length is not included)

I don't know if there's a good solution for this one, maybe letting the user enter the data track manually?

EAC reports: [Disc ID: 000fe2a0-7a0ad30a]

I think this EAC screenshot should contain enough information to calculate the correct Disc ID.
IPB Image

Moderation: Codebox.
Christopher Key
QUOTE(caligae @ Mar 28 2007, 07:27) *



QUOTE(Christopher Key @ Mar 27 2007, 22:22) *


Could you send me the cue sheet, along with the correct disc ids, and I'll have a go at adding support.



Here's the cue sheet:
CODE

REM GENRE Rock
REM DATE 1970
REM DISCID 7A0AD30A
REM COMMENT "ExactAudioCopy v0.95b4"
CATALOG 0724352190102
PERFORMER "David Bowie"
TITLE "The Man Who Sold The World"
FILE "Range.wav" WAVE
  TRACK 01 AUDIO
    TITLE "The Width Of A Circle"
    PERFORMER "David Bowie"
    ISRC USJT19900014
    INDEX 01 00:00:00

...

  TRACK 09 AUDIO
    TITLE "The Supermen"
    PERFORMER "David Bowie"
    ISRC USJT19900022
    INDEX 00 37:19:27
    INDEX 01 37:21:40


It obviously can't work since the data track isn't included in the cue sheet. (There is an entry for the data track in the multiple wavs/non-compliant cue sheet, but I think its length is not included)

I don't know if there's a good solution for this one, maybe letting the user enter the data track manually?

EAC reports: [Disc ID: 000fe2a0-7a0ad30a]


Yes, that sounds like the best solution, prompting for a data length for any data tracks. I'm moving over the weekend, but next week I'll have a go at tidying things up to support non compliant cue sheets and so on.

Regards,

Chris
caligae
QUOTE(Christopher Key @ Mar 30 2007, 09:40) *

QUOTE(caligae @ Mar 28 2007, 07:27) *

It obviously can't work since the data track isn't included in the cue sheet. (There is an entry for the data track in the multiple wavs/non-compliant cue sheet, but I think its length is not included)

I don't know if there's a good solution for this one, maybe letting the user enter the data track manually?

EAC reports: [Disc ID: 000fe2a0-7a0ad30a]


Yes, that sounds like the best solution, prompting for a data length for any data tracks. I'm moving over the weekend, but next week I'll have a go at tidying things up to support non compliant cue sheets and so on.


Have fun while moving. I'll probably do some more testing in the meantime.

Once the program works stable, we really should look into optimization. I fear this can't be done in pure perl very well. I don't know what options you have in perl. At least I know you can use C code in a module - but that will complicate distribution.

I've quickly hacked the checksumming in C. The perl script needed about 100 seconds for verifying an image I used for testing. The C version was limited by disk speed. With data already in cache, it took about 1.3 seconds.
madxcream
Great program. I found a cd that doesn't have a data track, and the disc ID is reported wrong by arcue. Here is the cuesheet:
CODE
REM GENRE "Christian Rock"
REM DATE 2006
REM DISCID 29107115
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Further Seems Forever"
TITLE "Hope This Finds You Well"
FILE "Further Seems Forever - [2006] Hope This Finds You Well.flac" WAVE
TRACK 01 AUDIO
TITLE "The Moon Is Down"
PERFORMER "Further Seems Forever"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Pride War"
PERFORMER "Further Seems Forever"
INDEX 00 03:12:57
INDEX 01 03:13:57
TRACK 03 AUDIO
TITLE "Hide Nothing"
PERFORMER "Further Seems Forever"
INDEX 00 06:20:40
INDEX 01 06:21:40
TRACK 04 AUDIO
TITLE "Snowbirds And Townies"
PERFORMER "Further Seems Forever"
INDEX 00 09:18:19
INDEX 01 09:19:19
TRACK 05 AUDIO
TITLE "Light Up Ahead"
PERFORMER "Further Seems Forever"
INDEX 00 13:46:24
INDEX 01 13:47:24
TRACK 06 AUDIO
TITLE "Against My Better Judgement"
PERFORMER "Further Seems Forever"
INDEX 00 16:56:04
INDEX 01 16:57:04
TRACK 07 AUDIO
TITLE "The Bradley"
PERFORMER "Further Seems Forever"
INDEX 00 20:38:58
INDEX 01 20:39:58
TRACK 08 AUDIO
TITLE "New Year's Project"
PERFORMER "Further Seems Forever"
INDEX 00 23:38:35
INDEX 01 23:39:34
TRACK 09 AUDIO
TITLE "How To Start A Fire"
PERFORMER "Further Seems Forever"
INDEX 00 27:43:51
INDEX 01 27:43:69
TRACK 10 AUDIO
TITLE "Someone You Know"
PERFORMER "Further Seems Forever"
INDEX 00 30:35:54
INDEX 01 30:36:04
TRACK 11 AUDIO
TITLE "The Sound"
PERFORMER "Further Seems Forever"
INDEX 00 33:52:47
INDEX 01 33:53:01
TRACK 12 AUDIO
TITLE "Wearing Thin"
PERFORMER "Further Seems Forever"
INDEX 00 37:31:47
INDEX 01 37:32:15
TRACK 13 AUDIO
TITLE "Bleed"
PERFORMER "Further Seems Forever"
INDEX 00 40:18:49
INDEX 01 40:19:48
TRACK 14 AUDIO
TITLE "Pictures Of Shorelines"
PERFORMER "Further Seems Forever"
INDEX 00 43:15:66
INDEX 01 43:16:65
TRACK 15 AUDIO
TITLE "For All We Know"
PERFORMER "Further Seems Forever"
INDEX 00 46:17:62
INDEX 01 46:18:61
TRACK 16 AUDIO
TITLE "Vengeance Factor (feat. Chris Carrabba)"
PERFORMER "Further Seems Forever"
INDEX 00 49:05:25
INDEX 01 49:06:24
TRACK 17 AUDIO
TITLE "There, Now I've Said It (feat. Jason Gleason)"
PERFORMER "Further Seems Forever"
INDEX 00 51:52:61
INDEX 01 51:53:28
TRACK 18 AUDIO
TITLE "Say It Ain't So (feat. Chris Carrabba)"
PERFORMER "Further Seems Forever"
INDEX 00 54:59:00
INDEX 01 54:59:74
TRACK 19 AUDIO
TITLE "Light Up Ahead (Acoustic) (feat. Jon Bunch)"
PERFORMER "Further Seems Forever"
INDEX 00 59:03:31
INDEX 01 59:03:67
TRACK 20 AUDIO
TITLE "Bye Bye Bye (feat. Jason Gleason)"
PERFORMER "Further Seems Forever"
INDEX 00 62:07:22
INDEX 01 62:07:47
TRACK 21 AUDIO
TITLE "Justice Prevails (feat. Chris Carrabba)"
PERFORMER "Further Seems Forever"
INDEX 00 65:30:56
INDEX 01 65:31:55

disc ID reported by EAC when ripping tracks : 0034a1e1-29107115
disc ID reported by ARCue: 0034a1e1-28107115

Thanks for any help.

Moderation: Codebox.
madxcream
I have another problem with a cd I just tried. With this disc ID: 00115f65-890a960a reported correctly with EAC and ARCue. Here is the problem.

EAC reports for track 1: Accurately Ripped (confidence 3) [eccc8d81]
ARCue reports for track 1: Track not present in database. [eccc8d81]

Here is copy and past of the disc ID also to clarify:

EAC : [Disc ID: 00115f65-890a960a]
ARCue: [Disc ID: 00115f65-890a960a]

This happens with all the tracks!

Anyone else getting problems with cd's that don't have data tracks also like me?
Christopher Key
QUOTE(madxcream @ Mar 31 2007, 13:28) *

I have another problem with a cd I just tried. With this disc ID: 00115f65-890a960a reported correctly with EAC and ARCue. Here is the problem.

EAC reports for track 1: Accurately Ripped (confidence 3) [eccc8d81]
ARCue reports for track 1: Track not present in database. [eccc8d81]

Here is copy and past of the disc ID also to clarify:

EAC : [Disc ID: 00115f65-890a960a]
ARCue: [Disc ID: 00115f65-890a960a]

This happens with all the tracks!

Anyone else getting problems with cd's that don't have data tracks also like me?


First part of the move completed...

Is this using the newer version of the script? Does it work correcty with the older version? I did have problems like this myself, it essentially boiled down to perl comparing two identical 32bit values as if one were signed and the other weren't. That was what the {use integer; $CRC = ... + 0} was to fix. I'll have another dig.

Regards,

Chris
Christopher Key
QUOTE(madxcream @ Mar 31 2007, 01:04) *

disc ID reported by EAC when ripping tracks : 0034a1e1-29107115
disc ID reported by ARCue: 0034a1e1-28107115


Should be fixed now.

For future reference, the latest version will now always be ARCue.pl, and i'll keep an archive of older versions online, named as ARCue-rXX.pl.

Chris
Christopher Key
QUOTE(caligae @ Mar 30 2007, 12:03) *

Have fun while moving. I'll probably do some more testing in the meantime.


First stage done, I've got two weeks at home now before heading off again.

QUOTE(caligae @ Mar 30 2007, 12:03) *

Once the program works stable, we really should look into optimization. I fear this can't be done in pure perl very well. I don't know what options you have in perl. At least I know you can use C code in a module - but that will complicate distribution.

I've quickly hacked the checksumming in C. The perl script needed about 100 seconds for verifying an image I used for testing. The C version was limited by disk speed. With data already in cache, it took about 1.3 seconds.


Indeed, perl really isn't written for doing this sort of thing.

I'm keen to keep a pure perl version for folks who just want something simple, but I agree a faster alternative would be better.

The best option I came up with was to try to create a generic perl module to do the majority of the work. This would either call compiled c code, or do that calculation in native perl if that option was unavailable. On win32 platforms, it would also be set up to call functions from AccurateRip.dll to query the database etc where appropriate. I did start having a go at writing an XS module that would call AccurateRip.dll; I got as far as writing skeleton code in C that would call most of the functions successfully.

Chris
Christopher Key
QUOTE(Christopher Key @ Mar 31 2007, 14:44) *

QUOTE(madxcream @ Mar 31 2007, 13:28) *

I have another problem with a cd I just tried. With this disc ID: 00115f65-890a960a reported correctly with EAC and ARCue. Here is the problem.

EAC reports for track 1: Accurately Ripped (confidence 3) [eccc8d81]
ARCue reports for track 1: Track not present in database. [eccc8d81]

Here is copy and past of the disc ID also to clarify:

EAC : [Disc ID: 00115f65-890a960a]
ARCue: [Disc ID: 00115f65-890a960a]

This happens with all the tracks!

Anyone else getting problems with cd's that don't have data tracks also like me?


First part of the move completed...

Is this using the newer version of the script? Does it work correcty with the older version? I did have problems like this myself, it essentially boiled down to perl comparing two identical 32bit values as if one were signed and the other weren't. That was what the {use integer; $CRC = ... + 0} was to fix. I'll have another dig.

Regards,

Chris


Sorry, just reread your original post, it doesn't sound like thats the problem after all.

Could you post the full output of ARCue.pl, including the summary. Secondly, where you've installed EAC, there should be an AccurateRipCache folder, containing a file called,

dBAR-nnn-00115f65-xxxxxxxx-890a960a.bin

where nnn is the number of tracks, anx xxxxxxxx is another checksum. Could you post this file too please.

Chris
madxcream
QUOTE(Christopher Key @ Mar 31 2007, 10:46) *

QUOTE(Christopher Key @ Mar 31 2007, 14:44) *

QUOTE(madxcream @ Mar 31 2007, 13:28) *

I have another problem with a cd I just tried. With this disc ID: 00115f65-890a960a reported correctly with EAC and ARCue. Here is the problem.

EAC reports for track 1: Accurately Ripped (confidence 3) [eccc8d81]
ARCue reports for track 1: Track not present in database. [eccc8d81]

Here is copy and past of the disc ID also to clarify:

EAC : [Disc ID: 00115f65-890a960a]
ARCue: [Disc ID: 00115f65-890a960a]

This happens with all the tracks!

Anyone else getting problems with cd's that don't have data tracks also like me?


First part of the move completed...

Is this using the newer version of the script? Does it work correcty with the older version? I did have problems like this myself, it essentially boiled down to perl comparing two identical 32bit values as if one were signed and the other weren't. That was what the {use integer; $CRC = ... + 0} was to fix. I'll have another dig.

Regards,

Chris


Sorry, just reread your original post, it doesn't sound like thats the problem after all.

Could you post the full output of ARCue.pl, including the summary. Secondly, where you've installed EAC, there should be an AccurateRipCache folder, containing a file called,

dBAR-nnn-00115f65-xxxxxxxx-890a960a.bin

where nnn is the number of tracks, anx xxxxxxxx is another checksum. Could you post this file too please.

Chris


Ok, here is dBAR-010-00115f65-008bd1e7-890a960a.bin

and here is the output from ARCue.pl :

CODE
Checking AccurateRip database

Track    Ripping Status        [Disc ID: 00115f65-890a960a]

1    Track not present in database.    [eccc8d81]
2    Track not present in database.    [16382340]
3    Track not present in database.    [3fe5c721]
4    Track not present in database.    [9546ab6b]
5    Track not present in database.    [ea657670]
6    Track not present in database.    [6b2167a2]
7    Track not present in database.    [6160a42b]
8    Track not present in database.    [2b80bb47]
9    Track not present in database.    [cab19e73]
10    Track not present in database.    [5fa7c9c6]

_______________________

Disc not present in AccurateRip database.


Kevin
madxcream
The other problem I had with ARCue having the wrong Disc ID is corrected, thanks alot!
Christopher Key
QUOTE(madxcream @ Mar 31 2007, 16:35) *


CODE

Disc not present in AccurateRip database.




Ok, that means that ARCue.pl is getting a file not found back from the accurate rip server; I tried forcing the discid, and it downloaded fine here. Could you give the following a go,

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue-madxcream.pl

and post the result please.

Chris
madxcream
QUOTE(Christopher Key @ Mar 31 2007, 14:19) *

QUOTE(madxcream @ Mar 31 2007, 16:35) *


CODE

Disc not present in AccurateRip database.




Ok, that means that ARCue.pl is getting a file not found back from the accurate rip server; I tried forcing the discid, and it downloaded fine here. Could you give the following a go,

http://www.srcf.ucam.org/~cjk32/ARCue/ARCue-madxcream.pl

and post the result please.

Chris


I'm getting this with the problem cd image:
CODE
http://www.accuraterip.com/accuraterip/5/6/f/dBAR-010-00115f65-008bd1e8-890a960a.bin
NO SUCCESS
404 Not Found


I'm getting this with one that works:
CODE
http://www.accuraterip.com/accuraterip/1/e/1/dBAR-021-0034a1e1-03244649-29107115.bin
SUCCESS
200 OK
Christopher Key
Hi Kevin,

Right, EAC is getting the file,

dBAR-010-00115f65-008bd1e7-890a960a.bin

whilst ARCue is trying to download,

QUOTE(madxcream @ Mar 31 2007, 20:31) *

CODE
http://www.accuraterip.com/accuraterip/5/6/f/dBAR-010-00115f65-008bd1e8-890a960a.bin



Note the difference in the middle 8 character id. This value is also calculated from the track offsets / lengths, like the rest of the discid. Do you think you could post a copy of the cue sheet, along with a screenshot of EAC showing the track lengths and offsets that it sees.

Regards,

Chris


madxcream
Hey Chris, here is the info you wanted:

IPB Image

Cuesheet:
CODE
REM REPLAYGAIN_ALBUM_GAIN -6.05 dB
REM REPLAYGAIN_ALBUM_PEAK 0.97723
REM REPLAYGAIN_ALBUM_SCALE 0.49831
REM GENRE "Christian Rock"
REM DATE 1985
REM DISCID 890A960A
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Stryper"
TITLE "Soldiers Under Command"
FILE "Stryper - [1985] Soldiers Under Command.flac" WAVE
TRACK 01 AUDIO
TITLE "Soldiers Under Command"
PERFORMER "Stryper"
INDEX 00 00:00:00
INDEX 01 00:00:32
TRACK 02 AUDIO
TITLE "Makes Me Wanna Sing"
PERFORMER "Stryper"
INDEX 00 05:04:27
INDEX 01 05:04:30
TRACK 03 AUDIO
TITLE "Together Forever"
PERFORMER "Stryper"
INDEX 00 07:56:55
INDEX 01 07:58:15
TRACK 04 AUDIO
TITLE "First Love"
PERFORMER "Stryper"
INDEX 00 12:01:40
INDEX 01 12:02:55
TRACK 05 AUDIO
TITLE "The Rock That Makes Me Roll"
PERFORMER "Stryper"
INDEX 00 17:50:40
INDEX 01 17:54:40
TRACK 06 AUDIO
TITLE "Reach Out"
PERFORMER "Stryper"
INDEX 00 22:53:17
INDEX 01 22:57:02
TRACK 07 AUDIO
TITLE "(Waiting For) A Love That's Real"
PERFORMER "Stryper"
INDEX 01 28:19:47
TRACK 08 AUDIO
TITLE "Together As One"
PERFORMER "Stryper"
INDEX 00 32:55:05
INDEX 01 32:56:62
TRACK 09 AUDIO
TITLE "Surrender"
PERFORMER "Stryper"
INDEX 00 38:01:37
INDEX 01 38:02:45
TRACK 10 AUDIO
TITLE "Battle Hymn of the Republic"
PERFORMER "Stryper"
INDEX 00 42:31:47
INDEX 01 42:33:15

Thanks again for this great tool. My other option was to wait until dbPowerAMP supported cuesheets and single image mode with accuraterip, which is probably around a year away (according to info from the site).

Kevin

Moderation: Codebox.
Christopher Key
QUOTE(madxcream @ Apr 1 2007, 16:21) *


CODE

  TRACK 01 AUDIO
    TITLE "Soldiers Under Command"
    PERFORMER "Stryper"
    INDEX 00 00:00:00
    INDEX 01 00:00:32



This was what was causing the problem; I wasn't correctly calculating the second part of the discid when the first track had a non zero offset. It should now be fixed in the latest version.

QUOTE(madxcream @ Apr 1 2007, 16:21) *

Thanks again for this great tool. My other option was to wait until dbPowerAMP supported cuesheets and single image mode with accuraterip, which is probably around a year away (according to info from the site).


No problem, I wrote it primarly for my own amusement, but thought it may well be of use to others.

Regards,

Chris
madxcream
Confirmed to work, thanks Chris!
madxcream
found another problem one:

EAC disc ID: [Disc ID: 00122ecc-950b070b]
ARCue disc ID: [Disc ID: 00122ecc-950b060b]

from this cue:
CODE
REM GENRE "Hard Rock"
REM DATE 1992
REM DISCID 950B070B
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Whitecross"
TITLE "High Gear"
FILE "Whitecross - [1992] High Gear.flac" WAVE
TRACK 01 AUDIO
TITLE "High Gear"
PERFORMER "Whitecross"
INDEX 00 00:00:00
INDEX 01 00:00:50
TRACK 02 AUDIO
TITLE "Dancin' In Heaven"
PERFORMER "Whitecross"
INDEX 00 03:26:67
INDEX 01 03:26:70
TRACK 03 AUDIO
TITLE "In America"
PERFORMER "Whitecross"
INDEX 00 08:41:05
INDEX 01 08:41:37
TRACK 04 AUDIO
TITLE "Overdrive"
PERFORMER "Whitecross"
INDEX 00 12:26:62
INDEX 01 12:27:10
TRACK 05 AUDIO
TITLE "Without Your Love"
PERFORMER "Whitecross"
INDEX 01 14:28:55
TRACK 06 AUDIO
TITLE "Coming Home"
PERFORMER "Whitecross"
INDEX 00 18:37:27
INDEX 01 18:37:30
TRACK 07 AUDIO
TITLE "My Love"
PERFORMER "Whitecross"
INDEX 00 22:45:27
INDEX 01 22:45:37
TRACK 08 AUDIO
TITLE "I'm Askin' You Today"
PERFORMER "Whitecross"
INDEX 00 28:00:40
INDEX 01 28:00:42
TRACK 09 AUDIO
TITLE "Gonna Keep On"
PERFORMER "Whitecross"
INDEX 00 32:17:07
INDEX 01 32:17:10
TRACK 10 AUDIO
TITLE "I Shout"
PERFORMER "Whitecross"
INDEX 00 36:18:52
INDEX 01 36:19:15
TRACK 11 AUDIO
TITLE "Long Road To Walk"
PERFORMER "Whitecross"
INDEX 00 40:39:72
INDEX 01 40:40:00

Kevin

Moderation: Codebox.
Christopher Key
QUOTE(madxcream @ Apr 1 2007, 20:36) *

found another problem one:

EAC disc ID: [Disc ID: 00122ecc-950b070b]
ARCue disc ID: [Disc ID: 00122ecc-950b060b]



Thanks very much for the alpha testing. Could you try the latest version, this should be fixed now.

Chris
madxcream
QUOTE(Christopher Key @ Apr 1 2007, 16:17) *


Thanks very much for the alpha testing. Could you try the latest version, this should be fixed now.

Chris


It works now for that cd. Thanks and hope I'm not bothering you too much smile.gif
madxcream
Chris, are you still working on getting ARCue to work with cd's that contain data tracks? I haven't found any more problems with any of my cd's I have checked. I only have a few more to go, except for all the cd's that do contain data tracks. I'll help test it if you like and get you any cue sheets and screen shots of EAC with cd's that contain data tracks.

Kevin
Christopher Key
QUOTE(madxcream @ Apr 12 2007, 19:10) *

Chris, are you still working on getting ARCue to work with cd's that contain data tracks? I haven't found any more problems with any of my cd's I have checked. I only have a few more to go, except for all the cd's that do contain data tracks. I'll help test it if you like and get you any cue sheets and screen shots of EAC with cd's that contain data tracks.

Kevin


Hi Kevin,

Sorry for the delay in replying, I'm part way through the second part of the big move, and don't have reliable internet access at the moment (I'm 'borrowing' a connection right now). I do intend to add support for CDs containing data tracks, as well as cue sheets referencing multiple wav files. I reckon I'll have computing facilities fully restored by next weekend, so maybe I'll get things done during the week following that. Any screenshots and data you can post to validate against would be much appreciated. Also, are all your data tracks always the final track? Do you know if this is always the case.

Regards,

Chris
madxcream
QUOTE(Christopher Key @ Apr 15 2007, 15:35) *


Hi Kevin,

Sorry for the delay in replying, I'm part way through the second part of the big move, and don't have reliable internet access at the moment (I'm 'borrowing' a connection right now). I do intend to add support for CDs containing data tracks, as well as cue sheets referencing multiple wav files. I reckon I'll have computing facilities fully restored by next weekend, so maybe I'll get things done during the week following that. Any screenshots and data you can post to validate against would be much appreciated. Also, are all your data tracks always the final track? Do you know if this is always the case.

Regards,

Chris


Chris, as far as data tracks, all the cd's I have, the data tracks show up as the last track. I have no knowledge of any cd's where the data track comes first, but that's just from my experience. Maybe someone else can shed some light on this that knows for sure.

As far as the screenshots, do you mean screen shots of cd's that contain data tracks and their correct Accurate rip ID number?

Kevin
brainsoft
Has any more work been done on producing a faster/C version of this? I've got some time again so I'm going to try out the latest version to see if I can even get valid results now. Doing all this testing before resulted in a burned out DVD-RW after doing read offset tests, that threw a kink in the plans for a month or so.
brainsoft
QUOTE(brainsoft @ May 1 2007, 20:25) *

Has any more work been done on producing a faster/C version of this? I've got some time again so I'm going to try out the latest version to see if I can even get valid results now. Doing all this testing before resulted in a burned out DVD-RW after doing read offset tests, that threw a kink in the plans for a month or so.


Well I was getting the "track not in database' error before, but either because of the new drive or the updated script it now works exactly as expected. This is great news, I can now check my ripped image files before they get converted to flac images and mp3 tracks.

It is fairly slow but it's not that much relative to the time it takes to rip then convert to flac then split and convert to mp3. If anyone has had any success converting this to a small c program it would be such a great addition thoug. Having to install perl just for this is excessive but it will fill the gap in the meantime.

Thanks so much for your work on this, you've found a way to give me exactly what I needed!
wraithdu
I'd like to integrate this into my REACT2 config. I've noticed that when the script is finished, whether successful or not, the command window closes if launched from a BAT file.

Is there a way to have the script return a value when finished, for example 0 if the disc is accurate, and 1 if the there are inaccurate tracks, and then have the BAT file created by REACT2 check that value? Basically I'd like to have REACT2 check the ripped WAV file before processing, then continue if it's accurate, and stop if it's not. I can take care of the IF's and such to make the BAT file do what I want after the check, but I don't know how to check the result of arcue.pl.

I know this question involves batch scripting as well, but this would be a great addition to my config if I can get it to work automatically.
madxcream
QUOTE(wraithdu @ May 2 2007, 20:45) *

I'd like to integrate this into my REACT2 config. I've noticed that when the script is finished, whether successful or not, the command window closes if launched from a BAT file.

Is there a way to have the script return a value when finished, for example 0 if the disc is accurate, and 1 if the there are inaccurate tracks, and then have the BAT file created by REACT2 check that value? Basically I'd like to have REACT2 check the ripped WAV file before processing, then continue if it's accurate, and stop if it's not. I can take care of the IF's and such to make the BAT file do what I want after the check, but I don't know how to check the result of arcue.pl.

I know this question involves batch scripting as well, but this would be a great addition to my config if I can get it to work automatically.


If you ever get this working with REACT2, please share it. I assume you are doing doing the F10 option with REACT ripping to single image? This is also how I rip my cd's.

Well, actually how about doing arcue test.cue >> txt file. Then scan the created txt file for errors. I'm not good with this sort of thing, but I'm sure it could work.
wraithdu
Getting arcue to scan the ripped WAV image is no problem, even getting it to pause after scanning so you can read the CMD window is easy, but getting it to intelligently decide to continue on a successful scan or abort on a failed scan is not so easy. Of course I wanna go the hard route wink.gif

The best usage of this would be when running REACT2 encodes in batch where you don't wanna monitor the whole thing. Then having failed scans written to a log while successful scans complete as usual.

To get REACT2 to perform the scan, just add the commandline to your REACT2 image.cfg somewhere a the top before any processing begins, then a PAUSE line after it. If it's successful, hit enter and it will continue. If not, hit CTRL-C to exit the batch process.

Hmmm, is there a way in a batch file to parse a text file and search for some text? Then perform a command if it is found/not found?

If so, you could use the

arcue test.cue >> textfile.txt

and then parse the txt file for 'Successful Rip' or some such text, then continue if found, or exit if not.

Where's Synthetic Soul when you need him? wink.gif
Antonski
QUOTE(brainsoft @ May 3 2007, 01:13) *

If anyone has had any success converting this to a small c program it would be such a great addition thoug. Having to install perl just for this is excessive but it will fill the gap in the meantime.


Well, if you don't want to install perl, you can try the following executable:

arcue.rar

It is not a C program, just a packet with all necessary perl libraries and the script itself, so it's far bigger than the perl script.
It works in the same way, just provide the cue files as parameters to arcue.exe

~
madxcream
QUOTE(wraithdu @ May 3 2007, 22:13) *


If so, you could use the

arcue test.cue >> textfile.txt

and then parse the txt file for 'Successful Rip' or some such text, then continue if found, or exit if not.

Where's Synthetic Soul when you need him? wink.gif


Yes, that's what I had in mind also. Never done anything like parsing a txt file before, so will have to wait for someone that does know how.
brainsoft
QUOTE(madxcream @ May 4 2007, 14:48) *
QUOTE(wraithdu @ May 3 2007, 22:13) *


If so, you could use the

arcue test.cue >> textfile.txt

and then parse the txt file for 'Successful Rip' or some such text, then continue if found, or exit if not.

Where's Synthetic Soul when you need him? wink.gif


Yes, that's what I had in mind also. Never done anything like parsing a txt file before, so will have to wait for someone that does know how.


Well the only thing left between me and ripping my collection was getting this working in REACT, so I sat down today and put in the error codes into arcue.pl and the handling into the REACT config and I'm finally ready to start ripping my collection. Thanks so much for doing this up!

I came here to say that, and I see posts asking if this could work with REACT, and... yes, it certainly can! Here's how I did it.


in ARCue.pl, change the final output section like so to include a return value for the various outcomes, then exit the script with said return value. Only changes here are the 5 lines that have references to $errlev. value of 0 means no problem, only changed if there IS a problem.
CODE

    my $errlev = 0;
    
    if ($arDiscNotInDb) {
        print "Disc not present in AccurateRip database.\n";
        $errlev = 2;
    } elsif ($arNetworkFailed) {
        print "Failed to get $arUrl : " . $arNetworkFailed . "\n";
        $errlev = 3;
    } elsif ($accuratelyRipped == $trackCount) {
        print "All Tracks Accurately Ripped.\n";
    } else {
        if ($notAccuratelyRipped >= 3) {
             print "Your CD disc is possibly a different pressing to the one(s) stored in AccurateRip.\n"
        }

        printf "Track(s) Accurately Ripped: %d\n", $accuratelyRipped;
        printf "**** Track(s) Not Ripped Accurately: %d ****\n", $notAccuratelyRipped;
        printf "Track(s) Not in Database: %d\n", $notInDatabase;
        $errlev = 1;
    }

    print "\n\n\n";
    exit $errlev;


Then, over in the REACT.ini add a few variables like

CODE

RunAccurateRip=1
ARcue=@Tools@\newARcue.pl


Then in REACT-image.cfg add a little error handling. If the script returns a value of 1 (inaccurate rip) then abort, otherwise carry on to wave gain and encoding. I also added a label just before cleanup because I didn't want EAC to ask me to over-write files anymore.

CODE

REM **** use ARCue.pl (perl script) to verify wav image against AR database
IF NOT @RunAccurateRip@==1 GOTO end_RunAR
    "@ARcue@" "@sourcecuesheet@"

    REM    if rip is inaccurate, abort, otherwise continue on to wave gain.    
    IF ERRORLEVEL 1 GOTO error_1
    GOTO :end_RunAR

:error_1
    ECHO Some tracks were not accurately ripped, aborting compression.
    ECHO Exiting script...
    PAUSE
    
    REM     delete old files so EAC doesn't ask to overwrite next time.    
    GOTO cleanup
:end_RunAR



I wrote other return values into arcue, but I'm personally only concerned about inaccurate rips at the moment.

I might expand later to do something with the discs that aren't in the DB, like making a list of them somewhere. Then I could re-rip them with secure test and copy and I submit the results to the DB, but I'll worry about that when I come across one.

I hope this helps you guys out, I spent all afternoon fiddling with funky win9x vs winNT batch syntax, but I've tested it out and it works great. Atleast for the one CD I've tested (i hardcoded the return value to test that the batch file could receive and interpret it okay.

wraithdu
This is EXACTLY what I've been looking for. Thanks so much for the leg work on this one. I'll be testing this out soon. Awesome job!
brainsoft
If anyone's interested here are my files. I have them configured to Rip to Image, Check with AR, then convert to FLAC Image and MP3 Tracks. This is everything I ever wanted, if only someone could come up with a quick sexy AR checker... or a new version of EAC with on the fly checking *drool*. Why read it twice, we have lots of ram now!

Anyways, here they are. I changed the name to arcue-react.pl because there was once a newarcue.pl I believe. Do with it what you will, let me know if there's are new "official" versions of REACT or ARCue that support this functionality! smile.gif

PS: this is posted on NOPASTE so it won't be up forever, so if you need it tell me where to put it.

React.ini
React-image.cfg
arcue-react.pl

edit: NOPASTE wipes even faster than I thought, if someone else can point out where to post these I will, otherwise maybe we can get it included into react or something





This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2008 Invision Power Services, Inc.