Guest Sebastian Mares Posted March 6, 2006 Posted March 6, 2006 Hi! I get the error that ImgBurn does not support multitrack images when loading a MDS file, but the disc image has only one track. Any idea what went wrong? Sebastian
LIGHTNING UK! Posted March 6, 2006 Posted March 6, 2006 It can't have - or at least not according to the MDS file it doesn't. If you're really really really sure it's only a single track one, post the mds file up here (or email it to support) and I'll take a look at it.
Guest Sebastian Mares Posted March 6, 2006 Posted March 6, 2006 I sent you the MDS. I am not 100% sure that the file has only one track, but MagicISO (and WinISO IIRC) reported only one session with one track.
LIGHTNING UK! Posted March 6, 2006 Posted March 6, 2006 Might aswell update this thread even though I replied via email.... It's a CD image and it would appear that by definition, they don't ever just contain 1 track - hence the value I check is always more than 1. This has now been fixed. That doesn't mean I recommend using ImgBurn to burn CD images when they're in MDS/MDF format. ImgBurn doesn't take into account any of the 'special' bits included in the image file - basically, it doesn't burn in 'RAW' mode.
Guest Sebastian Mares Posted March 6, 2006 Posted March 6, 2006 Just wondering - are there any special reasons why you don't want to add support for RAW writing?
LIGHTNING UK! Posted March 6, 2006 Posted March 6, 2006 Erm.. besides hassle?! It's not really needed for day to day image burning. If you NEED a tool that burns in RAW mode, you're always better off using the tool that made that RAW image in the first place.
fordman Posted March 9, 2006 Posted March 9, 2006 That doesn't mean I recommend using ImgBurn to burn CD images when they're in MDS/MDF format. ImgBurn doesn't take into account any of the 'special' bits included in the image file - basically, it doesn't burn in 'RAW' mode. How about .BIN files that have 2352 byte sectors? Programs like the old CDRWIN call these RAW images, and will burn all 2352 bytes for each sector. The author (Goldenhawk) in the help file suggested that this was only a good idea for 1st generation burns of a copy direct from the original. Otherwise one should allow the drive to write new ECC information in the area beyond user data (2048 bytes for mode 1/2336 bytes for mode 2) in each sector. I recall there were a bunch of programs that would "COOK" such an image to allow you to burn it with CDRWIN to allow your drive to create it's own ECC. These program would convert 2352 byte-per-sector images to 2048 (for mode 1) or 2336 (for mode 2) byte-per-sector images to accomplish this. So, what does ImgBurn do when one burns, say a 2352 byte per sector BIN image (single track of course)? Does ImgBurn simply disregard any bytes beyond the 2048 or 2336 of user data on-the-fly while burning? Or does it faithfully copy all 2352 bytes to each sector? I suppose the latter would be true RAW mode writing, so I'm assuming it doesn't do this.
LIGHTNING UK! Posted March 9, 2006 Posted March 9, 2006 That's not really RAW as I think of it, that's just the full sector. You can burn 2352 in normal SAO burning mode, and yes, ImgBurn supports that. You need to use RAW mode when burning subchannel info etc. That equates to a 2448 sector, which is what I'd assume alcohol is producing. It also gives you full control over leadin area - normally the drive does all that. I always send the full 2352 bytes to the drive if it's available in the source file. If the drive doesn't support 2352 (I'd found some old pioneer 104 drives didn't), I had to flick back down to sending 2336 bytes and manually convert the sectors myself. Most of the time though, the drive will only actually look at 2048 (well, for MODE1 data anyway), and as you mentioned above, the drive regenerates the ECC stuff itself.
fordman Posted March 9, 2006 Posted March 9, 2006 You need to use RAW mode when burning subchannel info etc. That equates to a 2448 sector, which is what I'd assume alcohol is producing.It also gives you full control over leadin area - normally the drive does all that. Ahhh, thanks for the clear explanation. I didn't realize one could have more than 2352 bytes in a sector - I was curious where the subcode info was stored, and assumed (incorrectly) that it was within the 2352 bytes!
Recommended Posts