LIGHTNING UK!

BEFORE: I 22:06:05 ImgBurn Version 2.3.2.0 started!I 22:06:05 Microsoft Windows Server 2003, Standard Edition (5.2, Build 3790 : Service Pack 2) I 22:06:05 Total Physical Memory: 2,094,704 KB - Available: 290,000 KB I 22:06:05 Initialising SPTI... I 22:06:05 Searching for SCSI / ATAPI devices... I 22:06:05 Found 2 DVD-ROMs, 2 DVD

They must be weird img files. Send me the first 5MB of one of them and i'll see what I can do.

You had another thread started about this, stop making new ones. http://forum.imgburn.com/index.php?showtop...amp;#entry48771

i formatted mine to ntfs manually using the command prompt format g: /fs:ntfs You need to change it to 'optimise for performance' in device manager first though before it'll let you. But it's not worth messing around with really as the fix I have now works for all filesystems - you just have to bypass the OS buffering using an extra flag in the 'CreateFile' api. Trouble is that you then can't write randomly sized amounts of data to the file, it always has to be a multiple of the sector size.

I've sussed it now bit it's going to take some tinkering to make sure i don't break other stuff!

The Welcome tab is just a welcome, it doesn't do anything! It simply tells you to press 'ok' in the sense that it closes the window and stops you messing about with things you don't understand. In any case, booktype stuff is automatic on Pioneer drives, there's nothing the software can do.

It doesn't apply to Read mode. By definition, it produces an exact copy of the original disc. So if the gaps were there in the first place, they'll still be there in the ISO. If they weren't there, they won't be.

Turn off 'auto calculate', then it won't prompt each time. Just click the button when you're done.

Hmm I see the problem but don't know of a way around it. Firstly, unless the drive uses NTFS, the files aren't pre-allocated (It takes ages on FAT / FAT32 (compared to NTFS) so I avoided it). That basically means that for every 'Write' operation that extends the lengh of the file, the file system gets updated (by windows) to reflect that change. That of course means there's a lot of random accessing going on, and USB memory sticks are very slow in that sense. I can get rid of that overhead by pre-allocating on all filesystems. Ok, so once that's implemented (very easy), the whole thing is a bit faster. The next issue is that for some VERY odd reason, windows decided to write to the drive twice. I send my data in chunks of 65536 bytes. I can see windows writing the data physically to the drive using the same transfer length, but it's issuing two commands for the same data, and to the same LBA. One is for 65536 bytes, the other is for 4096. Again, I've *NO* idea why it's doing that - and it is again introducing 'random access' into the write equation meaning it can never be quick. I'll keep digging / playing

This is a drive / media issue and nothing to do with which OS you're running. It's quite an old drive you have there actually, ever considered cleaning it / replacing it with a newer model?

HDDs working and Optical drives working are two VERY different things! Lots of IDE/SATA controllers won't support Optical drives, or at least not very well. Unless it's on the chipset one (which it actually sounds like yours is), there are normally problems with using them. So assuming yours is connected to the proper nvidia controller and not any 3rd party addon chipset one, the only drivers you need to check for are the nvidia ones. Some say the default Microsoft drivers work best, other say the latest nvidia nforce ones do. So basically, visit nvidia.com and download + install them. If it doesn't work, revert to the Microsoft driver.

You just had a 'Write Error'. Check for firmware updates for the drive and buy some better quality disc. We only recommend Verbatim (MCC dye) and Taiyo Yuden.

Right, yeah, it's misreporting the disc capacity. The 'Get Capacity' command is returning '605' (last sector written on disc), and so when starting from 0, that gives us a readable region of 0 - 605 = 606 sectors. This is confirmed in the TOC info But then there's some odd looking gap after the track and before the leadout that wouldn't normally be there. Hence that's where your 2 sectors are going missing. I assume you've tried burning to a read CD-R rather than a CD-RW?

For whatever reason, your drive appears to report the disc only has 606 sectors written to it. If it can't report the correct info, there's not much I can do. Copy + paste the info from the info panel on the right when in read mode please.

Out of interest, is it slow if you build hdd to usb or just usb to usb? What if you go usb to hdd, is that slow? Actually, thinking about it, I don't suppose write cache is enabled for those usb devices and I pretty much deal in sectors within the program. I guess that would bring about a lot of overhead if the OS isn't caching it and then doing 1 larger 'write' operation. When I get a minute I'll look into it a bit more closely.

It will only take off the random bytes at the end, not a full sectors worth. For instance, I just built a test iso from a random file on my desktop, it's size came out to: I 23:14:25 Image Size: 1,245,184 bytes I then used hexworkshop to insert 5 bytes on the end of it. Explorer then shows the size as: 1.18 MB (1,245,189 bytes) Once loaded into ImgBurn's Write mode, the size is still shown as: 1,245,184. ONLY those 5 bytes have been ignored.

You're not really giving us anything to go on! Tell us the specifics! How big is the image going by the file properties in Explorer? How big does ImgBurn think it is once loaded in Write mode? How big is it once burnt and looked at in Read mode (look in info panel on the right) ? Just copy + paste everything from the info panel and log window (after burning / reading). Screenshots help too. As for ASPI not working, it works fine. If you have SPTD installed (part of DAEMON Tools / Alcohol), ensure you're running v1.50.

Hmm odd, I've never seen the 'Logical Unit Communication CRC Error (ULTRA-DMA/32)' error from an SATA drive! Are you sure it's on a controller that supports optical drives? As donta said, go check for motherboard bios updates, sata driver updates etc. You could also check the sata cable is seated properly and/or swap it out for another one.

DVDFlick forces the settings on you because it specifies an ini file that ImgBurn should read from and then tells it not to save changes. If you use the program in 'standalone' mode, you won't have these problems.

It reads as much as the 'read capacity' command reports. If it's off by a few sectors, ImgBurn won't read them. You can see pretty clearly in the log window / info panel on the right just how much the drive thinks is on the disc. What does it say compared to what you expect to be on there? Also, when you load the image to burn it, does it not report the full / correct size? There shouldn't be any reason for it to cut it short - unless the data isn't a full sectors worth - it'll truncate odd amounts of bytes.

Loads of the commands are failing with the error: E 16:27:45 SENSE Interpretation: Unknown (0xA8, 0x03) Contact pioneer and see what it means, they're the only ones that can tell you / help you.

The drive is either reporting rubbish or there's some form of corruption going on. Check you've got the drive on a decent 80 wire cable and that it's set on either master or slave (check it's position on the cable too). Then follow the DMA post in the FAQ. If it still won't work, use the 'Filter Drive' option in the Tools menu and copy to clipboard + paste all that info. You could also eject the disc from the drive, press F8, insert the disc and wait until it says it's empty before pressing F8 again. Save the log to a file and upload it.

If the drive doesn't like the media, there's nothing you can do about it I'm afraid. Software can't do anything until the hardware recognises it properly (which yours isn't). See if a firmware update fixes the issue, but failing that, you'll have to try some different discs.

Take a hint please.

This is nothing to do with ImgBurn, search Google or something.