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 (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 (http://www.accuraterip.com/3rdparty-access.htm)
before use.
Chris Key
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.
I agree, very cool. Something I am likely to take a look at using in the future.
-brendan
Sounds very good Christopher. Now AccurateRip can be used with single-wav albums
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!
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?
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 (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 (http://www.accuraterip.com/3rdparty-access.htm)
before use.
Chris Key
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.
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.
For the programming uninitiated, how do you go about installing Perl to use this script?
Download and install ActivePerl (http://www.activestate.com/Products/ActivePerl/) and you're ready to go.
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.
--- 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){
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
Besides the lengths of all the tracks, the start point of the first track is also necessary.
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.
Check my previous post.
A data track will influence the Disc ID as well.
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 (http://search.cpan.org/dist/String-CRC32/CRC32.pod) might speed it up (As stated above, I never used perl.)
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.
[quote name='caligae' post='481280' date='Mar 27 2007, 11:12']
edit: Hmm, seems like it only works with a single wave file, not with multiple wavs.
[/quote]
Yes, currently only designed to work with single wav files. I'll update it to work with multiple wav file cue sheets.
[quote name='caligae' post='481280' date='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).
[/quote]
The pack documenation is available from
http://perldoc.perl.org/functions/pack.html (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 (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 name='caligae' post='481280' date='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.
[/quote]
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 name='greynol' post='481367' date='Mar 27 2007, 18:25']
Check my previous post.
A data track will influence the Disc ID as well.
[/quote]
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 (http://search.cpan.org/dist/String-CRC32/CRC32.pod) 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
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.
The pack documenation is available from
http://perldoc.perl.org/functions/pack.html (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 (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.
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:
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.
(http://img144.imageshack.us/img144/522/tmwstweacqn0.png) (http://imageshack.us)
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
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:
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
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.
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:
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.
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
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?
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
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
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.
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
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
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 (http://www.pirateshare.net/?id=3177405)
and here is the output from ARCue.pl :
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
The other problem I had with ARCue having the wrong Disc ID is corrected, thanks alot!
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 (http://www.srcf.ucam.org/~cjk32/ARCue/ARCue-madxcream.pl)
and post the result please.
Chris
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 (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:
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:
http://www.accuraterip.com/accuraterip/1/e/1/dBAR-021-0034a1e1-03244649-29107115.bin
SUCCESS
200 OK
Hi Kevin,
Right, EAC is getting the file,
dBAR-010-00115f65-008bd1e7-890a960a.bin
whilst ARCue is trying to download,
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
Hey Chris, here is the info you wanted:
(http://img252.imageshack.us/img252/5069/20070401111448ky0.png)
Cuesheet:
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
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
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.
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
Confirmed to work, thanks Chris!
found another problem one:
EAC disc ID: [Disc ID: 00122ecc-950b070b]
ARCue disc ID: [Disc ID: 00122ecc-950b060b]
from this cue:
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
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]Moderation: Codebox.[/size]
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
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
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
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
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
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.
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!
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.
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.
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
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?
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 (http://one.fsphost.com/Antonski/arcue/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
~
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?
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.
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?
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.
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
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.
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.
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!
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!
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 (http://rafb.net/p/XN7WcK13.html)
React-image.cfg (http://rafb.net/p/Z25YUR92.html)
arcue-react.pl (http://rafb.net/p/TgA5MD29.html)
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
megaupload works for me, or rapidshare I suppose. Either of those are at least 30 days from last download before they're removed.
I made a few additions to your scripts to write the output of arcue.pl to a text file that is then copied to the destination directory(s) as well as embedded in the FLAC image (if that is your desired format).
REM ** run ARCue on source WAV file
IF NOT @RunAccurateRip@==1 GOTO endAR
ECHO.
ECHO Processing image from AccurateRip database...
ECHO.
"@ARCue@" "@sourcecuesheet@">@arlog@
TYPE @arlog@
REM ** if inaccurate, abort, otherwise continue script
IF ERRORLEVEL 1 GOTO error_1
GOTO endAR
:error_1
ECHO Some tracks were not accurately ripped, aborting compression...
ECHO Exiting script
PAUSE
REM ** cleanup temp files
GOTO Cleanup
:endAR
add
arlog=accuraterip.log
to the react.ini
add
--tag-from-file="accuraterip=accuraterip.log"
to your flac commandline in the flac image section.
add
COPY /Y @arlog@ %dest%
to the image section as well to copy the actual log file.
add arlog=accuraterip.log
to the react.ini
add --tag-from-file="accuraterip=accuraterip.log"
to your flac commandline in the flac image section.
add COPY /Y @arlog@ %dest%
to the image section as well to copy the actual log file.
You should use the @arlog@ variable for for your flac command line options as well.
--tag-from-file="accuraterip=@arlog@"
My latest additions to my REACT2 code:
REACT.ini
RunAccurateRip=1
ARCue=C:\Download\Media\Music\Tools\ARCue\ARCue.pl
arlog=accuraterip.log
CopyAR=0
TagAR=1
REACT-image.cfg
REM ** Initialize accuraterip variables
SET ar_copy=0
SET ar_tag=
REM ** Run ARCue on source WAV file and output results if desired
IF NOT @RunAccurateRip@==1 GOTO endAR
REM ** Set accuraterip variables
SET ar_copy=@CopyAR@
IF @TagAR@==1 SET ar_tag=--tag-from-file="accuraterip=@arlog@"
ECHO.
ECHO Processing image from AccurateRip database. Please wait...
ECHO.
"@ARCue@" "@sourcecuesheet@"|find /v ".cue">@arlog@
TYPE @arlog@
REM ** If inaccurate, ask user what to do, otherwise continue script
IF NOT ERRORLEVEL 1 GOTO endAR
ECHO.
ECHO Error validating image with AccurateRip.
ECHO.
:ask
SET choice=
ECHO Enter [c] to continue anyway.
ECHO Enter [d] to delete temp files and exit.
SET /p choice="Enter [x] to exit without deleting temp files: "
IF [%choice%]==[c] GOTO continue
IF [%choice%]==[d] GOTO error_1
IF [%choice%]==[x] EXIT
ECHO.
ECHO [%choice%] is invalid.
ECHO.
GOTO ask
:error_1
REM ** Cleanup temp files
GOTO Cleanup
:continue
REM ** If failed but continuing, set variables so @arlog@ is not copied or embeded
SET ar_copy=0
SET ar_tag=
:endAR
under FLAC image
flac.exe @Opt_Flac@ %RG_Flac% %Cover_tag% -T "%ArtistField%=@cdartist@" -T album="@album@" -T totaltracks="$numtracks$" -T date="@year@" -T genre="@genre@" -T encoding="Flac @Ver_Flac@ @Opt_Flac@" --tag-from-file="cuesheet=@cuesheet@" --tag-from-file="eaclog=@eaclog@" %ar_tag% "@source@" -o "@image@"
and
IF %ar_copy%==1 COPY /Y @arlog@ %dest%
under FLAC and LAME tracks
IF %ar_copy%==1 COPY /Y "@sourcedir@\@arlog@" .
Cleanup section
REM ** Cleanup
:Cleanup
DEL "@source@"
DEL "@eaclog@"
DEL "@cuesheet@"
DEL "@albumfile@.[*].cue"
DEL "@cover@"
DEL "@arlog@"
I hope this is useful for someone else too!
EDIT - fixed some logical and syntax errors....must've been tired last night
Nice work.
For anyone interested arcue.pl has been updated with these error codes, you can download it from the normal download link on the first post.
Nice work.
For anyone interested arcue.pl has been updated with these error codes, you can download it from the normal download link on the first post.
Are you taking over ARCue for Chris? Is there still going to be support for cd's with data tracks also added? Thanks for any info.
Nice work.
For anyone interested arcue.pl has been updated with these error codes, you can download it from the normal download link on the first post.
Are you taking over ARCue for Chris? Is there still going to be support for cd's with data tracks also added? Thanks for any info.
He is still in the process of moving, he said his desk is coming soon, he's just set up the dev computer on the floor for now. The other features are still on the to do list until such a time as he can get back to them.
Nice work.
For anyone interested arcue.pl has been updated with these error codes, you can download it from the normal download link on the first post.
Are you taking over ARCue for Chris? Is there still going to be support for cd's with data tracks also added? Thanks for any info.
He is still in the process of moving, he said his desk is coming soon, he's just set up the dev computer on the floor for now. The other features are still on the to do list until such a time as he can get back to them.
Thanks for passing on the update. I had a call from the desk supplier saying they'd made a mistake with the finishing, and it's going to be another 3 weeks whilst they start again!?!! Anyway, I started to look at getting CDs with data tracks supported, and am considering what the best way to achieve this is.
Ideally, I'd quite like to have all the necessary data included in the cue sheet if possible. Is there any way to fully detail a data track in a cue sheet? From what I've read,
FILE "data.bin" BINARY
TRACK 10 MODE...
would be valid, but requires the track length to be determined from the file size of data.bin. I'd rather not have to prompt the user to input data, as this would make automation harder.
Any thoughts?
Regards,
Chris
I have a question. Does EAC using accruaterip download the cd checksums to the hardisk temporarily? If so, since alot of us want to use EAC + REACT to do our images, which means we want to run ARCue right after the ripping of a cd, could ARCue fetch the downloaded cd checksums that EAC downloads?
Of course, this will not work if EAC + accuraterip just loads the info into memory without saving to the hard drive. Any thoughts?
I have a question. Does EAC using accruaterip download the cd checksums to the hardisk temporarily? If so, since alot of us want to use EAC + REACT to do our images, which means we want to run ARCue right after the ripping of a cd, could ARCue fetch the downloaded cd checksums that EAC downloads?
Of course, this will not work if EAC + accuraterip just loads the info into memory without saving to the hard drive. Any thoughts?
AccurateRip does maintain a cache of checksums, in 'EAC/AccurateRipCache' from memory. I'd rather not hardcode logic to deal with something so specific into ARCue, but a command line option to force the use of a specific file for the checksums might be a good alternative. The calling code then need only identify which the most recently written bin file was, and point ARCue.pl to that.
Regards,
Chris
I think we need a logfile switch
arcue.pl source.cue -L arcue.log
Something like that. What Wraithdu has done above works, but redirecting the output leaves you stairing at a blank screen until the entire checking process is done, and then TYPEs the creative log to the screen. If the logfile creation were part of the script itself then you could still have regular file by file output while writing to the log file in perl.
A logfile option would be great. I wasn't totally pleased with my solution either, but that was the best option available with batch scripting I think. The user just has to have faith the perl script is actually doing something, lol.
So, what is the AccurateRip algo anyways? Best I could figure out...
Pseudocode:
where a cd frame equals 588 wav frames
where each wav frame equals 4 bytes
thus a cd frame equals 2352 bytes (read block size)
where accuraterip_crc(offset)
{
sum framevalues[i] * (offset + i)
}
iterate through PCM WAVE audio data one cd frame at a time
{
? first track
-> skip first 4 cd frames
-> ? 4th cd frame: crc += (value of last wav frame of this cd frame) * 588 * 5
-> ? after 4th cd frame: crc += thiscdframe_wavframevalues.accuraterip_crc(cd_frame_num * 588 + 1)
? not first or last track
-> crc += thiscdframe_wavframevalues.accuraterip_crc(cd_frame_num * 588 + 1)
? last track
-> skip last cd frames
-> ? before last 5 cd frames: crc += thiscdframe_wavframevalues.accuraterip_crc(cd_frame_num * 588 + 1)
}
Is the algo documented anywhere? I want to be sure I'm getting this right (for my Ruby language implementation). The Ruby implementation has a chunk of inline'd C code which makes it significantly faster than the pure Perl version. The same would be true of the original Perl version if it used inlined code or (more appropriately) a module as Chris mentioned is possible to write. How sure are we that the implementation is correct?
*update* I have overhauled my Ruby script skills on this endeavor. Now I've got it reading tocfiles and cuesheets without needing conversion. The algo works on everything I've tested so far. There are recent changes Chris made to ARCue.pl, I would like to know if there is a ChangeLog? (Or any recent communication at all, really. CK- I hope your move is going well and the desk works out!)
Code follows: http://osclab.net/foss/releases/notdown-0.22.tar.bz2 (http://osclab.net/foss/releases/notdown-0.22.tar.bz2)
To everyone who contributed to the ARCue.pl script and REACT2 config changes - THANK YOU!
I did a slightly modified version of the above with all my other REACT2 changes and all works well. I can now set my Plextor to Burst mode and re-do the CD's that either fail, or AccurateRip doesn't know about. With some of my rare CD's, that's probably 10% of my collection anyway, and I would want to securely rip them for peace of mind.
Robert
wraithdu,
I'm having one problem with a disc that is finally either bad, or not in the AR database. It's not processing REACT any further after the EAC rip, at least from what I can tell. It's not giving me the {C} choice menu. Do you have any updates to your REACT code by chance?
Edit: I fixed it so it now just moves past whether or not there are problems on the disc or not. Has anyone verified that errorlevel 1 works and presents the choice menu?
Robert
wraithdu,
I'm having one problem with a disc that is finally either bad, or not in the AR database. It's not processing REACT any further after the EAC rip, at least from what I can tell. It's not giving me the {C} choice menu. Do you have any updates to your REACT code by chance?
Hmm, I haven't actually ripped a disc recently that failed. I'll try something if I get a chance tonight that should fail and report. It should work though, the script looks good. I guess it depends if the perl script is actually passing the errorlevel correctly...I can test it, but if it isn't, then I don't know how to fix it unfortunately.
wraithdu,
I'm having one problem with a disc that is finally either bad, or not in the AR database. It's not processing REACT any further after the EAC rip, at least from what I can tell. It's not giving me the {C} choice menu. Do you have any updates to your REACT code by chance?
Hmm, I haven't actually ripped a disc recently that failed. I'll try something if I get a chance tonight that should fail and report. It should work though, the script looks good. I guess it depends if the perl script is actually passing the errorlevel correctly...I can test it, but if it isn't, then I don't know how to fix it unfortunately.
Well...I tested it tonight. Simple 3 track cue that is certainly not in AR, with the arcue.pl currently available (downloaded it tonight to be sure). I get the message "Disc not present..." which should set the errorlevel to 1. Testing it with a simple bat file, the errorlevel is NOT being returned to cmd.exe. Hence it is 0 and the Choice menu will never be triggered.
Can someone familiar with Perl (using ActivePerl-5.8.8.820-MSWin32-x86-274739.msi as the engine) take a look at the script and figure out how to correctly return the error codes to the batch script? Thanks!!
Hello guys, I have a request and I'm hoping you can help me with it.
I was thinking about how we can identify different pressings of the same CD album/issue. The problem you might be aware of: the TOC on CD A (made in Germany) and on CD B (made in England) are the same, but the audio isn't, or rather it has a different offset on the two pressings.
So the idea is to re-check and shift the offset of one track (ideally the shortest) of a CD that is in the AR database but where all tracks do not match for as long as it takes until we get a AR database match.
Can someone write a modified ARCue.pl so will accept an integer on the command line and use it as an offset modifier before checking a rip, plus the option to only check a specific track(s) and not the entire rip? This would be great, it's going to be a proof-of-concept tool to find a safe way of identifying these nasty "different pressings".
EDIT: Nope, I can't do it myself. My programming skills are very basic.
Can someone write a modified ARCue.pl so will accept an integer on the command line and use it as an offset modifier before checking a rip, plus the option to only check a specific track(s) and not the entire rip? This would be great, it's going to be a proof-of-concept tool to find a safe way of identifying these nasty "different pressings".
This may do what you need: Patched ARCue.pl (http://perm.david256.com/2007/07/10/ARCue.pl)
There's a new origin parameter which accepts an integer that indicates where the audio file begins with respect to the standard AccurateRip origin. For example, --origin=-30 indicates that the audio file begins 30 samples early wrt the AccurateRip origin (ie, it has 30 extra samples at the beginning and is missing 30 samples from the end). --origin=30 indicates that the audio file begins 30 samples late (ie, is missing 30 samples from the beginning but has 30 extra samples at the end).
The default is to use the AccurateRip standard origin. Any missing samples are filled with zeros when calculating the AccurateRip check values.
There's also a new --tracks parameter that accepts a list of tracks to check. The default is to check all tracks. You can tell the script to check only a subset of tracks like this: --tracks=2 ... or, --tracks=1-3 ... or, --tracks=1,3-5 ... etc.
There are a couple of other changes:
- When run on Unix/Linux, the script can read cue files with Windows line endings. Similarly, when run on Windows, it can read cue files with Unix line endings. This is useful for running the script on Linux with cue files generated by EAC.
- The script searches for the wav file in the same directory as the cue file. You don't need to cd to the directory containing the cue & wav files first.
I hope this helps.
David
Does your patched version fix the errorlevel return problem to the REACT2 batch script?
BTW, would the errorlevel be returned as normal and stored in %errorlevel%, or is it in %ErrLevel% as in the script?
I hope this helps.
David
Wow! Great work, thank you!
I did a quick test with some old rips where I didn't set the offset correction and they can be verified! Next thing I'll try to verify a different pressing...
Btw, looking at the perl script there seems to be a limit of 588 samples... why is that?
Hello all,
I tried the updated script from David256. I can't get it to work.
The CD was ripped by me in Linux (Wine -> EAC). I installed libwww-perl (Gentoo 32 bit, perl-5.8.8). Here's what happens:
ARCue.pl Dead\ Again.cue
Checking AccurateRip database
Track Ripping Status [Disc ID: 00009cfa-1402170a]
1 Track not present in database. [00000000]
2 Track not present in database. [00000000]
3 Track not present in database. [00000000]
4 Track not present in database. [00000000]
5 Track not present in database. [00000000]
6 Track not present in database. [00000000]
7 Track not present in database. [00000000]
8 Track not present in database. [00000000]
9 Track not present in database. [00000000]
10 Track not present in database. [3ef437c4]
_______________________
Disc not present in AccurateRip database.
Here's the AccurateRip log I got when I initially ripped the CD:
Track Ripping Status [Disc ID: 001d413e-88122d0a]
1 Accurately Ripped (confidence 6) [0c9d2efe]
2 Accurately Ripped (confidence 6) [81d7a414]
3 Accurately Ripped (confidence 6) [4494fac6]
4 Accurately Ripped (confidence 6) [2cdf6724]
5 Accurately Ripped (confidence 6) [110f3d17]
6 Accurately Ripped (confidence 6) [a4c2fc17]
7 Accurately Ripped (confidence 6) [f2f37d46]
8 Accurately Ripped (confidence 6) [5f72a931]
9 Accurately Ripped (confidence 6) [7b5ca255]
10 Accurately Ripped (confidence 5) [3ef437c4]
_______________________
All Tracks Accurately Ripped.
So the last track's crc is correctly calculated somehow it seems. The crc's of the other tracks aren't calculated (all 00000000 crc's pop up instantly).
And here's my cue file:
REM DATE 2007
REM DISCID 88122D0A
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Type O Negative"
TITLE "Dead Again"
FILE "01. Dead Again.wav" WAVE
TRACK 01 AUDIO
TITLE "Dead Again"
PERFORMER "Type O Negative"
ISRC DEA450702170
INDEX 01 00:00:00
FILE "02. Tripping A Blind Man.wav" WAVE
TRACK 02 AUDIO
TITLE "Tripping A Blind Man"
PERFORMER "Type O Negative"
ISRC DEA450702180
INDEX 01 00:00:00
FILE "03. The Profits Of Doom.wav" WAVE
TRACK 03 AUDIO
TITLE "The Profits Of Doom"
PERFORMER "Type O Negative"
ISRC DEA450702190
INDEX 01 00:00:00
FILE "04. September Sun.wav" WAVE
TRACK 04 AUDIO
TITLE "September Sun"
PERFORMER "Type O Negative"
ISRC DEA450702200
INDEX 01 00:00:00
FILE "05. Halloween In Heaven.wav" WAVE
TRACK 05 AUDIO
TITLE "Halloween In Heaven"
PERFORMER "Type O Negative"
ISRC DEA450702210
INDEX 01 00:00:00
FILE "06. These Three Things.wav" WAVE
TRACK 06 AUDIO
TITLE "These Three Things"
PERFORMER "Type O Negative"
ISRC DEA450702220
INDEX 01 00:00:00
FILE "07. She Burned Me Down.wav" WAVE
TRACK 07 AUDIO
TITLE "She Burned Me Down"
PERFORMER "Type O Negative"
ISRC DEA450702230
INDEX 01 00:00:00
FILE "08. Some Stupid Tomorrow.wav" WAVE
TRACK 08 AUDIO
TITLE "Some Stupid Tomorrow"
PERFORMER "Type O Negative"
ISRC DEA450702240
INDEX 01 00:00:00
FILE "09. An Ode To Locksmiths.wav" WAVE
TRACK 09 AUDIO
TITLE "An Ode To Locksmiths"
PERFORMER "Type O Negative"
ISRC DEA450702250
INDEX 01 00:00:00
FILE "10. Hail And Farewell To Britian.wav" WAVE
TRACK 10 AUDIO
TITLE "Hail And Farewell To Britian"
PERFORMER "Type O Negative"
ISRC DEA450702260
INDEX 01 00:00:00
Any idea what went wrong?
[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]MODERATION: Codebox.[/size]
ARCue.pl only supports single WAV rips. You'll have to find a way to convert it somehow.
ARCue.pl only supports single WAV rips. You'll have to find a way to convert it somehow.
Oh, I guess that explains things
Thx for clearing that up!
mic
For the programming uninitiated, how do you go about installing Perl to use this script?
Download and install ActivePerl (http://www.activestate.com/Products/ActivePerl/) and you're ready to go.
For the even less initiated how do I continue?
I've install perl to C:/Perl, i've placed ARCue.pl in C:/Perl.
In windows XP sp2, when i go start/ run/ cmd what should I type then.
The best i can do is to open the .pl file in notepad.
Does your patched version fix the errorlevel return problem to the REACT2 batch script?
No, I didn't change anything with the exit codes.
BTW, would the errorlevel be returned as normal and stored in %errorlevel%, or is it in %ErrLevel% as in the script?
It should be %errorlevel%. $errLevel is the script's internal variable that it uses to keep track of the error status. The operative statement is "exit $errLevel" where the script returns the status code to the operating system. It should then appear in %errorlevel%. I don't know why it doesn't. I'm not that familiar with ActivePerl.
Btw, looking at the perl script there seems to be a limit of 588 samples... why is that?
The script processes one frame at a time, which is 588 samples. It was somewhat easier to limit the offset to one frame rather than keeping track of it across multiple frames.
But, it shouldn't be hard to remove that restriction if necessary.
For the even less initiated how do I continue?
I've install perl to C:/Perl, i've placed ARCue.pl in C:/Perl.
In windows XP sp2, when i go start/ run/ cmd what should I type then.
The best i can do is to open the .pl file in notepad.
Try this:
Start >> Run... >> cmd
then:
cd "... your cue directory ..."
C:\Perl\perl C:\Perl\ARCue.pl "... your cue file ..."
You don't necessarily need to keep ARCue.pl in your C:\Perl directory. If you put a copy in a directory containing cue files, and if you have C:\Perl in your PATH, you can just do this:
cd "... your cue directory ..."
perl ARCue.pl "... your cue file ..."
Of course that may not be practical if you have your cue and wav files in a bunch of different directories.
I'm confused. I though the release of 0.99 prebeta 1 would see an end to this thread.
What am I missing? What does this script provide that the new EAC does not?
Sorry, I'm sure I could answer this myself by re-reading the whole thread.
Edit: Hmmm... as soon as I hit submit I remembered about return codes. Would I be right in saying that this script allows you to alter your rip process depending on the results provided by Accuraterip?
>What does this script provide that the new EAC does not?
It can check already existing files, not ones currently being ripped.
Yes, imagine you have ripped hundreds of CDs without using AccurateRip.
And the feature added by David256 makes it possible (but tedious) to verify rips of a "different pressing" or even old rips with no offset correction.
The script processes one frame at a time, which is 588 samples. It was somewhat easier to limit the offset to one frame rather than keeping track of it across multiple frames.
Ah, of course! I see.
But, it shouldn't be hard to remove that restriction if necessary.
That would be cool for people who own drives with very big read offsets.
Thanks guys.
It's funny, installing the new EAC kinda thrust Accuraterip on me, when I haven't bothered before. I'm not sure whether it will change the way I do things yet or not.
I think it's a very cool thing that EAC now comes with the AccurateRip.dll pre-installed. Now virtually everyone who upgrades to the new version of EAC will be using AR making it very popular so the database will receive a lot more results. That's good for everyone.
...except that there are some bugs that need to get worked out first.
Hopefully no one is ripping discs with gaps prepended and submitting results to the database.
I saw your post in the EAC release thread, nasty bug actually. I hope the next pre-beta won't be so pre-beta anymore and have this fixed, too.
>Hopefully no one is ripping discs with gaps prepended and submitting results to the database.
We will be purging EAC submissions from the new version, until we can veryify the quality of the results. (I am still waiting for someone to submit 10 discs as requested in the EAC prebeta thread, until then EAC will not be adding to AccurateRips database).
In case anyone is still trying to sort out the problems with %errorlevel% in wraithdu's batch file, I believe that the problem is the fact that the output of ARCue.pl is piped to a find command. As soon as the find command executes, it returns an errorlevel of zero, replacing whatever errorlevel is returned by ARCue.pl.
Here is how I got it to work:
pushd @sourcedir@
"@ARCue@" "@sourcecuesheet@">@arlog@.tmp
popd
set err=%errorlevel%
TYPE @arlog@.tmp | find /V ".cue">@arlog@
DEL @arlog@.tmp
TYPE @arlog@
The variable %err% contains the error code from ARCue. (Note that the pushd and popd commands are there because I was having problems getting ARCue to find the .wav file without these.)
Could it be made possible to check if an album needs offset correction? Usually if I mount an album that I ripped without setting the offset, EAC is able to find the correct offset, so I assume it's possible.
Btw, looking at the perl script there seems to be a limit of 588 samples... why is that?
The script processes one frame at a time, which is 588 samples. It was somewhat easier to limit the offset to one frame rather than keeping track of it across multiple frames.
But, it shouldn't be hard to remove that restriction if necessary.
Wouldn't you be so kind to do so?
BTW, I think it would be more comfortable if the "origin" value were synchronized with the "offset" value of another progs like CueTools or WavTools (I mean the sign).
Oh, and THANK YOU
Btw, looking at the perl script there seems to be a limit of 588 samples... why is that?
The script processes one frame at a time, which is 588 samples. It was somewhat easier to limit the offset to one frame rather than keeping track of it across multiple frames.
But, it shouldn't be hard to remove that restriction if necessary.
In contrast, I found that when I was rewriting the CRC code in C (for the speed increase, which is dramatic) the code was made rather simpler by not considering the audio as frames (or, not to the extent arcue does). Provided I haven't introduced a very subtle bug which has failed to show itself so far
*, the offset can simply be initialised at the start of CRC generation for each track and incremented with each sample, with no need for the concept of frame offsets. This is partially from memory, I was working on this a week or so again, but HA seems to have a rather pointless delay between registration and being allowed to post. I've since got rather fed up with AR for various reasons.
* It would be
really nice if any of this stuff was actually documented, AR has the potential to be very useful. But as it is currently then everyone that wants to do anything with it seems to have to reverse engineer it. This doesn't seem remotely productive. There is still at least one part of AR which I don't understand the use of, but I don't have the time to reverse engineer more stuff. Documentation is a wonderful thing.
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.
Please forgive me for not having read the whole thread, but has the script been updated since then ?
All my ripped albums are in multiple FLAC format (1 FLAC file per track), and I have no cue sheets because I have no need for them. I'd like to retrospectively check their AccurateRip accuracy.
Is this script the solution ? Is there another solution ? (maybe the new EAC version ? I'm still with 0.95b4...)
Thanks for enlightening me.
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.
Please forgive me for not having read the whole thread, but has the script been updated since then ?
All my ripped albums are in multiple FLAC format (1 FLAC file per track), and I have no cue sheets because I have no need for them. I'd like to retrospectively check their AccurateRip accuracy.
Is this script the solution ? Is there another solution ? (maybe the new EAC version ? I'm still with 0.95b4...)
Thanks for enlightening me.
There is a script which does what you want, or tries to. I'm not sure if it's publicly available. However, there are several issues with the script (which are caused by the AccurateRip design), so it does not work in all cases and may never be able to do so. Most notably it is -- I believe -- impossible for it to cope with CDs which contain data tracks or have a non-2second pregap on track 1.
Edit when I actually have time to finish typing: What I say about it being impossible is based on my experiences, I guess it would be more accurate to say that I don't see how it is possible. However unless there is an alternative way of looking up results from AR, I'm fairly confident about data tracks making it impossible. The disc IDs seem to require the total length of the CD in frames, which depends on the length of the datatrack as well as the lengths of the FLAC files you have.
I'd be interested in testing that script anyway.
Jose, get an Win32 executable version here: http://www.hydrogenaudio.org/forums/index....showtopic=59423 (http://www.hydrogenaudio.org/forums/index.php?showtopic=59423)
Discussion about the C++ version goes here: http://www.hydrogenaudio.org/forums/index....showtopic=60440 (http://www.hydrogenaudio.org/forums/index.php?showtopic=60440)
PS: It's also much faster than the Perl script.
Woo-hoo ! Rock'n'roll !
Thanks Fandango. Could you simply confirm that this new version :
- works with separate files ?
- works with FLAC files ?
Thanks again.
Nope, it will only accept whole image rips in WAV format.
Well, back to my previous post then :
There is a script which does what you want, or tries to. I'm not sure if it's publicly available.
Fandango, with your new software it shouldn't be too complicated to automatically decompress a bunch of FLACs in the same folder, make a single temporary WAV file and do the job, don't you think ?
Fandango, with your new software it shouldn't be too complicated to automatically decompress a bunch of FLACs in the same folder, make a single temporary WAV file and do the job, don't you think ?
I also just store the individual track flac files (easy to browse on a PC and never saw the need for CD images), and I'd really love the ability to check those FLAC files:
a) from pre-AR-enabled-EAC days
b) which after ripping say "track not present in the AR db" later on when the AR db is more populated. I'm sorry for having such non-mainstream taste ... ;-)
I'd love to be able to check individual files, too. But I didn't write the perl script nor did I port it to C++, I only provided the latest compiles. Sorry.
Ideally as a foobar2000 plugin, because fb2k will deal with all the decoding of the various lossless codecs:
http://www.hydrogenaudio.org/forums/index....showtopic=56531 (http://www.hydrogenaudio.org/forums/index.php?showtopic=56531)
I'd love to be able to check individual files, too. But I didn't write the perl script nor did I port it to C++, I only provided the latest compiles. Sorry.
Ideally as a foobar2000 plugin, because fb2k will deal with all the decoding of the various lossless codecs:
http://www.hydrogenaudio.org/forums/index....showtopic=56531 (http://www.hydrogenaudio.org/forums/index.php?showtopic=56531)
I didn't actually write the perl script, but I do have a copy of it and of my own C version of it (which is much faster). As I at least hinted above, I don't know of anywhere that the perl script's author has released it publicly. Because of that I don't want to post it here myself.
I did ask him to post it here, and I thought he had said he would, but it seems he hasn't yet. I can re-ask.
And as far as I'm concerned, a foobar2000 plugin is far from ideal. I, along with many, many other people, don't use fb2k. So a fb2k plugin would be useless, not ideal.
What would be ideal would be a portable library which plugins for the million and one players out that could use to do the hard work. As I think I mentioned above, I did start work on such a library. But it's not finished, and it's based off the aforementioned perl script to a great enough extent that I don't want to release it without that author's consent, not to mention that the sample prog that uses the library is as ugly as hell.
I did email the author of ARCue.pl itself about all this, and a possible collaboration of efforts, but unfortunately he hasn't got back to me.
You misunderstood me: I said something along the line of "I'd love to be able to check individual files [...] ideally with a foobar2000 plugin."
Apart from that I would also appreciate an enhanced command line tool written in C or C++ that can at least check individual tracks as files in WAV format. Although that would make things more complicated for me than a fb2k plugin, because I'm very bad at writing these BASIC style batch scripts for Windows.
I was only talking about my own needs here.
I, along with many, many other people, don't use fb2k.
WHAT ?!? ... just kidding. You are totally right, there are two kind of users out there :
- the foobar users,
- and those who don't know foobar yet.
(I'm out of here, I'm out of here, just kidding again folks)
... just kidding. You are totally right, there are two kind of users out there :
- the foobar users,
- and those who don't know foobar yet.
(I'm out of here, I'm out of here, just kidding again folks)
And those of us who choose to use other stuff, like mpd.
I, along with many, many other people, don't use fb2k.
WHAT ?!?
... just kidding. You are totally right, there are two kind of users out there :
- the foobar users,
- and those who don't know foobar yet.
(I'm out of here, I'm out of here, just kidding again folks)
And those of us who don't choose windows
As I see no reason not to post this here now, here (http://www.hydrogenaudio.org/forums/index.php?showtopic=61574) is my C version. The library portion of it should be reasonable portable, but the accuraterip-crcgen code is very ugly and probably will only work on *nix systems. Having said that, I haven't actually tried it anywhere else. YMMV, but if you can make it work then it's significantly faster than the perl implementations.
My problem is this:
I have lots of CDs ripped to FLAC, and I would like to use arflac to verify their quality. However unfortunately they were ripped using CDEX thus drive offsets were not taken into account while ripping.
Is there a tool which I could use to fix the drive offsets to the FLAC files before running arflac?
(There is also the added joy that I used a total of three different drives for ripping, but still it would be probably more convenient to run arflac three times than to convert everything once again using EAC... sigh)
Perhaps we must start a new thread for ARFlac.pl as most people may not look inside this thread when looking for a utility like this.
Omy started one for the version in C, but I'll split this one off.
ARFlac.pl can now be found here (http://www.hydrogenaudio.org/forums/index.php?showtopic=62522).
redirecting the output leaves you stairing at a blank screen until the entire checking process is done, and then TYPEs the creative log to the screen. If the logfile creation were part of the script itself then you could still have regular file by file output while writing to the log file in perl.
If you add
select STDOUT; $| = 1;
to the top of the script it stops the buffering problem. Pipe-ing through Tee works great this way.
P.S. ARCue.pl works great on my 64bit Debian machine.
I think I mentioned it earlier, but I *really* would like ARCUE to be able to determine an offset and still return the accuracy of a rip. This is also nessesary because of my recent experience:
I'm creating a script that will traverse all my albums and verify their accuracy with ARCUE, but an obvious problem makes this useless on almost any album. I've ripped all my music as seperate tracks with EAC. When a CD has any amount of silence in INDEX 00 in TRACK 01, it's impossible for me to recreate a true cuesheet that will work with ARCUE - All tracks will seem nudged the time of INDEX 00 to AR.
I really hope that this feature could be incorporated so I will be able to check my rips.
I think I mentioned it earlier, but I *really* would like ARCUE to be able to determine an offset and still return the accuracy of a rip. This is also nessesary because of my recent experience:
I'm creating a script that will traverse all my albums and verify their accuracy with ARCUE, but an obvious problem makes this useless on almost any album. I've ripped all my music as seperate tracks with EAC. When a CD has any amount of silence in INDEX 00 in TRACK 01, it's impossible for me to recreate a true cuesheet that will work with ARCUE - All tracks will seem nudged the time of INDEX 00 to AR.
I really hope that this feature could be incorporated so I will be able to check my rips.
I've updated the code with offset support, here (http://www.hydrogenaudio.org/forums/index.php?showtopic=61574&pid=772006&mode=threaded&start=#entry772006)
The ARCue script only works well for me with single file cuesheets. Is it possible to make it work also with multiple file cuesheets?
Help appreciated, thanks.