LIGHTNING UK!

It could be that the 2 image.dat files are just raw sector dumps, the same as an iso. are their sizes a multiple of 2048? try and open the one from the layer 0 folder in Write mode. if that use the ‘create .dvd file’ option in the tools menu and add both files to the list. Specify the layer break as whatever the size of layer 0 image.dat is, divided by 2048. Save the .dvd file and then load that in Write mode. you could test the .dvd file by mounting it in virtual clonedrive. If you can see the contents by browsing the virtual drive, go ahead and burn the .dvd to disc in write mode.

Find a program that mounts CDI files and then just perform a 'Read' operation on the virtual disc.

Yes, having that line in the file means ImgBurn doesn't have to run a dummy decode to get the correct output file length from the directshow decoding routine. MP3 isn't a lossless format anyway, so a few frames here and there probably won't hurt. You'd be using a different format if you really cared about faithfully reproducing the original format (and they came from CD). The decoding is all done in memory. No intermediate file is ever created. I feed the file into directshow and then just keep asking for the next chunk of output data until it says it has finished decoding.

Can you capture that in a video? Are you using standard or advanced input mode (basic box or the disc layout editor window) ?

I should imagine the timeout error that occurred before the one you’re asking about has caused the drive to reset internally or something. When ImgBurn has then asked it to do something, it simply wasn’t ready to receive the command yet and that’s the reason it gave.

If your drive can't produce a nice burn on the disc you're using at any of the speeds it claims to support burning them at, enabling defect management as per the thread you linked to on redfox forums might not be a bad shout. Enabling the 'perform opc before write' option may or may not help too.

Without doing quality checks on the burnt discs, it's hard to know if your drive has burnt them nicely. Assuming it has and the error rates are really low, it's a case of the laser in your PS1 not liking them - possibly just not liking any burnt discs in general. If it can't read the disc nicely, you'll get stuttering. I seem to recall that it is possible to tweak the laser power and improve things, but you do have to be careful or you could make things worse

Use advanced input and the disc layout editor window.

Post a log from the burn + verify process please.

ImgBurn is not the tool for this job. Try here instead: https://www.thewindowsclub.com/convert-physical-machine-to-virtual-machine-virtualbox

The whole reason for this thread is that the files on the disc don't have the file extension they started out with. The original 'mkv' file extension has been lost and they've taken on a new one based on what's after the last dot/period in the file name. This post showed what the disc looks like in Explorer...

The only way I can see this happening is if you use the 'Disc Layout Editor' to change the name of the files and manually remove the '.mkv' file extension from the file. If that's the case, I'm afraid it's user error. The DLE shows the full name (name inc. file extension) of the file as it'll be written on the disc. If your OS is then configured to hide extensions, it'll hide the last 'dot' and anything beyond of whatever the full name is. So, with 'show file extensions' disabled in Explorer, it might display a file names as 'name1.name2.name3'. ImgBurn's DLE window would show 'name1.name2.name3.ext' once added to the compilation. Once burnt and viewed back in Explorer, you'll just see 'name1.name2.name3' again. If you edit the name in the DLE window and remove the '.ext', you're essentially turning '.name3' into the new file extension. Explorer will then only show 'name1.name2'.

I just did a quick test on a dummy file with several dots in its name. Outputting to ISO and then mounting with Explorer. I was unable to reproduce the problem here of the extension getting lost. I tried with Joliet, UDF 1.02 and 2.60. Please post the build / burn log.

It has nothing to do with any of that.

What’s the reason behind trying to create an iso from your usb stick rather than using the iso you originally downloaded? The original iso was meant for burning to disc. What Rufus has created on your usb stick isn’t.

^^ “Free time” ^^ Which I have zero of as I also have a wife, 2 young children and a house to look after!

The update firmware may or may not improve things. https://www.firmwarehq.com/Lite-On/iHAS122/files.html It may eventually recover if you leave it for long enough btw.

I'd say to flip flop between it being on / off if you're having trouble burning some discs with whatever its currently set to. There's no hard and fast rule for when it should / shouldn't be used.

It's only for CDs. I'm pretty sure you can write any sort of data (type of disc) you want when using DAO96. Note: ImgBurn doesn't support it, so there's no point in talking about it on this forum really.

If you've posted at videohelp, why are you doing a copy+paste here? Pick a forum and stick with it. TAO doesn't apply to DVD/BD, it's only for CD.

If you can take an image of a disc that doesn’t play and burn it again with ImgBurn so it then plays, it could be something like booktype/ bitsetting. Are you using dvd+r format discs?

Program Director (by unknown) or Power Director (by Cyberlink) ? If it's Power Director by CyberLink, I like to think they'd know what they're doing seeing as they make one of, if not 'the', main (licensed) DVD video player software for Windows (PowerDVD).

ImgBurn can read some images in those formats and burn them to disc, that’s all. Dmg is Mac, so you’ll need to go looking in that direction for help with the file format. Pdi and gi are both proprietary formats and you’ll probably be lucky to even find the tools that created them. I think pdi was pinnacle instantcopy and gi was something related to roxio. All of this seems like a waste of time given that burning disc is very much a thing of the past for most people. Maybe you’re looking to emulate something?

It's a 'read ahead' buffer (held in memory) of the image you're burning - be it from an actual image file (iso etc) or created on the fly when burning files/folders to disc.

It's just a descriptor in the file system. There's no 'Microsoft API' involved where ImgBurn is concerned as I'm creating the descriptor from scratch at Byte level. If programs / OSs support reading from it, it'll work as intended.