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?

I'd surely use it. Now if only someone would develop it

I'd sure like it too...but there's one inherent problem with it...let me know if I'm wrong, but:

Every single drive when it rips offsets the rip differently...just barely. Therefore, in order to accurately compare a rip against the accuraterip database it requires knowing the exact offset of the drive that ripped it, which makes it a little difficult, since every drive has a different offset.

That's why there's plugins for ripping programs (EAC and dbPowerAmp) and nothing else. Do I make sense?

Thats why you are asked in some programs to make example rips to get the right settings for your drive

It would be great for such plugin, but I don't see any use for it in regard to lossy files - AT ALL! In fact I don't think that this plugin should be able to submit any data.

If such plugin is developed, it should check if %DISCID% is set on the files, and check them upon this particular disc. If it's not found, you would only be able to verify AR data if you select an entire album and AR could calculate the DISCID from this.

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.

Accuraterip requires you calibrate with a known key disc which has a known offset and therefore you can properly determine the drive offset. I use accuraterip when doing my 277 CDs with dbPowerAmp. Very nice feature since if the first pass of my rip agreed with the database then the ripper did not bother with secure mode. Makes for very fast rips excpt for scratched tracks or CDs not in the DB. A CD can be in the database but you might have a CD with a different production run(pressing) so in that case you still go secure.

I am out for looking at doing something like this. I would not touch C++ with a ten foot pole. Modula-2 is my game.

Hi everyone,

Please count me in : such component would be a great idea if properly developed.


I think the component should be able to calculate the CRC of each file and store them in the tag (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 also think that writing the confidence to the tag *would* be a good idea, since it can help distinguish very reliable rips (with high confidence scores) from less reliable ones (with 1-2 confidence scores for example). So one could choose to sort the files by the "AR confidence" field, select the ones with the lower scores, then re-check them over time to see if their confidence improves or not. If it doesn't, then either the CD is a very rare one, or then it could be a good idea to re-rip it and see what happens.


I agree with you (but lossless collections very often are made of entire albums, so this shouldn't be a big problem). And once we have calculated the DISCID, why not store it too in a %discid% tag field for all the album tracks ? It can't be a bad thing, can it ?


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 ?

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:

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.

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?

Yes I did - With several different drives, a few of them are already thrown away and I don't have much logs. I noticed after a while that I didn't use offset correction (that was before I used AccurateRip - It wasn't very widespread back then)

+1 : Fandango, I can assure that I have ripped ALL of my CDs (and I mean more than 1.000 legally-bought CDs) myself, with EAC and Accuraterip (who calculated my drive's offset automatically based on 3 different CDs).

However, I agree with odyssey : I have ripped some of my CDs at a friend's appartment who as a different drive with a different offset. Besides, in the near future, I may also want to change my drive for another model with a different offset.

And of course once you mix up all those ripped CDs in the same hard drive, you don't necessarily remember what CDs have been ripped with what drive. Of course I have most of the EAC logs, but again, having a look manually at more than 1.000 logs doesn't look like a good solution to me...

As for the AR logs, I have very few of them. Why ? Because with EAC 0.95b4 a year ago, it was a bit of a pain to manually copy/paste them in individual files. So I did it only when they indicated no confidence (CD not in database, or incorrect results).

Voilà.

That's what I think most people will have. Either the drive offset was corrected be it manually or with the help of AR, or it wasn't corrected at all, but most of the rips are done with the same drive.

So for offset corrected rips that have not been AR-checked while ripping there's no problem at all.

And for those rips that have no been offset corrected, a single setting for this component to use a temporary offset correction would also suffice.

In cases where the user who didn't use to care about offset correcting bought a new drive and he still can sort the rips by date and use a different offset for the tests on each batch of rips.

As a deluxe solution I was thinking about an EAC log parser that in combination with a drive offset database can do this on a per rip basis, but that probably is overkill.

Well, all this stuff looks promising. Now all we've got to do is find a dev willing to do it. Guys ?...

...ah yes, back to problem #1.

It would already be really useful if AR was integrated with the ripping function of fb2k.

True. It would be a real bonus to the fb2k ripper.

I'm sorry but just exactly how do you mean "check"? Are you hoping to verify that the audio data is unchanged?

If so, then how about http://wiki.etree.org/index.php?page=FlacFingerprint

That is very interesting, it is exactly what is needed in to perform a check of the audio data. It seems like the last step would be to combine this feature with something like the AccurateRip database, so that any "Flac Fingerprint" can be compared with other users and given a confidence rating, which would let you determine if any flaws exist in the audio.

I would be perfectly content with just a scanner, that can do nothing else but telling me if my files are accurate (and to what confidence & the crc).

It would be nice if it would work for multiple album inputs, tough (the same way the replaygain scanner does). That way I could verify a lot of my flac rips in one pass - right now the only way i can verify them is to burn them on disc, then rerip in eac. Very painful process.

hope to see this come to fruition someday.

I just wanted to open up a new thread about this.
I wish I was a programmmer.

However I would really appreciate this. although a working version of arflac.exe would do fine for me as well - if it would exist

arcue.exe already exists. Also flac.exe and shntool.exe exists if you need to decode and/or combine seperate files. Only I became aware of a spoiler today that makes it impossible for me to use it, because it doesn't take pregap (INDEX 00) in TRACK 01 into account, so all my albums with this will fail when I try.

I really hope some programmer would pickup this, and take offset into account. I would myself, but I still have no C++ experience

Such an utility exists.
It looks like this:

It's set up via foobar converter like this:

It can be downloaded here. Since that site doesn't allow direct links you have to click here:

I'm not the author. The author doesn't know yet about my post here - he is at vacations right now.
The utility is in the alpha state, it's the first test version, please beware.

But does it write the results in tags or even work with multiple albums at the same time ??


I don't think so. The internal stored md5 seem to be a checksum of the compressed file without headers. This means, different md5 sums for different flac versions or even different compression levels.

Calling it a "fingerprint" is a little way off IMHO.

Edit: Confusing article. Their "fingerprinting" method seems to me to be just a checksum of the decoded filedata. That's no different from the data stored in AR.

For those who don't know there's a small util called "Tripleflac" that does this on flac-files and even shows the offset! Still it would be great to have a "point 'n click" component that eases this in foobar, but for now it pretty well accomplishes my task.

It is first test version) you're demanding too much from it. Multiple albums support is planned AFAIR. Results would be saved most probably to a text file only.

Fooaccrip works for me. I tested with a cd ripped with EAC burst mode. EAC reports that all but 2 tracks were ripped accurately. Fooaccrip reports the same.

That's quite nice then.

Will it detect offset in the future? Maybe even be able to correct it?


Isn't it quite easy to call foobar2000 with the input filename and make it store a specific tag? Maybe you could ask the developer this. It should be as easy as outputting a textfile.

I will tell the author about my post here and hopefully he will look through the topic and answer your questions.

odyssey, According to my tests arcue supports pregap tags.
the only thing annoying is that everythings has to be cue+wav.
I hope this program (I dont know if it is correct to call it a plugin..) will get deveolped further, looks promising. I am not going to install it until its out of the testing stage

Yes it supports it correctly - Problem was that I were unable to re-create the pregap because it will always be missing in single-track rips, and I would have no clue how long - if any it might be.

But that's past now. I've discovered tripleflac (thanx to graynol) that verifies my singletrack rips. I'll try out this foobar "addon" soon to see it's capabilities.

Just tried it out today. It seem to work very well, although it could be VERY powerful!

Here's a list of feature requests I hope to see in a future version:

* I don't understand the concept of the dummy-files - Could they not be ignored?
* Write results into tags (can be done by calling foobar2000.exe with the filename and the tag that should be written)
* Support album grouping. Not sure which way is the best through converter, but maybe something similar to CUI NG grouping?
* Detect possible different offset values (just like tripleflac)
* Correct offset with any value available through entire album (I noticed some tracks usually differ with tripleflac). It could even automatically try to correct each possible offset values and present multiple possebilities to the user.

I definitely second that.

I imagine a foobar integrated accuraterip verifier to be something like a cross between the Replaygain scanner and the freedb tagger. Nevertheless this app works fine, but as it was said before, theres a lot of room for improvement. Multiple album checking and lack of dummy files are what I consider the most important.

Any upcoming news on FooAccRip ? Our friend odyssey has mentioned a good list of wanted features, and I'd like to know if we can expect them to be taken into consideration (or not) by FooAccRip's developer in a future version. Thank you.

I'd like to add as a 'most-wanted feature' (if it hasn't been mentioned before) the possibility to analyze single-track files in lossless form (FLAC, etc.). FooAccRip could automatically generate all the needed temp files (single WAV + CUE, etc.) so that it would be transparent for the end user.

I personally don't imagine having to convert 1000 or 2000 albums with single-track files to WAC/CUE form... so I hope this request will soon be heard.

Check out new version of CUETools, i added support for accurate rip and embeded flac cuesheets.