Jump to content

fordman

Members
  • Content Count

    184
  • Joined

  • Last visited

Everything posted by fordman

  1. fordman

    Constant Buffer Underruns with 1.2.0.0

    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? Maybe so, I am wondering what amount of RAM you have? I have 1.5 GB of RAM currently on a Medion (MSI motherboard) computer with a non-hyperthreading 2.66 Ghz P4.
  2. fordman

    Unable to burn MDS/MDF file

    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!
  3. fordman

    Unable to burn MDS/MDF file

    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.
  4. fordman

    Constant Buffer Underruns with 1.2.0.0

    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?
  5. fordman

    Official Forum for DVDInfo Pro?

    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
  6. fordman

    Official Forum for DVDInfo Pro?

    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.....
  7. fordman

    Constant Buffer Underruns with 1.2.0.0

    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...
  8. fordman

    skips, jumps and pauses during playback

    Do you mean "Maxell?"
  9. fordman

    Layer break Question

    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.
  10. 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.
  11. fordman

    Burning .bin with .cue?

    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...
  12. fordman

    Possible RAM-Leak with 1.2.0.0?

    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.
  13. fordman

    Burning .bin with .cue?

    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.
  14. fordman

    Possible RAM-Leak with 1.2.0.0?

    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.
  15. fordman

    Burning slowdown

    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....
  16. fordman

    Clarification of 1.2.0.0 verify behavior

    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....
  17. 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
  18. fordman

    error message of sorts at startup

    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.
  19. fordman

    Clarification of 1.2.0.0 verify behavior

    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
  20. fordman

    "Show Verify" in DVDInfo Pro doesn't work

    Ok, simple enough! Thanks.
  21. 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
  22. I finally burned my first dual layer ISO file that didn't have a .MDS file associated. The image was created by CloneDVD. I used the ISO tool to see what were acceptable layer break points and ImgBurn only indicated that cell 25 was acceptable, though the previous cell would have been preferable for me, as that was the beginning of a scene change with fade out. Cell 25 was during a scene. Judging from the final burned disc which put 57.72% of the sectors in layer 0 (42.28%) and the short time between chapters (avg 5 minutes) it should have been possible to put the flag on cell 24. However, ImgBurn modified the ISO file to insert the flag in the VTS_01_0.IFO and burned fine, and compared fine, so that is not the bug. The bug is that ImgBurn did not make the same change in VTS_01_0.BUP, which is supposed to be indentical to VTS_01_0.IFO and used in case VTS_01_0.IFO cannot be read for some reason. I recommend that this change be implemented in future releases. I was alerted to this difference by creating CRCs of the files on the original image mounted as a drive and also for the modified image mounted as a drive. By doing this, I found that the CRCs of TWO files differed between the original and modified images: VTS_01_0.IFO (as desired with the flag inserted, but VTS_01_0.BUP remained the same as original) AND VTS_01_3.VOB Now, why did ImgBurn modify the VTS_01_3.VOB file? The video where the layer break flag corresponds to is actually contained within VTS_01_4.VOB, but even then there is no need to modify a VOB at all when setting a layer break flag - correct? Here is the file compare log between the .SFV CRC files for both images: ***** Files_Image_Orig.sfv VTS_01_0.BUP 2A4C6EE0 VTS_01_0.IFO 2A4C6EE0 VTS_01_0.VOB C7EBDAE0 ***** FILES_IMAGE.SFV VTS_01_0.BUP 2A4C6EE0 VTS_01_0.IFO B7667004 VTS_01_0.VOB C7EBDAE0 ***** ***** Files_Image_Orig.sfv VTS_01_2.VOB 145425D8 VTS_01_3.VOB 0EB4222A VTS_01_4.VOB ABF4D22F ***** FILES_IMAGE.SFV VTS_01_2.VOB 145425D8 VTS_01_3.VOB C62DF9EB VTS_01_4.VOB ABF4D22F ***** So, is ImgBurn actually corrupting my video files when it modifies the .ISO image? I've attached zip files with the IFO and BUP files from both the original and modified images. However I cannot of course include the VOB file, though I would be curious to find out what change was made to it... Thanks, fordman EDIT: I did some more research and found the the ImgBurn modified ISO had changed the VTS_01_3.VOB quite dramatically! Beginning at address 08E15000 the VTS_01_03.VOB had large sequences of bytes changed - mostly from actually values to 00 (null)! This is not good, so I will likely extract the ISO files and burn with a program like RecordNow Deluxe 7.3 to ensure I have an uncorrupted copy. For example, here is an example of one such range, and I even truncated this one for brevity's sake (The first column is the hex address, the second is the byte value in the original VOB at the address, and the third column is the ImgBurn modified value): 08E16814: 81 00 08E16815: 00 01 08E16817: 0B 2D 08E16818: 30 00 08E16819: E0 01 08E1681A: 33 00 08E1681B: 8C 2E 08E1681C: 1F 00 08E1681D: 20 01 08E1681E: 69 00 08E1681F: 2B 2F 08E16820: 23 00 08E16821: 16 00 08E16822: DC 00 08E16823: 09 00 08E16824: 27 00 08E16825: EC 00 08E16826: AE 00 08E16827: 07 00 08E16828: 55 00 08E16829: 62 00 08E1682A: 33 00 08E1682B: 37 00 08E1682C: 56 00 08E1682D: 4E 00 08E1682E: 51 00 08E1682F: FC 00 08E16830: 3C 00 08E16831: 79 00 08E16832: CD 00 08E16833: 06 00 08E16834: E6 00 08E16835: 0D 00 08E16836: 42 00 08E16837: 5F 00 08E16838: 67 00 08E16839: 5A 00 08E1683A: BE 00 08E1683B: 55 00 08E1683C: 9F 00 08E1683D: 5D 00 08E1683E: 41 00 ModdedImage_VTS.zip OrigImage_VTS.zip
  23. fordman

    Bug with Layer Break Flag setting on ISO burns

    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
  24. fordman

    Bug with Layer Break Flag setting on ISO burns

    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...
  25. fordman

    Bug with Layer Break Flag setting on ISO burns

    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
×

Important Information

By using this site, you agree to our Terms of Use.