IPB

Welcome Guest ( Log In | Register )

5 Pages V  « < 2 3 4 5 >  
Reply to this topicStart new topic
ARCue.pl - Check whole CD rips with AccurateRip
David256
post Jul 15 2007, 21:18
Post #76





Group: Members
Posts: 4
Joined: 10-July 07
Member No.: 45169



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.
Go to the top of the page
+Quote Post
David256
post Jul 15 2007, 21:28
Post #77





Group: Members
Posts: 4
Joined: 10-July 07
Member No.: 45169



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.
Go to the top of the page
+Quote Post
David256
post Jul 15 2007, 21:57
Post #78





Group: Members
Posts: 4
Joined: 10-July 07
Member No.: 45169



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.
Go to the top of the page
+Quote Post
Synthetic Soul
post Jul 15 2007, 22:06
Post #79





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



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


--------------------
I'm on a horse.
Go to the top of the page
+Quote Post
spoon
post Jul 15 2007, 22:17
Post #80


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2758
Joined: 24-March 02
Member No.: 1615



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

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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Fandango
post Jul 15 2007, 23:09
Post #81





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



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.
Go to the top of the page
+Quote Post
Synthetic Soul
post Jul 16 2007, 07:39
Post #82





Group: Super Moderator
Posts: 4887
Joined: 12-August 04
From: Exeter, UK
Member No.: 16217



Thanks guys. smile.gif

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'm on a horse.
Go to the top of the page
+Quote Post
Fandango
post Jul 16 2007, 15:56
Post #83





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



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. smile.gif
Go to the top of the page
+Quote Post
greynol
post Jul 16 2007, 17:17
Post #84





Group: Super Moderator
Posts: 10338
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Fandango
post Jul 16 2007, 19:54
Post #85





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



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.
Go to the top of the page
+Quote Post
spoon
post Jul 16 2007, 20:39
Post #86


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2758
Joined: 24-March 02
Member No.: 1615



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


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
Sleepy
post Jul 18 2007, 07:45
Post #87





Group: Members
Posts: 9
Joined: 18-July 07
Member No.: 45411



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.)
Go to the top of the page
+Quote Post
odyssey
post Jul 30 2007, 23:41
Post #88





Group: Members
Posts: 2296
Joined: 18-May 03
From: Denmark
Member No.: 6695



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.


--------------------
Can't wait for a HD-AAC encoder :P
Go to the top of the page
+Quote Post
No Fun
post Dec 27 2007, 16:30
Post #89





Group: Members
Posts: 24
Joined: 8-April 04
Member No.: 13334



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

This post has been edited by No Fun: Dec 27 2007, 16:31
Go to the top of the page
+Quote Post
Omy
post Feb 11 2008, 22:09
Post #90





Group: Members
Posts: 6
Joined: 3-February 08
Member No.: 51018



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.

This post has been edited by Omy: Feb 11 2008, 22:09
Go to the top of the page
+Quote Post
Jose Hidalgo
post Feb 18 2008, 18:03
Post #91





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



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.

This post has been edited by Jose Hidalgo: Feb 18 2008, 18:06
Go to the top of the page
+Quote Post
Omy
post Feb 18 2008, 20:10
Post #92





Group: Members
Posts: 6
Joined: 3-February 08
Member No.: 51018



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.

This post has been edited by Omy: Feb 18 2008, 20:36
Go to the top of the page
+Quote Post
Jose Hidalgo
post Feb 19 2008, 10:26
Post #93





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



I'd be interested in testing that script anyway.
Go to the top of the page
+Quote Post
Fandango
post Feb 19 2008, 16:43
Post #94





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



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
Go to the top of the page
+Quote Post
Jose Hidalgo
post Feb 19 2008, 18:01
Post #95





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



Woo-hoo ! Rock'n'roll ! cool.gif

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
Go to the top of the page
+Quote Post
Fandango
post Feb 19 2008, 18:13
Post #96





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



Nope, it will only accept whole image rips in WAV format.
Go to the top of the page
+Quote Post
Jose Hidalgo
post Feb 19 2008, 19:04
Post #97





Group: Banned
Posts: 385
Joined: 22-June 06
Member No.: 32111



Well, back to my previous post then biggrin.gif :
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 ? wink.gif

This post has been edited by Jose Hidalgo: Feb 19 2008, 19:05
Go to the top of the page
+Quote Post
mr-b
post Feb 25 2008, 16:06
Post #98





Group: Members
Posts: 6
Joined: 22-May 07
Member No.: 43686



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 ? wink.gif

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 ... ;-)
Go to the top of the page
+Quote Post
Fandango
post Feb 25 2008, 17:49
Post #99





Group: Members
Posts: 1549
Joined: 13-August 03
Member No.: 8353



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
Go to the top of the page
+Quote Post
Omy
post Feb 25 2008, 18:05
Post #100





Group: Members
Posts: 6
Joined: 3-February 08
Member No.: 51018



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.
Go to the top of the page
+Quote Post

5 Pages V  « < 2 3 4 5 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd December 2014 - 00:45