I have following problem:
I've always encoded my files to *.ape format and in foobar2000 I've seen "Audio MD5" line:
(http://aycu11.webshots.com/image/22290/2003726967438254879_rs.jpg)
When I open *.ape in HEX editor and alter the data at offset 36, the verification from cmd line is successful anyway.
(http://aycu01.webshots.com/image/22280/2002637759045210213_rs.jpg)
(http://aycu25.webshots.com/image/21944/2004328732346860410_rs.jpg)
The question is: How to tell mac.exe to use this field while verifying my *.ape database?
(I know that GUI is performing this test)
It is possible?
Please help!
FYI byte 36 would still be part of the file header, so would not affect the audio data.
As far as I know using the -V switch is the only validation achievable using the command line.
FYI byte 36 would still be part of the file header, so would not affect the audio data.
I think what he means is that he found where in the APE file the MD5 sum is stored and changed it directly. So, this wouldn't change the audio data but should certainly cause the verify to fail (assuming that the MD5 is not stored again somewhere else in the file).
If the command-line verify takes the same time on files encoded "fast" and "insane" then I suspect that it is a "quick" verify that doesn't actually decode the audio. I seem to remember APE having a feature like this and in that case there would be no way to verify the audio MD5 at the same time.
FYI byte 36 would still be part of the file header, so would not affect the audio data.
Yes, I know that, but when I modify it (and then checksum_in_header?checksum_of_audio_data) the GUI shows me corruption and the command line mac.exe doesn't.
As far as I know using the -V switch is the only validation achievable using the command line.
OK, then I must stick with the GUI? There are no other way to check if the checksum_in_header corresponds to checksum of audio block?
So, this wouldn't change the audio data but should certainly cause the verify to fail (assuming that the MD5 is not stored again somewhere else in the file).
It should, but it wouldn't (in case of command-line use)
If the command-line verify takes the same time on files encoded "fast" and "insane" then I suspect that it is a "quick" verify that doesn't actually decode the audio. I seem to remember APE having a feature like this and in that case there would be no way to verify the audio MD5 at the same time.
No! AFAIK command-line verify consists of decoding and only decoding. That is the problem.
Another question. Can you folks assure me that changing ANY byte in audio block would result in decoding failure? If so, there is no need for md5 hashing. The regular mac.exe <filename> -v would detect such change.
P.S. Thank you for fast response.
P.P.S. Tag.exe with "file as source" support works awesome.
P.P.P.S I have some problems with embedding UTF-8 cuesheets by the tag.exe, but it's offtopic here
FWIW, the checksum you're looking at is not for the uncompressed audio data. You can easily verify this for yourself using shntool or some other program.