LIGHTNING UK!

Say you drag a folder with the following path into the source box or DLE window... C:\Users\Me\Documents\stuff With 'preserve full pathnames' on, you'll end up with the 'Users' folder in the root of the disc. With it off, you'll end up with the 'stuff' folder in the root of the disc.

Can you post the log please? I believe what's been modified gets mentioned in there. It might help us understand why.

Yes, the drive specs will detail the speeds at which it can read different media types.

The .CDT file is a straight/raw copy (dump) of CD-TEXT as it was on the original disc. Using it is the best way to reproduce what's meant to be there, so no, don't delete it (*unless the original is also unsupported and then you could replace it with text that actually works) Can your player read the CD-TEXT ok on the original but not the copy? If it can't read either, I'd say it's because it contains something your player doesn't support. Do the non working ones have anything in common? Number of tracks, certain characters in the performer / track names etc?

Yes, it’s restricted.

Ok, thanks for the background info. Sounds to me as if RetroArch just doesn't support CDDA binary images/cues... in the same way VLC doesn't. You could enable verbose output from it and see what actually happens when you load the CUE into it - I assume you're actually mid-game at that point? It has some way of outputting the log to a command window yeah? Maybe you just need to have loaded it via CLI. I've taken that idea from here: https://github.com/libretro/RetroArch/issues/5451

Can’t retroarch use a real (virtual) drive? I guess it all depends on which emulator you’re actually trying to use with it. Is there some old amazing player available to it that you want to use? The more details you can give us, the more chance we have of recreating your setup and being able to assist.

VLC might work with CUE sheets where each track is its own wav file or whatever, but it doesn't appear to support playing from a single binary (raw dump of the cd) file. Mounting and playing from the virtual drive might be your only option - but then you need a virtual drive program that actually supports audio and WinCDEmu doesn't.

Yes, it’s at fault. I edited my previous post as you were just writing yours. Please take another look

No, it should work fine with the default settings. It should not be this difficult! I’ve no experience of wincdemu, I only use virtual clonedrive and daemon tools. A quick google suggests it doesn’t support audio. So perhaps give daemon tools a go? It’s the most feature rich and mature virtual drive program by far.

They look pretty bog standard, I can’t think why they wouldn’t mount and then play in media player. Doesn’t wincdemu give you any sort of error message?

Can you post the log from you reading a disc that you say won’t work in bin/cue format please? There should be no problem mounting the cue in DAEMON Tools and playing from the virtual drive in media player. Don’t mount stuff directly in Windows, it only supports basic iso images really.

CCD files only work if the image is named *.img So if the app is set to create them, it'll rename the *.bin to *.img

No, I never mentioned the file systems. They’re something that’s part of the iso (user data) and are generated and written by the program. The TOC is something completely different. The disc layout editor window’s usage bar is there for a rough guide. It’s the ’calculate’ button back on the main form that tells you exactly how much your files (inc all file systems) will take up on the disc.

No, sorry.

No, Windows doesn't natively support BIN/CUE.

If you want it to make a BIN/CUE from your Audio CD and it's making a BIN/CUE, there's little more it can do. Playback issues aren't really an ImgBurn issue, you'd have to take that up with the programs you're trying to use them with.

For playing them, yes. They won't help with copying them though.

As we are just talking about reading here, not burning, OPC doesn't come into it. This looks like copy protection to me. SafeDisc or SecuROM. ImgBurn won't be able to do anything with those discs I'm afraid.

What the drive reports for free capacity on the disc is what you can fill up with *your* stuff (user data area). It should not be changing with every disc you use - assuming they're the same type etc. You don't need to consider things like TOC, leadin, leadout etc. They're all handled internally by the drive and do not interfere with what's available for user data.

That's not how it works. ImgBurn doesn't have to deal with the size of things when closing the disc, the drive does. So your drive hasn't burnt/finalised the disc correctly.... which is to be expected I guess as we already know it failed to burn it and forced you to reboot when it was meant to be finialising the disc, rather than completing nicely and returning control to the program. I'd be amazed if you could actually read 20+ GB off that disc. I'd expect your drive to error our the second you try to read beyond the last LBA - which is 5898559 according to it (and therefore ~11 - 12GiB of data).

Just to explain that, it's due to the entire log from the most recent instance of ImgBurn being saved at the top of the file (but still with individual lines in oldest to newest order), rather than the bottom. I'd need to just be able to append to it so as to avoid writing out the entire file to the disc each time a line gets added.

The only way that would work is if it saved to a secondary log file. The layout of the current one doesn’t lend itself to writing line by line.

This is a support issue, so I've moved it to the appropriate forum. If you go into Read mode and put that disc in the drive, maybe something from the Disc Info box on the right will explain why DVDInfoPro is listing the size as it is.

It saves the contents of the log window to the file when it's closed down. So you'd only lose it by terminating the process in task manager or wherever.