Efficient Forged Atomic Parallel

MergeQaiPro manual Comparing byte by byte
Contents

Comparing byte by byte

Some files are neither text nor image — or look the same as text and yet are not. The Binary view shows both files as a hex view: byte by byte, with address, hexadecimal values and the readable equivalent beside them. It thus shows differences that neither a text nor an image comparison sees.

Below the view stand the key figures: both file sizes and the number of deviating bytes, plus “first deviation @ 0x0004A2” — the point from which the files diverge. If they are the same, MergeQaiPro reports “Files are identical”.

Screenshot 20: Binary comparison as a hex view with deviating bytes highlighted, the map along the right edge and the footer “… deviating bytes · first deviation @ …”
Fig. 20 — Binary comparison as a hex view with deviating bytes highlighted, the map along the right edge and the footer “… deviating bytes · first deviation @ …”
ℹ️ No size limit
While you scroll, the view only ever fetches the lines currently on screen — so a file does not have to fit into memory to be examined. Even images of several gigabytes can be inspected in full; the comparison runs in the background and shows its progress.

10.1 Jumping to the differences

Two files can deviate in tens of thousands of bytes — scrolling there by hand is hopeless. The arrows and in the toolbar therefore jump from one range of deviation to the next; the counter between them shows which one of how many has been reached. A range is not a single byte but a contiguous stretch of deviating bytes — exactly what one perceives as “one change”.

Along the right edge lies the map: a narrow strip depicting the entire file, showing every deviation as a mark. At a glance it answers what no number can — whether the differences are scattered across the file, cluster at the front, or only start from a certain point. The bright frame inside it marks the currently visible section; a click or drag in the map jumps there.

💡 What the pattern reveals
Two photos that are identical up to the end of the header and then deviate completely have been encoded twice, separately — not modified afterwards. A file with just a few scattered marks, by contrast, was deliberately touched in a handful of places.

10.2 Jumping and searching deliberately

If you already know the spot, type it into the left field and press Enter. An offset is expected: hexadecimal as 1A2F or 0x1A2F, decimal with a leading #, i.e. #6703. The view scrolls there and marks the byte.

The right-hand field searches for content. With the Hex switch engaged, the input counts as a byte sequence — FF D8, FFD8 and 0xFF,0xD8 all mean the same. Without it, the text you typed is searched for, such as JFIF or PK. Each further Enter jumps to the next match; past the last one the search starts over from the beginning.

10.3 Selecting and copying bytes

A click in the hex or text column selects a byte, Shift+click extends the selection up to it, and dragging with the mouse button held does the same. The footer names the selected range and its length. Both sides show the same selection — after all it is the same section of the file.

The button puts the selection on the clipboard — in three formats:

FormatResultWhat for
As hex41 42 00 FFhanding over to a hex editor, noting it in a bug report
As textAB..pulling out the readable parts — anything unprintable becomes a dot
As C arrayunsigned char daten[4] = { … };pasting straight into source code, e.g. as a test record

10.4 Taking a file over — and why only whole

The two buttons and replace one file entirely with the other. MergeQaiPro asks first and names both files; afterwards it compares anew and the view reports “Files are identical”.

Individual bytes deliberately cannot be transferred. In a text comparison that is harmless because lines stand on their own: a line taken over leaves the rest of the file valid. With binary files that is almost never true — and a transfer that renders the target file unusable in most cases would be worse than none at all.

What stands in the wayConsequence
Length fields and reference tables (ZIP, PDF, EXE)point at fixed positions — inserted bytes shift everything behind them
Checksums (PNG, many containers)no longer match after the change, and the file is rejected
Compressed streams (JPEG, PNG, ZIP)carry meaning bit by bit — one byte in the middle destroys everything after it
Differing file lengths“overwrite” and “insert” would give two entirely different results
⚠️ Taking over cannot be undone
The target file is replaced, not moved to the recycle bin. Where the previous state matters, make a backup beforehand.
An unhandled error has occurred. Reload 🗙