fordman

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!

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.

Strange, I didn't seem to see ANY decrease during burning in the performance tab, and definitely not by that much even when the burn started! Hmmm, perhaps it depends on the version of Windows (I'm using XP Home SP2 with all critical updates), and possible differences in memory management?

I actually have version 4.56 installed, and it still has the aformentioned problems. Perhaps he saw the bug reports on cdrinfo.com and is working on them. I was just shocked to see the lack of traffic or acknowledgment of messages there. I guess I'm spoiled by your hands-on and rapid approach, LUK! It seems like it treats external drives just like a virtual image, for which it also doesn't display volume labels in the media info tab (I think other information like implementation id, etc. are also missing). Then again, I wonder if it has something to do with a more limited command set support for USB to ATA and Firewire to ATA chipsets? I seem to recall that at one time DVDD ignored my setting to limit read speed for a drive mounted in an external USB enclosure, but if the same drive was attached directly to the motherboard IDE, it worked fine. The reason I wanted to limite the speed was because I found that my effective max read speed through USB was 10X with that particular enclosure. As I watched it rise to 10X, a read error would occur and DVDD would retry and continue. It seemed like it stuck with 10X the rest of the way. However, even though DVDD successfully retried, I found that it actually affected the output of the ISO file! The CRC32 for that ISO would not match that of the same ISO made when the drive was attached to the MB IDE (for which no read errors occurred). I could reliably reproduce ISOs on a source with the exact same CRC32. But despite the fact that he same drive was being used (transferred internal to USB and back) and the same program settings were used, the ISOs produced by both sources never matched. This is no longer important since it related to DVDD, and because I liked the peace of mind knowing that he ISO was apparently "CLEAN" when attached to MB IDE, I gave up on using an external drive for reading or writing. Now that I'm using an NEC ND-4550A firewire drive (in addition to my internal PX-716A), that no longer seems to be a problem, though. The point is that I wonder if it says something about how fully functional the USB and 1394 to ATA command sets are... Any

Thanks. I did a lot of google searches and just found the cdrinfo site, and apparently nicw, the dvdinfo pro author used to have the dvdrrw.org domain, and lost it? He's optimized code and introduced new problems, like volume label truncation, and missing info on external drives or mounted images. version 4.52 was OK with the full volume labels at least, but I can no longer find a site to get that older beta version.... The current stable 4.36 doesn't work with ImgBurn.....

Does anyone happen to know where the official forum for DVDInfo Pro is these days? I searched and I found indications that it is supposed to be here: http://www.cdrinfo.com/forum/tt.asp?forumid=76 However, the lack of activity and posts seems to indicate this is no longer active. There are bug reports there and nobody is answering anything.... Does the author have a new official forum site on the web? Thanks, fordman

Yes, I think a lot of memory helps, but I don't think you need much to avoid issues. I had avoided using 1.2.0.0 until recently because I saw the bug reports cropping up. Normally I never have an image on the same drive (or even the same IDE channel - I have boot drive on primary IDE, others on Promise Ultra controller), so I doubt that I'd see an underrun from competing with the windows swap file anyway. I happen to current have 1.5GB of DDR RAM on my 2.66 GHz P4 (non-hyper threading) computer. I decided to give 1.2.0.0 a try because I wanted to get the verify curve on the DVDInfo Pro graphs. Anyway, I have NO issues with either the program or device cache emptying on me, and all works fine. I decied to open task manager before and during burning, and it looks like ImgBurn 1.2.0.0 only uses about 12 MB of memory (in the process window) before burning and only about 33 MB during burning. I believe it was about the same with 1.1.0.0. I also switched to the performance tab of task manger during the burn and I don't see any indication that large amounts of physical OR virtual memory are being used to create a cache for the whole image. This is on Windows XP Home SP2. I don't know if that has anything to do with it, but all seems well with 1.2.0.0 for me....no cache issues evident anywhere. What is it supposed to look like in task manager when all the memory disappaears during a burn? Does the available phyisical memory get consumed to leave 0 available as shown in the perofrmance tab? Mine stayed at about 1 GB free during the burn of a 4.3 GB single layer image...

Do you mean "Maxell?"

If you're looking at the .IFO file in IfoEdit, look for the cell in the main title set that has "layer br" next to it. Now look at the cell above it, and look at the cumulative playing time. In playing time terms, the layer break will occur right at that cumulative time figure. I routinely take burned dual layer DVDs to one of my pickier DVDs (when changing layers) to test them out. I jump to a time about 15 seconds before that point and watch what happens when it hits the layer break. If it gets past it, and I can rewind back and it goes past again, I know I got a good layer transition. To answer you question the way you asked it. it's BEFORE the cell that shows the actual flag. Or, another way to think about it is that the cell that shows the flag has the layer break directly before it, which puts the cell showing the flag on the second layer, as LUK stated.

If you're referring to the PxScan utility available here: http://www-user.tu-chemnitz.de/~noe/Plextor/index.php I don't think that progressed past the "threat" level, and the author continued after getting assurances from legal counsel that developing a 3rd party utility for a piece of hardware is not an infringement. Apparently Plextor agreed and instead included "protected commands" in their PX-755 drive (see the linked site)! I do agree that Plextools is great for copying audio CDs, as it correctly reads pre-gap information. I had been using Alcohol 120%, only to discover later that despite it being used in raw mode with reading of subchannels, it set all pre-gaps to 0 seconds - resulting in an inexact copy! I reported that and they acknowledged the problem, though I don't think they ever fixed it.

Thanks for your help. Hee's what the .cue says: FILE "TDA-CPIX.BIN" BINARY TRACK 01 MODE1/2352 INDEX 01 00:00:00 Seems as though it should work, no? Hmmm, yes, that should burn fine since it's only a single track. Take the full size of the BIN image, as shown in the general tab of the file properties dialog (size, NOT size on disk) and divide by 2352 - is it an integer? If, so it is truly an image with a sector size of 2352. If not an integer result, try dividing by 2336 or 2048, if either of those is an integer, then that's the true sector size, though ImgBurn should do this calculation correctly for you since it's not looking at the .CUE file. Can you explore the .BIN file with ISOBuster or other utility and see the disc structure within the image? Someone else posted a similar problem where Nero burned it happily and gave garbage contents and it turned out it had no file system...

Oh, OK. I thought the depletion of memory issue due to 256K chunks beign read from hard drive was universal. I'll give it a shot on a single layer image before trying dual layer. Thanks.

ImgBurn doesn't currently support .cue files, only a single track .BIN file is acceptable. So, if your .CUE sheet shows more than one track (i.e. an audio CD), then ImgBurn will not work, and could possible produce a seemingly "blanK" disc. Use the old CDRWIN, Nero, Alcohol 120% or some of the freeware solutions out there to burn your .CUE/.BIN.

So, considring this issue, and the "burning slowdown" report at http://forum.imgburn.com/index.php?showtopic=936, would you recommend not using 1.2.0.0 and going back to 1.1.0.0? I haven't yet burned with 1.2.0.0, and decided to go back to 1.1.0.0 for the time being.

However, the image files are not identical to begin with. What happens if you burn the exact same image file, from the same location, using each version of ImgBurn? I realize that they are close enough in size, but I wonder if one of the images is somehow corrupted, thereby confusing ImgBurn 1.2.0.0? Though this is extremely unlikely, you'll not know unless you eliminate the image file as a variable....

Your programming is quite brilliant! I must admit I was amazed that you were able to build the modification of files within the ISO image into your program, and so seamlessly and mostly automatically at that. Thanks again for sharing your great utility....

i could not figure out how to do that.....i understand that i need to change the values to disable media change notification but cant figure out how to get there any help is greatly appreciated This looks like something for a software developer to follow. Note at the bottom the requirement to declare it in Winioctl.h. This is an input to a compiler I believe. So, as far as I now, there's nothing you can do to change it in windows following that link. I don't have this problem, but I do have my "auto insert notification" set to off for all my CD and DVD devices. I wonder if that would help you? I sort of doubt it since it's being controlled by ImgBurn anyway.

Thanks to both you and Shamus! I'm a bit of neurotic when it comes to data verification before I erase my source, so it's good to know that ImgBurn is doing a byte for byte verification as default. When my old Plextor PX-716A drive started to fail, I sometimes found that DVD Decrypter would verify the disc (dual layer Verbatim MKM001) and said it was fine, but when I read it back with QuickSFV (or by copying by Windows Explorer), it would freeze on a particular file, complaining that the file could not be read, and I had to let Windows XP close quicksfv or windows explorer down. I took the resulting disc to other computers, other drives and standalone DVD players and verified that there was indeed a problem (usually in the middle of a VOB file located on the second layer) that would prevent it from being read or played correctly. Since DVDD verified the disc and had no read errors, I began to suspect that validity of that information, and that's why I really started to do my manual file verifications. Eventually it was happening on every Verbatim DL disc I burned, and I replaced the drive under warranty. When it got to this point, even DVDD would error out with a read error. In general, I think a byte for byte verification (whether in sector for file mode) is the only sure method. I've had burned discs (even single layer) that read back fine with Quick SFV or by copying back to my hard drive, but the CRCs didn't match the original files. When looking at the surface of the disc, I could observe that there might be a large "unburned" area where a large speck of dust or a defect in the polycarbonate protective layer might have been. Apparently the spot was too large for the error correction to correctly rebuild the data on reading, but it read just fine. For this reason, I also inspect blank discs and set aside ones with obvious physical defects and also use an air duster to blow dust from the surface and also from the drive tray before every burn... Unless, of course, you're parsing the file system looking for a good layer break point and subsequently modifying the IFO and BUP accordingly. Since you do have file system parsing built in, I thought it possible that file by file verification was being done, though I expected it was sector by sector so that the non-user data areas could be checked also. Thanks again, fordman

I saw this in the release notes: How was 1.1.0.0 handling verification? I think I started using ImgBurn at 1.1.0.0, so I didn't experience the 1.0.0.0 behavior. I had assumed that ImgBurn was verifying each byte of the written disc to the source image in a sector-by-sector methodology, which would therefore also ensure that each file matched the source exactly. Did DVDD only verify that sectors could be read? When pressed for time, I was in the habit of sometimes skipping the follow-up file mode verification that I normally do by creating a .SFV file (using QuickSFV) of the written disc and comparing it to a .SFV file made from the mounted image file. I do this because I have encountered instances where the written data CRC did not match the source, despite the fact that the sectors could be read fine. Also, when you state are you referring to the image file, or the individual files withing the image? Thanks - just curious about what I need to set to ensure I get full byte-for-byte error checking. fordman

Ok, simple enough! Thanks.

I noticed that despite that fact that I verify the disc automatically after burning with ImgBurn 1.1.0.0, when I look at the graph info with the DVDInfo Pro integration, the "show verify" option is grayed out and cannot be selected. This is with discs burned both on a NEC ND-4550A and a Plextor PX-716A. Meanwhile, I'm sure I've seen graphs posted that showed the verify curve also. What does one need to do to ensure that the verify curve can be viewed? fordman

Thanks for the recommendation. I do use PGCEdit for preparing video files for burning in file mode, but I have yet to build an ISO with it. Your second sentence confused me a bit. That type of ISO is what began this thread. It was an ISO made by CloneDVD, which had already stripped out the layer break flag, but ImgBurn was able to find an appropriate cell and made the right change on the .IFO, but of course the calculation problem caused other issues. I had PM'ed you about sending a certified check or something because I've head my credit card number used fraudulently twice here in the U.S. Once someone opened a PayPal account with my credit card info, but had all correspondence sent to an e-mail account that I didn't know about. Another time it was a local merchant. Both times, I had to fight to get my money back, and PayPal actually tried to refute/rebutt the chargeback! On the phone they admitted that because of the nature of the product and other circumstances it was an obvious fraudulent transaction, but their credit card department tried getting back the money my bank had charged back anyway! They were going for what they assumed would be the path of least resistance. Each time, it appears that my CC info was used by a dishonest employee at a vendor I do business with, and stores my CC info for recurring monthly charges. So, I refuse to do business with PayPal and I'm reluctant to send my credit card info overseas, figuring it would be even harder to recover a fraudulent charge. I had proposed sending a bank certified check or money order to you via a post office box or other address, and using whatever name or business name you could use to cash it. I really enjoy your utility and it has made my life easier, so I'd hate to not say thanks by making a donation. fordman

After writing that, I realized that ImgBurn also has this ability to enter the number of Layer 0 sectors. However, after burning a few backups and watching the progress windows state where layer 1 was starting, I think I might still have trouble translating the position of the layer break flag in the main VTS title set to the actual physical location on the disc in terms of Layer 0 sectors, so I still need to do more homework on this. Also, I would imagine that entering this manually would only be helpful for those ISOs that have no MDS file, but already DO have a layer break flag in the main VTS. For an ISO with no flag set, it would merely instruct ImgBurn where to physically put the break, but it would not alter that IFO/BUP files to point to it. Is this correct? If so, then the automatically functionality built into ImgBurn to do all this is indispensable... Thanks for the awesome utility - looking forward to 1.2.0.0! By the way, did you ever see my PM concerning a donation? I'd like to send one if you can help me work around the electronic payment means for the reasons I stated...

OK, Lightning UK! I have verified by looking at both versions of the subject DVD (burned ISO with ImgBurn 1.1.0.0 and burned files with RecordNow Deluxe 7.3), that both match your example calculation above using the MOD of the LBA divided by 16. Yes, the VTS set did start at a different point on the RecordNow version, so that's why it chose a different layer break point. My mistake was in thinking that the start sector addresses listed in the VTS_C_ADT were physical LBAs on the disc, instead of the offsets from the beginning of the VTS that they actually are. That's why I thought I could just divide the start sector (+1) for a cell by 16 to see if it was evenly divisible to aid in finding an appropriate cell for the layer break flag. This misconception is also why I thought I had seen actual original master DVDs written the same way. So, all is right with the DVD burning world - ImgBurn's algorithm for choosing the flag is correct, and so is RecordNow Deluxe's! Thanks for the layer break education. I would now know enough to go back and manually set a layer break with the DVDD utility - before this, I was clueless on how to set an appropriate one, so I used to burn ISOs without MDS files blindly with DVDD before I realized I was not ensured of getting an appropriate layer break to corresponding to a flag. That's when I began just extracting the files and using RecordNow. Once ImgBurn is fixed to take care of the math overflow problem, I expect ImgBurn will be making perfect copies with appropriate layer breaks from these ISOs! Thanks again, fordman

Yes, I burned the raw files with RecordNow Deluxe, not the ISO image. To be exact, I re-extracted the original ISO image (deleted the one modified by ImgBurn) and mounted that in a Alcohol 120% virtual drive, and added the "raw VIDEO_TS files" directly from the virtual drive. Since RecordNow does not need ot modify the original files, this works quite nicely without the unnecessary step of extracting the files from the ISO. So, perhaps you are correct that it padded the burned disc to make it's selection of cell 23 valid. I'll attempt to verify it by the method you suggest. I also need to refer to the DVD-VIDEO specs and get smarter on that. You are way over my head on some of the things you are referring to. In particular, I need to check try to recall some of my math courses for notation like (mod), which I think means the remainder from an integer division... Thanks again - it looks like your algorithm for choosing the cell for the flag is correct and compliant, and we managed to catch a math error for this type (ISO without flag nor .MDS) of image. I will try to verify that RecordNow is correctly padding to be compliant!