Answers.Body: <p>Use a vector scope and waveform monitor to judge the difference, not your eyes.  Even if you're doing an XOR comparison, there are cases where your eye isn't enough.</p>
  <p>Here, for example, I've taken this sample footage from BMD's SDK (available <a href="https://www.blackmagicdesign.com/support/" rel="nofollow noreferrer">here</a>):
  <a href="https://i.sstatic.net/8u8aV.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/8u8aV.jpg" alt="enter image description here" /></a> The original is 12bit RAW.  I then transcoded it to H.265, using these settings:
  <a href="https://i.sstatic.net/0CoY2.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/0CoY2.jpg" alt="enter image description here" /></a>
  If I then superimpose the transcoded version over the original, like this:
  <a href="https://i.sstatic.net/LH0FW.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/LH0FW.jpg" alt="enter image description here" /></a>
  ... and set the blending mode to &quot;difference,&quot; a.k.a., &quot;XOR&quot;
  <a href="https://i.sstatic.net/gSA2V.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/gSA2V.jpg" alt="enter image description here" /></a>
  and then use the scopes to analyze the result, you can clearly see that the files are different.
  <a href="https://i.sstatic.net/6sQBT.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6sQBT.jpg" alt="enter image description here" /></a>
  The top half of the above image shows the timeline viewer, and the result of the &quot;difference&quot; comparison.  To the naked eye, it looks black, as if there is no difference.  The bottom half of the above image shows Resolve's waveform monitor.  Here's a detail of that same image:
  <a href="https://i.sstatic.net/MRCz3.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/MRCz3.jpg" alt="enter image description here" /></a>
  There's clearly noise at the bottom end of the signal.  Other types of scopes will tell you different information about the comparison.  For instance, you can use a parade to examine Y'CbCr, and see that the transcode operation has affected the image's chroma more than its luma.   <a href="https://i.sstatic.net/RKqQT.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/RKqQT.jpg" alt="enter image description here" /></a></p>
  <p>I know that you're trying to examine the difference between files that you've <em>copied</em> and not necessarily <em>transcoded</em>, but this example is meant to demonstrate that scopes can give you insight into the type of difference between the files, when that difference is invisible to the naked eye.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-11T17:11:59.043Z
Answers.Text: Any options that don't cost thousands of dollars?
Answers.UserDisplayName: ulatekh
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-13T18:13:56.403Z
Answers.Text: DaVinci Resolve is free, and contains several different types of scopes.  ScopeBox used to be a good standalone scope utility for under $99, but the price has gone up, and the features included in Resolve's free scopes have narrowed the performance gap.
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-13T18:24:48.623Z
Answers.Text: I just double-checked to see if Divergent Media have brought ScopeBox down to a fair price.  Unfortunately, they've opted for a subscription pricing model which costs as much per year as their original software was for a lifetime.  I can't see how their development costs could possibly justify the expense; video signal standards simply don't change that quickly, and that's kind of the point of having a standard!
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-11-21T01:26:10.023Z
Answers.Text: I don't understand why my answer has been downvoted twice, so I've updated it to be more clear.  If somebody could please explain what I'm missing, I'll amend or withdraw.  I do realize that OP is probably looking for a more programatic, bitwise comparison, but since this is *video* stack exchange,  I believe standard video signal analysis tools are a fair answer.  If this question is purely about *file* comparison, maybe *video* production stack exchange isn't the right place for it.
Answers.UserDisplayName: Jason Conrad
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-17T04:47:19.197Z
Answers.LastActivityDate: 2020-11-21T01:15:43.247Z
Answers.LastEditDate: 2020-11-21T01:15:43.247Z
Answers.UserDisplayName: Jason Conrad
Answers.Body: <p>Assuming ffmpeg's result is reliable and it does what you think (I don't know, don't use ffmpeg much), it seems that one of your drives, either the primary one or any of the backup drives is faulty. Use tools that calculate checksums, like md5 or sha or crc32 to verify that the files are indeed different. If the checksums differ you have to find out the faulty drive(s).</p>
  <p>A few faulty bytes in a video are often not visible when watching, maybe the frame will be dropped where the faulty section is, maybe the way the video has been encoded masks the damage.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-07T16:24:15.590Z
Answers.Text: I'm aware that one of the drives is faulty...the question is which one. The differences were first revealed to me with a sha256sum, and verified by a direct binary compare. And if the faulty frame was dropped, it should have shown up when viewing the result of kdenlive's "difference' transition.
Answers.UserDisplayName: ulatekh
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-10-07T11:13:19.083Z
Answers.LastActivityDate: 2020-10-07T11:13:19.083Z
Answers.UserDisplayName: Matt
Body: <p>I back up my data to pairs of external hard drives, and recently (in the process of transferring the contents to larger external hard drives) found that some of the data between them has diverged. Several of them are video files.</p>
  <p>I used <a href="https://stackoverflow.com/a/33567032/603828">this answer</a> to use ffmpeg's ssim and psnr filters to find the differences between the two videos. Once I had a location, I loaded the tracks into <a href="https://kdenlive.org/" rel="nofollow noreferrer">kdenlive</a>, applied the &quot;difference&quot; transition, and seeked to the area where the difference was.</p>
  <p>However, no difference was to be seen! I even extracted the audio, and used audacity to <a href="https://forum.audacityteam.org/viewtopic.php?t=525" rel="nofollow noreferrer">compare differences</a>, and still nothing.</p>
  <p>The files are clearly different; ffmpeg shows that. But if I can't see any differences, I don't know which file to copy over the other file.</p>
  <p>Any idea what I could be doing wrong? This seems too simple to fail.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-07T06:29:18.060Z
Comments.Text: *The files are clearly different; ffmpeg shows that.* --> how?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-07T16:22:32.713Z
Comments.Text: @Gyan: The ssim.log and psnr.log files, generated by the method described above.
Comments.UserDisplayName: ulatekh
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-10-17T04:45:42.890Z
Comments.Text: Why use audacity to compare them?  Isn't this a question about video?  Use video vectorscope, waveform monitor, parade, etc.  That's what they do.  They're built to help you examine a video signal objectively, without the biases and limitations of your eyes and brain.  Lossy compression is designed to exploit those limitations, expressly so that you DON'T perceive a difference.
Comments.UserDisplayName: Jason Conrad
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-11-20T17:53:11.393Z
Comments.Text: @JasonConrad: I was using audacity to compare the audio, to look for differences around the same area.
Comments.UserDisplayName: ulatekh
Tags: <video><ffmpeg>
Title: Can't see differences between videos?
UserDisplayName: ulatekh
ThreadText: # Can't see differences between videos?
  
  (Asked by: username_0 on 2020-10-07)
  
  I back up my data to pairs of external hard drives, and recently (in the process of transferring the contents to larger external hard drives) found that some of the data between them has diverged. Several of them are video files.
  
  I used [this answer](https://stackoverflow.com/a/33567032/603828) to use ffmpeg's ssim and psnr filters to find the differences between the two videos. Once I had a location, I loaded the tracks into [kdenlive](https://kdenlive.org/), applied the "difference" transition, and seeked to the area where the difference was.
  
  However, no difference was to be seen! I even extracted the audio, and used audacity to [compare differences](https://forum.audacityteam.org/viewtopic.php?t=525), and still nothing.
  
  The files are clearly different; ffmpeg shows that. But if I can't see any differences, I don't know which file to copy over the other file.
  
  Any idea what I could be doing wrong? This seems too simple to fail.
  
  **Tags:** video, ffmpeg
  
  > **Comments:**
  > **username_1**: *The files are clearly different; ffmpeg shows that.* --> how?  
  > **username_0**: @username_1: The ssim.log and psnr.log files, generated by the method described above.  
  > **username_2**: Why use audacity to compare them?  Isn't this a question about video?  Use video vectorscope, waveform monitor, parade, etc.  That's what they do.  They're built to help you examine a video signal objectively, without the biases and limitations of your eyes and brain.  Lossy compression is designed to exploit those limitations, expressly so that you DON'T perceive a difference.  
  > **username_0**: @username_2: I was using audacity to compare the audio, to look for differences around the same area.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2020-10-17. Score: 1
  
  Use a vector scope and waveform monitor to judge the difference, not your eyes. Even if you're doing an XOR comparison, there are cases where your eye isn't enough.
  
  Here, for example, I've taken this sample footage from BMD's SDK (available [here](https://www.blackmagicdesign.com/support/)):
  [![enter image description here](https://i.sstatic.net/8u8aV.jpg)](https://i.sstatic.net/8u8aV.jpg) The original is 12bit RAW. I then transcoded it to H.265, using these settings:
  [![enter image description here](https://i.sstatic.net/0CoY2.jpg)](https://i.sstatic.net/0CoY2.jpg)
  If I then superimpose the transcoded version over the original, like this:
  [![enter image description here](https://i.sstatic.net/LH0FW.jpg)](https://i.sstatic.net/LH0FW.jpg)
  ... and set the blending mode to "difference," a.k.a., "XOR"
  [![enter image description here](https://i.sstatic.net/gSA2V.jpg)](https://i.sstatic.net/gSA2V.jpg)
  and then use the scopes to analyze the result, you can clearly see that the files are different.
  [![enter image description here](https://i.sstatic.net/6sQBT.jpg)](https://i.sstatic.net/6sQBT.jpg)
  The top half of the above image shows the timeline viewer, and the result of the "difference" comparison. To the naked eye, it looks black, as if there is no difference. The bottom half of the above image shows Resolve's waveform monitor. Here's a detail of that same image:
  [![enter image description here](https://i.sstatic.net/MRCz3.jpg)](https://i.sstatic.net/MRCz3.jpg)
  There's clearly noise at the bottom end of the signal. Other types of scopes will tell you different information about the comparison. For instance, you can use a parade to examine Y'CbCr, and see that the transcode operation has affected the image's chroma more than its luma. [![enter image description here](https://i.sstatic.net/RKqQT.jpg)](https://i.sstatic.net/RKqQT.jpg)
  
  I know that you're trying to examine the difference between files that you've *copied* and not necessarily *transcoded*, but this example is meant to demonstrate that scopes can give you insight into the type of difference between the files, when that difference is invisible to the naked eye.
  
  > **Comments:**
  > **username_0**: Any options that don't cost thousands of dollars?  
  > **username_2**: DaVinci Resolve is free, and contains several different types of scopes.  ScopeBox used to be a good standalone scope utility for under $99, but the price has gone up, and the features included in Resolve's free scopes have narrowed the performance gap.  
  > **username_2**: I just double-checked to see if Divergent Media have brought ScopeBox down to a fair price.  Unfortunately, they've opted for a subscription pricing model which costs as much per year as their original software was for a lifetime.  I can't see how their development costs could possibly justify the expense; video signal standards simply don't change that quickly, and that's kind of the point of having a standard!  
  > **username_2**: I don't understand why my answer has been downvoted twice, so I've updated it to be more clear.  If somebody could please explain what I'm missing, I'll amend or withdraw.  I do realize that OP is probably looking for a more programatic, bitwise comparison, but since this is *video* stack exchange,  I believe standard video signal analysis tools are a fair answer.  If this question is purely about *file* comparison, maybe *video* production stack exchange isn't the right place for it.  
  
  ---
  
  ### Answer by username_3 on 2020-10-07. Score: 0
  
  Assuming ffmpeg's result is reliable and it does what you think (I don't know, don't use ffmpeg much), it seems that one of your drives, either the primary one or any of the backup drives is faulty. Use tools that calculate checksums, like md5 or sha or crc32 to verify that the files are indeed different. If the checksums differ you have to find out the faulty drive(s).
  
  A few faulty bytes in a video are often not visible when watching, maybe the frame will be dropped where the faulty section is, maybe the way the video has been encoded masks the damage.
  
  > **Comments:**
  > **username_0**: I'm aware that one of the drives is faulty...the question is which one. The differences were first revealed to me with a sha256sum, and verified by a direct binary compare. And if the faulty frame was dropped, it should have shown up when viewing the result of kdenlive's "difference' transition.  
  
  ---
  
  