Jump to content

81RED

Members
  • Content Count

    28
  • Joined

  • Last visited

About 81RED

  • Rank
    ISF Newbie
  1. 81RED

    Strange Verify errors.

    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.
  2. 81RED

    Strange Verify errors.

    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.
  3. 81RED

    Strange Verify errors.

    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 Furthermore, would you not expect the error to also show itself when doing a manual verify, had the problem been memory-related? 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.
  4. 81RED

    Strange Verify errors.

    You had it disabled? Always. Only enabled when actually in use.
  5. 81RED

    Strange Verify errors.

    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.
  6. Taken from the log file: I 17:31:29 Source File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER! I 17:31:29 Source File Implementation Identifier: ImgBurn I 17:31:29 Source File File System(s): ISO9660; UDF (1.02) I 17:31:29 Destination Device: [0:1:0] PLEXTOR DVDR PX-810SA 1.00 (D:) (ATAPI) I 17:31:29 Destination Media Type: DVD-R (Disc ID: MCC 03RG20) (Speeds: 4x; 6x; 8x; 12x; 16x; 18x) I 17:31:29 Destination Media Sectors: 2.297.888 I 17:31:29 Write Mode: DVD I 17:31:29 Write Type: DAO I 17:31:29 Write Speed: 16x I 17:31:29 Link Size: Auto I 17:31:29 Test Mode: No I 17:31:29 BURN-Proof: Enabled I 17:31:30 Filling Buffer... (40 MB) I 17:31:30 Writing LeadIn... I 17:32:03 Writing Image... (LBA: 0 - 2268191) I 17:37:06 Synchronising Cache... W 17:37:18 Potential 'WaitImmediateIO' Deferred Error - (0/2) - Write Error I 17:37:33 Image MD5: 7ecac93c31f73fb18c42471ffc0b079d I 17:37:33 Operation Successfully Completed! - Duration: 00:06:03 I 17:37:33 Average Write Rate: 14.971 KB/s (10.8x) - Maximum Write Rate: 22.123 KB/s (16.0x) I 17:37:33 Cycling Tray before Verify... I 17:37:57 Device Ready! I 17:37:57 Operation Started! I 17:37:57 Source Device: [0:1:0] PLEXTOR DVDR PX-810SA 1.00 (D:) (ATAPI) I 17:37:57 Source Media Type: DVD-R (Book Type: DVD-R) (Disc ID: MCC 03RG20) (Speeds: 4x; 6x; 8x; 12x; 16x; 18x) I 17:37:57 Image File: -==/\/[bUILD IMAGE]\/\==- I 17:37:57 Image File Sectors: 2.268.192 (MODE1/2048) I 17:37:57 Image File Size: 4.645.257.216 bytes I 17:37:57 Image File Volume Identifier: Bug I 17:37:57 Image File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER! I 17:37:57 Image File Implementation Identifier: ImgBurn I 17:37:57 Image File File System(s): ISO9660; UDF (1.02) I 17:37:57 Verifying Sectors... (LBA: 0 - 2268191) I 17:44:23 Device MD5: 7ecac93c31f73fb18c42471ffc0b079d I 17:44:23 Image MD5: 7ecac93c31f73fb18c42471ffc0b079d I 17:44:26 Operation Successfully Completed! - Duration: 00:06:25 When I got the error I hit "retry" and it immediately finished the session. The verify afterwards went fine as well. Is my burner on the brink? I use only Verbatim media, so it's not likely thats where the problem lies. Tia, Simon
  7. 81RED

    VERY strange problem.

    I guess we learn something new every day, yeah?
  8. 81RED

    VERY strange problem.

    Another update - Learned a valuable lesson today, *never* assume anything, even if it's likely, without doublechecking and making sure you are right. The file in question originally came as part of a larger (4GB) DVD package that I tried to burn God knows how many times and failed. After removing said file the burn went ok, and that final burn was done on my last available blank DVD. All subsequent tests by me was done on CD-R media as I had a shitload of those lying around. Since one of the other people testing this, explicitly told me he was trying it on a DVD-R, I (wrongly) assumed that it did not matter which media was being used. He has now confessed that it was a CD-R he tried it on. Have now tried it on a few different DVD-R's, and have had no problems so far. Will try to see if I can create a test image that resembles the original to reproduce the problem. That being said, I can re-create the problem 100% of the time if writing in Mode 1 on any CD-R. Sincerely apologize for any confusion caused by my wrong assumptions.
  9. 81RED

    VERY strange problem.

    Goddamn! Here's an update that may change things a bit: When I first discovered the problem during the weekend, I did not have a single RW media in the house, and the result was that I now have enough coasters to tile my bathroom floor. Anyway, I took home one single Verbatim DVD RW from work today - just tried it right now, and guess what? NO PROBLEMS. It writes, it verifies, all is good and dandy. I then tested it again with a CD-R (have no more blank DVD Verbs in stock) and it bummed out again. Please Mr. Lightning, could you please try again - preferably with a CD-R (NON-RW) of some sort? I will gladly reimburse you for the expenses via a donation. EDIT: Just tried with an ancient Nashua CD-RW that I dug out from a drawer, that's a no-go as well.
  10. 81RED

    VERY strange problem.

    Yup, Mac and under Linux! Hmmm... It proves that it works with your hardware, which admittedly calms me down a bit - in my ideal world the problem I have just experienced should not be possible. But nevertheless it did, and you can laugh all you want - I have no real way of proving it to you, unless a member of the audience with a Plextor PX-750A or a NEC ND-3540A (just tested somewhere else) would like to join in the fun?
  11. 81RED

    VERY strange problem.

    Aargh! #?#"!?!%"!#?%!"#?! Please tell me you fixed something in 2.2.0.0 that you have not yet told anyone about, yeah? Anyway, I will still get the drive models off of the mates that tested besides myself, and compare their drives to your list - even though I find it more than odd that all ours fail, and none of yours do. Apart from that, might just give Plextor tech support a call tomorrow. Thanks for testing, even if the results were far from what I had expected
  12. 81RED

    VERY strange problem.

    I give up. The file is completely identical to mine, and out of the 7 other PC/platforms tested, of course it works on yours. Have *no* idea what's going on - The only thing I can say for sure is that your Plextor model is not amongst the ones already tested, and that you are using a newer version of Imgburn (of course ). I will ask the other "guinea pigs" what exact drive models and firmware revisions they are using, as this must be hardware related. You don't by any chance have a Plextor 750A to try it out on?
  13. 81RED

    VERY strange problem.

    >So in that log, you just burnt the file on it's own via build mode yeah? Exactly. >Rename that file to something else and then burn it again (on a rewritable of course). >Does it verify ok then? Nope. Tried that already - the DUMMYFIL.DMY name was something I made up. >What if you build an ISO from that file and mount in DAEMON Tools. >Can you then verify the mounted drive (uncheck the 'verify against image file' box) ? Yup, no problem. It's only when it's been through a burner that things go wrong. >It could either be the content of the file that's the problem, the name of it or some combination of the two. >If everything you've said about your testing is true, it certainly looks like something fishy is going on... it's >almost 'rootkit' like. >There's no way I know of to burn anything in mode 1 using tao/sao/dao write modes that then cannot be >read back - so it's like some other driver (hence the rootkit part) is reading some signature in the file and >returning the seek error. This is precisely why I'm so baffled. It can be reproduced on four different PC's so far - and while there may be some instances of identical programs installed, I find it hard to believe that all four PC's should be "infected" by the same rootkit. I *really* think you should take a look at that file...
  14. 81RED

    VERY strange problem.

    Sure thing, log included - even though I very much suspect that it will not reveal anything about the cause of this rather bizarre issue ;-) ImgBurn.log
  15. 81RED

    VERY strange problem.

    This boggles my mind. The other day a verify failed with a "No seek complete" error after burning a .ISO data disk with Imgburn. After wasting God knows how many blank DVDR's of various brands, swapping burner for another brand, extracting the files manually/burned using build mode and lastly trying it out on a completely different PC, I started taking notice of where the verify failed. It boils down to one single file that is about 20MB in size. Said file fails to verify when written to either a DVD-R/RW or CD, no matter whether it was burned via build mode or contained within any ISO/IMG whatever image file. It gets better. Having concluded that my hardware was OK, I started testing with other CD/DVD recording programs. Alcohol, Nero, Stomp Recordnow MAX and mkisofs & cdrecord (under Linux) all exhibit EXACTLY the same behaviour as Imgburn - and on four different PC's none the less. Interestingly Padus Discjuggler both burns and verifies the file when burning in Mode 2 XA, but not in Mode 1. I assume that both Nero and Stomp are also capable of burning in Mode 2 XA, but this has not yet been tested. I must admit that this experience completely undermines any conception I had of data storage and retrieval, but if anyone could come up with a reasonable explanation, I would be more than averagely interested in hearing it. Should LUK! or any of the resident experts like to get hold of the file in mention, I will be more than happy to comply.
×

Important Information

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