Hydrogenaudio Forums > ARCue.pl - Check whole CD rips with AccurateRip

wraithdu

May 8 2007, 22:31

megaupload works for me, or rapidshare I suppose. Either of those are at least 30 days from last download before they're removed.

wraithdu

May 10 2007, 22:02

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

CODE

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

CODE

arlog=accuraterip.log

to the react.ini

add

CODE

--tag-from-file="accuraterip=accuraterip.log"

to your flac commandline in the flac image section.

add

CODE

COPY /Y @arlog@ %dest%

to the image section as well to copy the actual log file.

brainsoft

May 16 2007, 16:31

QUOTE(wraithdu @ May 11 2007, 00:02)

add

CODE

arlog=accuraterip.log

to the react.ini

add

CODE

--tag-from-file="accuraterip=accuraterip.log"

to your flac commandline in the flac image section.

add

CODE

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.

CODE

--tag-from-file="accuraterip=@arlog@"

wraithdu

May 17 2007, 18:14

My latest additions to my REACT2 code:

REACT.ini

CODE

RunAccurateRip=1
ARCue=C:\Download\Media\Music\Tools\ARCue\ARCue.pl
arlog=accuraterip.log
CopyAR=0
TagAR=1

REACT-image.cfg

CODE

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

CODE

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

CODE

IF %ar_copy%==1 COPY /Y "@sourcedir@\@arlog@" .

Cleanup section

CODE

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

brainsoft

May 22 2007, 03:44

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.

madxcream

May 22 2007, 12:47

QUOTE(brainsoft @ May 22 2007, 04:44)

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.

brainsoft

May 22 2007, 15:35

QUOTE(madxcream @ May 22 2007, 14:47)

QUOTE(brainsoft @ May 22 2007, 04:44)

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.

Christopher Key

May 22 2007, 17:08

QUOTE(brainsoft @ May 22 2007, 22:35)

QUOTE(madxcream @ May 22 2007, 14:47)

QUOTE(brainsoft @ May 22 2007, 04:44)

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

madxcream

May 23 2007, 12:39

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?

Christopher Key

May 24 2007, 03:33

QUOTE(madxcream @ May 23 2007, 19:39)

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

brainsoft

May 27 2007, 20:40

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.

wraithdu

May 29 2007, 14:09

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.

jnc

Jun 3 2007, 18:53

So, what is the AccurateRip algo anyways? Best I could figure out...

Pseudocode:

CODE

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

valnar

Jun 12 2007, 19:48

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

valnar

Jun 18 2007, 04:29

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

Jun 20 2007, 11:00

QUOTE(valnar @ Jun 18 2007, 05:29)

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

Jun 20 2007, 17:59

QUOTE(wraithdu @ Jun 20 2007, 12:00)

QUOTE(valnar @ Jun 18 2007, 05:29)

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

Fandango

Jul 4 2007, 12:12

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.

David256

Jul 10 2007, 00:18

QUOTE(Fandango @ Jul 4 2007, 13:12)

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

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

wraithdu

Jul 13 2007, 19:26

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?

Fandango

Jul 14 2007, 17:38

QUOTE(David256 @ Jul 10 2007, 08:18)

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?

micmac

Jul 14 2007, 18:31

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:

CODE

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:

CODE

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:

CODE

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?

MODERATION: Codebox.

Fandango

Jul 14 2007, 19:16

ARCue.pl only supports single WAV rips. You'll have to find a way to convert it somehow.

micmac

Jul 15 2007, 06:31

QUOTE(Fandango @ Jul 14 2007, 19:16)

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

g30rge

Jul 15 2007, 07:51

QUOTE(gib @ Mar 27 2007, 04:55)

QUOTE(wraithdu @ Mar 26 2007, 17:28)

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

Download and install ActivePerl and you're ready to go.

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.

David256

Jul 15 2007, 14:18

QUOTE(wraithdu @ Jul 13 2007, 20:26)

Does your patched version fix the errorlevel return problem to the REACT2 batch script?

No, I didn't change anything with the exit codes.

QUOTE(wraithdu @ Jul 13 2007, 20:26)

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

Jul 15 2007, 14:28

QUOTE(Fandango @ Jul 14 2007, 18:38)

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

Jul 15 2007, 14:57

QUOTE(g30rge @ Jul 15 2007, 08:51)

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

Jul 15 2007, 15:06

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?

spoon

Jul 15 2007, 15:17

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

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

Fandango

Jul 15 2007, 16:09

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.

QUOTE(David256 @ Jul 15 2007, 22:28)

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.

QUOTE(David256 @ Jul 15 2007, 22:28)

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

Jul 16 2007, 00:39

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

Jul 16 2007, 08:56

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

Jul 16 2007, 10:17

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

Jul 16 2007, 12:54

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

Jul 16 2007, 13:39

>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

Jul 18 2007, 00:45

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

Jul 30 2007, 16:41

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

Dec 27 2007, 09:30

QUOTE(David256 @ Jul 16 2007, 00:28)

QUOTE(Fandango @ Jul 14 2007, 18:38)

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

Omy

Feb 11 2008, 15:09

QUOTE(David256 @ Jul 15 2007, 20:28)

QUOTE(Fandango @ Jul 14 2007, 18:38)

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.

Jose Hidalgo

Feb 18 2008, 11:03

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

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

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

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

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.

Omy

Feb 18 2008, 13:10

QUOTE(Jose Hidalgo @ Feb 18 2008, 17:03)

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

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

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

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

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.

Jose Hidalgo

Feb 19 2008, 03:26

I'd be interested in testing that script anyway.

Fandango

Feb 19 2008, 09:43

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.

Jose Hidalgo

Feb 19 2008, 11:01

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.

Fandango

Feb 19 2008, 11:13

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

Jose Hidalgo

Feb 19 2008, 12:04

Well, back to my previous post then

:

QUOTE(Omy @ Feb 18 2008, 20:10)

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 ?

mr-b

Feb 25 2008, 09:06

QUOTE(Jose Hidalgo @ Feb 19 2008, 18:04)

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

Feb 25 2008, 10:49

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

Feb 25 2008, 11:05

QUOTE(Fandango @ Feb 25 2008, 16:49)

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.