I just wanted to bring your attention to the foobar2000 homepage.I figured some of you would be interested.

Very cool!

Would be great if it could write them to tags just as CUETools though.

Edit: Also would be nice if it was able to verify multiple albums at a time.

this is so good. i recently ripped a load of cds without setting my offset correctly but i can now verify them with this.

many thanks.

Apologies for the noob question, but would this mean that I be able to produce perfect 1:1 flac copies as per the recommendations made by others users in this thread?

Or is the fact that EAC produces non-compliant cues which preserves pre-gaps the reason for the perfect copy?

Oh my, i was hoping for something like this since so long. Thank you.

Edit: Concerning the poster above me. Accurate rip surely is a useful tool for confirming rips, even though it's very accurate it's not perfect. Imperfect rips -can- pass accurate rip. Also yes, without the EAC's non-compilant CUEs you won't be able to re-write the CD 1:1 including the pregap and possible hidden tracks.

I second this.
It would also be nice to have an automatic offset detection (so rips made without offset correction could still be verified as accurate).

Edit: sorry, I've missed “verbose” option — it seems foo_verified already does this Thanks, Peter!

Why might I be getting different results from foobar and CUETools?

For example, one album foobar says is not in the AR database ; CUETools says it is, and it's verified as accurate.

another example -

foo_verifier 1.1 reports:

CUETools 1.9.5a reports:

Notice the CRC values vs. the Status for the two programs.

CUETools also gives results for a lot more offset variations. In the above example, foobar only offered the 'offset by 6' variation, while CUETools returned 3 other variations.

... Aside: ...
I'd like to request that the verbose report give the Disc ID.

It seems this has to do with CUETools reading the CUE file and knowing about the track one pregap, which means it generates a different Disc ID.


Again, I'd like to request that the verbose report give the Disc ID.

i'd like to report a problem with WMA lossless files.



it says this even with WMA lossless files created using foobar (ripped from cd or converted from other lossless files).

and converting these WMA files to another lossless format verify correctly so i'm guessing this component doesn't like WMA. if it can't be made to work, i think the option to verify should be greyed out like it is with lossy files.

I don't know anything about WMA lossless, but did you use different encoder versions for your WMA lossless files?
I got the same message, when I checked a flac album, for which I edited some tracks and saved them with another encoder version as the original one. Of course, I didn't change the length of the edited tracks.

i tried

WMP11 on xp
using foobar + windows media encoder 9 as per this guide - http://www.hydrogenaudio.org/forums/index....showtopic=47759
WMP12 on windows 2008 R2

all give the same exact error. converting these files to either flac or wav works fine (the rips from WMP aren't accurate but at least i can verify them using this tool )

BTW, i don't use WMA lossless myself. i've just been messing around using this tool to verify rips from various media players.

Thank you very much for this!

Can you please provide a function to write the values as metadata just like ReplayGain? That way we could put an indicator in the foobar UI to show which albums/tracks are verfied as accurate.

I have one more question as well. Is it possible to fix offset variations afterwards?

Thanks to the separate mention of the new features of the verifier component I was made aware of the accurate rip db and checked some of my older rips against it.
After digging into the subject some more I also compared the results of the foobar verifier component with those of cuetools, corrected offsets with cuetools, etc.

In the course of events I have stumbled across some questions.. maybe you can enlighten me?

First some logs.

Original rip scanned with foobar:


Original rip scanned with cuetools (without cue):


Original rip scanned with cuetools (with cue):


Offset corrected rip scanned with cuetools (with cue):


Offset corrected rip scanned with foobar (without cue):


Offset corrected rip scanned with cuetools (without cue and tags):



As already mentioned in this thread without the knowledge of the pregap length foobar (or cuetools for that matter) seems to generate another disc id and checks that id against the accuraterip db, getting of course different results than it would get with the knowledge of the length of the pregap.

Now some questions I wonder about:

1. Is this a design flaw of accuraterip or what is the reasoning behind assigning different ids to discs with exactly the same audio data checksums except for the "digital silence" in the beginning?

2. Am I right with my assumption that the most plausible bit-perfect copy of my original CD would be the one with offsets applied (I have many very old not offset corrected rips I want to "fix" now) according to the results given by cuetools (which has the right knowledge of the pregap when a cuesheet or an EAC log is available)?
I.e.: Which one would be the perfect rip in the above mentioned case? The original rip or the one with an offset of -18 applied?
As it can only be one of the two, how comes the other ones are still flagged as accurately?

3. What is the smartest way to handle pregaps in order to conserve the possibility to create bit-perfect copies of the CDs in the future? Given that foobar is not willing to handle EACs non-compliant cuesheets due to some stricter standard enforcement rules (as older versions were able to process these non-compliant cuesheets) the only other possibility to to get accurate accuraterip (pun intended ) results with foobar would be to process the files with cuetools with gaps appended + HTOA which is not really feasible (at least for me).
Is there any other way I am missing?
How shall I handle pregaps in future rips to avoid this annoying scenario?

4. Am I even able to produce bit-perfect CD copies with my flac files and foobar without foobar able to read my old cuesheets?


Sorry for the wall of text.. but I am a bit confused

(mods, feel free to split this if this is off-topic)
One quick comment on foo_verify: I've noticed that a LARGE number of MP3 files I have (including ones on a somewhat popular site dedicated to free arrangements of video game music) get flagged by Verify with misreported lengths, even on files using CBR encoding (which further confuses me, as I can resolve this issue by running "Fix VBR Header").

Is this normal? If so, is there something I'm missing? If not, is there something I'm missing?

I have a question about the code for this... the output looks to be identical to the output of CUETools, which is open source. Not to accuse, but to question. My goal is not to see the feature removed at all, just wanted to make sure proper credit was given, if it needs to be. you can refer to this post for further exposition:

http://www.hydrogenaudio.org/forums/index....st&p=665603

Btw, thank you to developers of foobar2000 and all of its wonderful plug-ins... you all are awesome for your hard work towards creating and forwarding such a powerful and robust music player.

Did it ever occur to you that there's only a very limited number of ways to represent the AccurateRip data? I'm sure if Peter used open source code, the developer would be credited. He has done it before in the past, and has always given credit where credit was due.

Wishlist:
- scan entire database for albums which are truly identical modulo offset