Jump to content

AlbertEinstein

Members
  • Content count

    50
  • Joined

  • Last visited

Everything posted by AlbertEinstein

  1. The "Disk Layout Editor" shows the incorrect ICONs for the related files. For example, I have mostly .ISO image files in a project and their corresponding .SHA1 files. The .ISO files show a Steam ICON and the .SHA1 files show a "Sims 2" ICON. Both of these are related to gaming. I'm not sure if that matters or it's just by coincidence. Also, more generally, I am wondering if a new version of ImgBurn would be released anytime in the near future that fixes some persistent bugs like these. It looks like it's been 5 years since the last release. It seems like an awfully long time to go to between releases. Features aside, there has to be more than a few bugs that could be done away with in a new maintenance release. Thanks for reading! ***EDIT***: I did exit out of ImgBurn all together. Then I re-launched ImgBurn and reloaded my "Most Recent Project". This fixed the improper ICON associations for the time being. So, this must be something that happens dynamically when certain steps are taken in alignment with the stars.
  2. I am too. I didn't think it would "really" work. The disc becomes unreadable at about 75% through the ImgBurn process. So, your software is imaging fine for a long time until it starts getting near the outer edges of the disc. Then, it just becomes a nightmare. But on the other hand, since I know that standard DVD players just ignore read errors so you can enjoy your movie even with scratches, it does make sense in a way. Maybe my burner is special in that it behaves the same way using the File Explorer. Or maybe the credit is all due to File Explorer by ignoring the read errors in a different way.
  3. I've tried several times to rip an image of a standard DVD movie disc to my hard disk drive. In "Settings->Read" I've set: Read Errors->Software Retries to 0, (checked) Hardware Retires: to 0, and (checked) Ignore Read Errors. Still, the software seems to engage in retries anyway. Is there a fast easy way to rip a standard DVD movie disc with the ImgBurn software that doesn't take hours wasting time on retries? The funny part is, I've watched the movie with the scratches and one can never even detect it's not a perfect copy as the DVD players handle the errors/scratches without a single hiccup. I wish the imaging process was the same. Take what's good and skip the bad, fast as you can. After so many minutes of optical disc drive grinding I just abort the operation. Any tips for me?
  4. I'll try it, thanks. EDIT: Wow, it worked. You are a genius. Thank You!!! It's a bit mind-boggling how easy the work-around was. My method was killing off my optical drive faster than I wanted too. It's already old enough. No reason for me to kill it on purpose.
  5. I had just started burning a new project onto a single-sided 25GB BD-R disc. The next to last log message in the "live" log window was "Filling Buffer ... (80 MiB)" followed by "Failed to open file: XXX". The software paused and I know why it couldn't find the file. I moved it into a sub-folder on my hard drive at the last minute like I do sometimes and forget to move it in your disc layout editor so that it was valid. This caused the error. I thought it would be safe to simply cancel the entire operation and start over versus seeing more of these errors if I had moved any other files into different folders. So, I cancelled the first burn. But on my second attempt to burn the project to the same disc I got even more bad news: I thought for sure that cancelling a burn during the buffer filling stage would not permanently damage the BD-R since not even the lead-in had been written from what I can tell. The writing lead-in occurs right after the filling buffer step, so why is my BD-R disc permanently damaged? Is it possible the BD-R disc was bad already and I just didn't realize it? Or does your software verify the BD-R media is good from the very beginning?
  6. Alas, after another reboot, my LG burner lives on. I think it was just playing dead so I would let it live out the rest of it's days in peace. I've put it back to work and it's approximately half way through another successful burn (fingers crossed).
  7. Good question, maybe it's the same reason Intel and AMD sell overclockable processors. They sell them guaranteed to work at a rated speed but if you are an enthusiast and want to try your hand at faster speeds you can (on the overclockable models, that is). In other words, as a producer of goods, you always want to under promise and over deliver, versus over promising and under delivering. That's the absolute worst thing you can do. But like you I'm just not sure whether those media descriptors are created on the fly by the drive itself or they are already pre-written to the media. Maybe somebody else can clear this up for us. **EDIT**: I think your absolutely right though. Those media descriptors appear to be for the hardware itself and not the media.
  8. I was just curious if the drive was able to write faster than the rated speed of the media because it's an extra special drive or because there were faster media descriptors on the media already, but it's no big deal.
  9. I just tried writing to this virgin BD-R (referenced in above post) and the software/system/burner froze up at the "Reserving Track" step. I waiting for about 5 minutes to see if anything changed (it never did) and then unplugged my SATA power cable from the physical BD-R burner so that ImgBurn didn't try to do something that permanently damages this disc also. I closed ImgBurn (well actually had to kill the process), reconnected the SATA power cable to the BD-R burner, rebooted Windows 10 and now the drive is not even recognized by the system. This burner is going on 9 years old now (purchased at the end of 2010), IIRC. "It's dead Jim!"?
  10. But that's what I'm asking. Your saying that your Verbatim BD-R rated at 6X on the label (or physical media surface) can be burned at 12x on your Pioneer drive. Have you used ImgBurn to see the highest rated burn speed per the actual descriptors on the media itself and not just the packaging or physical media surface print? Or are you saying that the burner's firmware can write faster than the fastest rated descriptors pre-written on the media if it wants too?
  11. But the real question is do those Verbatim media have media descriptors for those faster speeds? I'm assuming that no matter what the burner brand is it has to have a media descriptor. I'm guessing this is something along the lines of the manufacturer guaranteeing a minimum safe burn speed on the label but having extra descriptors for those who have a capable burner? Or are just adventurous.
  12. Is there missing data still? This data is for a brand new Optical Quantum 25GB BD-R I just pulled off a newly opened spindle of 25 discs. #2 off the stack. I bought this spindle over a year (or more) ago. It's interesting to me that the label that hugs the spindle says these are for "1-4x SPEED" but there's a couple of descriptors above showing that it will burn at 6x and 8x also. You gotta love a producer that under promises and over delivers.
  13. I just burned a new BD-R disc using file system UDF 2.50. I set the volume label at about 40 characters. The only software that seems to recognize all 40 characters is ImgBurn itself. Windows 10 File Explorer and diskmgmt.msc only recognizes the first 32 characters. The 3rd party file explorer "Explorer++" also only recognizes the first 32 characters of my label. While it's nice to be able to use 64 characters in a volume label, it's not idea if only 1 software program can read all 64 characters. Can somebody please explain what's going on here? It looks like the UDF 2.50 standard, in section 2.2.2, limits the VolumeIdentifier to a dstring of 32 characters: dstring VolumeIdentifier[32]; So, why does ImgBurn allow me to use 64 characters for a volume label?
  14. Yep, I'm not sure why. I tried UDF 2.50 and 2.60 both. Here's a screenshot: On the other hand, "Volume Set" allows 128 characters. But that's distinct from "Volume Label". **EDIT**: I figured it out. If you disable Unicode support under the "Advanced" tab then you can get 128 characters for the "Volume Label". Unicode takes 2 bytes per character. Problem solved!
  15. @dbminter, I just write my folders and files to disc on the fly most of the time since it saves ... time. But, one thing I do know, from my experience with burning BD-R using ImgBurn, is that I could have simply continued the burning process by skipping the file that was not found. Or, I could have moved the missing file back into the original folder that it was in when it was added to the disc layout editor, and ImgBurn, would have resumed burning the disc without issues. I've done this before and was very pleased at the flexibility of such a scheme. Being able to fix authoring errors mid-burn is a wonderful ability. Two thumbs up for that. I wish I would have just tried putting the files back where they were to begin with. Instead, I tried stopping the burn all together. I probably won't do that next time given this bad experience. EDIT: But just to answer your question and to re-iterate what I said before, the live log window said filling buffer when I cancelled the burn. It never specifically stated that it had begun (or finished) writing a lead-in and I know that has to be done first thing in the burn-process, does it not? When I say 'done first thing' I mean literally altering the physical media.
  16. I went back through my "ImgBurn.log" text file and checked all of the "Destination Media Type: BD-R" entries in the log file. Some of them have just the 'BD-R' description while others have the actual manufacturer's name in parentheses. For example, "Destination Media Type: BD-R (Disc ID: RITEK-BR2-000)". I had to go back about 13 entries in my log file before I came across the 'RITEK' entry. I didn't see a correlation between having more specific data on the Disc ID and being a successful burn. In other words, the last successful burn I just did described the disc only as "BD-R". It was an Optical Quantum branded disc. The failed one came with an inkjet printer label on top, so I know that it came from my stack of these Ri-DATA: https://www.newegg.com/Product/Product.aspx?Item=N82E16817132086
  17. I don't even know what a DID is so... ... I couldn't tell you. My burner has been disconnected for a few days and this "assumed" blank BD-R was already in it. Maybe it was a failed burn from when I last tried to use the burner and I just never took it out and marked it as bad. Hence, my question about whether ImgBurn actually verifies the media is good from the start! I thought the software would verify good media as one of it's first steps. Maybe it verifies some meta-data that gives the impression it's good.
  18. This is the 2nd failed burn log file: My 3rd attempt using a brand new virgin BD-R disc was successful.
  19. This software is one of the best for burning optical media. I've always liked it. But I have to ask the question. The last official version was released almost 5 years ago. Will it ever be updated to address bugs or add features? A feature request I would like to see is something along the lines of statistics. Like showing how many of the last burns were successful and without issue. And the media brand used could be added as well. "21 of the last 25 burns were successful. Media used: 8x - RiData, 15x - Verbatim, 2x - Optical Quantumm". "4 of the last failed burned were for the following reasons: 2x - Program Memory Area Update Failure, 2x - Whatever and Whatever". EDIT: Now that I think about it though, if ImgBurn doesn't flush the log output window data to text log files on a failure this won't work. I can figure out all this myself so it's not a big deal but I just thought I would throw it out there. Over the lifetime of my BD-R burns (probably around 100 now) the majority have been pretty successful. I hate it when one fails!
  20. AlbertEinstein

    The ' Program Memory Area Update Failure ' Thread!

    First post in 2008, last post before mine in 2012. So, I'm gonna bump it again. I just got the same type of error message today. And in my personal opinion this has: absolutely nothing to do with bad media. It is just my opinion, however, based upon the ratio of good burns to bad burns I get with most of the media (RiData) and the burner I use them with (LG-WH10LS30). This has to be one of the most disappointing errors to ever receive. The entire disc was burned successfully, brimming with 25+ GB of data. The only thing that failed is the closing process. Or, at least that's my perception of things. So, I have 25+ GB of data but a "ghost" TOC. Wonderful. Now, I'm learning something brand new from just reading this 10 year old thread (thank God the Internet is forever). Even though burn failures do not always (ever?) produce textual data in .log file, there is always the fall back to the actual output window itself, as shown by laurik in the screenshot above. I questioned/complained about this many times and no one ever thought to mention capturing the actual log window??? Anyhow, Here's a screen capture of the error message window and my log output window: Okay, The website keeps saying, "You are not allowed to use that image exension on this community." ???? It's a simple .png file extension. Are we erroneously detecting profanity in imgur's randonmly generated URLs?? I'll tinker with this but the link is there. I just can't show it inline with the post. https://imgur.com/wrPVBHq The first error message (before the burn) was followed up with a successful finish on retry #1 of 20. The failed attempts after the burn only tried 8x...why not 20? Were all attempts after 3 on my command? I can't remember but that would answer my question if so. The last 3 or 4 burns (from the same media spindle, 25-pack) I've done were without issues.
  21. AlbertEinstein

    Windows 10 "Chokes" on UDF 2.50 Labels...maybe?

    Well, that sounds like a bug to me. I just finished burning another BD-R disc and Windows 10 immediately recognized both 1)the UDF volume label in the Windows File Explorer and 2) the file system as being "UDF" in the properties dialog box of the BD-R drive. I used UDF 1.02 this time instead of UDF version 2.50. So, I would personally phrase Windows 10 support of all UDF file systems versions as less than perfect. Rebooting to see a volume label after each burn is not something I want to do. Especially, since 1) your software has no problem with UDF 2.50 labels nor does 2) diskmgmt.msc. 100's of programmers working on different applications on Windows 10 so this isn't a big deal for me. There are lots of easy work arounds. I guess the title of my thread should have been, more concisely, "Windows 10 File Explorer Chokes on UDF 2.50 Labels!".
  22. Hi, I just successfully burned a BD-R 25GB disc with your software. After the burn was finished I went to look at the BD-R label in the Windows 10 File Explorer and it wasn't showing. So, I went back to your program and into "Read" mode to see if it could read the label without any issues and it did. I'm not sure what's up with Windows File Explorer choking on the display of labels. Maybe it's the version of the UDF file systems that I'm using? I closed and reopened File Explorer. That didn't fix the label not being displayed. Maybe a restart of Windows 10 will fix the issue? I can explore the disc just fine though. ***EDIT***: On a more positive note, I just launched diskmgmt.msc and it does successfully show the label in that software package. So, by my observations, File Explorer sucks, that's all it is. ***EDIT***: I just checked the properties of my optical device in File Explorer again. It shows the "File System" as: "Unknown". I put all 3 file systems on the BD-R. I think it's okay with reading UDF 1.02 but not UDF 2.50. I'm gonna back away from using 2.50 and just use UDF 1.02 on my next burn since I don't see much benefit for me personally anyways.
  23. @dbminter, It's all pretty complicated. I guess experience is the best teacher. I just burned another disc moments ago on the same burner and media I've been using. But this time I explicitly capped the burn rate at 4x in ImgBurns "Write Speed" settings. And I got a 100% successful burn. Knock on wood. The "Write Speed" might be what was causing the problem but it may have also been that some other 3rd party software on my PC was putting "Read Locks" on files that I had selected for burning in my project. I was using "MediaInfo" to pull up metadata on .MKV files that I was throwing into the project just because I could. I don't know for sure. I'll keep burning at 4x I guess unless I start having more failures. That's what the media were rated for anyway. I guess I just got lucky with the earlier burns.
  24. Since you cannot get log files when the software doesn't complete a burn successfully I've resorted to screen captures. Here they are: Of course, the software is not able to successfully close the disc and the infinite grinding loop continues until I reboot the PC. As far as I can tell there are no errors on the disc itself. I've taken the liberty of writing .sha-1 hash files for all of the biggest files burned so I will check those. While this looks pretty bad and it's no fun having to jump through all the hoops by "attempting" to close the session and actually having to reboot the PC, the burn still seems to be okay. I left about 1 megabyte of free space on the BD-R in the project editor window. So, I am filling these discs to capacity. I think there may be an issue somewhere in that regard. Maybe the discs I'm using are about 200 sectors shy of meeting the official BD-R requirements? To fill my discs full, I am burning some small files in the name of redundancy. How can I control what folders/files would literally be burned near the end of the discs where this type of failure is most likely to occur? I want to engage in this practice. Okay, I just tested a small video file near the end of the disc. It does appear to be messed up near the end of the video. So, it looks like the files are written to disc in the order of the actual folder/file structure used to master the disc. No worries. 99% good, I'll burn the bad file to another disc. Still, what's causing this? DVDInfoPro thinks the disc is only half full:
  25. I thought the File Systems and the TOC were the same thing. Thank you for the clarification on that.
×