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: Why does foo_bitcompare do literal bit-comparison when lenghts differ? (Read 1687 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

The 'problem' is of course that I sometimes get a big job wrong, and after working on it for a long time, it finally tells me that no pair matches, because all are different length.  I would have wished for it to scan through and tell me in seconds that I messed up.

Is there any good reason (bar Peter's priorities, can't complain when I get it for free ...) for this behaviour? E.g., could it be so that the only way to compare non-compliant files, is to decode through and see how long the decoded stream actually is ...?


BTW, I would also wish for foo_bitcompare to warn me if I try to compare a file to itself.  Yeah I could sometimes use some foolproofing.

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

Reply #1 –
I wouldn´t like any filter on such a verification tool whose result needs to be trusted.

I´d rather see a small warning in the progress bar window:
Length mismatch from file header. Double checking through decoding...

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

Reply #2 –
MSDOS/CMD.exe fc (/b) supported comparing files of different lengths. Upon finding that the files are identical up to the length of the shortest file, it would report that files are different only by a length mismatch.

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

Reply #3 –
In certain cases the length information is reported inaccurately or incorrectly due to file format limitations (WMA), truncated or otherwise corrupted file; the file would have to be decoded completely to know the real duration. The idea was to make the binary comparator work in such cases anyway. Maybe an advanced preferences toggle can be added for this.
Microsoft Windows: We can't script here, this is bat country.

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

Reply #4 –
@ Peter: If you are to implement some more advanced features, why not allow an option to speed up the process by stopping a track pair at first difference - in case I am not interested in the magnitude of the error?
You could then consider a tolerance (stop first time the peak diff exceeds a certain threshold), to keep floating-point roundoff errors that are not really differences in data from being reported as merely 'different' without any quantitative information.


Quote from: mezenga on
I´d rather see a small warning in the progress bar window:
Length mismatch from file header. Double checking through decoding...


Good idea. Suggested workflow (toggle-able in advanced preferences):

(I) FOR each pair, check length; IF matches THEN bit-compare ELSE set aside for later; NEXT pair

(II) Output a 'Now comparing suspicious lengths' dialogue with button 'Export preliminary results' (to a report which says X out of T files suspected different length, now checking; Y out of T files differ; Z out of T files identical') and a Cancel button

(III) Until user cancels or job done, run through a bit-compare for each pair in the 'aside for later' pair set.

Why does foo_bitcompare do literal bit-comparison when lenghts differ?

Reply #5 –
A year and a half old thread, but:

Quote from: Peter on
In certain cases the length information is reported inaccurately or incorrectly due to file format limitations (WMA), truncated or otherwise corrupted file; the file would have to be decoded completely to know the real duration. The idea was to make the binary comparator work in such cases anyway. Maybe an advanced preferences toggle can be added for this.


It seems to me that if I apply the Fix VBR MP3 header, then the new file can be reported to differ in length from the old. A bit inconsistent behaviour, maybe? Or not?