Can't burn .ISO files for some reason

Hello, I’m wondering if someone could help me out here. I’m not new to burning. I’ve been doing it for roughly 5 years on a daily basis.

The problem I’m having right now is that I recently did a format on my computer and now my software/hardware isn’t allowing me to burn .iso files. I’ve done many formats in the past and I’ve never run into a problem like this.

I’m using RecordNow Max 4.5, with 358px engine update. I’ve also tried versions 4.0, 4.1 and 4.6 with many different px engine updates and I’ve had no luck. My burner is a Pioneer A04, with firmware version 1.40. I’m also using Windows XP, with service pack 1.

What’s happening is, I can burn .gi files fine, I can burn data and audio files just fine. I can make VCDs and SVCDs just fine. I cannot however, burn a .iso file. I’ve tried multiple .iso files, mostly over 2gb, and they’re stopping around 60% - 85% of the way through and giving me an error.

Here’s the error:

ID:0 (D: ) - Pioneer DVD-RW DVR-104 Stopped because of job error -20

I get this error both with real recording and during a test burn.

That’s all it’s saying, nothing else. I’m pretty certain that it’s not the media, because I’m using Ritek G03 discs, which I’ve burned many times with this same burner and software. I’ve tried different blanks and even different brands, with no luck.

If anyone could help me, it would be much appreciated as I’m pulling my hair out trying to figure this out. Thanks in advance for any help.

It’s very possible the .iso may be corrupted.

Have you tried mounting the .iso on a virtual drive and it worked?

It’s happening with all .iso files, not just one.

Just a little more info on my problem. With Nero everything is fine until 62%, then the “Used Read Buffer” drops all the way out, I get an “Error Reading Data” error at the top, then at the bottom it says “Record State: Failed”.

This is really frustrating because I know my burner works or it would not record every other format I throw at it. I know the software works, because I can burn all other formats fine with it. I know the discs are good, because I can burn a .gi file on them with no problems.


Try extracting the contents of the ISO with ISOBuster then attempt to burn the extracted content.

I’ve figured out and fixed the problem. I should probably explain here, so that this board has record of it, incase anyone in the future runs into the same thing.

Recently I bought a new video card, that was just gigantic. It caused me to have to replace the IDE cable that was running from my two, 200gb hard drives, to my ATA 133 card. Having installed new RAM and also formatting my computer on the same day, I didn’t think anything of switching the cables.

However, that was the problem. The new IDE cable, even though it was a 133/100/66 compatible cable, was actually the wrong type of cable. The difference I’ve found, is that normal IDE cables are 32-bit and the one that came with my ATA card was 48-bit. The 48-bit allows for large files sizes to be utilized on large capacity hard drives. This means, everything works fine, except large files and a handful of specific and smaller 1mb - 4mb sized files, because even though Windows knows what to do with the files, your cable doesn’t. So it gives you a “path is too deep” error, or simply ruins all your burns and gives you generic error messages.

I’ve fixed the problem by replacing the cable again with the original, though it’s still not long enough to connect to both of my hard drives. So now I’m shopping for a proper ATA 133/100/66 cable that is 48-bit, which seems very hard to find at even the best online stores as they do not list cables by “bit”, but rather by the 133, 100, 66 label.

There’s no such thing as a 48-bit LBA cable, nor is standard IDE 32-bit (it’s actually 28-bit LBA and a 16-bit data bus).

The IDE interface is no different electrically in 48-bit LBA mode to 28-bit LBA mode (which, with 512 byte sectors, only supports 2^28 * 512 bytes, which works out at just over 137GB, using the hard disk convention that a gigabyte is 1000^3 bytes, or 128GB exactly, using the binary gigabyte of 2^30 bytes).

There’s not suddenly a load of extra wires in the IDE interface for 48-bit LBA! Anyone that’s marketing a cable as a 48-bit cable is marketing based on FUD (Fear, Uncertainty and Doubt) - or, being more charitable, is trying to persuade the buyer that their cable is a high quality product especially suited for the latest large hard disks. The requirements for 48-bit and 28-bit so far as cables go do not differ; you need a cable that is capable of the maximum speed in use on the IDE channel - which means a good quality 80 wire cable for UDMA/66 and upwards.

The only difference between 48-bit and 28-bit LBA is in the command structure; an extension to the ATA command set is used that passes addresses in a 48-bit format rather than a 28-bit format so each command is a little longer in a 48-bit LBA environment than in a 28-bit LBA environment.

I think the real answer to this was revealed by your comment about cable length, with the working cable being too short. Whilst the use of IDE cables longer than 18 inches (45 cm) is common, 18 inches is all that is permitted by the IDE standards. The published ATA/ATAPI-6 specification, which is the current one, isn’t available online, but reference is made to the section about cable length in one of the documents on the T13 web site (T13 are the official guardians of the ATA/ATAPI standards) that you can read here (the paper is a proposal to allow 27 inch 80 conductor cables using a host adapter with a special 80 pin connector, rather than the standard 40 pin).

I am pretty sure that all the published ATA/ATAPI-6 standard allows is 18 inches, which means that the commonly available and commonly used 24 inch (60 cm) cables are in breach of the standards. Even though the report quoted argues that, in the tested case, an extra 9 inches on the standard 18 inch cable doesn’t cause significant impact to the signals (and backs it up with some traces taken from a very expensive oscilloscope), your problem could well be subtle corruption on a longer cable, especially if the cable is snaking around electrically noisy PC innards or happens to be of low quality. I’m pretty sure, by the way, that the proposed amendment in the paper I gave the link for above wasn’t passed - and I can’t think there’d be any will for it in ATA/ATAPI-7, seeing as things are gradually moving over to SATA.

There’s several possible ways to connect your hard disks if an 18 inch cable is insufficient and you can’t juggle the drives in the case. There are cables available, particularly round cables, that have added screening over and above the 40 ground wires of an 80 wire cable - and that might work, though it’s still a standards breach.

Another alternative is to switch to an SATA controller (or use existing SATA ports on your motherboard). Highpoint makes a little adapter that goes on the back of an ordinary IDE drive and allows you to use an SATA cable - this adapter it’s not very expensive, and SATA cables can be up to a metre long. No reviewer has mentioned problems from using it, though I have no direct experience of it. It’s likely to be little more than a serialiser/deserialiser chip; if the internal design is OK, it should work correctly.

Indeed, it’s better to have a hard disk on an IDE channel by itself - as IDE, unlike SCSI, cannot multi-task I/O between two devices on the same cable. When an I/O request is outstanding with one drive, the other drive is inaccessible. I believe this is one reason why SATA has gone with the ‘one drive per channel’ approach.


can anyone help ive got a lot of mp3 and cdg files i want to put on cd to play in dvd player but dont know how can anyone help