Jump to content

Recommended Posts

Posted

Hi there, first off thanks for imgburn, top little utility :)

 

second, my problem....

 

Basically this is whats happened....

 

1. Today I decided to back up all my Xbox 360 games and burnt about 16 with no problem at all and they all "verified" fine in imgburn (Ticked verify box)

 

2. I Then burnt some of my game backup images with verify - again no problem.

 

3. I then burnt some very large video files (HD DVD backups encoded to fit a Dual layer) using the "build" mode in imgburn....Again with "verify" on.

 

Now with 3. I had a problem, during the verify it would say something about a "mismatch" between the written data and what it should be,I had 2-3 of these on each disc - but no slowdown when reading. I assumed this meant I had some faulty memory on my hands - sure enough after running memtest I'm getting errors all over the place on it...

 

So my question is...

 

Are all my backups ruined, and is Imgburn not correctly picking up the errors because its not in "build" mode and in the other modes is more running a "readability" test than a 100% bit-for-bit comparison? I find it hard to believe that it would just be these large WMVs that are messed up where only errors are showing up on them?

 

Would really appreciate some clarifycation on this, as although the backups work fine, if I go online with them on my Xbox 360 they might be detected as not original and I might get banned etc...

 

(Please note all my backups are of my legally owned discs)

 

Thanks in advance for any help :)

 

Rob

Posted

It's hard to know because your memory is bad. This happened to me a couple of years back though and the DVDs were fine.

 

Obviously, the ones that verified OK (and work OK) shouldn't be an issue - maybe just the HD transcode.

 

In terms of what verify does, it is a 1:1 bit comparison of the data. You can tell by your logs as it also generates MD5 hashes.

 

Regards

Posted
It's hard to know because your memory is bad. This happened to me a couple of years back though and the DVDs were fine.

 

Obviously, the ones that verified OK (and work OK) shouldn't be an issue - maybe just the HD transcode.

 

In terms of what verify does, it is a 1:1 bit comparison of the data. You can tell by your logs as it also generates MD5 hashes.

 

Regards

 

Thanks for the reply mate :)

 

Hmmmm, still abit doubtful as although the backups work fine, they play and all that. But if its only the odd bit here and there that is different they would play fine and maybe crash later on in a game etc....sooo hmmmm. I really don't fancy burning all them again. Oh well :(

 

I guess also what I'm asking is, could there be a different kind of comparison in the verify stage of the program for build vs burning an actual image etc?

 

I've had bad memory before and when burning in nero I always got a fail in the verify data stage when burning an iso...

 

Anyway I'm rambling now, but if anyone has anything else to add on this, do please post :) and many thanx to you Blutack for posting its appreciated

Posted
I guess also what I'm asking is, could there be a different kind of comparison in the verify stage of the program for build vs burning an actual image etc?

 

Nope they're all the same, it's the same function/code being called in all modes.

Posted
I guess also what I'm asking is, could there be a different kind of comparison in the verify stage of the program for build vs burning an actual image etc?

 

Nope they're all the same, it's the same function/code being called in all modes.

 

Thanks for clearing that up :)

 

I installed some new memory earlier (100% working)

 

However I went to check that md5 hash when burning an iso and it turns out it works differently to when burning from the "build" mode.

 

I burnt an iso, and I then checked the log and the md5 was different for the iso (with the words "padded" in brackets). The md5 was the same for thr "build" mode.

 

(Both burns were 100% accurate) The thing is, does this mean that the verify stage might now pick up the "mis-matched" data for the ISOs that I burnt yesterday? Since the md5 was different and no error was reported on a correct burn of one?

 

Sorry for my waffleing, I hope you know what I mean :) (Bit confused about the padding thing, and if it lets the md5 be different because of it, does it basically invalidate any positive verifycation, in so far as wrong data being written, and not just poor media, which would obviously give a read error?)

 

Thanks for your time.

Posted

The padding value comes from burning a file that doesn't have a 'number of sectors' that's divisible (exactly) by 16.

 

When you burn to DVD+R media the drive will always pad the image (disc) so the size is divisible by 16 - so if you read the disc back you'll get the MD5 shown in the 'padded' line and not the other one.

Posted
The padding value comes from burning a file that doesn't have a 'number of sectors' that's divisible (exactly) by 16.

 

When you burn to DVD+R media the drive will always pad the image (disc) so the size is divisible by 16 - so if you read the disc back you'll get the MD5 shown in the 'padded' line and not the other one.

 

 

Right gotcha :) thanks.

 

So my final question is, based on that do I have anything to worry about :innocent: Would imgburn still report if they md5 is different to what it should be when burning a "padded" thing, or, because of the padding does that make the md5 thing pointless if they would never match anyway?....

 

ohhhhh I wish i could explain myself better...

 

Lets forget the md5 checksum thingy, if my verify phase passed - can I safely assume that the disc has burnt perfectly without any slightly wrong bits being written due to bad memory, as bad memory would never make a disc pass a verify when it shouldn't etc...

 

So if its checking every single bit on the disc for a match to my iso - then I'm ok?

 

(Sorry I know I sound really pedantic) thanks for your patience

Posted
The padding value comes from burning a file that doesn't have a 'number of sectors' that's divisible (exactly) by 16.

 

When you burn to DVD+R media the drive will always pad the image (disc) so the size is divisible by 16 - so if you read the disc back you'll get the MD5 shown in the 'padded' line and not the other one.

 

 

Right gotcha :) thanks.

 

So my final question is, based on that do I have anything to worry about :innocent: Would imgburn still report if they md5 is different to what it should be when burning a "padded" thing, or, because of the padding does that make the md5 thing pointless if they would never match anyway?....

 

ohhhhh I wish i could explain myself better...

 

Lets forget the md5 checksum thingy, if my verify phase passed - can I safely assume that the disc has burnt perfectly without any slightly wrong bits being written due to bad memory, as bad memory would never make a disc pass a verify when it shouldn't etc...

 

So if its checking every single bit on the disc for a match to my iso - then I'm ok?

 

(Sorry I know I sound really pedantic) thanks for your patience

 

(Also is an md5 a calculation of all the bits, or just based on the size of the image etc)

Posted

It's of all the actual data.

 

Like CRC only better and more reliable.

 

If it passed verify (ignore the MD5 values, they're cosmetic and nothing to do with a verify pass/fail), the disc is 100% fine (Well, it's content matched what was read from the file anyway!).

Posted
It's of all the actual data.

 

Like CRC only better and more reliable.

 

If it passed verify (ignore the MD5 values, they're cosmetic and nothing to do with a verify pass/fail), the disc is 100% fine (Well, it's content matched what was read from the file anyway!).

 

Thats what I wanted to hear :)

 

I love you, well I know I'm only saying that cos I don't have to waste 20 discs and 10 hours doing them again.

 

But I kinda do lol DVD Decrypter served me well, thanks for a great featured little swiss army knife of a program and thanks for the replies, been a real help :)

 

You doing any donations thingy here cos i'll chuck in a couple £ if you are?

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.