VideoHelp Forum
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 46
Thread
  1. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    No, this isn't gamemanico, gamemanico2, samus87, et.al. Though it's inspired by his insane, endless postings at DigitalFAQ.

    I'm not talking about disc verify, immediately after the burn and I'm not talking about tests like Nero does, which only test the readability of the disc and data.

    I'm asking about actual HASH verification of the disc files against the original files. The only thing I can think of is to copy the data from the disc to your hard drive and run a file compare between the two (copied and original). It seems to me that even if there was a way to do this as direct compare against the files on the disc itself, a mismatch could be the result of a read or transmission error from the drive itself.
    Quote Quote  
  2. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Doesn't IMGBURN to a compare against the source data when you do a burn/verify?
    Quote Quote  
  3. Member
    Join Date
    Jul 2008
    Location
    Old Dominion
    Search Comp PM
    Doesn't ImgBurn provide a source/destination hash comparison?
    Quote Quote  
  4. Originally Posted by lingyi View Post
    I'm asking about actual HASH verification of the disc files against the original files. The only thing I can think of is to copy the data from the disc to your hard drive and run a file compare between the two (copied and original).
    There's no need to copy the disc contents to the hard drive. You can run the file compare directly on the disc. A batch file calling the command line FC/B will work.

    Originally Posted by lingyi View Post
    It seems to me that even if there was a way to do this as direct compare against the files on the disc itself, a mismatch could be the result of a read or transmission error from the drive itself.
    You can run the test again.
    Quote Quote  
  5. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Imgburn verify is only immediately after the burn [Yes, rereading my OP, that's what I asked, but not what I meant. Sorry] . I'm asking about after the burn is completed and verified. To test file integrity after the disc has has been in storage.
    Last edited by lingyi; 12th Oct 2020 at 22:36.
    Quote Quote  
  6. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    Originally Posted by lingyi View Post
    I'm asking about actual HASH verification of the disc files against the original files. The only thing I can think of is to copy the data from the disc to your hard drive and run a file compare between the two (copied and original).
    There's no need to copy the disc contents to the hard drive. You can run the file compare directly on the disc. A batch file calling the command line FC/B will work.

    Originally Posted by lingyi View Post
    It seems to me that even if there was a way to do this as direct compare against the files on the disc itself, a mismatch could be the result of a read or transmission error from the drive itself.
    You can run the test again.
    Interesting. I vaguely knew about File Compare, but didn't know it would work on optical discs [and not text files]. I'm assuming it could be used to compare two burned discs against each other.

    What I like about is that it performs multiple verification tasks at once. File integrity, read integrity and drive transmission integrity.
    Quote Quote  
  7. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Tried it on a executable on two different hard drives and it works. The only thing missing is a HASH that can be saved.
    Quote Quote  
  8. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    The olde and goode PRASSI Ones can do file compares too.
    Yes, it works fine on Windows 7, even without that crazy "fuzzy-logic" driver...
    Image Attached Thumbnails Click image for larger version

Name:	prassi-ones-compare-files.png
Views:	77
Size:	11.5 KB
ID:	55471  

    "Programmers are human-shaped machines that transform alcohol into bugs."
    Quote Quote  
  9. Originally Posted by lingyi View Post
    File Compare... I'm assuming it could be used to compare two burned discs against each other.
    If you have two drives. Or copy one to the HD first.

    Originally Posted by lingyi View Post
    What I like about is that it performs multiple verification tasks at once. File integrity, read integrity and drive transmission integrity.
    What it doesn't tell you is how easily the disc was read. Drives and the OS will retry when there are errors. A marginal sector on a disc might not read until after 10 retries -- you wouldn't be told about that by FC or the OS. Drives usually make a distinctive noise when that happens though. A total failure to read a sector will be reported as an error.
    Quote Quote  
  10. Various utilities can run checksum calculations, allowing to store them for future reference. I use three, depending on the situation : HashTab for a single file, MD5Checker for a bunch of files in a single folder, and md5deep for a large number of files in several folders / subfolders. HashTab adds a tab to the “Properties” window. MD5Checker is a simple GUI, and saves lists in a simple format ([MD5]|[file path + name]. And md5deep is a command line utility, with more options. I generally use it with this command :
    Code:
    md5deep64 -r -z -t -e -j1 "H:\[main folder path]\*" > "G:\md5deep [main folder path] [date].txt"
    -r => recursive (processes all subfolders)
    -z => display file sizes
    -t => display creation times
    -e => show estimated time remaining
    -j => number of threads
    The last one is important, as I found out that running a command without this switch would use all available threads (8 for an Intel i7 6700K CPU), which means reading several files simultaneously, which means that the HDD's heads have to run like crazy from one file to the other, which considerably slows down the process and stresses the drive for no reason (it may be different on a SSD, haven't tested). It also has another adverse effect, which is that files can be processed in a different order in the source and destination folder. With -j1, each file is read sequentially, which maxes out the drive's throughput (if the file is not fragmented), and files are read in a consistent order. That way, when running two commands simultaneously, one for the source folder and one for the destination folder (provided that they are not located on the same physical device, otherwise, for the same reason, the two analyses should not be launched simultaneously), the resulting text files should be identical, except for the files' paths. So I open one with Notepad2, for instance the "destination folder" text file, replace for all lines the path of the "destination" main folder with the path of the "source" main folder (for instance replace each instance of "E:\DVD 20150512\" with "D:\" if D: is the optical drive and E: the partition where the DVD's contents are stored), then save it with a new name. Then (with either HashTab or MD5Checker) I check the MD5 of the "source" text file and the edited "destination" text file (with paths matching the "source" text file) : if the values are the same, it means all the individual files' MD5 values are identical, and therefore that all files are identical between the source folder and the destination folder. (I've done this for folders with thousands of files and hundreds of gigabytes.) In case of discrepancy, I would open both files in WinMerge and check which lines are wrong, then open each pair of corresponding files in WinHex to examine which one is corrupted — as it could be either : it is possible, although less likely, that a file which was stored on a DVD-R 5 years ago is still flawless, while the same file stored on a HDD has been corrupted at some point.

    It can also be very useful to have a reference of checksums in a data recovery situation — I just wrote this post reporting my experiences on that matter.
    Last edited by abolibibelot; 13th Oct 2020 at 01:05.
    Quote Quote  
  11. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Originally Posted by abolibibelot View Post
    Various utilities can run checksum calculations, allowing to store them for future reference. I use three, depending on the situation : HashTab for a single file, MD5Checker for a bunch of files in a single folder, and md5deep for a large number of files in several folders / subfolders. HashTab adds a tab to the “Properties” window. MD5Checker is a simple GUI, and saves lists in a simple format ([MD5]|[file path + name]. And md5deep is a command line utility, with more options. I generally use it with this command :

    Code:
    md5deep64 -r -z -t -e -j1 "H:\[main folder path]\*" > "G:\md5deep [main folder path] [date].txt"
    -r => recursive (processes all subfolders)
    -z => display file sizes
    -t => display creation times
    -e => show estimated time remaining
    -j => number of threads

    The last one is important, as I found out that running a command without this switch would use all available threads (8 for an Intel i7 6700K CPU), which means reading several files simultaneously, which means that the HDD's heads have to run like crazy from one file to the other, which considerably slows down the process and stresses the drive for no reason (it may be different on a SSD, haven't tested).

    It also has another adverse effect, which is that files can be processed in a different order in the source and destination folder. With -j1, each file is read sequentially, which maxes out the drive's throughput (if the file is not fragmented), and files are read in a consistent order.

    That way, when running two commands simultaneously, one for the source folder and one for the destination folder (provided that they are not located on the same physical device, otherwise, for the same reason, the two analyses should not be launched simultaneously), the resulting text files should be identical, except for the files' paths.

    So I open one with Notepad2, for instance the "destination folder" text file, replace for all lines the path of the "destination" main folder with the path of the "source" main folder (for instance replace each instance of "E:\DVD 20150512\" with "D:\" if D: is the optical drive and E: the partition where the DVD's contents are stored), then save it with a new name.

    Then (with either HashTab or MD5Checker) I check the MD5 of the "source" text file and the edited "destination" text file (with paths matching the "source" text file) : if the values are the same, it means all the individual files' MD5 values are identical, and therefore that all files are identical between the source folder and the destination folder. (I've done this for folders with thousands of files and hundreds of gigabytes.)

    In case of discrepancy, I would open both files in WinMerge and check which lines are wrong, then open each pair of corresponding files in WinHex to examine which one is corrupted — as it could be either : it is possible, although less likely, that a file which was stored on a DVD-R 5 years ago is still flawless, while the same file stored on a HDD has been corrupted at some point.

    It can also be very useful to have a reference of checksums in a data recovery situation — I just wrote this post reporting my experiences on that matter.
    Good info. I broke it up to reduce the hard to read wall of text.
    Quote Quote  
  12. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    To be clear, does this work with optical discs in the drive? (Oooof...I just sounded like gamey right now). You state that it does, but have you done this?

    I know I could do it myself, but this is a what could be done question for me. I would never bother to do it myself especially with the necessary setup and I don't have anything but the movies on my DVDs/Blu-Rays and the rips are all customized, so the HASH would fail.
    Quote Quote  
  13. Good info. I broke it up to reduce the hard to read wall of text.
    Thanks. Sorry.

    To be clear, does this work with optical discs in the drive? (Oooof...I just sounded like gamey right now). You state that it does, but have you done this?
    Are you talkin' to me ?

    I haven't done this with optical disks specifically (or I don't think I have) as I haven't used optical disks for storage in a long time (and I have a still unsolved issue with my DVD drive disappearing from my system whenever its tray is ejected — I kinda gave up on it for now, as I rarely ever use it anymore, only for the very occasional DVD burn to share files with someone who doesn't live nearby), but it should work. The only caveat is that optical drives are excruciatingly slow compared with current HDDs, even more so with SSDs.

    I use this method when transferring a large amount of data from a HDD to another, to ensure that the transfer went flawlessly before deleting files on the source drive (I beame a bit paranoid when it comes to data integrity, never taking it for granted, as for instance I've sometimes found a couple files on a drive or its backup that were totally empty, although the drives themselves had no physical issue according to their SMART status and no error was reported during the transfer, I have no idea how it happened but it happened, and if it could happen once it can happen any time, SNAFU is the main rule in the computer world as it is in the general world — after all, we as a species are the outcome of multiple copy errors, although I don't know it it's for better or worse, perhaps the Earth would have been better hoof stopping evolution at the horse).

    (Uh-uh-uh, that's a good one ! I'm giggling alone in front of my computer screen right now... that'll probably be the only giggle of the day, sadly...)
    Last edited by abolibibelot; 13th Oct 2020 at 03:18.
    Quote Quote  
  14. Member
    Join Date
    Feb 2006
    Location
    United States
    Search Comp PM
    Originally Posted by lingyi View Post
    No, this isn't gamemanico, gamemanico2, samus87, et.al. Though it's inspired by his insane, endless postings at DigitalFAQ.

    I'm not talking about disc verify, immediately after the burn and I'm not talking about tests like Nero does, which only test the readability of the disc and data.

    I'm asking about actual HASH verification of the disc files against the original files. The only thing I can think of is to copy the data from the disc to your hard drive and run a file compare between the two (copied and original). It seems to me that even if there was a way to do this as direct compare against the files on the disc itself, a mismatch could be the result of a read or transmission error from the drive itself.
    is this what your looking for ?? - https://superuser.com/questions/79149/how-to-check-dvd-integrity-at-max-read-speed-of-dvd-writer
    Quote Quote  
  15. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Unfortunately no. That doesn't work for the scenario I'm thinking of as it requires forethought of performing a HASHcheck beforehand and burning it to the disc. I'm asking for something that can check and generate a HASH after the disc is burned.

    Here's gamey's situation that prompted the question.

    Most of us are familiar with his obsession with preserving his DVDs. One of his latest threads at DigitalFAQ (Yep! He's still there!) started as a question, if his hard drive that has a couple hundred unallocated bad sectors was still good. After the usual back and forth telling him that it wasn't, I explained that the data he burned on his precious discs could be corrupt because of unmarked bad sectors. This lead to how could he verify the data on his discs were good. I explained that the only way he could do that would be to copy the files from his discs and perform a compare against known good files not on his corrupted hard drive.

    Then he dropped the bombshell. He not only deleted the files on the bad drive, but he's unable to get them again! Back and forth with him asking if he could compare the four disc copies he has against each other and my explaining that all that would do is prove that all four copies have the same possibly bad data. *SIGH*
    Quote Quote  
  16. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Originally Posted by abolibibelot View Post
    Good info. I broke it up to reduce the hard to read wall of text.
    Thanks. Sorry.

    To be clear, does this work with optical discs in the drive? (Oooof...I just sounded like gamey right now). You state that it does, but have you done this?
    Are you talkin' to me ?
    .

    LOL. Exactly what I thought when I read your question! Love the cap!

    Yes, I'm interested if the programs you listed work with optical discs. I read somewhere that optical discs don't lend themselves to file checking like hard drives, which is why I told gamey to copy the contents of his discs to his hard drive. But if File Compare works with optical discs, I'm assuming (always dangerous <GRIN>) your programs should too.
    Quote Quote  
  17. Most of us are familiar with his obsession with preserving his DVDs. One of his latest threads at DigitalFAQ (Yep! He's still there!) started as a question, if his hard drive that has a couple hundred unallocated bad sectors was still good. After the usual back and forth telling him that it wasn't, I explained that the data he burned on his precious discs could be corrupt because of unmarked bad sectors. This lead to how could he verify the data on his discs were good. I explained that the only way he could do that would be to copy the files from his discs and perform a compare against known good files not on his corrupted hard drive.
    Another method I improvised once was to use ddrescue's “generate” feature with individual files as sources (instead of whole drives or partitions or image files as it's designed to deal with{*}) to then get a visual presentation of totally empty sectors using ddrescueview (as usually unreadable / corrupted sectors default to empty). It's not as reliable as a direct comparison with a known good file or a checksum comparison, but with no such reference it can work well enough to assess how damaged a binary file is (as binary files are usually full of “something”, with very few totally empty sectors).


    {*} The “generate” feature is normally meant to recreate a makeshift logfile, a plain text file which allows ddrescue to keep track of which areas from a (typically defective) storage volume have already been recovered and which remain to be parsed, when said logfile has been lost, or hasn't been created in the first place (as it has to be specified in the command line), in order to avoid starting the recovery all over again (thus needlessly stressing an already flailing drive). It marks all empty sectors in the current recovery (either on a physical device or as a volume image) as “non-tried” (therefore only sectors which were legimately empty on the source drive will be parsed again in the later stages of the recovery). And when a logfile (be it created normally during a ddrescue recovery or generated through this “generate” mode) is loaded into ddrescueview, it displays a map showing green blocks for “rescued” areas, and grey blocks for “non-tried” areas.
    Quote Quote  
  18. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Interesting, this may be helpful in the situation I gave above. However, it doesn't address corrupted data written to the disc, which to my understanding can only be discovered by direct comparison to the original file or by matching a saved HASH.
    Quote Quote  
  19. Member
    Join Date
    Feb 2006
    Location
    United States
    Search Comp PM
    Originally Posted by lingyi View Post
    Interesting, this may be helpful in the situation I gave above. However, it doesn't address corrupted data written to the disc, which to my understanding can only be discovered by direct comparison to the original file or by matching a saved HASH.

    VSO inspector - http://www.vso-software.fr/products/inspector/inspector.php
    Quote Quote  
  20. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Thank you. But (Gaaaah...channeling gamey!), this just checks disc integrity, not the actual files. What I'm asking about, and has been addressed to an extent by jagabo and possibly to the full extent by abolibibelot, is how to verify that the files on the disc are the same as the original, bit for bit, including being able to generate a HASH file.
    Quote Quote  
  21. Member
    Join Date
    Feb 2006
    Location
    United States
    Search Comp PM
    Originally Posted by lingyi View Post
    Thank you. But (Gaaaah...channeling gamey!), this just checks disc integrity, not the actual files. What I'm asking about, and has been addressed to an extent by jagabo and possibly to the full extent by abolibibelot, is how to verify that the files on the disc are the same as the original, bit for bit, including being able to generate a HASH file.
    this ?? - https://superuser.com/questions/220082/how-to-validate-a-dvd-against-an-iso
    Quote Quote  
  22. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Yes. Thank you. That seems like it would work since it seems to be able to work with DVD to DVD comparisons.

    Thank you all of your suggestions. Good to know that there are alternatives to copying the files to the hard drive.
    Quote Quote  
  23. Originally Posted by lingyi View Post
    Thank you. But (Gaaaah...channeling gamey!), this just checks disc integrity, not the actual files. What I'm asking about, and has been addressed to an extent by jagabo and possibly to the full extent by abolibibelot, is how to verify that the files on the disc are the same as the original, bit for bit, including being able to generate a HASH file.
    You do realize, don't you, that the bits on a DVD are totally different than the bits on a hard drive? Digital data is stored on each medium in a different format (ISO 9660 for a DVD). It also has redundant bits added to not only check errors, but also correct them. Those error correction bits have nothing directly to do with the data that is on whatever media you are checking.

    You can use software to check how many times these error correction bits must be used, and this provides information on the quality of the burn.

    There are really only two useful things you can do: check the quality of the burn (as just described) using DVD Speed (or something similar); and check that the actual information, once retrieved from the media (using correction, as needed) matches the original. For the latter, which is what you are asking for, all you need to do is a standard verify operation.

    Bottom line: the data on a DVD will never be "bit for bit identical" to the data on a hard drive or on a thumb drive, etc.
    Quote Quote  
  24. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    Thank you for the info.

    I thought what you stated in your first paragraph was what I read and why I thought the only way to do a direct comparison of a files on a DVD and on the hard drive was to copy the files from the DVD to the hard drive and perform a verify there. I believe you're stating the same thing, "once retrieved from the media (using correction, as needed)" as far as verification of the two files on the hard drive.

    Ohhh...I'm seriously trying not to channel gamey and question what's already been obviously stated...but I'm confused as to what you mean by "For the latter, which is what you are asking for, all you need to do is a standard verify operation." Standard verify of what? The file transfer? The burn? The readability of the disc?

    I'm not concerned (actually just curious, I don't use optical discs anymore) about the quality of the burn and readability of the files, though that would affect the verification process. I'm just curious about verifying that the files, whether read from the disc or copied to other media is the same as the original.

    Maybe lordsmurf, lordsmurf, lordsmurf (LOL) will show up and knock some sense into me since he participated in the thread at DigitalFAQ that sent me on this dizzying quest.

    I may be wrong, and I'll apologize to gamey if I am, but I've been telling him that the quality and readability of the burn doesn't change one wit, the fact that if the file he burned is corrupted because of the bad sectors on his hard drive, the file on his DVD(s) are also corrupted. No amount of error correction [verification of burn quality or readability] on the disc will change that fact. The same holds true if you copied the file to a HDD, SSD, flash drive, SD card, tape, floppy, etc.
    Last edited by lingyi; 13th Oct 2020 at 16:32.
    Quote Quote  
  25. Here's a basic file compare using the command line FC:

    Code:
    ECHO off
    DEL C:\DVD\~DVDComp.txt
    K:
    CD \
    for /R %%F in (*.*) do ( ^
        fc /b  "%%~dpnxF" "C:\DVD%%~pnxF" >>C:\DVD\~DVDComp.txt ) 
    PAUSE
    It compares files on the DVD in drive K: to the files in C:\DVD\. It creates a log called ~DDComp.txt" in that folder. If a difference is detected you'll see something like this in the log:

    Code:
    Comparing files K:\VIDEO_TS\VTS_02_0.BUP and C:\DVD\VIDEO_TS\VTS_02_0.BUP
    FC: no differences encountered
    
    Comparing files K:\VIDEO_TS\VTS_02_0.IFO and C:\DVD\VIDEO_TS\VTS_02_0.IFO
    00000010: 00 FF
    Comparing files K:\VIDEO_TS\VTS_02_0.VOB and C:\DVD\VIDEO_TS\VTS_02_0.VOB
    FC: no differences encountered
    The first and third files there were fine. In the second I changed a 00 to FF with a hex editor. I guess you'll have to check the log carefully to verify there are no errors.
    Quote Quote  
  26. Also, I use a program called FreeFileSync to sync may NAS to an external backup. That program has a file comparison option works similar to FC. I use it to verify my entire backup a few times a year. You can probably use that to verify a DVD backup too.
    Quote Quote  
  27. You do realize, don't you, that the bits on a DVD are totally different than the bits on a hard drive? Digital data is stored on each medium in a different format (ISO 9660 for a DVD). It also has redundant bits added to not only check errors, but also correct them. Those error correction bits have nothing directly to do with the data that is on whatever media you are checking.

    You can use software to check how many times these error correction bits must be used, and this provides information on the quality of the burn.

    There are really only two useful things you can do: check the quality of the burn (as just described) using DVD Speed (or something similar); and check that the actual information, once retrieved from the media (using correction, as needed) matches the original. For the latter, which is what you are asking for, all you need to do is a standard verify operation.

    Bottom line: the data on a DVD will never be "bit for bit identical" to the data on a hard drive or on a thumb drive, etc.
    But when the operating system accesses an optical disk, it “sees” (or reports) only individual files, not the underlying structure, so how should it matter ? Just like it doesn't matter, when examining files' contents, if one is on a NTFS partition and one on a FAT32 partition (only the attributes will be different, for instance the timestamps are more accurate on NTFS).
    Quote Quote  
  28. This thread has officially entered the Twilight Zone. This is a trivial issue, answered perfectly by jagabo: use the DOS "fc" command that has been with us since the IBM PC and PC-DOS were introduced in 1981. Actually, it's been around longer than that because we had a similar thing in CP/M, the O/S on which DOS was built (actually, DOS is CP/M, but that's a story for another time).
    Quote Quote  
  29. Member
    Join Date
    Jul 2007
    Location
    United States
    Search Comp PM
    LOL!

    I'm soooo trying my best to be good, and I should have been more specific in my OP. jagabo's method is 95% there, but missing the HASH that's possibly addressed by other methods, particularly the ideal of adding the HASH as a file before the burn.

    Why am I so adamant about having a HASH? Because it becomes invaluable if the original file is no longer available as in gamey's case (though there's an additional layer of umm... unfortunate circumstance in his case).

    If I were so intent on making sure the files on my burned discs were exactly the same as on the hard drive, SSD, etc.

    I'd burn and verify with IMGBurn.

    Then verify the the files on the disc were exactly the same as on my hard drive, by running a program that could generate and save a HASH after comparing the disc against the original.

    If I lose the data on the hard drive, I could then restore the files from my disc, running the same program again to verify that the new generated HASH is the same as the saved one. Proving that the restored file is exactly the same as before.

    I'm not that concerned or anal about my files, but some are.

    What I find surprising and interesting, is that there are many programs and ways to do this with non-optical media, for example Teracopy will verify and generate a HASH during copy/move and ViceVersa will allow it after the copy/move procedure is completed. And I think both allow you save the HASH in a file.

    I've been ragging gamey for years for his obsession with preserving his discs, but since starting this thread, I see a bit of sanity in his obsession for those that do backups to optical discs. You can run all the disc verify programs that you want, but unless you have a way to verify the integrity and ideally generate a saveable HASH of the files on your discs, you'll never know if your restore from it is bit for bit perfect.

    WOW! Did I really say that gamey is right???

    To be fair to the guy, a while back I PMed him about a private matter and realized that his heart is in the right place. He's just OCD about his discs and he really can't help himself. Doesn't mean I'm nice to him all the time, but I do try once in a while to help him, but get frustrated when he keeps going on and on.

    Edit: To be clear and fair. While I firmly believe that flipped bits are real, IMO it's not a major issue or concern to me, since 99.99% of what I have are videos. A split-second glitch here or there isn't going to completely kill my enjoyment.

    However, a few flipped bits on my business accounting worksheets that flipped the numbers or made my worksheets unreadable is a major concern. In gamey's case, where his collection contains game ROMS which may be just a few kilobytes or megabits in size (actually don't know how far back his ROM collection goes), a few flipped bits may mean the difference between being able to complete the game or not.
    Last edited by lingyi; 13th Oct 2020 at 19:43.
    Quote Quote  
  30. A hash is no better than a a byte-by-byte file compare. Generating one is only useful the next time(s) you want to check the file(s) -- you won't need to read both the original and the copy, just check the hash of the copy.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!