Anyone who wants to write foo_accuraterip_db?, Plugin for checking any tracks Options

[Fandango]

Hi,

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!

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

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

[Fandango]

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

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:

(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 ? )

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.

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?

This post has been edited by Fandango: Jan 11 2008, 19:50