
AlbertEinstein
Members-
Posts
84 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Everything posted by AlbertEinstein
-
This whole project is a bit unusual. Last release over 10 years ago. I think there was a time when the thought of abandonment was in the head of the developer. I understand having to work for a living as I do also. But 2 year beta releases? How many beta testers does this project have now? And why wouldn't more beta testers be a good thing? I walk a fine line myself between walking away from optical media or not. I still think it's superior to the life of a 1 TB flash SSD but that's only because I have CD-R that have lasted over 20 years. That's some reliable shiaught!!!! So, I figure my BD-R will last that long as well. Seriously, let me get in on this deal. I am actively burning the software and have used it for years.
-
Can I become a beta tester so that I can get the latest features? As long as my media aren't turned into coasters I can deal with bugs. And I try to master at least 1 BD-R a month. To back up data that I need to backup, not just for kicks and giggles. It's time consuming, trying to categorize what you want to burn and then doing it.
-
This was one of the best optical media mastering programs of it's time. It's a shame it appears to have been abandoned. I am here today after discovering yet another bug. I consider it a bug because there is no warning about what the user is about to do. And you see this in other area's of the software asking, "Are you sure you want to do that?". I've discovered that, if you start a project by allowing Unicode support in the volume labels, entering in X number of Unicode characters into the label field. And then haphazardly going back to disable Unicode support in the labels, the ImgBurn software will not warn you that the final master will not be what you intended it to be? How did this situation arise to begin with? I'll tell you. It happens when you eagerly start a label with Unicode characters but quickly realizing that you're volume label needs more than 66 (or whatever the max is) Unicode characters. So, this happened to me. I started my label with a few smiley faces for XXXXs and giggles. But then realized I needed more than 64 characters to describe all the data on the disc. I checked the "Disable Unicode support" box to double the volume label width and BOOM, no warning, no prompt, no erasure of the volume label to protect the user. But this is just one gripe in a sea of many. What is the state of this software? If the author wants money to sell the rights, let us know. Open source this software if there's no interest in it anymore. Something, tell us something. This software is too good to just let it simply languish to death. Case in point. Coincidentally on the same burn, there were several missing files that should have been where they were when they were added to the folder/file list but weren't. The software paused 5x so that I could add the missing files and I finished the burn without any issue whatsoever. That is amazing. Let's keep this goodness going.
-
I'm still using this software in spite of the few bugs it has. One of them I discovered recently has to do with when the log get's updated. It appears to only happen upon exiting the software. Which means, if you keep the software open over several days (which I do) and you perform several burn procedures over those several days (which I have) the log will not be as accurate as it should be. I'd like to see this software updated, in spite of it's age, and it's dwindling utility in the world today. Shunned by some but, no means, by all.
-
I burned a new BD-R recently using Unicode characters with smiley faces. Okay, cool. But Microsoft's crappy File Explorer still only shows 32 characters. I submitted feedback telling them to update their crapware to support the 63/126 characters as stated in the OSTA UDF standard. But I couldn't pinpoint the exact section and field structure that verifies this. Can someone point that out to me? It just bugs me that the ImgBurn software is about the only optical media software to support this properly. Yes, optical media is old, and less common, but I still think it's "dope" and I still use it. For awhile anyways. I hope they fix this someday soon!
-
I'll give a shot. My theory is that because this is such a great freeware burning solution that someone (I don't know who, ;)) is soliciting or waiting for offers and releasing a newer version of the software would impact the value of those offers. I know I wouldn't pay for a software package that was 2 days newer than the last free version versus a software package that was updated 5+ years ago. That's my theory. I could be wrong.
-
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.
-
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.
-
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?
-
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.
-
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!"?
-
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?
-
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.
-
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.
-
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!
-
@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.
-
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?
-
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
-
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.