Prev: [UPDATE] SUPERAntiSpyware 4.41.1000
Next: DVDFab HD Decrypter
From: Fuller on 7 Aug 2010 21:07
On Fri, 23 Jul 2010 06:45:55 +0800, Johnw wrote:

> Fuller explained :
>
>> Given the extensive ImgBurn log file, is there a way to find out exactly
>> WHICH FILE failed the verification step (so I can test that one file out of
>> thousands)?
>
> Present the log on their forum.
>
> Where can I find the ImgBurn log?
> http://forum.imgburn.com/index.php?showtopic=14632
> http://forum.imgburn.com/index.php?showforum=6
>
> --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---

Here is what just happened on a supposedly "bad" burn:

0. ImgBurn I/O Error!
Device: [0:1:0]SONY DVD+-RW DW-Q58A UDS1 (E:) (ATA)
ScsiStatus: 0x02
Interpretation: Check Condition
CDB: 28 00 00 01 25 68 00 01 00
Interpretation: Read (10) - Sector: 75112
Sense Area: 70 00 03 00 00 00 00 0A 00 00 00 00 11 00 00 00 00 00
Interpretation: Unrecovered Read Error
[ Cancel ] [ Try Again ] [ Continue ]

In ImgBurn, I hit "View->Log" and it still does NOT tell me WHICH FILE
failed?

The log is below (but how do I know which file failed)?
When I view the resulting DVD, it seems "fine" but of course, we know
"something" is wrong.

How can I get ImgBurn to tell me which FILE is corrupted & why?
I see a file listed but it comes up fine in Irfanview.

Here is the log excerpt ...
I 15:07:53 Source Device: [0:1:0] SONY DVD+-RW DW-Q58A UDS1 (E:) (ATA)
I 15:07:53 Source Media Type: DVD-R (Book Type: DVD-R) (Disc ID: SONY16D1)
(Speeds: 2x, 4x, 6x, 8x)
I 15:07:53 Image File: -==/\/[BUILD IMAGE]\/\==-
I 15:07:53 Image File Sectors: 1,231,504 (MODE1/2048)
I 15:07:53 Image File Size: 2,522,120,192 bytes
I 15:07:53 Image File Volume Identifier: 20100722BCK
I 15:07:53 Image File Application Identifier: IMGBURN V2.5.1.0 - THE
ULTIMATE IMAGE BURNER!
I 15:07:53 Image File Implementation Identifier: ImgBurn
I 15:07:53 Image File File System(s): ISO9660, UDF (1.02)
I 15:07:53 Read Speed (Data/Audio): MAX / MAX
I 15:07:53 Verifying Session 1 of 1... (1 Track, LBA: 0 - 1231503)
I 15:07:53 Verifying Track 1 of 1... (MODE1/2048, LBA: 0 - 1231503)
W 15:09:33 Failed to Read Sector 75112 - Reason: Unrecovered Read Error
W 15:09:33 Sector 75112 maps to File: \201007_JULY\20100712\2021.jpg
W 17:57:29 Waiting for device to become ready...
I 17:57:30 Device ready!
I 17:57:30 Verifying Sectors...
W 17:57:34 Retrying (1)...
I 17:57:34 Verifying Sectors...
W 17:57:44 Failed to Read Sector 75172 - Reason: Unrecovered Read Error
W 17:57:44 Sector 75172 maps to File: \201007_JULY\2021.jpg
W 17:57:47 Failed to Read Sector 75172 - Reason: Unrecovered Read Error
W 17:57:47 Sector 75172 maps to File: \201007_JULY\2021.jpg
W 17:57:54 Failed to Read Sector 75173 - Reason: Unrecovered Read Error
W 17:57:54 Sector 75173 maps to File: \201007_JULY\2021.jpg
W 17:57:56 Retrying (1)...
W 17:58:03 Retry Failed - Reason: Unrecovered Read Error
W 17:58:06 Retrying (2)...
W 17:58:13 Retry Failed - Reason: Unrecovered Read Error
E 17:58:30 Failed to Read Sector 75173 - Reason: Unrecovered Read Error
E 17:58:30 Sector 75173 maps to File: \201007_JULY\2021.jpg
E 17:58:30 Failed to Verify Sectors!
I 17:58:31 Exporting Graph Data...
I 17:58:31 Graph Data File: C:\Documents and Settings\bill\Application
Data\ImgBurn\Graph Data
Files\SONY_DVD+-RW_DW-Q58A_UDS1_SATURDAY-AUGUST-07-2010_2-56_PM_SONY16D1_MAX.ibg
I 17:58:31 Export Successfully Completed!
E 17:58:31 Operation Failed! - Duration: 02:50:37
I 17:58:31 Average Verify Rate: 14 KB/s (0.0x) - Maximum Verify Rate: 4,967
KB/s (3.6x)
From: B. R. 'BeAr' Ederson on 8 Aug 2010 06:50
On Sun, 8 Aug 2010 01:07:06 +0000 (UTC), Fuller wrote:

[ImgBurn]
> Here is what just happened on a supposedly "bad" burn:

The sense data and the log both indicate unrecoverable parity outer
failure (POF). Therefore, no other program should be able to get
useful data from there. To verify this, you could try to make an
image file with <Ignore read errors> *not* set inside the ImgBurn
<Settings> dialog. - Or better yet (to rule out specific ImgBurn
problems) any other imaging program.

With "weak" burns it is possible, that later reads are sometimes
successful, sometimes not. (Which /could/ permit temporary access to
the affected files.) You could increase retries (both hardware and
software) in the ImgBurn <Settings> dialog to reduce the probability
of ImgBurn reporting unrecoverable read errors while other software
is successful, later on. (Also - as you probably know - other drives
may be successful in reading, while the burning drive is not.)

ImgBurn has a manual <Verify> mode. Try it on the same disk, whether
the same sectors are /again/ reported as faulty. If not, ImgBurn may
have auto-reallocated the files during the burn/verify process. (I'm
not sure, whether ImgBurn would try this during a verify, though. It
does when encountering /write/ errors. - You'd need to straighten this
out with their forum.)

You can manually detect relocation by opening the disk in question
inside a hex editor. Search for a long (and distinctive) enough string
of hex values of the file in question. (Open both, the file and the
disk, inside the hex editor at the same time for easier copying.)
Compare the sector number, where you found the string, with the number
from the ImgBurn log. (Repeat the search to be sure, that the string
only appears /once/ on the disk.) Look here for a good hex editor:

http://mh-nexus.de/en/hxd

The offset (the last numbers of the address) of the string should
match between the file and the disk view inside the hex editor. Only
in the leading base address part (where the file address consists only
of zeros), the addresses should differ. The sector number is shown by
HxD on the right hand side of the hex/text listing. Scroll upwards,
if you don't see it right away.

You can also have a look at the reported sectors at sector level by
using the <Sector viewer> tool inside ImgBurn (the small icon on the
left hand side, below the <Source> drop-down box). If the sectors
really are unreadable, you should get an error here, too.

Besides all the above, you maybe just happen to have a combination of
burner and DVD's, which is on the edge of operability. This can also be
the case, if varying sectors are reported as faulty on subsequent
<Verify> runs.

Another possible explanation for the latter could be, though, that your
PC has interfering hardware components: A mouse, sound card, and the
like may access the same resources as the burner. - This, nowadays, does
not happen as often as a couple of years ago. But it can't be ruled out,
completely. Raid setups (even without really installed Raid!) sometimes
conflict with optical drives. So try to connect your DVD drive to another
(best: separate) connector if possible.

Apart from all this, the usual applies:
- clean your drive
- test other burning speeds
- use other DVD blanks
- install another firmware (sometimes even an older one can help)
- check/update drivers for all your hardware components (esp. for the
mainboard, controller chips,...)

Everything else, IMHO, /really/ needs to be straightened out within the
dedicated ImgBurn forum, as Johnw already pointed out... ;-)

BeAr
--
===========================================================================
= What do you mean with: "Perfection is always an illusion"? =
===============================================================--(Oops!)===
From: Orak Listalavostok on 8 Aug 2010 16:24
On Sun, 8 Aug 2010 12:50:21 +0200, B. R. 'BeAr' Ederson wrote:
> - clean your drive
> - test other burning speeds
> - use other DVD blanks
> - install another firmware (sometimes even an older one can help)
> - check/update drivers for all your hardware components (esp. for the
> mainboard, controller chips,...)

If you've defragmented your drive, lowered the burn speed, used
good-quality DVD media, then this article describes the problem which you
almost certainly have, as do many others unknowingly:

http://winhlp.com/node/10

Basically, when Windows has a DMA problem reading or writing, it
"permanently" lowers the UDMA speed by a notch, then another notch, then
another ... until it's down to the PIO mode. Permanently.

The only solution is to re-enable DMA as explained in that article.

I highly recommend you (and anyone reading this whose drives aren't as fast
as they like), check what mode your secondary IDE port is currently working
in. Go to Device Manager: right-click on My Computer, select Properties,
click on the Hardware tag, click on the Device Manager button, click on the
plus sign to the left of IDE ATA/ATAPI Controller, double-click on the
secondary IDE channel, click on Extended Settings and check whether it is
set to DMA when available. Directly underneath that setting is a grey field
that shows the actual working mode of your IDE channel. You want the
highest possible DMA or Ultra DMA mode there, and you definitely don't want
PIO mode.
From: Donna Ohl on 8 Aug 2010 16:29
On Sun, 8 Aug 2010 13:24:44 -0700, Orak Listalavostok wrote:

> this article describes the problem which you
> almost certainly have, as do many others unknowingly:
> http://winhlp.com/node/10

Look in your ImgBurn log file.

If you see this, then you have the Windows bug where it lowers DMA to PIO!

.... waiting for buffers to recover (LBA ...
.... waiting for hard disk activity to reach threshold level ...

The solution is to remove the DMA driver from the device manager and
reboot!
From: Melissa Andrade on 8 Aug 2010 16:33
On Sun, 8 Aug 2010 20:29:34 +0000 (UTC), Donna Ohl wrote:

> remove the DMA driver from the device manager and reboot!

Or, just run REGEDIT.

Go to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318}

It has subkeys like 0000, 0001, 0002, etc. Normally 0001 is the primary IDE
channel, 0002 the secondary, but other numbers can occur under certain
circumstances. You have to go through these subkeys and check the
DriverDesc value until you find the proper IDE channel.

Delete MasterIdDataChecksum or SlaveIdDataChecksum, depending on whether
the device in question is attached as master or slave, but it can't
actually hurt to delete both. Reboot. The drive DMA capabilities will be
redetected.

Note that many CD and DVD drives only use UDMA-2, because their data rate
is much lower than that of a hard disk. This is normal and no reason to
worry.

2006-01-19 – Horst Schülke wrote that it is sufficient to empty the content
of these values. But you can also delete the values entirely. Windows will
automatically recreate them anyway, with new content.

Open Device Manager again and check whether the device is now actually
using DMA mode. If so, congratulations, you've made it (at least until the
next time Windows disables DMA). If not, you may have to change the IDE
channel setting from PIO back to the highest available DMA mode and reboot
again.

--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [UPDATE] SUPERAntiSpyware 4.41.1000
Next: DVDFab HD Decrypter