Welcome Guest ( Log In | Register )

Anyone who wants to write foo_accuraterip_db?, Plugin for checking any tracks
post Aug 1 2007, 03:32
Post #1

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


why is there no plugin that checks any selected tracks as an album using AR checksums for comparing the results with the AR database?

That would be handy, since foobar2000 would do all the conversion.

Anyone who wants to write such a plugin? Would be awesome! laugh.gif

EDIT: Thanks for moving the thread and giving it a better title. blush.gif

Some things to consider...
  • There shall be no any limitation regarding the source of the tracks used. So lossy files get decoded to PCM, just like losslessly encoded files. It doesn't hurt if the plugin is held dumb enough to not be bothered whether the source was lossy or lossless. In fact this might even be useful to verify that a false entry based on a non-CD-source has made it into the AR database, in case someone has a hunch that a specific "release" has made it into the database.

    Of course, checks on the decoded output must apply, namely that it is 16bit, 44.1kHz PCM. And maybe it's also wise to not allow internet radio streams as input for this plugin, in case it's possible to check this. Or else the user who accidentally chose such a playlist entry might wait forever for the plugin to finish.

  • Don't object: "but why any tracks? you mean you want to select some lossy files and see if they make up an album that is present in the AR database?" -- No, I don't want to do that, maybe once or twice just for the fun of it. But although it doesn't make sense to check random tracks as one album, there's also no reason why this shall not be possible.

    To make myself clearer: I think the grouping of tracks for an AR check should be implemented more or less exactly like the grouping for replaygain was done... i.e. "treat selected tracks as one album", "treat selected tracks as album(s) (using tags)".

  • There should be a log output, that can be copied and pasted or even automatically written to a file using tagz script for creating that file's name. Not just a window that says "Album was verified as being accurately ripped."/"Album couldn't be verified as being accurately ripped."

    The log output should resemble the output of the AR.dll for the time being... and maybe later, even better it could be written using user-defineable templates.
Any more ideas? Objections?

This post has been edited by Fandango: Aug 1 2007, 04:04
Go to the top of the page
+Quote Post
Start new topic
post Jan 11 2008, 19:24
Post #2

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

A wrong offset correction is always an issue when doing an AR check on a rip in retrospect.

The AR-approved-and-enabled rippers make use of AR's calibration, whereas this was not the case with the rips you want to check retrospectively. Although you may have been so wise to manually set the read offset correction in EAC anyway.

But in those cases where you didn't use an AR-enabled ripper or a manually configured EAC, the most important piece of information is taken from the EAC log here. It gives us two important clues about the correctness of the offset correction: the offset correction applied on the audio itself and the drive's model. For other rippers than EAC, knowing the drive's model will do, since they usually rip without offset correction anyway, and the rare case that can happen with a misconfigured EAC where you have to "correct the incorrect read offset correction" should never happen here.

In combination with the drive database that can be found at the AccurateRip homepage, a wrong offset correction shouldn't be a problem anymore in theory. The only challenge would be to apply the right correction to your rip. You can do this manually with a tool like CUE Tools, but when you want to batch process ten thousands of tracks with fb2k, then this simply doesn't work.

So some kind of EAC log processing for the lossless rips with wrong offsets would be a nice extra feature. I say extra feature, because it's really your fault if you hadn't set the offset correction in EAC. Of course, this does not apply when you didn't use EAC... wink.gif

So a simpler solution which is maybe sufficient for most cases is to be able to set an offset correction in the preferences page of this component. Assuming that most of your rips were made with the same drive, this should do.

@Jose Hidalgo:
QUOTE (Jose Hidalgo @ Jan 11 2008, 19:17) *
(the file CRC, not the AR CRC of course ! what would be the use in storing the AR CRC if it's not the same as the file CRC ? tongue.gif )

I know what you mean, but let's stick to the convention that when talking about "AR CRC" it does not explicitely mean the CRC stored in the database. Because AccurateRips way of creating a CRC from the track is different from a "normal" CRC of the tracks' audio. If you would CRC the raw PCM of a track (like EAC does it) and then do a CRC check AR-style both results will differ always. Therefor I am using the term "AR CRC" no matter if it's the AR CRC of the local file or the AR CRC in the database. wink.gif

QUOTE (Jose Hidalgo @ Jan 11 2008, 19:17) *
QUOTE (odyssey @ Aug 24 2007, 21:58) *

A little bonus feature I hope to be possible is the check for offset correction. I'm not sure if this is possible with *every* disc, but according to AR it should be, since any discs could be used as configuration disc.

Yes, why not. But the main thing for me would be to NOT use silence samples for CRC calculations. That should solve a part of the offset problems IMHO, since most tracks begin and end with a part of silence. Am I wrong ?
AccurateRip's way of calculating the CRC is quite different from the way EAC does it, throwing out silent samples is not an option, and would give negative AR results always. And honestly I don't see how cutting of silent samples has anything to do with offset correction. You want all your tracks to be correct, not just those with silence at the beginning and the end, and besides silent samples are used for AR calculation, too. So this will never work.

What's really needed for rips without offset correction is to get to know the read offset of the drive used for ripping. And that's no problem, right? Because you ripped the CDs yourself, right? dry.gif

This post has been edited by Fandango: Jan 11 2008, 19:50
Go to the top of the page
+Quote Post

Posts in this topic
- Fandango   Anyone who wants to write foo_accuraterip_db?   Aug 1 2007, 03:32
- - kanak   I'd surely use it. Now if only someone would d...   Aug 1 2007, 04:12
- - jdcarr   QUOTE (Fandango @ Jul 31 2007, 21:32) Hi,...   Aug 24 2007, 19:53
|- - Spirit_of_the_ocean   Thats why you are asked in some programs to make e...   Aug 24 2007, 20:32
|- - NormanPCN   QUOTE (jdcarr @ Aug 24 2007, 11:53) I...   Aug 24 2007, 22:39
- - odyssey   It would be great for such plugin, but I don't...   Aug 24 2007, 21:58
- - Jose Hidalgo   Hi everyone, Please count me in : such component ...   Jan 11 2008, 19:17
- - Fandango   A wrong offset correction is always an issue when ...   Jan 11 2008, 19:24
|- - odyssey   QUOTE (Fandango @ Jan 11 2008, 19:24) Wha...   Jan 11 2008, 20:16
- - Jose Hidalgo   +1 : Fandango, I can assure that I have ripped ALL...   Jan 11 2008, 22:07
- - Fandango   That's what I think most people will have. Eit...   Jan 12 2008, 00:09
- - Jose Hidalgo   Well, all this stuff looks promising. Now all we...   Jan 12 2008, 02:38
|- - Fandango   QUOTE (Jose Hidalgo @ Jan 12 2008, 02:38)...   Jan 12 2008, 16:09
- - ssjkakaroto   It would already be really useful if AR was integr...   Jan 27 2008, 16:05
|- - Fandango   QUOTE (ssjkakaroto @ Jan 27 2008, 16:05) ...   Feb 3 2008, 21:38
- - 2tec   QUOTE (Fandango @ Jul 31 2007, 19:32) why...   Apr 13 2008, 15:14
- - gausome   QUOTE (2tec @ Apr 13 2008, 08:14) QUOTE (...   Apr 21 2008, 20:25
- - Borisz   I would be perfectly content with just a scanner, ...   Apr 25 2008, 12:34
- - unfortunateson   hope to see this come to fruition someday.   Jun 11 2008, 18:59
- - Parsi   I just wanted to open up a new thread about this. ...   Jul 18 2008, 18:06
|- - odyssey   QUOTE (Parsi @ Jul 18 2008, 19:06) Howeve...   Jul 18 2008, 19:44
- - XPEHOPE3   Such an utility exists. It looks like this: It...   Jul 28 2008, 06:56
|- - odyssey   QUOTE (XPEHOPE3 @ Jul 28 2008, 07:56) Suc...   Jul 28 2008, 08:33
- - XPEHOPE3   QUOTE But does it write the results in tags or eve...   Jul 28 2008, 09:16
|- - odyssey   QUOTE (XPEHOPE3 @ Jul 28 2008, 10:16) QUO...   Jul 28 2008, 12:19
- - twostar   Fooaccrip works for me. I tested with a cd ripped ...   Jul 28 2008, 12:09
- - XPEHOPE3   I will tell the author about my post here and hope...   Jul 28 2008, 13:17
- - Parsi   odyssey, According to my tests arcue supports preg...   Jul 29 2008, 11:59
|- - odyssey   QUOTE (Parsi @ Jul 29 2008, 12:59) odysse...   Jul 29 2008, 14:17
- - odyssey   Just tried it out today. It seem to work very well...   Aug 4 2008, 20:19
- - foorious   I definitely second that.   Aug 5 2008, 14:59
- - Borisz   I imagine a foobar integrated accuraterip verifier...   Sep 14 2008, 11:23
- - foorious   Any upcoming news on FooAccRip ? Our friend odysse...   Sep 22 2008, 14:52
- - Gregory S. Chudov   QUOTE (foorious @ Sep 22 2008, 16:52) I...   Oct 2 2008, 12:20

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: 27th November 2015 - 12:45