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: Bitcompare offset correction might use some improvement? (Read 778 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Bitcompare offset correction might use some improvement?

Not sure if arbitrary corner cases are worth that much developer time, but here is the situation:
* There is a difference mid-stream. The beginning and the end are bit-identical
* fb2k aligns the offset to ... something else. Obviously not to what minimizes difference peaks.

Log extract in point. Actually I have first applied the right offset and then clipped down to 100 seconds to get the point ahead: there are three seconds around midway where the streams differ. So now offset is already "optimal":
Code: [Select]
Compared 4410000 samples.
Differences found: 285762 values, 0:53.488209 - 0:56.728186, peak: 1.914429 (+5.64 dBTP) at 0:55.929252, 2ch
Channel difference peaks: 1.890472 (+5.53 dBTP) 1.914429 (+5.64 dBTP)
File #1 peaks: 0.977325 (-0.20 dBTP) 0.977325 (-0.20 dBTP)
File #2 peaks: 0.977325 (-0.20 dBTP) 0.977325 (-0.20 dBTP)
Detected offset as -588 samples.

Comparing again with corrected offset...
Compared 4409412 samples, with offset of -588.
Discarded 588 leading null samples from file #1.
Discarded 588 trailing samples containing non-null values from file #2.
Differences found within the compared range: 8527539 values, 0:00.042336 - 1:39.986644, peak: 1.954529 (+5.82 dBTP) at 1:37.195465, 2ch
Channel difference peaks: 1.954498 (+5.82 dBTP) 1.954529 (+5.82 dBTP)
File #1 peaks: 0.977325 (-0.20 dBTP) 0.977325 (-0.20 dBTP)
File #2 peaks: 0.977325 (-0.20 dBTP) 0.977325 (-0.20 dBTP)