Falcon

Well it's obviously not the command's fault, so LUK's doing fine on that part. However, LUK is also responsible for interfacing with the drivers, something that seems to be at fault in the reason why it works under one controller but not under the other. I think it would be in LUK's best interest to investigate the cause of the hangup instead of living in dreamland where Microsoft actually cares about the drivers they bundle with the OS, and fixing bugs or limitations in their drivers. I've always thought of ImgBurn as the de-facto standard of "if it doesn't work with ImgBurn, it doesn't work at all"... and I'd hate to think that there are limitations within the program for the sole reason of the developer choosing not to fix a problem. But maybe that's just me. =\

That's certainly an unusual response I wasn't expecting... o_O So whose is it? Wouldn't you think that a goofy error like that may be causing other problems as well? I mean, I'm the first to tell anyone how much garbage Vista is, but I wouldn't expect a developer to say "oh, a problem with my program using all system default drivers and programs? that's not my problem"... *confuzed*

I thought I'd chime in here and report my problem as well. I set up a Vista x64 build specifically for low level work like Folding@Home and DVD backup... ImgBurn just threw me this same curve, in exactly the same screenshot as posted by OP. I didn't update to SP1 though, I installed it as SP1 with a whole ton of vLiting (it's installed on a 10gb HDD with 7.1gb free ATM - pathetic for just having Windows installed, none the less). No third party software is installed other than SpeedFan (to shut up that dang front fan), WinRAR, Folding@Home, ImgBurn, and good ol' DVD Decrypter. Think I might check through the drivers, maybe switch off AHCI mode, see if it helps any. The burner is a SATA drive (ironically, which I've had more trouble with in Vista than on XP) on an ICH9 southbridge, the boot drive is ATA on a secondary integrated PCI-E controller, and the drive with the burn data is SATA as well. edit: Swapped the drive over to that secondary PCI-E ATA controller and rebooted (SATA = plug and pray, more like...), and now bitsetting works fine. Evidently it's a problem or conflict with the Intel AHCI drivers. May want to look into that?

Google led me to this, so I figured it's worth a bump. Honestly, I'm logically led to believe I should be able to open, or otherwise import, an existing CUE file (created by ImgBurn, for example), to do further manipulation to it. I rarely want to make the same disc twice, but I may want to make a similar disc based on a previous one. For example, last night I burned someone an audio CD with ImgBurn, but today someone else wants the same disc, plus one extra song. I'm just glad I copied all the music on the disc into a single folder, so drag-n-drop is easy, but imagine if I hand-selected songs out of a large music library? LUK, is it very hard to add "open" functionality to the existing "create" system, or is that something reasonably requested? As a PHP web designer myself, I can understand the pain if it wasn't designed with that function in mind, so I can understand if it won't be added. But I would like to put in my vote for a future feature

If I may add... FAT32 should NOT be used with XP or 2000. You might oughtta wanna run the convert tool on that drive to make it NTFS. It'll be faster, more reliable, and more stable (Of course, then you should defrag it with a professional tool - Paragon Total Defrag is capable of rewriting and optimizing the MFT so it'll run even better)

[derailed trainwreck] My god, you are so misled. Torrents are the WAY of the FUTURE for data distribution. Don't buy into bullshit clients like BitComet or "hybrid" clients like Limewire that claim to do more than one type of network. If you want torrent software, get

Yeah, I could cram that, fully functional, onto a CD-R. (BTW, there's always MS Virtual PC, which is free for anyone using XP Pro... ever considered using that instead of DVDs and RWs? ) I <3 optimizing shit. As for distribution... I have to ask, because many people seem to totally miss the boat here. Have you ever heard of TORRENTS?

[offtopic] Yeah... Process Explorer's CPU usage also went through the roof as well. IMO, a program that monitors process performance shouldn't be eating up 20-50% CPU just to do its job... o_O I kinda have a mix... I'm not totally anti-Microsoft but I do dislike that they bought out Sysinternals. They should have been left to do their art alone. Sigh... edit: LULS! Hah... thanks! Yeah, one sec, lemme gzip those (server side) and link it. editedit: Here you go... smileys.tgz. Wow, server-side processing is effing COOL. I tar-gzipped it straight to my FTP-upload user account, then ran Hostfile's FTP import script, which snatched the file and put it in its proper place to be hosted online. Two minute job, including download to verify. There's also a copy of some VERY EARLY Hostfile.org code in there (index.php), but none of that code is relevant in the current rendition of the site, so it's OK to be released. [/offtopic]

This should clarify a little more: Programs only ask DirectShow to play ("render") something. DirectShow is part of Windows. So basically, programs are asking Windows to play something. If Windows can play it, the program can play it. Since Windows Media Player is pretty much a front-end for DirectShow, you can bank on using WMP to test if ImgBurn can play something. If it can't, ImgBurn wouldn't be able to. If you want to make ImgBurn be able to read something, Google around for how to make Windows Media Player play it.

Astoudndingly, the only lowercase filename in the i386 folder on my hard drive that I noticed is "setupldr.bin" - the file referenced in the binary code of the boot sector (boot.bin - or commonly known as "Microsoft Corporation.img") is "SETUPLDR.BIN'. Never woulda thought that a case change would make that much difference. =P edit: NTLDR is for hard drives, but since they share the same loader code, M$ probably opted to recycle the old code in the setup bootloader (since they don't expect people to change it). So they left the misleading "Couldn't find NTLDR" text there...

Shit, I got so involved last night that I forgot to add: it installs perfectly Now ImgBurn has a new purpose in life: burning my WinXP discs! Oh... and at a binary level (the ASM used in the tiny 4-sector boot image, for example), I'm sure MS couldn't cram in case-insensitive code, that's probably why

Okay. Update time. I tried booting from a disc created with the new version of the OS CD detection mechanism. Still no dice, still the same exact error (CDBOOT: Couldn't find NTLDR). NTLDR should be setupldr.bin (but I think it's misnamed here). I asked it to make changes. Unfortunately, it ignored my option of filesystem choice (at the time, ISO9660+UDF). It only corrected errors for the current choice, it seems. It tried burning the OS CD using ISO+UDF, seriously. I'm no (real) expert, but I think that won't worky. I switched it instead to pure ISO9660. Here's the kicker: if I remember correctly, it's Joliet that allows lowercase filenames. Funny thing is, I have mixed case filenames on the resulting disc. How'd that happen? Lots of filesystem weirdness going on in here. Not sure what to make of it. I'll play with some settings... =\ edit of the century: Oh, how ironic. After about 10 image creations and testing in Microsoft Virtual PC, I found that ImgBurn's own correction was causing the problem. The filesystem character set must be STANDARD, not ASCII, as is suggested in the dialog. Switching it to Standard and making no other changes to the suggested options (which I screenshotted and changed back in the main GUI), caused the disc to now be bootable. Yay! edit edit: Okay, that got it booted, but that would not make it install (in theory). After ticking the option to log changed ISO9660 filenames, I found that several critical filenames were changed - like $OEM$ to _OEM_. To avoid that, I changed the mode to DOS instead of Standard (instead of ASCII by far). Now it only changed the case of several folder names, and since Windows is a case insensitive operating system, it'll work just fine (again, in theory). It also booted just as well. The only one that doesn't boot is ASCII. Now, on to the real world test - installing it on a real computer.

Alright, well, thanks anyway! Oh, and I saw the work you did on the new "OS install CD detection" dialog. Sweet work, thanks for listening!

That's very strange. It's a brand new (well, relatively - about 3 months old) SATA Samsung (TSST) DVD+RW drive. A very old disc though (which means it should be well supported). And like I've mentioned before, I've only written it in drive A (TSST) -> read it in drive B (Sony DVD+RW) -> tried writing it in drive A again (TSST) and it then says it's no longer formatted. And I hate formatting the disc - I actually posted this in an effort to try keeping from doing it yet again! So far I've bypassed the "properly formatted" check and it works like a dream, I've rewritten it at least 3 times today and it works quite well. For me and DVD+RWs (even another brand I tried in the past), keeping a disc formatted seems to be a roll of the dice problem. 'Sup with that?

No, in fact, the disc still contains data from the LAST time I had to do a second full format due to ImgBurn's apparent glitch. Nothing at all was written to the disc between the last time I used ImgBurn to burn an image, and this time. However, it may be a strange condition that I don't use DVD+RW's for video data. Most people probably expect to use that. I use it to burn images typically burned on CD-R/RW's, and maybe it contains data that's messing up the format in ImgBurn's eyes. I did (thanks to that topic) find the option to not necessarily prefer "properly formatted" DVD+RW's. But it is very strange that ImgBurn would randomly slip from "Formatted: YES" to "Formatted: NO" after only some READING actions in another computer... =\

Okay... odd problem. I like to use DVD+RWs for my OS installations whenever possible because they burn fast, and install even faster. However, with my drive and ImgBurn, I'm encountering an odd problem. Sometimes ImgBurn likes to tell me the disc isn't formatted - when it VERY CLEARLY is (by the fact that there's readable data on it, and it's acting like a normal disc!). Book type is DVD+RW. It identifies it as a DVD+RW. It identifies the data on it (by the TOC information), it identifies that it is formatted. But it continues to tell me that I can't burn it without a FULL FORMAT. Full formats on DVD+RW's, as I've read, shorten their life. If I understand DVD+RW structure as well, it also erases the bad sector information and leaves it to start from scratch again. Bad stuff. I'm not doing another full format on this disc. I also only have precisely one DVD+RW disc to work with, a 4x Memorex disc. What is the up? Here's the full status page: ---- TSSTcorp CDDVDW SH-S203N SB01 (ATAPI) Current Profile: DVD+RW Disc Information: Status: Complete Erasable: Yes Formatted: No (Started) Supported Write Speeds: 2.4x, 4x TOC Information: Session 1... -> Track 01 (Mode 1, LBA: 0 - 2295103) -> LeadOut (LBA: 2295104) Physical Format Information (ADIP): Disc ID: INFODISC-A10-01 Book Type: DVD+RW Part Version: 2 Disc Size: 120mm Maximum Read Rate: Not Specified Number of Layers: 1 Track Path: Parallel Track Path (PTP) Linear Density: 0.267 um/bit Track Density: 0.74 um/track First Physical Sector of Data Area: 196,608 Last Physical Sector of Data Area: 2,491,711 Last Physical Sector in Layer 0: 0 Physical Format Information (Last Recorded): Disc ID: INFODISC-A10-01 Book Type: DVD+RW Part Version: 2 Disc Size: 120mm Maximum Read Rate: Not Specified Number of Layers: 1 Track Path: Parallel Track Path (PTP) Linear Density: 0.267 um/bit Track Density: 0.74 um/track First Physical Sector of Data Area: 196,608 Last Physical Sector of Data Area: 614,047 Last Physical Sector in Layer 0: 0 Current Format Capacity: Sectors: 2,295,104 Size: 4,700,372,992 bytes Time: 510:03:29 (MM:SS:FF) Preferred Format Capacity: Sectors: 2,295,104 Size: 4,700,372,992 bytes Time: 510:03:29 (MM:SS:FF) Maximum Format Capacity: Sectors: 2,295,104 Size: 4,700,372,992 bytes Time: 510:03:29 (MM:SS:FF)

Hey, I've got over 10 years of Windows PC experience under my belt, I can fix anything, I live with sysinternals.com tied to my belt loop, and I'm not afraid of messing things up. I think I'd make a great beta tester. So yeah, I'm not Mr. "why my burn doesn't do disc rite? do i clik here?" asking for "da newest and stuff version!11".

I've been known to: 1) create a Windows install disc ISO with nLite then burn it with ImgBurn (like I am at this moment) 2) create an audio CD in Nero, write an NRG, and burn it with ImgBurn... 3) create a bootable disc image with VFD (Virtual Floppy Drive/r) then make a bootable CD/DVD with ImgBurn... 4) go out of my way to find a way to make a program spit out an image instead of burning, so I can burn it with ImgBurn. ImgBurn just rules that hard. It tells me everything about the drive. It IS everything I'd ever need to do with any optical drive. It's the universal do-all know-all burner program. It solves all problems and ends world hunger. Now if only it could do its own disc-scanning without relying on a payware/bugware/mehware program like DvdInfoPro... but then again, ImgBurn is just that (ImgBURN), right?

You may be the coolest developer ever. Thanks!! (Can I get a test version? Heh)

Well, I was saying it didn't do shit, because in that confirmation dialog overviewing the settings (after telling it to make the corrections), it still said ISO9660+UDF and all the old settings, which I at least know won't work for a Windows install disc (Windows can only read UDF after it's installed, dur!). Now, I'd been able to create image-based bootable discs before (using a floppy image)... but on another note, using that mechanism, I do wish it would let me burn a "CD floppy" without any files (just the bootable floppy image). Heck, even the Windows disc itself boots. It just doesn't seem to create the right filesystem. =(

Hey, I'm curious as to what the prompt asking: "Your image contains a 'I386' folder in the root directory so I'm going to assume it's an Operating System installation disc. That's fine by me, except you have some conflicting settings that could stop it from working properly. Would you like me to adjust the settings for you?" ... actually does. I do a bit of Windows CD burning (every time I install Windows on a computer, I make a custom disc for it with nLite). Usually, I leave the task to nLite itself, because it knows what it's doing most of the time. Sometimes I make an ISO with nLite than burn it with ImgBurn. But whenever I use ImgBurn's "Build" mode to make it, even after setting up the boot options (boot using the boot sector, load 4 sectors, no emulation), I end up with a coaster. Thank goodness I use CD-RW. I figure that the prompt would correct differences between burning a DVD-Video disc and a Windows disc, like ISO+UDF filesystem and ISO+Joliet filesystem. I don't know the exact options needed for making a Windows bootable CD (it's always been a dark art to me, CD filesystems...) so I would have hoped the question about CD options would fix that. However, it didn't change a thing when I answered "Yes". It left it as ISO+UDF and burned me a disc that boots, but gives "NTDETECT failed" (or something like that) when it goes to load Setup. What's it supposed to do? =\

Well, bright red would typically mean "Do NOT select this or your computer will explode", so I don't know that a bright red star would be used any time soon. Colored smileys, perhaps? =P Actually, I think what would be more beneficial would be to explain, somewhere (like here), what makes a position "good" etc... so you can pick for yourself. Or turn the stars into their own column and let you sort by it.

I still say my solution is more elegant and doesn't require a reboot. ^-^ edit: in fact, can even be done while the disc is burning, under some configurations, I believe.

Hrrm... how to say this. =P So sometimes I open ImgBurn and it automagically picks 1) the last burner selected, and 2) the last mode I was in. If there's no disc in the drive, that's all cool, because it just scans the drives, finds no disc in the selected drive, and lets me pick a new mode or drive. But if there IS something in the drive, and say, the disc is scratched, or the drive (which I may or may not have intended to be selected) is having trouble reading the disc, I'm sitting there with an uncontrollable program that's just doing its own thing! (Wow that was a long sentence.) So I have to eject the disc if it's jammed... and what do I get? A flood of errors reaming me out for having ejected the disc! Gaah! Finally if I ever get back to the main screen through the endless flood of "major error" messages, I get to select a new burner or a new mode. Yay! How about a way to abort the initialization process, leaving the program "not ready" but able to select a new mode or burner? Or maybe leaving the burner selector and "mode" menus un-greyed-out and aborting the process when it changes? That would really, really help some of my hair... it wants to NOT be pulled out!

Yay, the magic phrase was finally uttered, PIO. I got that clue early on, when someone mentioned that the CPU usage spikes when the buffer dies. PIO = using CPU to move data around, at very slow speeds. Normally this data-movement is done by the controller. At any rate, Windows hit its infamous problem of decreasing maximum transfer rate, for no apparent reason, without being able to restore the maximum speed via any user interface. Oh, how I love Windows. It tends to create threads this long for such problems. (I'm high as a kite right now so... pardon my rambling. XD) Run this... then go back to device manager, set to PIO mode, then back to DMA. Bam, on the fly, you'll be set to UDMA mode once again, and your burning problems will be no more. FixDMA.reg It tells Windows to quit limiting your disk drives... it writes to the most common location for the ATA controller settings, so it should work. Wonder why this thread went dead before the solution was found though?