LIGHTNING UK!

If they were in the format I mentioned, it would be working Use 'MediaInfo' to examine one of the wav files.

Copy and paste everything from the Log window please.

Right, so you have a disc image file? An ISO or whatever. Mount the file in a virtual drive program and play from the virtual drive... or copy from the virtual drive onto your hdd. You can also probably extract the files from the disc image file using something like 7zip or winrar.

You haven't given us enough info to actually help you. Where is the file now? Why can't you copy it over using Explorer?

Are they in some sort of weird format? 44khz, 16 bit stereo is 'normal'.

What?! So if you set the enum method 'Device Class' or 'Drive Letter', you get 'no devices found' ? Your system is not well! I did a fresh install of Window 10 1709 (Build 16299) earlier today inside VMWare and all 3 of the enum methods work just fine. Do you get any errors when attempting to use the other enumeration methods? If so, please copy + paste everything from the Log window so I can see them.

Can't you go back to your 8 wav files and follow this? http://forum.imgburn.com/index.php?/topic/5555-how-to-write-an-audio-cd-from-music-files-using-imgburn/ You can fill out the CDTEXT info on there and it'll generate a proper CUE.

It's very strange that every command appears to be working ok, except for the actual 'WRITE' one. As I said before, the 'Incorrect function' message is from the OS rather than the drive. The OS (or some sort of driver) is messing with how things normally work. That fact you've had this issue on multiple machines is interesting... if it was genuinely an issue, I'd expect a lot more 'noise' here on the forum about it. I can't think of any reason why a 100% clean install of Windows 10 (with nothing but all windows updates) wouldn't work fine. You've definitely tried booting the machine into safe mode and running ImgBurn from there yeah? Perhaps try adjusting the SPTI enumeration method in the settings (on the I/O tab) to the other options. If Nero works (and assuming it isn't using a lower level driver to bypass whatever the issue is, maybe only one method of enumerating the drives is being blocked / broken.

It's 2448 really but 2352 is generally available for CDDA or Mode2 stuff. Mode 1 sectors just have 2048 available for user data.

I expect you need to go back to the drawing board and work out where each track really starts. How did you end up with a bin file if you're making what I assume is your own disc? Are the tracks all mixed in? If not, individual WAV files would be better. Even if they are all mixed in, you could still have a single large WAV file. Then open it in any media player and make note of the timer so you can make proper track/index cues.

That BIN file is 398,172,432 bytes in size. As a sector is 2352 bytes, that makes 169,291 sectors. The last index in your cue sheet claims it starts at 37:39:16 (MM:SS:FF) within the file. Converting MSF to sectors.... (37 * 60 * 75) + (39 * 75) + 16 = sector 169,441 Therefore, your last index point is beyond the end of the file.

Which motherboard do you have? Have you tried the current / correct Intel Rapid Storage Tech drivers for it? I assume all 3 drives behave the same way?

Have you possibly installed some software that's preventing access to the drive? The 'WRITE' commands are being blocked by something. Have you tried booting into safe mode to see if you run into the same issue? Failing that, go for another reinstall of the OS and check it functions correctly from a clean version - i.e. before you install *anything* else.

Your BIN file isn't big enough for the CUE you've got there. Where did the CUE come from?!

Right click the drive selection box and pick family tree. Close the message box that pops up and then copy and paste everything from the log window please

That's not in bytes, but I'll get it close enough

And what's the size in bytes of your bin file please?

Please attach the cue file in question.

Test mode is a flag you set (named as much) in a certain command that's sent to the drive before a burn. That flag and command aren't 100% supported by drives when burning anything other than cd and DVD media. So although the program will send it, as per your request, the drive may ignore it. When a drive is asked to enable its 'test mode', no data is usually written to the disc. It'll go through the motions of burning but won't enable the laser properly. Test mode will not detect a disc that's going to fail to burn due to defects, dust etc. It's more of a logical test. So if test mode isn't supported by the drive for that media, it'll burn the disc exactly as if you'd never attempted to enable the option in the first place.

If verify fails under normal circumstances, it'll return error 3. If you mess with the disc during the tray cycling (not easy unless you have a laptop style drive), verify never actually begins - hence no errorlevel 3 return code. I could make it return 3 there for a future version, but I'd probably prefer to return a different number so as to be able to distinguish between the 2 points of failure.

Do any error codes actually get returned for you? I've just tried with the following in a batch file and it printed out the number '1' as expected. (1 meaning no media in the drive or drive not ready) @echo off imgburn /mode isowrite /start /close echo %errorlevel% pausebtw, /overwrite and /noimagedetails don't apply to write mode.

What you've read wasn't a lie, you'll get errorlevel 3 when verify is unsuccessful. That value is only set when you've specified /start and /close as CLI parameters though.

I'm not seeing that on the DD mirror. Perhaps you clicked an advert? The actual download button is in the green box on the right... just above the Facebook widget.

Try writing at the various speeds your drive claims to support. Some may work where others fail. You could also try enabling the 'Perform OPC Before Write' option in the Settings on the Write tab. Try other discs... clean the drive with a cleaning disc... replace the drive etc. etc. Oh and you can't erase DVD-R discs, they're 'write once' media. That's why that bit didn't work.

That absolutely shouldn't be possible... to have a bad ISO I mean... to the point where the drive fails to burn it. Data is just data, the drive doesn't know or care, it's just 1's and 0's.