ARCue.pl - Check whole CD rips with AccurateRip Options

[David256]

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.

[David256]

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.

[David256]

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:

CODE

Start >> Run... >> cmd

then:

CODE

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:

CODE

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.

[Synthetic Soul]

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?

This post has been edited by Synthetic Soul: Jul 15 2007, 22:08

[spoon]

>What does this script provide that the new EAC does not?

It can check already existing files, not ones currently being ripped.

[Fandango]

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.

[Synthetic Soul]

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.

[Fandango]

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.

[greynol]

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

[Fandango]

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.

[spoon]

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

[Sleepy]

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:

CODE

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

[odyssey]

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.

[No Fun]

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

This post has been edited by No Fun: Dec 27 2007, 16:31

[Omy]

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.

This post has been edited by Omy: Feb 11 2008, 22:09

[Jose Hidalgo]

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.

This post has been edited by Jose Hidalgo: Feb 18 2008, 18:06

[Omy]

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.

This post has been edited by Omy: Feb 18 2008, 20:36

[Jose Hidalgo]

I'd be interested in testing that script anyway.

[Fandango]

Jose, get an Win32 executable version here: http://www.hydrogenaudio.org/forums/index....showtopic=59423

Discussion about the C++ version goes here: http://www.hydrogenaudio.org/forums/index....showtopic=60440

PS: It's also much faster than the Perl script.

This post has been edited by Fandango: Feb 19 2008, 16:44

[Jose Hidalgo]

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.

This post has been edited by Jose Hidalgo: Feb 19 2008, 18:02

[Fandango]

Nope, it will only accept whole image rips in WAV format.

[Jose Hidalgo]

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 ?

This post has been edited by Jose Hidalgo: Feb 19 2008, 19:05

[mr-b]

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

[Fandango]

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

[Omy]

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

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.