Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: APE embedded MD5 checksum question (Read 4317 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

APE embedded MD5 checksum question

I have following problem:
I've always encoded my files to *.ape format and in foobar2000 I've seen "Audio MD5" line:



When I open *.ape in HEX editor and alter the data at offset 36, the verification from cmd line is successful anyway.




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!

APE embedded MD5 checksum question

Reply #1 –
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.
I'm on a horse.

APE embedded MD5 checksum question

Reply #2 –
Quote from: Synthetic Soul on
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.

APE embedded MD5 checksum question

Reply #3 –
Quote from: Synthetic Soul on
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.

Quote
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?

Quote from: bryant on
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)

Quote from: bryant on
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