Odd anomaly in verification

[JeremyP]

Version 12.2.0.2 XP SP2 all updates etc

Batch program used to convert 2 directories of shn to lossless wma
Final shn file in second directory gave a verification error.

Ran conversion again, this time on JUST the file that had previously given the error - no error. Did it on a hunch.

So - a) it seems your verification needs a bit of work? & b) it would be good to have more detail ABOUT the errors, rather than just that there has been one. It is disconcerting if an md5 check has been OK, and then dbpoweramp says there is an error.

Love the program, by the way!

[Spoon]

WMA Lossless has been proven to have issues sometimes, ie it is not lossless 100% of the time, so it is likely the verification stage was correct.

[JeremyP]

WMA Lossless has been proven to have issues sometimes, ie it is not lossless 100% of the time, so it is likely the verification stage was correct.

Conversion involved was from flac to wma, not from wma to whatever. So I think the above does not apply?

[Spoon]

Going to wma lossless is the problem.

[JeremyP]

Going to wma lossless is the problem.

But the real inconsistency - and which is what brought it to my attention - is that I am given an error in the batch convert, and then reconvert in non-batch mode, and am NOT given an error. That's plain wrong - either there is an error (in which case it would be good to know WHAT that error is!), or there isn't, yes? The results conflict.,

[Spoon]

Verify does just that verifies, you might think that there could be an error in the verify code, but it is a very simple CRC and compare at the end, or there might be an error in the WMA Lossless compression which internally sends the compressed data onto multiple threads to get a speed advantage on multicpu systems (we do not do this Microsoft do).

[JeremyP]

Verify does just that verifies, you might think that there could be an error in the verify code, but it is a very simple CRC and compare at the end, or there might be an error in the WMA Lossless compression which internally sends the compressed data onto multiple threads to get a speed advantage on multicpu systems (we do not do this Microsoft do).

OK. But why then does it verify OK in one mode, and not in the other (batch) - that implies the conversion behaves differently - at times? - in batch and non-batch. BTW, I left a career in IT - analysis and software design and production - last year, after 25 years in, so am well familiar with the arcana of software and the testing environment.

Bottom line - if an error is flagged when converting in batch mode, it should be flagged in non-batch mode! Np two ways about it. And the codecs are approved to industry standards, so I have to say, I am sure the lossless wma is as it says on the can - lossless.

[Spoon]

Batch or single conversion both call the same program (called CoreConverter) to do the work, this is a GUI less program.

Wether is it batch or not I do not think effects it, unless you can bet batch conversions to fail all the time.

[Spoon]

See here for an exmaple of a file WMA lossless fails with:

http://www.hydrogenaudio.org/forums/...opic=59764&hl=

[JeremyP]

See here for an exmaple of a file WMA lossless fails with:

http://www.hydrogenaudio.org/forums/...opic=59764&hl=

Granted. Still doesn't explain why the verification doesn't always fail. Either the file is wrong or it is not. It can't be wrong one time, then OK another, can it?!

[Greybeard]

This past weekend I came to the shocking realization that I did a bad thing by ripping my over 400 disc CD collection to lossless WMAs using Windows Media player. So I went looking for a better way and hit on dBpoweramp 12.4 which I am 99% certain I will be regestering. After reading this thread I thought I should share one of the things I encounterd.

Without trying to justify why, I am continuing to rip to lossless WMAs. After only a couple of disc I ran into one track that ripped "Accurate (confidence 4)" but failed verification. Tried several more times with exactly the same result. Everything I tried resulted in a verify error on the WMA conversion. Following is a description of the last things I tried.

1. Ripped track to WAV file using DSP filter to remove all tags.
2. Converted WAV file to lossless WMA file.
3. Converted WMA back to WAV.
4. Observed that file from 3 was 48 bytes shorter than the original WAV file.
5. Used FC /b to compare 1 and 3. Result was two bytes different near the front of the file (probably length codes) and the rest of the file matched exactly except for the 48 bytes missing at the end.
6. Converted WAV file to APE.
7. Converted APE file to WAV.
8. File 1 and 7 matched exactly.
9. Converted APE file to WMA.
10. Converted WMA (from the APE) to WAV.
11. File 10 and 3 matched exactly. Again the file from 10 was 48 bytes short of the original WAV file but exactly the same as the file from 3.

Conclusion: For some reason the conversion to WAV is lopping 48 bytes off the end of the original WAV file. I assume it is just a coincidince that the CD drive offset is also 48 bytes.

Even though I will play the WMA that is missing 48 bytes, I kept the APE file (it seems to store a lot more tags than a WAV file) so that I can convert it to WMA in the future in the event MS ever fixes the codec. I continue to rip to WMA with the confidence that dBpoweramp will alert me if there are any more conversion problems but have not run into any more after 15 more discs.

I am getting to really like dBpoweramp. At this point I see no reason to even try anythig else.

[Spoon]

Just a co-incidence that your drive offset is 48 and 48 bytes are missing (if you ask me, your drive could have a -22 offset and WMA would still loose data).