Jump to content
Sign in to follow this  
81RED

Strange Verify errors.

Recommended Posts

Have been making a lot of rather expensive Verbatim +R DL coasters lately - Imgburn complains about verify errors in around 50% of the media i try to burn.

Decided to investigate a bit, and now I'm baffled.

 

Here's a snip of the latest log:

 

I 01:02:32 ImgBurn Version 2.4.2.0 started!

I 01:02:32 Microsoft Windows Vista Ultimate Edition (6.0, Build 6001 : Service Pack 1)

I 01:02:32 Total Physical Memory: 3.142.684 KB - Available: 1.733.024 KB

W 01:02:32 AnyDVD can interfere with ImgBurn's ability to verify accurately, please ensure it's disabled!

I 01:02:32 Initialising SPTI...

I 01:02:32 Searching for SCSI / ATAPI devices...

I 01:02:32 Found 2 BD-ROM/HD DVD-ROMs and 1 BD-RE/HD DVD-ROM!

I 01:02:34 Operation Started!

I 01:02:34 Source File: C:\XXXXX\XXXXX.iso

I 01:02:34 Source File Sectors: 3.571.056 (MODE1/2048)

I 01:02:34 Source File Size: 7.313.522.688 bytes

I 01:02:34 Source File Volume Identifier: NN

I 01:02:34 Source File Volume Set Identifier: 49358ACC49357F12

I 01:02:34 Source File Implementation Identifier: Nero

I 01:02:34 Source File File System(s): UDF (1.02)

I 01:02:34 Destination Device: [0:1:0] PLEXTOR BD-R PX-B920SA 1.01 (D:) (ATAPI)

I 01:02:35 Destination Media Type: DVD+R DL (Disc ID: MKM-003-00) (Speeds: 2,4x; 4x)

I 01:02:35 Destination Media Sectors: 4.173.824

I 01:02:35 Write Mode: DVD

I 01:02:35 Write Type: DAO

I 01:02:35 Write Speed: 4x

I 01:02:35 Link Size: Auto

I 01:02:35 Test Mode: No

I 01:02:35 OPC: No

I 01:02:35 BURN-Proof: Enabled

I 01:02:35 Book Type Setting: N/A

I 01:02:35 Optimal L0 Data Zone Capacity: 1.785.536

I 01:02:35 Optimal L0 Data Zone Method: ECC Block Boundary

I 01:03:07 Filling Buffer... (256 MB)

I 01:03:09 Writing LeadIn...

I 01:03:12 Writing Session 1 of 1... (1 Track, LBA: 0 - 3571055)

I 01:03:12 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 3571055)

I 01:03:12 Writing Layer 0... (LBA: 0 - 1785535)

I 01:14:22 Writing Layer 1... (LBA: 1785536 - 3571055)

I 01:25:33 Synchronising Cache...

I 01:25:34 Closing Track...

I 01:25:37 Finalising Disc...

I 01:26:28 Image MD5: 73f7f7407d1a89c82f66729c5ee1b9f7

I 01:26:28 Operation Successfully Completed! - Duration: 00:23:53

I 01:26:28 Average Write Rate: 5.325 KB/s (3.8x) - Maximum Write Rate: 5.577 KB/s (4.0x)

I 01:26:28 Cycling Tray before Verify...

W 01:26:36 Waiting for device to become ready...

I 01:27:01 Device Ready!

I 01:27:02 Operation Started!

I 01:27:02 Source Device: [0:1:0] PLEXTOR BD-R PX-B920SA 1.01 (D:) (ATAPI)

I 01:27:02 Source Media Type: DVD+R DL (Book Type: DVD-ROM) (Speeds: 2,4x; 4x)

I 01:27:02 Image File: C:\XXXXX\XXXXX.iso

I 01:27:02 Image File Sectors: 3.571.056 (MODE1/2048)

I 01:27:02 Image File Size: 7.313.522.688 bytes

I 01:27:02 Image File Volume Identifier: NN

I 01:27:02 Image File Volume Set Identifier: 49358ACC49357F12

I 01:27:02 Image File Implementation Identifier: Nero

I 01:27:02 Image File File System(s): UDF (1.02)

I 01:27:02 Read Speed (Data/Audio): MAX / MAX

I 01:27:03 Verifying Session 1 of 1... (1 Track, LBA: 0 - 3571055)

I 01:27:03 Verifying Track 1 of 1... (MODE1/2048, LBA: 0 - 3571055)

I 01:27:03 Verifying Layer 0... (LBA: 0 - 1785535)

W 01:27:59 Miscompare at LBA: 106016, Offset: 1824, File: \XXXXX\XXXXX.cab

W 01:27:59 Device: 0x9E

W 01:27:59 Image File: 0xDE

W 01:27:59 Total Errors in Sector: 1

I 01:27:59 Verifying Sectors...

W 01:28:50 Miscompare at LBA: 237088, Offset: 1824, File: \XXXXX\XXXXX.cab

W 01:28:50 Device: 0xB5

W 01:28:50 Image File: 0xF5

W 01:28:50 Total Errors in Sector: 1

I 01:28:50 Verifying Sectors...

W 01:29:19 Miscompare at LBA: 302624, Offset: 1824, File: \XXXXX\XXXXX.cab

W 01:29:19 Device: 0x9A

W 01:29:19 Image File: 0xDA

W 01:29:19 Total Errors in Sector: 1

I 01:29:19 Verifying Sectors...

 

And so forth.

 

Interestingly, when I do a binary filecompare (good old FC /B from a CLI) theres no discrepancies whatsoever.

Even more intriguing is the fact that a manual "Verify against image file" from within Imgburn also reports that all is well.

 

So I have a semi-random verify problem that only occurs when the media is verified immediately after the burn process. Does not make a lot of sense to me, if it does to any of you guys, I would love to hear about it.

Share this post


Link to post
Share on other sites
W 01:02:32 AnyDVD can interfere with ImgBurn's ability to verify accurately, please ensure it's disabled!

You had it disabled?

 

:)

Share this post


Link to post
Share on other sites
W 01:02:32 AnyDVD can interfere with ImgBurn's ability to verify accurately, please ensure it's disabled!

You had it disabled?

 

:)

 

Always. Only enabled when actually in use. :)

Share this post


Link to post
Share on other sites

Test your computer's memory with memtest+ and let it do a few passes, as it seems you have a memory problem.

Share this post


Link to post
Share on other sites

have you tried any burns at 2.4x ? if so post a log of them.

have you recently bought some verbatim DL's

your using the ones with ID of MKM-003 , was you using the 2.4x MKM-001 before

Share this post


Link to post
Share on other sites
Test your computer's memory with memtest+ and let it do a few passes, as it seems you have a memory problem.

 

No errors found. Would have surprised me if that was indeed the case - Windows does not take too lightly to even intermittent memory errors, and my PC has been running as stable as an average Vista user can expect :whistling:

Furthermore, would you not expect the error to also show itself when doing a manual verify, had the problem been memory-related?

 

have you tried any burns at 2.4x ? if so post a log of them.

have you recently bought some verbatim DL's

your using the ones with ID of MKM-003 , was you using the 2.4x MKM-001 before

 

Writing at 2.4 makes no difference whatsoever, it's still a hit & miss affair as to whether I get verify errors or not.

You may have a point regarding the media itself, am quite sure that the 003 dye is new, but then again - would that not create

easily reproducable errors?

 

Still baffled.

Share this post


Link to post
Share on other sites

Maybe it's heat combined with bad error correction or something.

 

Can you use PlexTools / PlexUtilities with that drive and do a PI/PE scan on the disc?

 

Stick to the MKM-001-00 discs where possible, they just work better in more drives than their big brothers do.

Share this post


Link to post
Share on other sites
Maybe it's heat combined with bad error correction or something.

 

Can you use PlexTools / PlexUtilities with that drive and do a PI/PE scan on the disc?

 

Stick to the MKM-001-00 discs where possible, they just work better in more drives than their big brothers do.

 

Heat is pretty much out of the question, also happens when the system has just started.

Plextools tells me that the PI/PE test "function is unavailable for this device". Go figure.

Will try with some 001 media, if I can I get hold of them - could be a bit of a problem around here.

Share this post


Link to post
Share on other sites

But you've just burn the disc, no? Therefore the drive will be hot.

 

The verify code after the burn is exactly the same thing that runs when you do it manually so corruption is getting in somewhere, you just need to figure out where.

 

Examine the problem sectors at a later date and see which is correct... either the disc one or the hdd one. It'll give you a starting point.

Share this post


Link to post
Share on other sites
Examine the problem sectors at a later date and see which is correct... either the disc one or the hdd one. It'll give you a starting point.

That's a very good idea indeed.

 

In the meantime, I plopped in my "old" Pioneer drive and did some burns on that - problem gone.

Would seem that my B920SA has intermittent problems with that specific media. Oh well, will call Plextor on Monday and hear what their excuse is.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×

Important Information

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