fordman

Hi blutach, Yes, indeed they play fine and are unaffected by this - it's just an aesthetics and usability issue, as I often use the volume label to quicky indentify the DVD without having to play it, and that's the only reason I bother to change it in the first place. I was not complaining at all by posting this here. I merely wanted to alert others that 2.3.2.0 works OK for changing the volume label in case that matters to them. I only mentioned the number because it took me that long to notice it. Thanks, fordman

I've had a PM discussion with LUK and he has verified that there is a bug in changing the UDF label on an image - the symptom is that the ISO9660 label is changed, and the UDF label will be changed in one area of the image (sector 32), but not further in (usually sector 262 or close to that), and this is the location where Windows Vista and tools like ISOBuster pull the UDF volume label from. The temporary fix is to use 2.3.2.0 for changing volume labels. 2.3.2.0 correctly changed the first instance in this higher sector, and therefore your desired new volume label will be displayed correctly in windows. You can continue using 2.4.0.0 after you change the volume label to burn the image... I just thought I'd post this warning so others will not continue to experience this undesirable behavior. I have no less then 12 burned DVDs that are negatively affected by this... fordman

I agree with blutach that this is very odd. As for a plugin causing it, I NEVER received the warning message with 2.3.2.0 on this same computer, and was burning with it right before installing 2.4.0.0. Then once I installed 2.4.0.0 I received it with my very first burn attempt, and the log showed a list of progams with "access denied," and it looked like just about every process that I had running, including Symantec Antivirus modules. I let ImgBurn continue burning despite it the message for the first two instances and the burned copy compared exactly to the image. I have since encountered times when having internet explorer open did not cause and issue, but then later it will. The only sure way for me to avoid the message is to close all other programs before beginning a burn, and then to start them after burning begins. Over in the DVDFab forum in CDFreaks, you can see the author made a new version with one fix being to work around the "unable to lock volume for excluse access" in ImgBurn 2.4.0.0, and he had previously allowed Imgburn as the burning program to be called from within DVDFab, so perhaps there was a change from 2.3.2.0 to 2.4.0.0 that makes this check by ImgBurn much more agressive? I can only conclude that since the DVDFab author found it necessary to recode DVDFab once 2.4.0.0 was released and users of DVDFab began getting this error. Apparently there were no such complaints wit 2.3.2.0...

I have to admit that I'm encountering "unable to lock volume" messages with 2.4.0.0 while I never once had that with 2.3.2.0, and when I ran process explorer (from sysinternals/Microsoft) and searched for "cdrom" in the handles, it showed that internet explorer was utilizing the DVD writer! Strange, but once I closed all instances of internet explorer it burned fine without the error. This is on my workplace system where I'm locked to user mode and antivirus scans run regularly. So, now that I'm using 2.4.0.0 I make sure that I close everything before using ImgBurn, and then open them back up once burning starts...

That has happend on some images for me with all versions of Imgburn that had the LB selection and preview capability. I would estimate it happens in 1 out of 5 burns. To regain control of the LB selection window, I have gotten in the habit of bringing up the task manager and killing the ImgBurnPreview.exe process, which allows me to close the LB selection screen properly. Since I could see the hard drive was being accessed, a few times I just waited and eventually the preview screen did pop up, but it took a couple minutes. So, it seems that some images may take longer to "parse" to get to the selected point. fordman

Yep, I just replied to LUK's message without looking at the whole thread - my mistake. Thanks for the explanations! fordman

OK, you've piqued my curiosity - what is '49'? the 49th item on the wish list which could not be implemented for this version, perhaps? This worked well for DVD authoring, but I'm really anxious to try it for audio CDs now! What is the MP3 decoder that you are using when using MP3s to make an audio CD, or as the changelog suggests, are you relying on directshow filters, so it's likely using whatever media player uses for decoding? Thanks for the massive release! fordman

Great - that sounds exactly how the old CDRWIN (Goldenhawk Technology) did it. The ability to read nonstandard pregaps seemed to vary with the choice of reader, however. CDRWIN would create both INDEX0 and INDEX1 times needed to create a nonstandard gap on some drives, but not on others.

Oh, my - that's great! Do you plan to support retention of individual pre-gaps for each track, or will they all default to zero or two seconds? I've found most software doesn't keep the individual pre-gap lengths, which is used in the CDDB/Gracenote (and I assume FreeDB) indentification schemes. I even pointed out to the Alcohol 120% makers that their supposed raw copy didn't retain the individual pre-gap lengths, and they acknowledged that as a bug, but later releases didn't seem to rectify it...

Wow, you are way ahead in all the tweaks! OK, I've verified that without a doubt ImgBurn's Calculate WAS looking at the previous write job that was already finalized - I found the log and it's L0 sectors match exactly that in the Calculate section of the log I posted here. However, in finding my log for that previous job, I also discovered why it happened in my normally regimented approach. Read on if you are interested in the details: 1. The previous job was a .ISO/.MDS image file combination. I ALWAYS have ImgBurn set to verify immediately after writing. So in this case the DVD was written in my Pioneer DVR-111L drive, and was then in the middle of verifying in the same drive. 2. The computer locked up during the verification - I think I unplugged my USB scanner accidentally, and this tends to do that for some reason... CTRL-ALT-DEL didn't work, so I had to power down and boot windows back up. 3. After running some chkdsk tests, I moved the burned DVD to my Plextor PX-716A drive, and then opened ImgBurn in Verify mode and verified the DVD in the Plextor drive to the image. This was verified by the fact that my saved log for this prior job only has the verification log in it - I lost the write log when the computer locked up. I closed Imgburn and then followed up with my usual file-by-file verification of the same DVD from the Plextor drive. 4. I closed ImgBurn, and opened it later with a blank in the Pioneer drive, as usual, and I pressed the Calculate button. However, ImgBurn was looking at my Plextor drive (Imgburn is set to default to the most recently used device), which still had the prior job in it, and it looked at that DVD instead of the blank in the Pioneer drive. I now recall realizing this when I went to write and found that the button was greyed out, and I then switched it to the Pioneer drive and pressed write. Viola - different sector estimates for the exact reason you theorized! Since Imgburn doesn't identify the drive looked at when estimating the LB sectors in device mode, the posted log alone was insufficient to help me recall this sequence of events, and prior log having only verification information was the key. You guessed the issue without the benefit of that prior log! (EDIT: Smiley added for LUK! at blutach's suggestion!) Please check your PM about something important! Thanks, fordman

OK, I've verified that your theory would indeed behave as you describe. I inserted an already finalized DL DVD, and then added a new set of files in build mode and pressed the Calculate button. Indeed, it showed padding my selected layer break point out to the exact number of sectors that was in L0 of the already finalized DVD. My usual procedure is burn DVDs in my Pioneer drive, double-click the .ibg in the log to open DVDInfoPro and save the graph to hard drive, then move it to my Plextor drive for file-by-file verification (the Plextor had become unreliable for writing). Then while I'm verifying by creating a .SFV file from the DVD to my hard drive (to be matched with the one I've already created from the mounted image), I begin building the job for the next burn in the Pioneer. So, this procedure would normally preclude such an occurrence, but I cannot swear that I removed the finalized DVD from the Pioneer drive in this instance. However, I will go back and look at the log of the prior write job and see if the L0 sectors in that match the initial estimate (2029184) in the log I posted here. If that matches, then that will be irrefutable proof this is what happened. In that one odd instance where there were initially no valid LB points, it's possible I had a very small burned DVD, like a DivX file or something similar, already in the drive. So, if this proves to be the case, I apologize for setting you on a "wild goose chase." However, perhaps we've at least uncovered an opportunity to add some error checking to make it "idiot proof" (for idiots like me, apparently). For instance, you could have ImgBurn ignore the sectors on a burned DVD in the drive and default to the media profile, or return an error at that point - perhaps something like "Please insert a blank DL disc into the drive, or switch to image ouput before calculating potential layer break points." Even though Imgburn isn't technically doing anything wrong as is, such an error check might make it more intuitive... Stay tuned, when I get home again, I'll sift through my logs to verify that my prior write job was still in the drive... Thanks, fordman

OK, I checked and (without any DVD+DL blank inserted), here's what my profile shows: (* = enabled profile on Media tab) Single Layer: * DVD+R/RW: Maximum Sectors: 2295104 DVD-R/RW: Maximum Sectors: 2298496 DVD-RAM & Custom: Maximum Sectors: 2236704 Double Layer: * DVD+R DL: Min Sectors in L0: 0 / Max Sectors in L0: 2086912 / Media Capacity: 4173824 DVD-R DL & Custom: Min Sectors in L0: 2092896 / Max Sectors in L0: 2092896 / Media Capacity: 4171712 and the ONLY double layer media I ever use is Verbatim MKM-001-00, which Device mode properties match the DVD+R DL profile on the Media tab. What is interesting is this part of the log: D 19:35:45 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 2029184 D 19:35:45 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2029184 D 19:35:45 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2144640 . . . I 19:35:51 Using Layer Break LBA: 2023891 -> 2029184 (....................) If you add the MaxL0 and MaxL1 capacities together it equals 4173824, which matches the Media Capacity for DVD+R DL, which would indicate that profile is active even when no blank has been inserted yet. However, it seems curious that the number for MaxL1 sectors is greater than that for MaxL0 sectors. Doesn't DVD+R DL require that L0 be larger than L1? Also, it appears the Calculate function wants to pad L0 out to the maxmum of 2029184 sectors - why? So, whether a blank is inserted or not, why does Imgburn assume that it must pad L0 out to the maximum? OK, though I can't verify for sure if this was one of the instances where I inserted a blank between the Calculate and Write operations, I do know that I was doing that recently in the past few days. So, it seems that the discrepancy is indeed due to not having a blank inserted first, and I can avoid it by having the blank in from the beginning. However, the question remains why ImgBurn is picking MaxL0 sectors that do not match any profile, and for that matter is providing the same number for the MinL0 capacity, which should be 0....OK, so THAT is why Imgburn wants to pad out to the max - because it believe it is also the min! Hmmmm...so where is Imgburn getting this information from if not from the profile? Of course none of this explains why on that one DVD, the Calculate function provided no usable layer break points, when the DVD was not anywhere near capacity, yet did find them when I wrote the image... I often keeps logs of my write jobs, so I can go back and refer to the MD5 value, so I will try to sift through them to find this odd case, though it was quite some time ago. In the meantime, I'll keep a blank inserted (when in Device mode) before I use the Calculate function! Thanks, fordman

No, I didn't change a thing. Here's what I did, as I typically do: 1. Prepare source files with PGCEdit, use PGCEdit's "Burn DVD/Create ISO" just to see potential layer break positions, set the seamless flag manually in PGCEdit, save the source files (note that I remove the backup directory first), and then exit PGCEdit. I've noted the sector number that PGCEdit calculated at this point, by the way. 2. Open ImgBurn and press F6 to enter debug mode, add the root directory for the DVD to the build job. Note that I usually employ a directory structure such as the following DVD_NAME Burn VIDEO_TS AUDIO_TS So I add the Burn directory as the root of the build job. 3. I set custom dates and labels in the job 4. I then press the calculate icon in Imgburn - it presents me with layer break choices, none of which match that calculated by PGCEdit 5. If I haven't already, I add a blank DVD (usually it's already inserted) 6. I press the Write icon in Imgburn - it presents me with layer break choices, with at least one matching my choice that PGCEdit calculated 7. The burn proceeds and finishes fine! So, as you can see I've done nothing outside of ImgBurn between the calculation and write stage. As I've said, I've encountered this three times in the past months, though by the volume of DVDs I burn, I'd estimate that amounts to less than 5% of the instances. In addition, since the sector calculated by ImgBurn's write mode is correct, the DVD is written correctly with the desired LB. The only time I was thrown off was the one time when ImgBurn stated there were no appropriate layer break positions when I pressed calculate, but as I said when I pressed write, it found potential LB positions, one of which matched what I had chosen/calculated with PGCEdit. What also seems to prove that I'm not changing anything between the "Calculate" and the "Write" is the fact that the sector number at ImgBurn's write stage matches PGCEdit's calculated sector number for the same sector. If I was changing some data between the Calculate and Write stages in Imgburn, you'd expect that the sector number at the Calculate stage would match PGCEdit's, and THEN change when the Write stage started... So, if this is a spurious error with the sector calculations, it is hard to duplicate when it only happens in less than 5% of the instances, and it is of little consequence since it ends up writing correctly. I only mention it in case you wanted to examine possible reasons. You are probably bored since 2.3.2.0 has had little complaints since it was released! :-) Seriously, it looks like you've squashed all or most of the bugs... Any ideas how I can troubleshoot further? Regards, fordman

I've encountered an interesting occurence three times when using ImgBurn in the build mode. I often use Imgburn 2.3.2.0 in build mode to write DVDs from the source files directly to DVD. I add the folder containing the VIDEO_TS and AUDIO_TS directories, and after setting a custom date and a label, I press the calculate icon which presents me with a choice of potential layer break positions. In the vast majority of the cases, the sector number (after padding) corresponding the the selecting layer break point matches that also shown when actually writing the DVD. In addition this number matches that calculated by PGCEdit, though the amount of padding needed to arrive at that sector is always two sectors diffrent between the two programs (I assume due to internal logic differences in the padding calculation). In two instances I've found that the sector number calculated by ImgBurn's calculate function did not match that calculated during the write mode, though the write mode seems to be correct (it matches PGCEdit), so I'm confident that the DVD is being written correctly. In one instance, the calculate function actually advised me that there were NO potential layer break positions, but when I pressed the write button, Imgburn then found potential layer break points, which again matched PGCEdit, and I was able to write the DVD. Is there a logic difference in how this sector is calculated in Imgburn's calculate versus write mode? I thought I'd post this in case there is a possible bug that needs squashing. I've posted the log of the most recent occurrence below (with debug mode on). Summary: calculate produces "Using Layer Break LBA: 2023891 -> 2029184" while write correctly produces "Using Layer Break LBA: 2023891 -> 2023904" for the same exact cell. Any ideas? fordman ----------------------- LOG Follows --------------------------------------------------------------- I 19:35:05 ImgBurn Version 2.3.2.0 started! I 19:35:05 Microsoft Windows XP Home Edition (5.1, Build 2600 : Service Pack 2) I 19:35:05 Total Physical Memory: 2,096,600 KB - Available: 1,495,992 KB W 19:35:05 Drive E:\ (FAT32) does not support single files > 4 GB in size. I 19:35:05 Initialising SPTI... I 19:35:05 Searching for SCSI / ATAPI devices... I 19:35:05 Found 2 DVD-ROMs, 1 DVD±RW and 1 DVD±RW/RAM! W 19:35:11 Program 'Debug Mode' has been Enabled! I 19:35:19 Project Loaded Successfully! I 19:35:44 Operation Started! I 19:35:44 Building Image Tree... I 19:35:45 Checking Directory Depth... I 19:35:45 Calculating Totals... I 19:35:45 Preparing Image... D 19:35:45 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 2029184 D 19:35:45 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2029184 D 19:35:45 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2144640 D 19:35:45 GenerateFileLBA_DVDVideo - MaxCapacity = 4173824 D 19:35:45 GenerateFileLBA_DVDVideo - MaxPadding = 200311 D 19:35:45 GenerateFileLBA_DVDVideo - Start/End LBA Match - File: VTS_01_4.VOB D 19:35:45 Potential Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, Vob/Cell ID: 1/17, Time: 01:01:31, SPLIP Flag: Yes) D 19:35:45 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP Flag: No) D 19:35:45 Useless Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, VIDEO_TS Padding: 241001) - Reason: Cell requires too much padding. D 19:35:45 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, VIDEO_TS Padding: 5293) I 19:35:51 Using Layer Break LBA: 2023891 -> 2029184 (VTS_01, PGC: 1, Chapter: 17, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP: No) I 19:35:51 Checking Path Length... I 19:35:51 Image Size: 8,148,647,936 bytes I 19:35:51 Image Sectors: 3,978,832 I 19:35:51 Operation Successfully Completed! - Duration: 00:00:06 I 19:36:15 Operation Started! I 19:36:15 Building Image Tree... I 19:36:16 Checking Directory Depth... I 19:36:16 Calculating Totals... I 19:36:16 Preparing Image... D 19:36:16 GenerateFileLBA_DVDVideo - MinL0DataZoneCapacity = 1986768 D 19:36:16 GenerateFileLBA_DVDVideo - MaxL0DataZoneCapacity = 2086912 D 19:36:16 GenerateFileLBA_DVDVideo - MaxL1DataZoneCapacity = 2086912 D 19:36:16 GenerateFileLBA_DVDVideo - MaxCapacity = 4173824 D 19:36:16 GenerateFileLBA_DVDVideo - MaxPadding = 200311 D 19:36:16 GenerateFileLBA_DVDVideo - Start/End LBA Match - File: VTS_01_4.VOB D 19:36:16 Potential Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, Vob/Cell ID: 1/17, Time: 01:01:31, SPLIP Flag: Yes) D 19:36:16 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP Flag: No) D 19:36:16 Useless Layer Break Position! - LBA: 1866256 (VTS_01, PGC: 1, Cell: 17, VIDEO_TS Padding: 241001) - Reason: Cell requires too much padding. D 19:36:16 Potential Layer Break Position! - LBA: 2023891 (VTS_01, PGC: 1, Cell: 18, VIDEO_TS Padding: 13) I 19:37:11 Using Layer Break LBA: 2023891 -> 2023904 (VTS_01, PGC: 1, Chapter: 17, Cell: 18, Vob/Cell ID: 1/18, Time: 01:06:32, SPLIP: No) I 19:37:11 Checking Path Length... I 19:37:11 Image Size: 8,137,834,496 bytes I 19:37:11 Image Sectors: 3,973,552 I 19:37:22 Operation Successfully Completed! - Duration: 00:01:06 I 19:37:22 Operation Started! I 19:37:22 Source File: -==/\/[bUILD IMAGE]\/\==- I 19:37:22 Source File Sectors: 3,973,552 (MODE1/2048) I 19:37:22 Source File Size: 8,137,834,496 bytes I 19:37:22 Source File Volume Identifier: DVD I 19:37:22 Source File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER! I 19:37:22 Source File Implementation Identifier: ImgBurn I 19:37:22 Source File File System(s): ISO9660, UDF (1.02) I 19:37:22 Destination Device: [1:0:0] PIONEER DVD-RW DVR-111L 8.29 (H:) (ATA) I 19:37:22 Destination Media Type: DVD+R DL (Disc ID: MKM-001-00) (Speeds: 2.4x, 4x, 6x, 8x) I 19:37:22 Destination Media Sectors: 4,173,824 I 19:37:22 Write Mode: DVD I 19:37:22 Write Type: DAO I 19:37:22 Write Speed: 6x I 19:37:22 Link Size: Auto I 19:37:22 Test Mode: No I 19:37:22 BURN-Proof: Enabled I 19:37:22 Optimal L0 Data Zone Capacity: 2,023,904 I 19:37:22 Optimal L0 Data Zone Method: IFO Cell Boundary, 'SPLIP' Flag Not Set D 19:37:41 Device Buffer Size: 1,605,632 bytes. D 19:37:41 Device Buffer Available: 1,605,632 bytes. I 19:37:41 Filling Buffer... (256 MB) I 19:37:49 Writing LeadIn... I 19:38:00 Writing Image... (LBA: 0 - 3973551) I 19:38:00 Writing Layer 0... (LBA: 0 - 2023903) I 19:46:37 Writing Layer 1... (LBA: 2023904 - 3973551) D 19:54:34 CryptGetHashParam(ImageBuilder, HP_HASHSIZE) - Size: 16 - Length: 4 D 19:54:34 CryptGetHashParam(ImageBuilder, HP_HASHVAL) - Length: 16 I 19:55:07 Synchronising Cache... I 19:55:08 Closing Track... I 19:55:16 Finalising Disc... I 19:56:26 Image MD5: 47f7a8801d0ce2d92e3ac0dd3795e673 I 19:56:26 Exporting Graph Data... I 19:56:26 Graph Data File: C:\Program Files\ImgBurn\PIONEER_DVD-RW_DVR-111L_8.29_9-25-2007_7-37_PM_MKM-001-00_6x_DVD.ibg I 19:56:26 Export Successfully Completed! I 19:56:26 Operation Successfully Completed! - Duration: 00:19:03 I 19:56:26 Average Write Rate: 7,745 KB/s (5.6x) - Maximum Write Rate: 8,690 KB/s (6.3x) I 19:56:26 Cycling Tray before Verify... I 19:56:53 Device Ready! I 19:56:53 Operation Started! I 19:56:53 Source Device: [1:0:0] PIONEER DVD-RW DVR-111L 8.29 (H:) (ATA) I 19:56:53 Source Media Type: DVD+R DL (Book Type: DVD-ROM) (Disc ID: MKM-001-00) (Speeds: 2.4x, 4x, 6x, 8x) I 19:56:53 Image File: -==/\/[bUILD IMAGE]\/\==- I 19:56:53 Image File Sectors: 3,973,552 (MODE1/2048) I 19:56:53 Image File Size: 8,137,834,496 bytes I 19:56:53 Image File Volume Identifier: DVD I 19:56:53 Image File Application Identifier: IMGBURN V2.3.2.0 - THE ULTIMATE IMAGE BURNER! I 19:56:53 Image File Implementation Identifier: ImgBurn I 19:56:53 Image File File System(s): ISO9660, UDF (1.02) I 19:56:54 Verifying Sectors... (LBA: 0 - 3973551) I 19:56:54 Verifying Layer 0... (LBA: 0 - 2023903) I 20:06:16 Verifying Layer 1... (LBA: 2023904 - 3973551) D 20:14:37 CryptGetHashParam(ImageBuilder, HP_HASHSIZE) - Size: 16 - Length: 4 D 20:14:37 CryptGetHashParam(ImageBuilder, HP_HASHVAL) - Length: 16 D 20:15:05 CryptGetHashParam(Device, HP_HASHSIZE) - Size: 16 - Length: 4 D 20:15:05 CryptGetHashParam(Device, HP_HASHVAL) - Length: 16 I 20:15:05 Device MD5: 47f7a8801d0ce2d92e3ac0dd3795e673 I 20:15:05 Image MD5: 47f7a8801d0ce2d92e3ac0dd3795e673 I 20:15:05 Exporting Graph Data... I 20:15:05 Graph Data File: C:\Program Files\ImgBurn\PIONEER_DVD-RW_DVR-111L_8.29_9-25-2007_7-37_PM_MKM-001-00_6x_DVD.ibg I 20:15:05 Export Successfully Completed! I 20:15:05 Operation Successfully Completed! - Duration: 00:18:11 I 20:15:05 Average Verify Rate: 7,284 KB/s (5.3x) - Maximum Verify Rate: 10,450 KB/s (7.5x)

You may also want to check out the CDFreaks optical drive forum at: http://forum.cdfreaks.com/forumdisplay.php?f=61 You can read different opinions on the different brands. fordman

For awhile, it seemed like one in five of my commercial DVDs were PTP, but now maybe only one in ten. I noticed a lot of BBC region 1 DVDs are this way. Luckily I've never encountered one that I couldn't re-master in file mode to make a valid OTP copy.

Probably, but it would be out-of-date and overpriced. It sounds like you live in the U.S. If so, and you want to purchase locally, check out Best Buy if you have one locally, or Circuity City otherwise. Best Buy often has their Pioneer drives on sale, and after owning Plextors, NECs, Lite-Ons, and Pioneers, I must say that Pioneer drives (I have the DVR-111D converted to a DVR-111L) have produced the best and most consistent burns so far. Sony drives are usually re-badges of other drives. I don't think Circuit City has Pioneer, and they mainly carry "3rd party" drives like "Mad Dog." I did purchase an external mad dog there because I knew it was an NEC drive and I wanted to try that once.

I think the .gi format is a "Global Image" from RecordNow Max/Deluxe.

Are the media statistics visible in the right pane of the write window? If not, then your drive is not recognizing the media and therefore the button would not be clickable. If the statistics ARE there, check them to make sure that ImgBurn doesn't see some data already recorded on the disc. A friend was having this issue, and it turned out he had a background UDF formatting program like DirectCD or InCD that was formatting them in the background to use as a random write media. Once this happens on a DVD-R or other write-once media, you cannot ever use it again for ISO burning...

Both the regular debug and the I/O debug at the same time? I'll ask....stay tuned.

I'm posting the subject bug found by my brother. I don't use DVD-RAM, nor do I have any DVD-RAM discs to duplicate this issue, so I'm reporting it as he found it. Note that he experienced this with a new Pioneer drive that otherwise is working fine with DVD-RAM discs in conjunction with other applications. Here's what he reported to me, along with a screen shot: Any ideas? Ford Man

Thanks for the confirmation - I agree that parsing UDF file system specs is not the best use of your time. I'd only be interested in such a function on a few occasions, and for those, I suppose I could just back into a .ZIP or .RAR archive and maintain all attributes, and then burn the archive. Of course that would't provide direct access to the files, but good enought in most cases if there is sufficent temporary space on the hard drive.

OK. I think you mean that in ISO9660 specs for recordable media, there is no way to store the system attribute, but there is for the hidden attribute? Thanks, Ford Man

LIGHTNING UK!, you added the retention of the hidden attribute in response to betaqlity's (and a previous) post. His point was also valid for system file attribute retention also, i.e. if one were doing a direct backup of an operating system folder. It would be equally important to retain the system attribute on the recorded media. Would you consider expanding the retention to the system attribute on the next release? Thanks, Ford Man

This is minor, and perhaps is only a bug if the numeric keypad on standard keyboards was meant to be supported for numeric entry. If one attempts to enter a custom number of sectors or MB in those fields with the number keypad (as opposed to the top row above the letters), the results are unexpected. For instance, using the keypad for these numbers seems to be fine: 0, 1, 3, 5, 6, 7, 8, 9 Meanwhile 4 does nothing, and 2 takes you to the build mode! So, of the 10 digits of the keypad 8 of 10 work as expected, while 2 seem broken.... Is ImgBurn designed to accept data entry from the keypad? Ford Man