"FLAC: Audio File Passed Verification" - what about when it doesn't pass?

[mville]

The behaviour seems to be random. There's no discernible pattern that I can see, and it is different tracks which are not logged as verified when I re-rip the same disc.

I believe it's a bug in the software and wouldn't waste any more of your time on it.

I haven't noticed this behaviour, but I have never really looked for it, assuming that if there were verification errors, they would be reported. Running Test Conversion on my flac library, post rip, alerts me to any corruption issues.

[Max Dread]

OK, fair enough.

I couldn't see a sub-forum for reporting potential bugs. @Spoon, if you read this are you able to confirm it logged as a bug? Might it be addressed in the next release? Or should I start a new thread to suggest this might be a bug?

Thanks for all your help mville.

[Spoon]

As already mentioned, the function does not function as you expect.

FLAC has never had a bug in the library where the code has corrupted the file, so you are checking for disc errors, however this verify function will never detect a HDD error because Windows caches the file. The re-read of the data comes from memory, not the HDD. The only way to correctly check your library, is to reboot your PC and convert the whole music folder to 'Test Conversion'

[Max Dread]

Thanks for the reply Spoon, and nice to hear from you.

I must admit that I do not fully understand what you are saying though. I can confirm that even when the verify message is NOT present in the log for a track after ripping to FLAC, the same ripped track passes the "Test Conversion" without issue. So that's good...

What I do not understand is what function the "Verify Written Audio" option in the FLAC encoder has? What is it for? I presumed it was an extra level of security which checks that the rip from CD to FLAC (or perhaps just the FLAC file itself) was all good with no errors. And on top of that, that the log reported the results. So if the log is NOT telling me that the track has passed verification, how I am to interpret that? Why are some tracks passing verification and others not? What is the significance? It must be there for a reason I presume?

I'm sorry for all the questions, especially in light of the fact that the said tracks are passing the "Test Conversion" and are therefore seemingly fine.

But I still don't get this anomaly, and - as stupid as it might be - I don't like the fact that some tracks are being reported as passed verification, whilst others are not.

Just for the record, I'm using a Plextor PX-716AL to rip. I have "Drive Read Cache" set to None, and "Clear Read Cache with FUA" is ticked. Just thought I'd mention that in case it has any relevance to what you said regarding caches and memory.

Cheers

[Max Dread]

Any further thoughts please Spoon?

[Spoon]

The verify is a feature to make sure there is not an error in our code, I should perhaps remove it as it does not do what people expect (it is not possible to do as people expect with Windows file caching).

[Max Dread]

So in what circumstances might there be "an error in our code"?

And if there were, what would happen?

And if some tracks in my rips don't have "an error in our/the code", why are they not being logged as verified?

But forgetting all that for a moment, I guess my bottom line question is: why do some tracks report as being verified and some not? Surely that must signify something or else be a bug/error? Otherwise what's the point?

I'm sorry to keep harping on but I just don't get it!

[garym]

Otherwise what's the point?

Spoon is saying that this is not doing what you and others (including me) thought the function was doing. Consequently there "is no point" and in fact, he points out that he should probably remove even reporting this, as it only confuses users (just as it has confused you).

[Max Dread]

I see what you're saying. But if it is not doing the function we both thought it was doing, what function IS it doing? That's what I'm interested to know. Although saying that I did not even have a guess as to what function it might be doing!

So it would be good to know....

[Dat Ei]

Developers write sometimes code to check and verify their own assumptions and their own code. In this case that code does not work as the developers thought it would work. So the code to check the main code is faulty or behaves faulty because of the Windows caching mechanisms. Forget about those message. If you like to check your audio files, do as Spoon said and run a separate check routine after the ripping.


Dat Ei

[Max Dread]

The help file / manual has this to say:

"After Encoding Verify Written Audio - once compression is complete the compressed audio will be read and compared to the source, verifying the compression is without error (hard disk, or very unlikely codec induced)."

[Jailhouse]

But if it is not doing the function we both thought it was doing, what function IS it doing?

When there is no report that a file passed verification, it could well be because the function has not run at all. Whether it runs or it doesn't, though, it has no effect in terms of ripping results. The fact that your files lacking verification reports have all passed Test Conversion checks is proof.

As someone who has missed many meals and much sleep over the years while working hours on unresolved problems, I understand that you want an answer. And if this behavior had a negative impact on my rips, I'd be demanding one myself. But it's merely a random lack of information that ultimately means nothing to us as users, whether we know or don't know why it happens.

My advice: Untick "Verify Written Audio" and run Test Conversion on your files as you see fit.

[Max Dread]

Thanks Jailhouse for the info and the reassurance. It is nice to know I'm not the only person out there who stresses over these minor things. I guess I'll just do as you say and carry on regardless.

But it is strange that this is happening on my system, but not to anyone else who has contributed to the thread... Do your rips have the log entry missing (presuming you use FLAC that is)? I do wonder why this should only be happening to me if it is a more general thing.

And I still cannot reconcile Spoon's explanations with the entry from the manual (quoted above in post *56). Perhaps someone can explain how the two are saying the same thing, and I might then be able to rest a little more easy

EDIT: It's a bit too early to say this conclusively, but what I have noticed is a pattern whereby when I leave the PC alone while ripping, all of the logs are there at the end. If I use the PC whilst ripping (for things like using the internet, write word docs; basic stuff like that) that's when there seems to be tracks with missing logs.

[Dat Ei]

But it is strange that this is happening on my system, but not to anyone else who has contributed to the thread... Do your rips have the log entry missing (presuming you use FLAC that is)? I do wonder why this should only be happening to me if it is a more general thing.

Maybe other people don't care at all about that missing message? Maybe other people trust in AccurateRip? Maybe other people trust in the results of the test conversion? Maybe other people trust in Spoon's statements?


Dat Ei

[Max Dread]

Maybe other people don't care at all about that missing message? Maybe other people trust in AccurateRip? Maybe other people trust in the results of the test conversion? Maybe other people trust in Spoon's statements?


Dat Ei

Maybe other people are not having the same problem and it is therefore irrelevant to them?

If you guys or any other users were coming on here to say that the same thing was happening and so we were all in the same boat, then I'd be fine and dandy to ignore.

Am I missing something in the manual section on this function? It says "once compression is complete the compressed audio will be read and compared to the source, verifying the compression is without error". Is that incorrect?